Table of Contents
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.
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.2Exports 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).
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?/rootthe five root directories for the five client machines. Each client has its own root directory.
/export/cli?/swapFive swap directories for the five swap machines.
/export/common/usr/usr directory; common for all client
hosts.
/usr/srcCommon /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.
/net
with amd(8)
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.eduExports 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.
You can set up such a /net directory with the
following steps (including basic amd
configuration):
in /etc/rc.conf, set the following variable:
amd=yes
mkdir /amd
mkdir /net
Taking /usr/share/examples/amd/amd.conf,
put the following into /etc/amd.conf:
[ /net ] map_name = /etc/amd/net map_type = file
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
Reboot, or (re)start amd by hand:
#sh /etc/rc.d/amd restart
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 -bntp1.inrim.itntp2.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:
serverntp1.inrim.itserverntp2.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.