File:  [NetBSD Developer Wiki] / wikisrc / guide / net-services.mdwn
Revision 1.2: download - view: text, annotated - select for diffs
Sun Mar 10 10:21:40 2013 UTC (8 years, 8 months ago) by jdf
Branches: MAIN
CVS tags: HEAD

    1: # Network services
    3: ## The Network File System (NFS)
    5: Now that the network is working it is possible to share files and directories
    6: over the network using the Network File System (NFS). From the point of view of
    7: file sharing, the computer which gives access to its files and directories is
    8: called the *server*, and the computer using these files and directories is the
    9: *client*. A computer can be client and server at the same time.
   11:  * A kernel must be compiled with the appropriate options for the client and the
   12:    server (the options are easy to find in the kernel configuration file. See
   13:    [[A walk through the kernel configuration|guide/net-practice#kernel-options]]
   14:    for more information on NFS related kernel options.
   16:  * The server must enable the rpcbind, mountd lockd statd and `nfs_server`
   17:    daemons in `/etc/rc.conf`:
   19:        rpcbind=yes
   20:        mountd=yes
   21:        nfs_server=yes
   22:        lockd=yes
   23:        statd=yes
   25:  * The client must enable the rpcbind, lockd statd and `nfs_client` daemons in
   26:    `/etc/rc.conf`:
   28:        rpcbind=yes
   29:        nfs_client=yes
   30:        lockd=yes
   31:        statd=yes
   33:  * The server must list the exported directories in `/etc/exports` and then run
   34:    the command `kill -HUP \`cat /var/run/` (`hup mountd` may work
   35:    too!).
   38: A client host can access a remote directory through NFS if:
   40:  * The server host exports the directory to the client. The list of filesystems
   41:    a NFS server exports can be checked with the `showmount -e` command, see
   42:    [showmount(8)](
   44:         # showmount -e
   45:         Exports list on
   46:         /home                              host1 host2 host3
   48:  * The client host mounts the remote directory with the command `mount
   49: /home`
   51: The [mount(8)](
   52: command has a rich set of options for remote directories which are not very
   53: intuitive (to say the least).
   55: ### NFS setup example
   57: The scenario described here is the following: five client machines (*cli1*, ...,
   58: *cli5*) share some directories on a server (**). Some of the
   59: directories exported by the server are reserved for a specific client, the other
   60: directories are common for all client machines. All the clients boot from the
   61: server and must mount the directories.
   63: The directories exported from the server are:
   65:  * `/export/cli?/root` -- the five root directories for the five client
   66:    machines. Each client has its own root directory.
   67:  * `/export/cli?/swap` -- Five swap directories for the five swap machines.
   68:  * `/export/common/usr` -- `/usr` directory; common for all client hosts.
   69:  * `/usr/src` -- Common `/usr/src` directory for all client machines.
   71: The following file systems exist on the server
   73:     /dev/ra0a on /
   74:     /dev/ra0f on /usr
   75:     /dev/ra1a on /usr/src
   76:     /dev/ra2a on /export
   78: Each client needs the following file systems
   80:     buzz:/export/cli?/root   on /
   81:     buzz:/export/common/usr  on /usr
   82:     buzz:/usr/src            on /usr/src
   84: The server configuration is the following:
   86:     # /etc/exports
   87:     /usr/src  -network -mask
   88:     /export   -alldirs -maproot=root -network -mask
   90: On the client machines `/etc/fstab` contains:
   92:     buzz:/export/cliX/root  /        nfs rw
   93:     buzz:/export/common/usr /usr     nfs ro,nodev,nosuid
   94:     buzz:/usr/src           /usr/src nfs rw,nodev,nosuid
   96: Each client machine has its number substituted to the `X` character in the first
   97: line of the previous example.
   99: ### Setting up NFS automounting for `/net` with
  100: [amd(8)](
  102: #### Introduction
  104: The problem with NFS (and other) mounts is, that you usually have to be root to
  105: make them, which can be rather inconvenient for users. Using
  106: [amd(8)]( you can
  107: set up a certain directory (Commonly `/net`), under which one can make any
  108: NFS-mount as a normal user, as long as the filesystem about to be accessed is
  109: actually exported by the NFS server.
  111: To check if a certain server exports a filesystem, and which ones, use the
  112: `showmount`-command with the `-e` (export) switch:
  114:     $ showmount -e
  115:     Exports list on
  116:     /export/home             
  117:     /export/local            
  118:     /export/adm/log          
  119:     /usr                     
  120:     /                        
  121:     /archive                           Everyone
  123: If you then want to mount a directory to access anything below it (for example
  124: `/archive/systems/unix/NetBSD`), just change into that directory:
  126:     $ cd /net/
  128: The filesystem will be mounted (by amd), and you can a access any files just
  129: as if the directory was mounted by the superuser of your system.
  131: #### Actual setup
  133: You can set up such a `/net` directory with the following steps (including basic
  134: amd configuration):
  136:  1. in `/etc/rc.conf`, set the following variable:
  138:         amd=yes
  140:  2. `mkdir /amd`
  142:  3. `mkdir /net`
  144:  4. Taking `/usr/share/examples/amd/amd.conf`, put the following into
  145:     `/etc/amd.conf`:
  147:         [ /net ]
  148:         map_name =              /etc/amd/net
  149:         map_type =              file
  151:  5. Taking `/usr/share/examples/amd/net` as example, put the following into
  152:     `/etc/amd/net`:
  154:         /defaults       type:=host;rhost:=${key};fs:=${autodir}/${rhost}/root
  155:         *             host==${key};type:=link;fs:=/                           \
  156:                       host!=${key};opts:=ro,soft,intr,nodev,nosuid,noconn
  158:  6. Reboot, or (re)start amd by hand:
  160:         # sh /etc/rc.d/amd restart
  163: ## The Network Time Protocol (NTP)
  165: It is not unusual to find that the system clock is wrong, often by several
  166: minutes: for some strange reason it seems that computer clocks are not very
  167: accurate. The problem gets worse if you administer many networked hosts: keeping
  168: the clocks in sync can easily become a nightmare. To solve this problem, the NTP
  169: protocol (version 3) comes to our aid: this protocol can be used to synchronize
  170: the clocks of a network of workstations using one or more NTP servers.
  172: Thanks to the NTP protocol it is possible to adjust the clock of a single
  173: workstation but also to synchronize an entire network. The NTP protocol is quite
  174: complex, defining a hierarchical master-slave structure of servers divided in
  175: strata: the top of the hierarchy is occupied by stratum 1 servers, connected to
  176: an external clock (ex. a radio clock) to guarantee a high level of accuracy.
  177: Underneath, stratum 2 servers synchronize their clocks with stratum 1, and so
  178: on. The accuracy decreases as we proceed towards lower levels. This hierarchical
  179: structure avoids the congestion which could be caused by having all hosts refer
  180: to the same (few) stratum 1 servers. If, for example, you want to synchronize a
  181: network, you don't connect all the hosts to the same public stratum 1 server.
  182: Instead, you create a local server which connects to the main server and the
  183: remaining hosts synchronize their clocks with the local server.
  185: Fortunately, to use the NTP tools you don't need to understand the details of
  186: the protocol and of its implementation (if you are interested, refer to RFC
  187: 1305) and you only need to know how to configure and start some programs. The
  188: base system of NetBSD already contains the necessary tools to utilize this
  189: protocol (and other time related protocols, as we'll see), derived from the xntp
  190: implementation. This section describes a simple method to always have a correct
  191: system time.
  193: First, it is necessary to find the address of the public NTP servers to use as a
  194: reference; a detailed listing can be found at
  195: [](
  196: As an example, for Italy the three stratum 1 servers ``,
  197: ``, and `` can be used.
  199: Next, to adjust the system clock give the following command as root:
  201:     # ntpdate -b
  203: (substitute the names of the servers in the example with the ones that you are
  204: actually using. Option `-b` tells
  205: [ntpdate(1)]( to
  206: set the system time with the settimeofday system call, instead of slewing it
  207: with adjtime (the default). This option is suggested when the difference between
  208: the local time and the correct time can be considerable.
  210: As you've seen, ntpdate is not difficult to use. The next step is to start it
  211: automatically, in order to always have the correct system time. If you have a
  212: permanent connection to the Internet, you can start the program at boot with the
  213: following line of `/etc/rc.conf`:
  215:     ntpdate=YES      ntpdate_hosts=""
  217: The name of the NTP server to use is specified in the `ntpdate_hosts` variable;
  218: if you leave this field empty, the boot script will try to extract the name from
  219: the `/etc/ntp.conf` file.
  221: If you don't have a permanent Internet connection (ex. you have a dial-up modem
  222: connection through an ISP) you can start ntpdate from the `ip-up` script, as
  223: explained in
  224: [[Setting up TCP/IP on NetBSD in practice|guide/net-practice]].
  225: In this case add the following line to the `ip-up` script:
  227:     /usr/sbin/ntpdate -s -b
  229: (the path is mandatory or the script will probably not find the executable).
  230: Option `-s` diverts logging output from the standard output (this is the
  231: default) to the system
  232: [syslog(3)](
  233: facility, which means that the messages from ntpdate will usually end up in
  234: `/var/log/messages`.
  236: Besides ntpdate there are other useful NTP commands. It is also possible to turn
  237: one of the local hosts into an NTP server for the remaining hosts of the
  238: network. The local server will synchronize its clock with a public server. For
  239: this type of configuration you must use the
  240: [ntpd(8)](
  241: daemon and create the `/etc/ntp.conf` configuration file. For example:
  243:     server
  244:     server
  246: ntpd can be started too from `rc.conf`, using the relevant option:
  248:     ntpd=YES
  250: NTP is not your only option if you want to synchronize your network: you can
  251: also use the timed daemon or the
  252: [rdate(8)](
  253: command as well. timed was developed for 4.3BSD.
  255: Timed too uses a master-slave hierarchy: when started on a host, timed asks the
  256: network time to a master and adjusts the local clock accordingly. A mixed
  257: structure, using both timed and ntpd can be used. One of the local hosts gets
  258: the correct time from a public NTP server and is the timed master for the
  259: remaining hosts of network, which become its clients and synchronize their
  260: clocks using timed. This means that the local server must run both NTP and
  261: timed; care must be taken that they don't interfere with each other (timed must
  262: be started with the `-F hostname` option so that it doesn't try to adjust the
  263: local clock).
  265: Finally,
  266: [rdate(8)]( can
  267: be used to synchronize once against a given host, much like
  268: [ntpdate(8)](
  269: The host in question must have the "time" service (port 37) enabled in
  270: `/etc/inetd.conf`.

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb