Kwok-Room Linux Technical Details

2.1. Kernel

The kernel is compiled directly from an unpatched Linux 2.2.19 - under Kwok Linux, the source is available in /usr/src/linux. Obviously, there must be some means of providing the kernel to the client machines - this was originally accomplished using Intel's PXE (Pre Boot eXtensions) system. The network cards (Intel Etherexpress Pro 100) were configured to send out DHCP requestes on system boot. These are answered by Poseiden (the JCN server), which then provides a boot loader that supports the PXE protocol. This function is currently fulfilled by BpBatch ( http://www.bpbatch.com). The main bpbatch program is downloaded from Poseidon via TFTP. It then proceeds to download the other files it requires in the same way, and finally downloads a configuration file. This contains a script that is run by bpbatch - in the current configuration, an information box is placed on the screen and the system waits for 5 seconds. If a key is pressed during this time, the Linux kernel is downloaded via TFTP and executed. If not, the system simply boots off hard drive in the normal fashion.

2.2. Bootp

Since the same root file system is used for each machine in the cluster, it is necessary to set up networking in a way not reliant on the configuration being stored on the filesystem. Currently this is achieved using bootp, with Poseidon being used to provide ip addresses and similar configuration to each machine. A small modification to the kernel allows bootp requests to be directed at specific hosts. As the desired bootp server can be passed as a kernel argument, this theoretically allows another method for using the same initial boot disk to provide different services.

2.3. Root filesystem

Poseidon also sends the clients the location of their root filesystem. Currently this also resides on poseidon and is exported to each client over NFS. This is (at present) a fairly standard Debian installation with minor alterations to the etc and /var/run directories in order to allow for host-specific information.

2.4. Host-specific information

Unix-type systems generally rely on several files being unique to the machine on which the operating system is running. An example of this is the /var/run/utmp file, which keeps track of which users are logged in. Given that there may be up to 25 clients in simultaneous use, it would be impractical to keep the same utmp between every machine - the most obvious point of failure is the finger command, but other (more subtle) problems would also arise. Instead, a small disk image is copied off the filesystem onto the ram disk device. This is then mounted under the root file system at /ramdisk. Various files on the root file system are symlinks into the ramdisk.

Since the initial contents of the ramdisk are consistent between every host, it may still be necessary to add files which differ between machines. This was originally implemented due to two machines having different monitors to the rest of the hardware. The files for which this is necessary are replaced with symlinks to /ramdisk/localhost which is itself a symlink generated with the command ln -s /admin/`hostname` /ramdisk/localhost

A directory in /admin is then created for each host - at present, these are themselves symlinks a directory containing the configuration files for whichever type of hardware the host belongs to. This is obviously beneficial in the almost entirely homogenous environment the system has been developed in.

The final issue was /etc/mtab, which keeps track of which devices are currently mounted. This would obviously be a problem if shared between clients - once one machine had mounted a device, no other machine would be able to do the same. Instead, /etc/mtab is a symlink to /proc/mounts which provides most of the same functionality and is host specific.

2.5. Device node handling

Having a consistant root file system led to one unforseen side effect. Logging into a unix-type system changes the file permissions and ownerships of the corresponding device node which causes obvious problems when the same device nodes are being used on several distinct hosts. This problem was solved by applying the devfs patches to the kernel source. Devfs allows the mounting of a virtual filesystem (similar to proc) on /dev which will be specific to the host hardware. Permissions on the devices are handled by a tar file in /admin/`hostname`/.

If changes are made to the /dev filesystem, you should run /etc/init.d/rc.devfs stop (and presumably restart it) on one machine from each hardware profile.

2.6. Offering different screen resolutions

It seems some people are keener to preserve their eyesight than others, so a debate soon broke out over what resolution the default X session should run at. It was eventually decided to start wdm with two screens, one running at 1152x864 and the other running at 1280x1024. This was achieved by using the following lines in our Xservers file:

	  :1 local /usr/bin/X11/X :1 -dpi 75 -xf86config /ramdisk/localhost/XF86Config-4_higher_res vt8
	  :0 local /usr/bin/X11/X :0 -dpi 75 vt7
	

2.7. Persistancy of window managers

The X login prompt is provided by WDM. One of the features of WDM is the ability to choose the desired window manager from a drop-down menu, which will then override the system defaults. However, in its standard state this choice is not maintained and at the next login the window manager will refer to its default. The default Xsession file was modified in such a way that if a window manager other than the default is chosen, the filename is stored in a file in the user's home directory called .lastsession. Unless another window manager is chosen, the system will now default to whatever is stored in this file.

2.8. Printing

The Kwok Room printers are part of the Windows network. As a result, the most trivial way to print files is by producing postscript output and then sending it directly to the printers by smbclient '\\turnip\kwok-a4 -P and entering the user's NT password when requested. However, this is somewhat less transparant than printing under Windows. An alternative method has also been implemented. /etc/printcap calls a wrapper script in /usr/local/bin that calls smbclient with the correct arguments, obtaining the required password from a file in the user's home directory called .ntpasswd. For obvious reasons, it is advisable that this file be made readable only by the user.

3.1. Graphics Card

The current machines are equipped with Voodoo 3 graphics hardware. This is supported in version 3.3.6 of the XFree86 X server. Support for the 3D functionality of the hardware is provided by the Glide libraries, with an OpenGL interface being provided by the Mesa libraries.

3.2. Sound

The current machines are equipped with soundcards based on the Ensoniq ES1371 chipset. This is well supported by the standard Linux kernel drivers.