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

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

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb