Thin Client

Company: PC & Web Xperience, Inc.

03/20/2001


Design Document

Version 0.2


Overview

The purpose of this document is to define the specifications and goals for the thin client technology and how they will be achieved, including but not limited to the independent filesystem for the client station along with supporting server-side installation scripts and archives, the organization with which a client will be recognized and configured by the server, the hierarchy of the filesystem that will support the client stations, the necessary configuration tools that will take care of helping to manage the client stations (i.e., setting them up initially, reconfiguring, modifying DHCP, etc.) including the server-side web based client administration tool and the client-side scripts that will gather information about the client (primarily its MAC address), and the process by which a client station will configure itself when booting.


Filesystem Hierarchy

One of the main purposes and goals of the thin client technology is to maintain separation (as much as possible) of the client filesystem from the server filesystem and architecture. The client filesystem will reside in an NFS/NBD mount point on the server. The client filesystem will contain the necessary libraries that will not be included in the initial ramdisk along with the necessary executables for the different services the client station will provide. These will include, among other things, X, sound redirection services, floppy redirection services, ssh, configuration tools running on virtual consoles, etc.

The following directories will be contained in the client filesystem for a particular hardware architecture (i386, i586, i686, sparc, alpha, etc.):


/lib contains libraries necessary for shared linked executables

/modules contains any modules needed by the clients for hardware or drivers that are not compiled into the kernel or need to be loaded at boot time (could be specific to network cards, sound cards, NBD, etc.)


/bin contains binary executables

/sbin contains more binary executables


/usr

/bin contains executables

/sbin contains more executables

/X11R6 contains the distribution of X (currently version 4.0.2)


/settings contains the client- and/or type-specific configuration files (client-specific files will end with the MAC address of the network card in the client)


/swapfiles the mountpoint for the swapfile (of the form swapfile.MAC) for NFS/NBD network swap for the client


All configuration specific files for supporting applications that need to run from the server will be stored in the /etc/<thinclient> directory and sub-directories thereof.


DHCP Settings

The version of the ISC DHCP server that allows for client-type recognition via vendor-class-identifier tags needs to be installed on the server that will hand out IP addresses to booting workstations. These features are available in ISC dhcpd 3.0b2pl14 and subsequent releases. The configuration file for the DHCP server will need to be modified in order to allow the DHCP administration program to recognize the different types of clients that can connect (PXE, Etherboot, unknown PXE, unknown Etherboot, etc.) and the different networks these known clients will be booting into. This will be accomplished by the use of keywords that will be substituted for every time they are encountered in the /etc/dhcpadmin/dhcpd.conf.template file. These keywords will be specified in and substitute values from the /etc/dhcpadmin/dhcpadmin.conf file. Some of the default keywords that will be supplied are:

When the /etc/dhcpadmin/dhcpd.conf.template file is parsed, the DHCP administration program will substitute the contents of the appropriate variable or file for the recognized keyword. Keywords starting with a dollar sign ($) will be translated directly as a value. Keywords starting with the (@) symbol will be translated as a file from which to pull the contents and substitute. The files will be in the directory /etc/dhcpadmin/network0..networkN/. The default file for known PXE clients will be named knownPXEClients.dhcp. The default file for known Etherboot clients will be named knownEtherbootClients.dhcp. The structure of the files will contain lists of valid hostname entries for dhcp. The web-based client administration program will be able to insert different kernel images for the particular host to download to override the default boot file. For example, the default dhcpd.conf.template file might look something like this:


ddns-update-style none;


class "PXE" {

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

}

class "Etherboot" {

    match if substring (option vendor-class-identifier, 0, 9) = "Etherboot";

}


subnet NETWORK0 netmask NETMASK0 {

    pool {

        range dynamic-bootp PXE_KNOWN_RANGE_START0 PXE_KNOWN_RANGE_END0;

        allow members of "PXE";

        deny unknown clients;

        filename "/tftpboot/pxelinux.bin";


        PXE_KNOWN_CLIENTS0

    }


    pool {

        range dynamic-bootp ETHERBOOT_KNOWN_RANGE_START0 ETHERBOOT_KNOWN_RANGE_END0;

        allow members of "Etherboot";

        deny unknown clients;

        filename "/tftpboot/<thinclient>/vmlinuz.generic";


        ETHERBOOT_KNOWN_CLIENTS0

    }


    pool {

        range PXE_UNKNOWN_RANGE_START0 PXE_UNKNOWN_RANGE_END0;

        allow members of "PXE";

        deny members of "Etherboot";

        allow unknown clients;

        filename "/tftpboot/pxelinux.bin";

    }

    pool {

        range ETHERBOOT_UNKNOWN_RANGE_START0 ETHERBOOT_UNKNOWN_RANGE_END0;

        allow members of "Etherboot";

        deny members of "PXE";

        allow unknown clients;

        filename "/tftpboot/<thinclient>/vmlinuz.generic";

    }

}


The keywords in the above sections would be substituted on and would be replaced with the value of the variable or contents of the file for the respective section. The file for known hosts for PXE would look something like the following:


host pxews01 {

    hardware ethernet AA:BB:CC:DD:EE:FF;

}

host pxews02 {

    hardware ethernet FF:AA:EE:BB:DD:CC;

}


