Chapter 29. Network services

Table of Contents

29.1. The Network File System (NFS)
29.1.1. NFS setup example
29.1.2. Setting up NFS automounting for /net with amd(8)
29.2. The Network Time Protocol (NTP)

29.1. The Network File System (NFS)

Now that the network is working it is possible to share files and directories over the network using the Network File System (NFS). From the point of view of file sharing, the computer which gives access to its files and directories is called the server, and the computer using these files and directories is the client. A computer can be client and server at the same time.

  • A kernel must be compiled with the appropriate options for the client and the server (the options are easy to find in the kernel configuration file. See Section 24.1, “A walk through the kernel configuration” for more information on NFS related kernel options.

  • The server must enable the rpcbind, mountd lockd statd and nfs_server daemons in /etc/rc.conf:

    rpcbind=yes
    mountd=yes
    nfs_server=yes
    lockd=yes
    statd=yes
  • The client must enable the rpcbind, lockd statd and nfs_client daemons in /etc/rc.conf:

    rpcbind=yes
    nfs_client=yes
    lockd=yes
    statd=yes
  • The server must list the exported directories in /etc/exports and then run the command kill -HUP `cat /var/run/mountd.pid (hup mountd may work too!).

A client host can access a remote directory through NFS if:

  • The server host exports the directory to the client. The list of filesystems a NFS server exports can be checked with the showmount -e command, see showmount(8):

    # showmount -e 192.168.1.2
    Exports list on 192.168.1.2:
    /home                              host1 host2 host3
  • The client host mounts the remote directory with the command mount 192.168.1.2:/home /home

The mount command has a rich set of options for remote directories which are not very intuitive (to say the least).

29.1.1. NFS setup example

The scenario described here is the following: five client machines (cli1, ..., cli5) share some directories on a server (buzz.toys.org). Some of the directories exported by the server are reserved for a specific client, the other directories are common for all client machines. All the clients boot from the server and must mount the directories.

The directories exported from the server are:

/export/cli?/root

the five root directories for the five client machines. Each client has its own root directory.

/export/cli?/swap

Five swap directories for the five swap machines.

/export/common/usr

/usr directory; common for all client hosts.

/usr/src

Common /usr/src directory for all client machines.

The following file systems exist on the server

/dev/ra0a on /
/dev/ra0f on /usr
/dev/ra1a on /usr/src
/dev/ra2a on /export

Each client needs the following file systems

buzz:/export/cli?/root   on /
buzz:/export/common/usr  on /usr
buzz:/usr/src            on /usr/src

The server configuration is the following:

# /etc/exports
/usr/src  -network 192.168.1.0 -mask 255.255.255.0
/export   -alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0

On the client machines /etc/fstab contains:

buzz:/export/cliX/root  /        nfs rw
buzz:/export/common/usr /usr     nfs ro,nodev,nosuid
buzz:/usr/src           /usr/src nfs rw,nodev,nosuid

Each client machine has its number substituted to the X character in the first line of the previous example.

29.1.2. Setting up NFS automounting for /net with amd(8)

29.1.2.1. Introduction

The problem with NFS (and other) mounts is, that you usually have to be root to make them, which can be rather inconvenient for users. Using amd(8) you can set up a certain directory (Commonly /net), under which one can make any NFS-mount as a normal user, as long as the filesystem about to be accessed is actually exported by the NFS server.

To check if a certain server exports a filesystem, and which ones, use the showmount-command with the -e (export) switch:

$ showmount -e wuarchive.wustl.edu
Exports list on wuarchive.wustl.edu:
/export/home                       onc.wustl.edu
/export/local                      onc.wustl.edu
/export/adm/log                    onc.wustl.edu
/usr                               onc.wustl.edu
/                                  onc.wustl.edu
/archive                           Everyone

If you then want to mount a directory to access anything below it (for example /archive/systems/unix/NetBSD), just change into that directory:

$ cd /net/wuarchive.wustl.edu/archive/systems/unix/NetBSD

The filesystem will be mounted (by amd), and you can a access any files just as if the directory was mounted by the superuser of your system.

29.1.2.2. Actual setup

You can set up such a /net directory with the following steps (including basic amd configuration):

  1. in /etc/rc.conf, set the following variable:

    amd=yes
  2. mkdir /amd

  3. mkdir /net

  4. Taking /usr/share/examples/amd/amd.conf, put the following into /etc/amd.conf:

    [ /net ]
    map_name =              /etc/amd/net
    map_type =              file
  5. Taking /usr/share/examples/amd/net as example, put the following into /etc/amd/net:

    /defaults       type:=host;rhost:=${key};fs:=${autodir}/${rhost}/root
    *             host==${key};type:=link;fs:=/                           \
                  host!=${key};opts:=ro,soft,intr,nodev,nosuid,noconn
  6. Reboot, or (re)start amd by hand:

    # sh /etc/rc.d/amd restart

29.2. The Network Time Protocol (NTP)

It is not unusual to find that the system clock is wrong, often by several minutes: for some strange reason it seems that computer clocks are not very accurate. The problem gets worse if you administer many networked hosts: keeping the clocks in sync can easily become a nightmare. To solve this problem, the NTP protocol (version 3) comes to our aid: this protocol can be used to synchronize the clocks of a network of workstations using one or more NTP servers.

Thanks to the NTP protocol it is possible to adjust the clock of a single workstation but also to synchronize an entire network. The NTP protocol is quite complex, defining a hierarchical master-slave structure of servers divided in strata: the top of the hierarchy is occupied by stratum 1 servers, connected to an external clock (ex. a radio clock) to guarantee a high level of accuracy. Underneath, stratum 2 servers synchronize their clocks with stratum 1, and so on. The accuracy decreases as we proceed towards lower levels. This hierarchical structure avoids the congestion which could be caused by having all hosts refer to the same (few) stratum 1 servers. If, for example, you want to synchronize a network, you don't connect all the hosts to the same public stratum 1 server. Instead, you create a local server which connects to the main server and the remaining hosts synchronize their clocks with the local server.

Fortunately, to use the NTP tools you don't need to understand the details of the protocol and of its implementation (if you are interested, refer to RFC 1305) and you only need to know how to configure and start some programs. The base system of NetBSD already contains the necessary tools to utilize this protocol (and other time related protocols, as we'll see), derived from the xntp implementation. This section describes a simple method to always have a correct system time.

First, it is necessary to find the address of the public NTP servers to use as a reference; a detailed listing can be found at http://support.ntp.org/bin/view/Servers/WebHome. As an example, for Italy the three stratum 1 servers tempo.cstv.to.cnr.it, ntp1.inrim.it, and ntp2.inrim.it can be used.

Next, to adjust the system clock give the following command as root:

# ntpdate -b ntp1.inrim.it ntp2.inrim.it

(substitute the names of the servers in the example with the ones that you are actually using. Option -b tells ntpdate to set the system time with the settimeofday system call, instead of slewing it with adjtime (the default). This option is suggested when the difference between the local time and the correct time can be considerable.

As you've seen, ntpdate is not difficult to use. The next step is to start it automatically, in order to always have the correct system time. If you have a permanent connection to the Internet, you can start the program at boot with the following line of /etc/rc.conf:

ntpdate=YES      ntpdate_hosts="ntp1.inrim.it"

The name of the NTP server to use is specified in the ntpdate_hosts variable; if you leave this field empty, the boot script will try to extract the name from the /etc/ntp.conf file.

If you don't have a permanent Internet connection (ex. you have a dial-up modem connection through an ISP) you can start ntpdate from the ip-up script, as explained in Chapter 24, Setting up TCP/IP on NetBSD in practice. In this case add the following line to the ip-up script:

/usr/sbin/ntpdate -s -b ntp1.inrim.it

(the path is mandatory or the script will probably not find the executable). Option -s diverts logging output from the standard output (this is the default) to the system syslog(3) facility, which means that the messages from ntpdate will usually end up in /var/log/messages.

Besides ntpdate there are other useful NTP commands. It is also possible to turn one of the local hosts into an NTP server for the remaining hosts of the network. The local server will synchronize its clock with a public server. For this type of configuration you must use the ntpd daemon and create the /etc/ntp.conf configuration file. For example:

server ntp1.inrim.it
    server ntp2.inrim.it

ntpd can be started too from rc.conf, using the relevant option:

ntpd=YES

NTP is not your only option if you want to synchronize your network: you can also use the timed daemon or the rdate(8) command as well. timed was developed for 4.3BSD.

Timed too uses a master-slave hierarchy: when started on a host, timed asks the network time to a master and adjusts the local clock accordingly. A mixed structure, using both timed and ntpd can be used. One of the local hosts gets the correct time from a public NTP server and is the timed master for the remaining hosts of network, which become its clients and synchronize their clocks using timed. This means that the local server must run both NTP and timed; care must be taken that they don't interfere with each other (timed must be started with the -F hostname option so that it doesn't try to adjust the local clock).

Finally, rdate(8) can be used to synchronize once against a given host, much like ntpdate(8). The host in question must have the "time" service (port 37) enabled in /etc/inetd.conf.