File:  [NetBSD Developer Wiki] / wikisrc / guide / net-services.mdwn
Revision 1.5: download - view: text, annotated - select for diffs
Mon Sep 2 20:48:37 2019 UTC (10 months, 1 week ago) by cnst
Branches: MAIN
CVS tags: HEAD
find wikisrc -name '*.mdwn' | xargs perl -pi'' -e's#\[(http[^]]*)]\(\1\)#<\1>#g'

    1: **Contents**
    2: 
    3: [[!toc levels=3]]
    4: 
    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:    [[!template id=man name="showmount" section="8"]]:
   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 [[!template id=man name="mount" section="8"]]
   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: [[!template id=man name="amd" section="8"]]
  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: [[!template id=man name="amd" section="8"]] 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: 
  144:  2. `mkdir /amd`
  145: 
  146:  3. `mkdir /net`
  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: 
  162:  6. Reboot, or (re)start amd by hand:
  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>.
  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: [[!template id=man name="ntpdate" section="1"]] 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: [[!template id=man name="syslog" section="3"]]
  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: [[!template id=man name="ntpd" section="8"]]
  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: [[!template id=man name="rdate" section="8"]]
  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: [[!template id=man name="rdate" section="8"]] can
  271: be used to synchronize once against a given host, much like
  272: [[!template id=man name="ntpdate" section="8"]].
  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