Diff for /wikisrc/guide/net-services.mdwn between versions 1.5 and 1.6

version 1.5, 2019/09/02 20:48:37 version 1.6, 2021/04/12 13:15:03
Line 1 Line 1
 **Contents**  This page was moved to:
   [The NetBSD Guide - Network services](//www.NetBSD.org/docs/guide/en/chap-net-services.html)
 [[!toc levels=3]]  
   
 # 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  
    [[!template id=man name="showmount" section="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 [[!template id=man name="mount" section="8"]]  
 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  
 [[!template id=man name="amd" section="8"]]  
   
 #### 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  
 [[!template id=man name="amd" section="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.  
   
 #### 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>.  
 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  
 [[!template id=man name="ntpdate" section="1"]] 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  
 [[!template id=man name="syslog" section="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  
 [[!template id=man name="ntpd" section="8"]]  
 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  
 [[!template id=man name="rdate" section="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,  
 [[!template id=man name="rdate" section="8"]] can  
 be used to synchronize once against a given host, much like  
 [[!template id=man name="ntpdate" section="8"]].  
 The host in question must have the "time" service (port 37) enabled in  
 `/etc/inetd.conf`.  
   

Removed from v.1.5  
changed lines
  Added in v.1.6


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