Annotation of wikisrc/guide/net-services.mdwn, revision 1.2

1.1       jdf         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
1.2     ! jdf       140:  2. `mkdir /amd`
1.1       jdf       141: 
1.2     ! jdf       142:  3. `mkdir /net`
1.1       jdf       143: 
                    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
1.2     ! jdf       158:  6. Reboot, or (re)start amd by hand:
1.1       jdf       159: 
                    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