Diskless Linux X Terminals

The X terminal is not a new idea; companies such as NCD have been manufacturing them for 15 years or more. The thin client idea fell out of fashion during the late 1990s, however, as the price of PC hardware fell so low that there was no obvious cost advantage to using X terminals. Heated arguments ensued over the total cost of ownership (including both the cost of the hardware and administrative support) of thin clients vs. PCs, and the debate will not be resolved by this article. The objective here is simply to describe a technique that allows one to utilize some of the growing pile of obsolete hardware left in the wake of advancing PC technology to build X terminals.

The essential characteristic of any thin client is that it should have little or no persistent storage. Typically, a purpose-built X terminal has a small quantity of NVRAM used to store configuration options and nothing else. In practice, it usually is possible to put even these options in a configuration file stored on the server and downloaded by the terminal on boot. This article takes the purist view that an X terminal should have no persistent storage whatsoever.

The PC has no hard, floppy or CD-ROM drive, so some other device must provide the bootloader and bootable image. X terminals are creatures of the network they inhabit, so the obvious choice is the network interface card (NIC). The NIC, therefore, must identify itself to the BIOS as a bootable device. If chosen, it must be able to download the bootloader from the network. This is not something most run-of-the-mill NICs can do. However, a standard for NIC boot ROMs called PXE (Preboot eXecution Environment, pronounced pixie) has been published by Intel and implemented by that company as well as by some other vendors in some products. Many newer motherboards with built-in Ethernet have PXE support.

In preparing this article, I tested five different kinds of NICs, all of which were advertised to support PXE: the Intel PRO/100+ (PILA8460BNG1), the 3Com 3C905CX-TX-M, the D-Link DFE-550TX, the Linksys LNE100TX and the SMC 1255TX (Tulip chipset). Of these five, only the 3Com card worked right out of the box. I was able to get a boot ROM separately for the SMC card, after which it also worked. The other three cards all had conspicuous but vacant sockets for boot ROMs, which were not shipped by default. Caveat emptor.

When the PXE NIC is chosen by the motherboard BIOS as the boot device, it broadcasts DHCP requests on the LAN and looks for PXE extensions in the responses it receives. If it receives a response containing some of these extensions, it then acknowledges and accepts the response. In particular, it respects the next-server and filename parameters in the server's response. These parameters specify the IP address of a TFTP server and the name of the file containing a bootloader that the client should download and start.

The Internet Software Consortium's version 3.0 DHCP server can be configured to advertise PXE extensions, and it is the DHCP server shipped with a number of Linux distributions, including Red Hat 8.0 and later versions. Listing 1 is an example of a DHCP server configuration file, dhcpd.conf, that generates DHCP responses with PXE extensions when the DHCP client identifies itself as a PXE NIC. With this configuration, the client downloads the file pxelinux.0 from the TFTP server, located at 192.168.1.1. Table 1 lists the options set in the configuration file.

option space PXE;
option PXE.mtftp-ip
  code 1 = ip-address;
option PXE.mtftp-cport
  code 2 = unsigned integer 16;
option PXE.mtftp-sport
  code 3 = unsigned integer 16;
option PXE.mtftp-tmout
  code 4 = unsigned integer 8;
option PXE.mtftp-delay
  code 5 = unsigned integer 8;
option PXE.discovery-control
  code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr
  code 7 = ip-address;

subnet 192.168.1.0 netmask 255.255.255.0 {

  class "pxeclients" {
    match if substring (option
      vendor-class-identifier, 0, 9) = "PXEClient";
    option vendor-class-identifier "PXEClient";
    vendor-option-space PXE;

    # At least one of the vendor-specific PXE
    # options must be set in order for the client
    # boot ROMs to realize that this is a PXE-
    # compliant server. We set the MCAST IP address
    # to 0.0.0.0 to tell the boot ROM that we can't
    # provide multicast TFTP.

    option PXE.mtftp-ip 0.0.0.0;

    # This is the name of the file the boot ROMs
    # should download.
    filename "pxelinux.0";
    # This is the name of the server they should
    # get it from.
    next-server 192.168.1.1;
  }

  pool {
    max-lease-time 86400;
    default-lease-time 86400;
    range 192.168.1.2 192.168.1.254;

   # If you include this, you must provide host
   # entries for every client, optionally associating
   # ethernet MAC addresses with IP addresses.

   # deny unknown clients;
  }
}

Obviously, the server at 192.168.1.1 must be configured to provide the TFTP service. It also must have a bootloader image called pxelinux.0, where the TFTP server process looks for it (usually in the directory /tftpboot). The TFTP server process usually is managed by one of the superservers, inetd or xinetd, so turning it on means messing around with one of their configuration files (/etc/inetd.conf or /etc/xinetd.conf, respectively).

The file pxelinux.0 is a bootloader that comes from H. Peter Anvin's SYSLINUX Project. Unlike generic bootloaders, such as LILO or GRUB, PXELINUX understands the PXE protocol and has the necessary networking functionality to pick up the boot process at this point by downloading the kernel and compressed RAM disk using TFTP. However, PXELINUX requires an enhanced TFTP server, one that understands the TSIZE option (RFC 2349). Fortunately, H. Peter Anvin also provides a modified version of the standard BSD TFTP dæmon, called tftp-hpa, that does support this option. The easiest thing to do is to replace the standard TFTP dæmon, often located at /usr/sbin/in.tftpd, with tftp-hpa.