Technically, PXE clients could not change the file they download by modifying their section in the DHCP configuration file. Those settings would need to be changed in the pxelinux.cfg directory in the particular configuration file that matches the PXE client's IP address (default if there are no files that match).


The Etherboot client section looks similar but has the ability to override the default boot file option.


host ethws01 {

    hardware ethernet AB:CD:EF:GH:IJ:KL;

}

host ethws02 {

    hardware ethernet KL:AB:IJ:CD:GH:EF;

    filename "/tftpboot/<thinclient>/vmlinuz-2.2.18-nfs";

}


The last example shows that the DHCP administration program (or the administrator manually) modified the entry for ethws02 to download a different boot file than the default set in the pool section for known Etherboot clients.


Once the /etc/dhcpadmin/dhcpd.conf.template file has been parsed and the known PXE and Etherboot clients have been inserted into a temporary file (/tmp/..., obtained by using tmpnam()), the /etc/dhcpd.conf file will be copied to /etc/dhcpd.conf~ (just like the dhcp server does with the leases file) and then the /etc/dhcpd.conf file will be overwritten with the new temporary file. The DHCP server will then need to be restarted for any new changes to take place. Any clients affected by the changes (i.e., new kernel image, changing a workstation's root path, etc.) will need to be restarted for the changes to take effect.


Web-based Client Administration Program

The client administration program is at the heart of the thin client technology. This web-based application is used to generate and update the files that configure a client workstation.


When committing changes to a workstation or a type of client/machine, the administration program will parse all configuration files and plugin scripts in the /etc/<thinclient>/ directory(ies) searching for keywords that are to be replaced in the files in the /tftpboot/<thinclient>/settings/ directory.


There are three categories that the web-based configuration tool will deal with when configuring workstations: types, services, and groups.


Definitions for the three categorizations:


How to configure settings for services based on the hardware type? Groups will need to know what Types of hardware are contained in the respective groups.


All workstations will fall under a particular instance of the above three categorizations. All workstations will start out as being of Type=default, Service=X,setup, Group=default. This instance of categorization will allow the machine to get up and running with a 16 color, 640x480 X display and the runtime choosing script/application that will allow the user to modify certain settings during the operation of the machine, running on a virtual console (most likely /dev/vc/10).


Network Swapping over NFS

For NFS swapping to work, the workstation kernel must be patched with the NFS swapping patch. The kernel must be compiled with the options to allow it to use a file exported from an NFS server as its swap space. This is accomplished by setting "Use network swapping" in Network Options and "Use Swapping over NFS" in Filesystems->Network Filesystems in the kernel configuration. The steps to setup an NFS swap file are simple:


dd if=/dev/zero of=<swap_dir>/swapfile.<MAC> bs=1024 count=<# KB> (i.e., 32MB = 32768KB)

mkswap <swap_dir>/swapfile.<MAC>


This will create a no-holes (very important for swapping) file that the workstation can use for swap space. The workstation then mounts the swap directory and issues a 'swapon' on its swapfile.


Network Swapping over NBD

When the client is to use network swapping over network block devices, the nbd-client will be launched at the appropriate time on the client to connect to the swap-server that stores the swapfiles for the client workstations. On the swap-server, nbd-server will be called through a script running from (x)inetd. When (x)inetd is contacted at the port that is to provide swapping service, the wrapper script (nbd-swapping-wrapper) will be called to check that the client connecting to the service is allowed to use swap space on the network. If the client is allowed access, the file for the MAC address of the client will be checked to determine if it exists. If it does not exist, the default swap size for network swapping and default location for swapping files will be used to create a file for use with network swapping of the form swapfile.<MAC: colon-separated>. At this point, the nbd-server will be exec'd from the wrapper script with the filename of the existing/created swap file for the client. Once the network block device has been connected, the client workstation will issue a "swapon" on the NBD device that it uses for swapping (i.e., /sbin/swapon /dev/ndb).


What information do we need?

Kernel - RAMdisk -> mounts /settings to get <config>.MAC

           Filesystems

           Services

<config>.MAC contains: <type>,<group>


Console X4-menu:

  1. Xconfigurator

  2. xf86cfg

  3. xf86config

  4. Save XF86Config to server

  5. Restart X


Pros: user can temporarily reconfigure X when needed without administrator help

Cons: user can mess up X, but easily fixed by rebooting since changes are temporary


NFS/NBD Filesystems (mount points):

/tftpboot/<thinclient>/types

/default

/XF86Config

/arch

/P75ps2

/P75serial


/tftpboot/<thinclient>/arch

/i386

/bin

/lib

/sbin

/usr

/i586

/i686

/sparc

/alpha


/tftpboot/<thinclient>/groups

/office5

/ltsp_printing

/lab23 -> XFree86

-> xinetd-floppy

-> esd


/tftpboot/<thinclient>/services

/XFree86

/mgetty

/ssh

/esd

/xinetd-floppy

Steps to booting a workstation:

  1. Workstation boots with either PXE or Etherboot and receives an IP address and the file to download.

  2. PXE/Etherboot downloads the kernel + initial ramdisk.

  3. Kernel launches linuxrc (does the work to configure the workstation and setup inittab with all the services to be run by the workstation):

  4. linuxrc execs init to launch the workstation's services.