# Network services
## 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
[[A walk through the kernel configuration|guide/net-practice#kernel-options]]
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)](http://netbsd.gw.com/cgi-bin/man-cgi?showmount+8+NetBSD-5.0.1+i386):
# 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(8)](http://netbsd.gw.com/cgi-bin/man-cgi?mount+8+NetBSD-current)
command has a rich set of options for remote directories which are not very
intuitive (to say the least).
### 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.
### Setting up NFS automounting for `/net` with
[amd(8)](http://netbsd.gw.com/cgi-bin/man-cgi?amd+8+NetBSD-5.0.1+i386)
#### 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)](http://netbsd.gw.com/cgi-bin/man-cgi?amd+8+NetBSD-5.0.1+i386) 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.
#### 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
## 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](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(1)](http://netbsd.gw.com/cgi-bin/man-cgi?ntpdate+8+NetBSD-current) 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
[[Setting up TCP/IP on NetBSD in practice|guide/net-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)](http://netbsd.gw.com/cgi-bin/man-cgi?syslog+3+NetBSD-5.0.1+i386)
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(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ntpd+8+NetBSD-current)
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)](http://netbsd.gw.com/cgi-bin/man-cgi?rdate+8+NetBSD-5.0.1+i386)
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)](http://netbsd.gw.com/cgi-bin/man-cgi?rdate+8+NetBSD-5.0.1+i386) can
be used to synchronize once against a given host, much like
[ntpdate(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ntpdate+8+NetBSD-5.0.1+i386).
The host in question must have the "time" service (port 37) enabled in
`/etc/inetd.conf`.