| << | < | > | >> | Version 1.0 |
This section presents a complete example of a network booting diskless workstation, based on the prototype assembled by the author. It illustrates network booting via PXE, and mounting a root NFS file system (read/write), a relatively simple configuration, based on the Diskless Nodes HOWTO. While this approach has some scalability problems (particularly because of the use of a read/write NFS file system), it is relatively simple to understand and get operating. Other approaches, including ones that scale better, are discussed briefly at the end of this paper.
The boot server used was a AMD K6-2/300, with 128MB of RAM, and a 4GB SCSI disk, and two network cards, running Debian GNU/Linux 2.0 (Slink) and then later Debian GNU/Linux 2.2 (Potato). The machine has two network cards partly to give a dedicated 100Mbps link to the diskless workstation, and partly because the author had only 10Mbps hubs, and wished to have a 100Mbps connection to the display for efficiency.
The diskless workstation is a small, low power, PC produced by SuperTek, similar but not identical to their IQ-Terminal models. (It was acquired from a Dove dealership, and appears to be an earlier model of what is now the IQ-Terminal range.) The model used contains a low wattage power supply that contains no fans, and is based around a Cyrix MediaGX chip running at 200Mhz that also has no fans. This achieves the author's aim of a workstation with no moving parts, and thus completely quiet. The Cyrix MediaGX chip includes built in video and audio, and the motherboard has a RTL8139 Fast Ethernet chip. The unit also included a M-Systems Disk-on-Chip socket, a single SDRAM socket, and a single PCI or ISA expansion socket. Because the video output from the Cyrix MediaGX isn't very high quality (eg only 60Hz refresh at 1024x768), the author chose to put a Matrox MGA (Millennium I) video card into the single expansion socket to provide high quality video.
A dedicated network cable (a Cat-5 cable wired as a 100BaseT crossover) was used between the client and server largely to gain the benefits of 100Mbps networking without the need for a 100 Mbps hub. The second network card in the boot server connected to the rest of the network, and also to a cable modem. This separation also enables DHCP, TFTP and other services to be more easily limited to a single network segment.
The diskless workstation included PXE boot support in its BIOS, so the choice was made to boot it via PXE. While there is not currently a PXE server available for Linux (at least in production; the current beta of the ISC DHCP server appears to include PXE support), it is possible to configure the ISC DHCP 2.0 server to pass sufficient information back to convince a PXE client that it is dealing with a PXE server. The pxelinux program (by H Peter Anvin, included in the syslinux package) was used as a second stage boot loader. While pxelinux is still a beta program, other than some minor quirks this author has not had any problems with it. (The two problems noted are pxelinux messages not displaying on a PCI video card with the test hardware, and an incorrect pathname when given a filename with no path.)
A Linux kernel was prepared for the diskless workstation to run, using the official Linux 2.2.16 kernel source (from a kernel.org mirror). This kernel includes (kernel configuration file):
Everything else that wasn't required was turned off, including IDE disk support, floppy drive support, and even module support. All of the necessary support was compiled straight into the kernel, producing a single bzImage kernel of approximately 500KB. The kernel was compiled with only the CPU=586 option because the MediaGX chipset does not support any of the more advanced functionality.
A /tftpboot/pxe directory was prepared on the boot
server for network booting the client, and the directory hierarchy under
/tftpboot was made available via TFTP using the TFTP server
provided by H Peter Anvin on kernel.org (and mirrors). That TFTP server
has been is customised to allow larger block sizes during transfers, an
option that is required by the pxelinux code. For easy of maintenance
the chroot option of the TFTP server was used to make the directory
available to clients as /pxe, rather than hard coding
the top level directory into the other configuration files.
(Example inetd.conf file)
The /tftpboot/pxe directory contained a copy
of pxelinux, a pxelinux.cfg subdirectory containing
the file default with configuration for pxelinux.
(List of files in TFTP directory;
PXE configuration file)
pxelinux supports most of the boot options of syslinux, using
essentially the same syntax. The Linux kernel (bzImage file) was
placed in /tftpboot/pxe/linux, and the pxelinux
configuration file pointed at that file as the default (and only)
boot image. The pxelinux configuration file also specified additional
kernel parameters to indicate that the root file system should be a NFS
file system, and the location from which it should be mounted. The
kernel receives these parameters when control is transfered to it after
the kernel has been loaded and uncompressed.
The DHCP server (an ISC 2.0 based DHCP server) was configured to pass the extra PXE information, including the path to the pxelinux boot file. The configuration chosen identifies the diskless workstation by its Ethernet MAC address, but in other environments it may be appropriate to pass the information to all DHCP clients. (DHCP Configuration file example)
A root NFS area was prepared for the diskless workstation to run once it had booted. For ease of installation and maintenance this area was based on the Debian distribution with minor customisations.
To prepare the root NFS area, the "base" tar file
for the Debian distribution was downloaded and unpacked under
/var/wsroot. This area was shared via NFS to the IP
address that was to be assigned to the diskless workstation, with the
"no_root_squash" option, which is required to allow the diskless
workstation full read and write access. This was done by editing the
/etc/exports file and then restarting the NFS server.
(Example /etc/exports file)
Some initial setup was done to make the root NFS area ready for
booting (all paths relative to the /var/wsroot area; all
steps based on the Base system in Debian 2.1 (slink) -- Debian 2.2
(potato) should be similar except for the changes noted below):
/etc/hosts file was created for the NFS area, based
on the hosts file of the boot server./etc/hostname file was created containing the
name of the diskless workstation./etc/resolv.conf was created based on the
file from the boot server./etc/init.d/network script was created to
initialise the loop back network interface. (Since the kernel is
compiled to do kernel DHCP the Ethernet interface is already
initialised.) (Please note that the
/etc/init.d/network script is appropriate to the
Debian 2.1 (slink) distribution; Debian 2.2 (potato), the current
release, uses the /etc/network/interfaces file, and the
/etc/init.d/networking script./etc/modules file was created. (The kernel
was compiled without module support, but some Debian scripts
expect to process /etc/modules.)
/sbin/unconfigured.sh was moved aside./etc/fstab file was created that included one line
for the root file system via NFS (mirroring the parameters passed
to the kernel for root-NFS), and one line for the proc file
system. Mounting the proc file system is important in a Debian
system, and several things will not operate correctly if /proc is
not mounted./fastboot was created. This file
indicates to several init scripts that the disks should not be
checked, something which is not appropriate to a NFS shared area./etc/init.d/checkfs.sh was moved
out of the way (to /etc/init.d/checkfs.sh-skip) so
that it was not run.chroot /var/wsroot /bin/bash, and then the script
/root/setup.sh was run; the script removes itself
when run.At this point the diskless workstation was bootable, and the diskless workstation was booted up to continue the setup of the root NFS area. On first bootup a bare Debian installation prompts to set up the keyboard (normally done during install, but easier done with the actual machine in question and thus left until the first boot here), time zone (using tzconfig), root password, and optionally a non-privileged user. All of these things were configured.
The PCMCIA support was then removed from the Debian installation
using the command dpkg --purge pcmcia-cs; it may be
necessary to edit the /var/lib/dpkg/pcmcia-cs.postrm script
and place an exit 0 near the top to ensure that the script
succeeds if there is no module support in the kernel as it attempts to
ensure the PCMCIA modules are not loaded which fails if there is no
module support.
Having done this the root NFS area was ready to go, but provided only
a basic text login. To get X operational, a chroot(1) was performed
on the boot server again (chroot /var/wsroot /bin/bash),
the apt configuration file (/etc/apt/sources.list) set up
to point at a local Debian mirror, and the list of packages downloaded
using apt-get update. (This setup is easier done on the
boot server because it avoids copying the data over the network twice,
and in the authors setup the diskless client does not have any routing
to the Internet.) Then the X server packages were installed, primarily
by using apt-get to install the xserver-svga package, which pulls in all
the other packages that it requires. xf86config was used to configure
the X server, but equally easily a configuration from another already
set up system could be copied into place.
The boot server was also configured to provide font services to the
diskless workstation (rather than installing all the fonts into the root
NFS area for the diskless workstation). This was done by installing the
xfs font server, and editing the /etc/X11/xfs/config file
to comment out the line disabling TCP listening (no-listen =
tcp). The X configuration for the diskless workstation was
modified to ensure that the font servers were listed in the font page,
using lines like FontPath "tcp/fontserver:7100".
As required other network services have been made available to the diskless workstation, including NFS shares of additional software and data packages.
Booting then proceeds by the PXE support in the diskless workstation
BIOS taking control, performing a DHCP request for an IP address and
boot path and then performing a TFTP of the pxelinux binary (less than 8K).
Once pxelinux is running, it searches for its configuration file (in the
pxelinux.cfg directory relative to where it was loaded from) trying
names based on its IP address and eventually the file
default. Once found, it then boots the kernel image
specified in the configuration file (loaded relative to the location of
the pxelinux binary), and transfers control to the kernel with the
additional boot parameters including the location of the NFS mount point
for the root file system.
When the kernel receives control it initialises the hardware, and then performs a kernel DHCP request to configure the network interface. It then starts its NFS client, and mounts the NFS root area as the root file system (read only), and transfers control to init.
Once running init performs the same basic initialisation as on any
Debian system, running the scripts in /etc/rc1.d and
/etc/rc2.d, with the few exceptions noted above. One of
the more important scripts is /etc/init.d/mountnfs.sh which
remounts the root file system in read/write mode, and also mounts the
/proc file system.
In the configured root NFS area, one of the last scripts run starts up the X server in xdmcp query mode against the boot server (which is also the XDM server), and the XDM login screen from the boot server is displayed.
Once booted, the diskless workstation functions as a remote X
terminal. When the user logs in, the XDM server sets the
DISPLAY environment variable to point at the remote
X server, starts up the user's X login scripts. After that any X
applications can be run as usual and will display themselves on the
diskless workstation as a remote X terminal. Care is required with
certain applications that assume that they are displaying on the same
computer they are running on (eg, Abiword which assumes that it can add
fonts to the fontpath using local filenames, fixed by adding the
relevant fonts to the font path via XFS) or which have restrictions
against running remotely (eg, xlock; overridden with the
"-remote" option, or in its configuration file).
For most applications this setup (with a dedicated network link between the boot server and the diskless workstation) appears as fast as running X locally on the server. This is particularly true for xterms, and even nearly true for running applications such as Netscape. Applications that display a lot of graphical content will be noticeably slower (eg, xv, the gimp, etc) but are still perfectly usable. Generally applications that were written with remote display in mind make better use of the client/server nature of the X protocol and will perform better.
Because X is inherently designed to be operated remotely it is possible to use all of the software developed for running on a Linux desktop, including KDE and Gnome. Apart from some speed concerns about running particularly graphics intensive window managers (such as Enlightenment with all the window decorations, animation, etc, turned on; the author uses FVWM 2) and other very graphics intensive applications, anything available for Linux that uses X should be usable. The author has even heard reports of VMware being used in this type of configuration, although cannot recommend it as VMware is very graphics intensive and at its best when it can write directly to the video hardware.
The increasing range of Linux desktop software, particularly now that StarOffice has been released under the GPL, the Gnome Foundation formed to continue the development of the Gnome desktop (and both Sun and HP have announced its use in their products), and KDE 2.0 nearly released makes this a quite practical platform for general office work. (The author has been using Linux as his primary desktop for the past 2 years, and increasingly finds that almost everything required can be done with native Linux applications.)
The major catch with a diskless workstation setup is sound support. Since all the applications are running on the server, the sound hardware used by any sound playing programs is the server. While this is not a major problem in the single client/single server situation, it is obviously more of a concern if more clients are being used and need sound support. One possibility is to arrange to run the sound programs on the diskless workstation itself, perhaps using ssh to start the program. Another is to make use of some of the network audio programs to send the audio to the diskless workstation for output. At present the author has not investigated this extensively, but see the references section for some pointers.
| << | < | > | >> | Copyright © 2000 Naos Limited |