Kwok-Room Linux Technical Details
This document describes how the technical aspects of the
Kwok-Room Linux system work.
The implementation of Kwok Linux was made somewhat more
difficult by a variety of factors, which may be broadly split into
hardware independent and hardware dependent issues.
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.
BpBatch exploits several functions of the TFTP protocol
that are not commonly implemented. This required the
replacement of the TFTP server with one that understood
these functions - this was obtained from ftp://ftp.kernel.org/pub/software/network/tftp.
Unfortunately, when College implemented its new NAT
system, it was no longer possible for poseidon to answer the
DHCP requests. Therefore, the kernel now has to be supplied
by booting the machines from a floppy disk
This boot image is an ext2 floppy containing a kernel, lilo
and all other necessary files (boot.b and chain.b, a /dev
directory, lilo.conf) and lilo used with the -r option to
create a boot sector. Additionally, a text file is placed on
the disk in order to provide a simple menu.
The lilo method gives the advantage of a quick and simple boot
sequence along with the ability to choose between different
derivatives of the Kwok Linux system. To make matters as
simple as possible, the same kernel and root file system are
used for all three forms with the selection being passed to
the operating system by the selection of initial run level. In
addition, O2 is passed an extra kernel option disabling the
usage of the ramdisk in order to conserve memory. Once an
option has been selected, the kernel is read off floppy and
executed with the options provided by the lilo.conf file.
The option to boot NT is also provided - this simply chains
the boot loader from the beginning of the NT partition on the
local hard drive.
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.
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.
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
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.
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.
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
Screen :0 is listed second to make it the default.
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.
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.
Thankfully, the most recent hardware that Kwok Linux is run on is
significantly more standard than the previous generation - therefore,
it was unnecessary to hack the kernel and X server in order to support
the graphics hardware.
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.
The current machines are equipped with soundcards based on the
Ensoniq ES1371 chipset. This is well supported by the standard Linux
These pages are maintained by JCN. This file was last modified on 17/10/05. Copyright © JCN, 1998-2005.