Root over nfs clients & server HOWTO

2. Basic principle

As already said with this setup the clients share basicly the entire root-fs with the server. But the clients ofcourse only get read access to it. This is basicly how things work.

2.1 Things can't be that simple

Unfortunatly things aren't that simple, there are a couple of problems the overcome with this simple setup.

Each ws needs its own writable copy of a number of dirs

A normal linux setup needs to have write access to the following dirs:

1. /dev
2. /var
3. /tmp

There are 3 solutions for this, of which one will only work for /dev:

1. mount a ramdisk and populate it by untarring a tarball, or by copying a template dir.
   • Advantages:
     1. It's cleaned up every reboot, which removes tmp files and logs. Thus it needs no maintaince unlike server sided dirs.
     2. It doesn't take up any space on the server, and that it doesn't generate any network traffic. A ramdisk takes less server and network resources, and is faster.
   • Disadvantages:
     1. It takes memory.
     2. The logs aren't kept after a reboot, if you really want logging of all your clients tell syslog to redirect the logging to your server.
2. create a dir for each ws on the server and mount it rw over nfs.
   • Advantages & disadvantages:
     1. The above arguments work in reverse for serversided dirs.
3. With kernel 2.2 devfs can be used for /dev, this is a virtual filesystem ala /proc for /dev.
   • Advantages:
     1. Devfs takes very little memory when compared to a ramdisk / no diskspace on the server and is very fast. A normal /dev takes at least 1.5 mb since the minimal size for a file (and thus for a device) is 1k, and there are somewhere around 1200 devices. You can offcourse use a template of a stripped /dev with only the entries you need to save some space. 1.5 Mb is a lott for a ramdisk and also isn't nice on a server.
     2. Devfs automagicly creates entries for newly added & detected devices, so no maintainance is needed.
   • Disadvantages:
     1. Any changes to /dev like creating symlinks for the mouse and cdrom are lost. Devfs comes with a script called rc.devfs to save these chances. The script's provided in this howto will automagicly restore these symlinks settings by calling rc.devfs If you make any changes to /dev you need to call the rc.devfs yourself to save them by typing:

     /etc/rc.d/rc.devfs save /etc/sysconfig

As you can see, there are a number of ways to solve this problem. For the rest of this Howto the following choices are assumed:

• For /dev we'll use Devfs
• For /var and /tmp we'll use a shared ramdisk of 1mb. It's shared to use the space as effeciently as possible. /tmp is replaced by a symlink to /var/tmp to make the sharing possible.
• Populating the ramdisk with tarballs or template dirs, works equally well. But with template dirs it's much easier to make changes, thus we'll use template dirs.

Write access to /home might be needed

Not really a problem in every unix client/server setup /home is mounted rw from the server so we'll just do that ;)

How does a ws find out it's ip so that it can communicate with the server?

Luckily for us, this problem has already been solved and the linux kernel has support for 2 ways of autoconfiguration of the ip-address:

1. RARP
2. Bootp

Rarp is the easiest to setup, bootp is the most flexible. Since most bootroms only support bootp that's what we'll use.

What about ws sepecific configuration

On redhat most system dependent config files are already in /etc/sysconfig We'll just move those which aren't there and add symlinks. Then we mount a seperate /etc/sysconfig on a per ws basis. This is really the only distribution dependent part on other distributions you can just create a sysconfig dir, move all config files which can't be shared there and create symlinks. Also /etc/rc.d/rc3.d, or symilar on other dists, might need to be different for the server resp the workstations. Assuming that all ws run the same services in runlevel 3, we'll just create a seperate 3th runlevel for the workstations and the server:

1. Create both a /etc/rc.d/rc3.ws and a /etc/rc.d/rc3.server
2. make /etc/rc.d/rc3.d a symlink to /etc/sysconfig/rc3.d
3. make /etc/sysconfig/rc3.d a symlink to the apropiate /etc/rc.d/rc3.xxx
4. replace S99local in rc3.ws by a link to /etc/sysconfig/rc.local so that each ws can have it's own rc.local

Miscelancious problems

There are a few problems left:

1. /etc/rc.d/rc.sysinit needs /var, so /var needs to be mounted or created before /etc/rc.d/rc.sysinit is run. It would also be nice if the ws-specific /etc/sysconfig is mounted before any initscripts are run.
   • We'll just source a bootup script for the ws in the very top of /etc/rc.d/rc.sysinit. Note this script will then ofcourse also be sourced by the server itself on boot, so the script has to detect this and do nothing on the server.
2. /etc/mtab needs to be writable:
   • This is a tricky one, just create a link to /proc/mounts and create an empty file mounts in /proc so that fsck and mount don't complain during the initscripts when /proc isn't mounted yet. One note smb(u)mount doesn't respect mtab being a link and overwrites it. Thus if you want to use smb(u)mount create wrapper scripts that restore the symlink.