Root over NFS - Another Approach: Setting up the server

2. Setting up the server

The first, and less tricky, thing to do is to setup the server. The server must be prepared to run these services:

NFS, preferably version 3, for exporting the following directories: /usr, /lib/modules, /opt (at least at SuSE) and /home (unless you have a dedicated file server).
DHCP server (in bootp mode), for matching the clients' MAC addresses to IP addresses.

Also, the administrator has to create directories for each client, containing nessesary startup files and programs. The directory scheme created for the installation described was like this one:



/usr/local/linux-
                  |-/base-
                  |       |-/bin
                  |       |-/sbin
                  |       |-/etc
                  |
                  |-/workstations-
                  |               |
                  |               |-195.251.160.100
                  |               |               |-/bin
                  |               |               |-/sbin
                  |               |               |-/etc
                  |               |
                  |               |-195.251.160.101
                  |               |-195.251.160.102
                  |               |-base(symbolic link to ../base)

The /base directory contains the whole file system you want to export to your clients. The per IP directories contain files that are needed before mounting the /usr or /lib/modules directories, like the /etc folder. This is a confortable directory structure for 2 purposes: i) You can easily create a basic system at the base directory and copy the per workstation files at the workstation directories easily, with an entry level bash script ii) You can easily add or delete or update workstations by modifying the directories under /workstations. A script for copying the appropriate files (which will be discused later) can be found in Appendix A.

2.1 Setting up the NFS server

An NFS server can be set up in two ways:

Using the /etc/exports file at BSD-compliant Unices like Linux of FreeBSD.
Using the /etc/dfs/dfstab at SysV Unices like Solaris.

/etc/exports: The /etc/exports file controls the directories to be exported and the export options per workstation. It has a structure like the following (Linux):

/path/to/dir1   ws1(options) ws2(options)....
/path/to/dir2   ws3(options) ws1(options)....

Options include ro or rw, root_squash, wsize, tcp, version.

Have a look at the nfs or the exports man page and the NFS Howto for a more detailed description of what these options mean.

/etc/dfs/dfstab:A typical dfstab file on Solaris should look like the following:

share -F nfs -o rw=193.250.160@,ro=193.250.161@ /export/home
share -F nfs -o ro=193.250.160@,root=193.250.161.132 /export/engineering

Of course, these options are discused in detail at the dfstab man page.

The directories we want to export are /usr/local/linux/base/usr, /usr/local/linux/base/opt, /usr/local/linux/base/lib/modules and /home, assuming that you 've followed the suggested structure.

Optimising NFS

Of course, this is none of our business but here are some general principles:

Reduce the TCP window size (parameter wsize for Linux) to whatever is closest to the MTU of your network type. For Ethernet, a good value of wsize is 2048 bytes as long as the MTU is 1536 bytes. This is generally a good idea because the main traffic load between the clients and the server consists of little packets and only in the case of starting large programms like X or StarOffice there is a big number of fragmented packets. Of course this may vary in your case, according to the needs of your users.
If you plan to have a large installation, break the space for your workstations into 2 or more SCSI disks. This will allow consequent writes and reads on both disks, increasing responce and reducing latency before a request completes
Always use NFS v3 over TCP. The main reason for migrating from v2 to v3 is the writeback case it offers on both the workstation and the server. Also, mounting NFS over TCP lets you use the first recomentation. \end{itemize} For further optimising use a packet analyzer like Ethereal or tcpdump and dicide your needs.By the way, Sun has written an excellent guide to optimizing NFS performance which, although emphasised on Solaris, is applicable to every modern Unix and is accessible online at http://docs.sun.com.

2.2 Setting up the DHCP/BOOTP server

Although there are many DHCP or BOOTP servers 'out there', some of which are proprietary, the best option is to use the reference IETF DHCP server. It is the least vulnerable and the most extensible DHCP available. The main server configuration is done through the /etc/dhcpd.conf file. This file is divided into two sections, the general server configuration and the host specific configuration. A typical dhcpd.conf file looks like this, in case that the DHCP/BOOTP server is used in BOOTP mode:


subnet 193.250.160.0 netmask 255.255.255.0 {
        range 193.250.160.10 193.250.160.12;
 }

host george{
        hardware ethernet  00:60:08:2C:22:20;
        fixed-address   193.250.160.10;
}

host earth{
        hardware ethernet 00:A0:24:A5:FD:E0;
        fixed-address   193.250.160.12;
}

This structure is fairly easy to be understood by everyone. For every diskless client we have to supply the programm with a 'host' declaration providing a pair of hardware and IP adresses. The host name provided in the 'host' statement can be everything, but there is a conversion to use the real host name of the client having the specific IP. The range statement in the subnet declaration is not necessary to be the range that you want your clients to have. In fact, if these clients are normal workstations with an operating system that during its boot uses DHCP to obtain an IP address it is not recommended to have the same IP for their operation as diskless clients. If you have specific needs, have a look at dhcpd.conf man page.

Another difficulty is how to obtain the IP - MAC address pairs for a large network. The solution is a nice little programm called arpwatch. This programm runs at the background and keeps track of the IP - MAC address pairs of the computers that your computer has contacted in a file that you have specified. The only thing you have to do is to ping the computers you want. At Appendix B there is a script that starts arpwatch, pings a range of subsequent IP's and creates the dhcpd.conf file. If you want to do it manually, start arpwatch when your network is at its peak of usage and wait for some time. On a shared medium network (Ethernet, Tokenring) arpwatch will track down all different IP 's and hardware addresses.

2.3 Preparing the base system

To prepare the base system just install your favorite distribution to a mountable partition on a hard disk with a Unix like operating system already installed. Install all the programms you want to be available to your users. Then you have to transfer the whole partition preserving the links and the character or block devices. This is best done using the tar programm. Boot the previously installed system and execute the following command, assuming that you have mounted the new partition at /mnt:


 tar cpvf system.tar /mnt/.

This command will create a tar archive at the current directory with the whole system to be served to the diskless clients. Then just copy the tar archive to the server using a CDROM or through the network and extract it at the base directory. The command to do this is:


 tar xvf system.tar /usr/local/linux/base

Next Previous Contents