Thin Client Computing

Thin client computing has been a buzzphrase for the past few years. In a thin client network, users sit at low-powered machines and run programs on more powerful central computers.

As described shortly, this approach to computing offers certain advantages over the more common desktop computer approach. This month’s column looks at the basic principles of thin client computing and presents basic information on the server side of the thin client equation. Next time I’ll describe the client side.

Why Use Thin Client Computing?

The idea behind thin client computing is one of centralization: A single computer, or perhaps a small” farm” of computers, holds all user accounts and most of the programs that users run. Users access these systems using less powerful systems– the thin clients. This approach provides several advantages over the more conventional method of providing each user with a fully-equipped desktop computer:

• The thin clients are inexpensive, minimizing costs and perhaps enabling continued use of old computers as thin clients.
• The thin clients hold simple software packages, reducing administrative requirements to maintain them.
• The thin clients can be diskless and can use less power-hungry CPUs, minimizing power consumption, noise, and cooling costs.
• The thin clients don’t need direct Internet access, reducing security risks and enabling them to run on private IP addresses, thus reducing the need for public IP addresses.
• Users can use any thin client to access their own accounts and files. This is handy in public computing centers or when users move from one work space to another.
• Upgrades to most software packages are restricted to the server systems, reducing administrative effort.
• Backups are simplified; only the servers need to be backed up.

Of course, thin client computing isn’t without its drawbacks. The servers that power thin clients must be more powerful than the average desktop system, since each one will host several users. As a general rule of thumb, count on about 75-100MHz of CPU power and 50MB of RAM per client, plus a baseline of 512MB of RAM to start. Your exact needs will vary depending on your uses, though.

Computing reliability is tied to the server (s). When a user’s fat client fails, that user is disable– but the rest of the office can keep working. If an office using thin clients experiences a server failure, all users will be affected. Picking reliable hardware and having backup hardware ready can mitigate problems caused by hardware failures. Keeping server software backups is important, as well.

The network load is likely to be higher in a thin client configuration than in a typical desktop-using office.

Since thin client computing requires servers to accept remote logins, thin client computing introduces a potential security hole.

Access to local hardware (CD-ROM drives, printers, USB devices, etc.) can be complicated. Some thin client packages are preconfigured to handle some common local hardware, but this isn’t always the case. Finally, CPU-intensive and display-intensive programs are poorly matched to thin client configurations.

As a general rule of thumb, thin client computing works best in situations where users run typical office programs, such as e-mail, Web browsing, word processing, and light spreadsheet use. Tools that are very CPU-intensive or that make heavy use of the display (streaming videos, games, and scientific simulations, for instance) don’t work well because they demand too much of the server or of the network.

Servers Required to Support Thin Clients

The ideal setup for a network that uses thin clients involves configuring the thin clients to boot from the network. This enables thin clients to run without any local storage. Not all computers support network boots, though, so you may need floppy disks or even CD-ROMs on some or all of your thin clients to get the process started.

In order to boot thin clients from the network, you’ll need to run two server protocols: The Dynamic Host Configuration Protocol (DHCP), which assigns IP addresses to clients, and the Trivial File Transfer Protocol (TFTP), which delivers boot files to thin clients. Neither DHCP nor TFTP is strictly required in a thin client environment, but they are needed for network booting. On all but very large networks, only one system needs to be configured as a server for each of these protocols.

Of course, you’ll also need to configure X or Virtual Network Computing (VNC) to handle remote logins. You might have just one or many computers running remote login protocols. DHCP, TFTP, and remote login protocols need not all run on a single computer, but they can do so if it’s convenient.

Configuring DHCP

DHCP configuration is complex enough that I can’t describe the whole process here. If you’re not already using a Linux DHCP server, you’ll have to research basic Linux DHCP configuration before you proceed, learn to configure your non-Linux DHCP server to do the tasks I describe, or forego DHCP configuration for thin clients. You can still use thin clients without the help of DHCP, but you may need to tell clients where to find your TFTP server or even outfit them with complete software packages locally (on CD-Rs or hard disks).

The main point of DHCP configuration for thin clients is to enable the DHCP features that point clients to a TFTP server. If you’re using the popular Internet Software Consortium (ISC) DHCP server, you’ll probably find its main configuration file in /etc/dhcpd.conf. This file includes a series of global options followed by one or more subnet declarations, which define options for specific subnets. To support thin clients, you’ll want to ensure that two options are set, either globally or as part of specific subnet declarations:

option tftp-server-name "192.168.1.1";
filename "thinstation.nbi";

The tftp-server-name option points clients to a TFTP server. This line is extremely important if you intend to boot thin clients from the network. Note that the name must be enclosed in quotation marks, even if you specify it as an IP address.

The filename option provides the name of an OS image file in the TFTP server’s directory (described shortly). This option should be set to a name that’s appropriate for whatever thin client software you intend to run. The preceding example uses"thinstation.nbi", which is suitable for the ThinStation client described next month.

Some thin clients require one or both of two additional options:

allow bootp;
option x-display-manager 192.168.1.1;

These options enable the older BootP protocol, which is similar to DHCP, and point the client to an X server. Neither of these options is required for the ThinStation client software, but you may need these options if you use other thin clients.

Of course, you should adjust the values of all of these options for your own network. You can provide all of these options as globals, or in subnet, host, or other more specific declaration blocks. You can use this fact to provide a default configuration or tweak the configuration for individual clients or groups of clients. For instance, you can mix and match dedicated thin clients, which require their own software, with ThinStation clients.

Remember to restart your DHCP server once you’ve changed its configuration. Typically, you can do this by passing the restart option to a SysV startup script, like/etc/init.d/dhcpd restart.

Configuring TFTP

TFTP is delivered with most Linux distributions, or you can download a copy fromhttp://www.kernel.org/pub/software/network/tftp/. Linux TFTP packages typically ship with a file called /etc/xinetd.d/tftp, which launches the TFTP daemon via the xinetd server. Chances are you’ll have to edit the /etc/xinetd.d/tftp file and change the disable line to readdisable=no. You may also need to set the server_args line; it should use the -soption and point to a directory in which boot files are to be stored:

server_args=-s /tftpboot

Once you’ve edited /etc/xinetd.d/tftp, you should create the directory you’ve specified, if it doesn’t already exist. You should then restart the xinetd daemon. You can usually do this by typing /etc/init.d/xinetd restart, although the exact path to the startup script may vary depending on your distribution.

With the TFTP server running, you must still populate its file directory with the thin client software. Although the files reside on the TFTP server computer, this is really a client issue, so I describe it in more detail next month.

Configuring X and XDMCP

X is peculiar because it uses client and server roles that seem backwards to most people; you sit at the server computer and use X clients that are remote. Thus, in a thin client configuration, you don’t need to be concerned with X server configuration on the powerful host computer. Instead, you’ll run the X server on the thin client computer. In most cases, X configuration on the thin client is fairly straightforward, and I describe it next month.

You do, however, need to configure a login protocol server for X. This protocol is XDMCP. If your environment hosts multiple systems that a user might access, you’ll need to configure XDMCP on each of them.

Most Linux distributions ship with an XDMCP server. The most common are the X Display Manager (XDM), the KDE Display Manager (KDM), and the GNOME Display Manager (GDM). On a desktop computer, one of these programs, or something similar, manages the GUI login screen. Most Linux distributions, however, configure XDMCP to block outside access attempts. This is a useful security feature for a typical desktop computer, but it just won’t do if thin clients are to access the computer using X. Thus, you’ll have to loosen the security restrictions on your system.

The first trick is in finding which XDMCP server you’re running on the computer you intend to have accept thin client logins. Try typing ps ax|grep dm. This command shows you all processes with the string dm in their names. You’ll probably notice xdm, kdm, or gdm in the output. If you don’t, then the system isn’t configured to start up in GUI mode or you’re using some other XDMCP server.

If you’re running XDM, you can configure it to accept remote logins by editing two or three files. The first of these is /etc/X11/xdm/xdm-config. Locate the following line:

DisplayManager.requestPort: 0

Change the 0 in this line to 177 to have XDM listen for remote access attempts. The second file you must edit is /etc/X11/xdm/Xaccess. This file will probably include the following two lines:

# *
# * CHOOSER BROADCAST

Remove the hash marks (#) at the start of these lines to tell the computer to accept remote accesses and to generate a list of available remote hosts, respectively. You can substitute a wildcard matching your network, such as *.example.com, for the simple asterisk (*) in these lines, to limit access to your network. Finally, the third XDM file you may need to edit is /etc/X11/xdm/Xservers. Details vary greatly from one distribution to another, but you’ll probably find a line that resembles the following:

:0 local /usr/X11R6/bin/X -nolisten tcp -br vt7

The -nolisten tcp option prevents X from making remote connections. This won’t affect a thin client’s ability to connect to the computer, but it will prevent you from accessing other X servers from the affected system. Thus, you may want to edit it out. If you don’t want X to run locally at all, you should comment out this line entirely. This will cause XDM to accept remote connections but not to launch X locally.

In theory, KDM configuration is similar to that of XDM; however, you’ll need to track down the equivalent configuration files, which vary greatly in location from one distribution to another. In practice, KDM is also much more finicky than XDM, so configuring KDM can be frustrating. Be aware that you’ll probably need to edit a file called kde-config or kdm-config rather than xdm-config. An additional configuration file, kdmrc, may also require editing. Locate the [Xdmcp] section of this file and edit it so that it includes these lines:

Enable=true
Port=177

GDM uses the gdm.conf configuration file, which usually resides in /etc/X11/gdm. This file is similar to the kdmrc file, and you must make the changes just described to the [Xdmcp]section of this file. Alternatively, you can use the gdmsetup utility to make the changes using a GUI tool.

Whatever XDMCP server you use, you must restart it before the changes you’ve made take effect. This will shut down your current X session, so you should save your work, close your open programs, and log out. On many Linux systems, changing to runlevel 3 and then back to runlevel 5 will restart the XDMCP server. Type telinit 3 followed bytelinit 5 to do this. On others, you can restart the XDMCP server by typing/etc/init.d/xdm restart (you may need to substitute kdm or gdm for xdm on some distributions).

Configuring VNC

If you want to use VNC rather than X, you can do so, but configuration can be tricky; X is generally superior if your thin clients support it. Two popular Linux VNC servers are RealVNC (http://www.realvnc.com) and TightVNC (http://www.tightvnc.com); you’ll run one of these on your login host. Under Linux, VNC is designed to be run by an individual user, and the login connection then accesses that user’s account directly. This approach may be adequate for some small-scale operations, but for greatest flexibility, it’s best to link the VNC server to an XDMCP server. This way, remote users will see a Linux login screen when they connect, so any user with an account may enter a username and password to access the computer.

This configuration requires you to make the changes to the XDMCP setup just described. You can then create a xinetd configuration file, say /etc/xinetd.d/vnc, to launch the VNC server:

service vnc-800x600
{
 disable = no
 socket_type = stream
 protocol = tcp
 wait  = no
 user  = nobody
 server  = /usr/bin/Xvnc
 server_args = -inetd -query localhost \
    -once -geometry 800x600 -depth 24 \
    -fp /usr/share/fonts/local/,/usr/share/fonts/misc/
}

This configuration works for a TightVNC server on a Gentoo Linux system. Unfortunately, the details of VNC configuration vary from one VNC server to another. Thus, you may need to read the man pages and experiment to find a configuration that works. This particular configuration relies on an entry in /etc/services:

vnc-800x600 5901/tcp

This entry assigns TCP port 5901 to the service name vnc-800x600. On the client side, you’ll need to tell the thin client to connect to this port.

decide what software you want to use on the clients, prepare a client configuration, and distribute the software to the clients. The software distribution task can be handled by a TFTP server, as described last month; or you can put the software on a CD-R or other local storage medium. Once you’ve done all of this, you can boot your thin client and, if all goes well, use it.

Thin Client Options

Broadly speaking, thin clients come in two forms: dedicated thin client hardware and general-purpose PCs that run thin client software. Dedicated thin client hardware can be handy if you’re building a network from scratch, but using PCs as thin clients has the advantage of enabling you to re-use outdated but still functional computers.
If you’re using a dedicated thin client, you should consult its documentation to learn how to configure and use it. You should be able to drop some files, provided by the hardware’s manufacturer, into the TFTP server’s files area and configure your DHCP server to point specific machines to particular files. You should then be able to boot your thin clients and get on with using them.
To use an ordinary PC as a thin client, you must have software for it. Linux can serve this role quite well, but the question is, which Linux? I recommend you turn to a dedicated thin client distribution, such as ThinStation or 2x PXES. These distributions include the Linux kernel, X, additional remote-access protocols, and a set of additional tools required to run a system as a thin client. Note that many Linux thin client distributions can access Windows servers as well as Linux (or other Unix) servers.
Requirements for a computer to operate as a thin client are minimal. A Pentium-class CPU will do the job well, but a 486 or even a 386 can serve in a pinch. The ThinStation developers recommend a minimum of 64MB of RAM. You do not need a hard disk.
You do need a keyboard, mouse, and monitor, of course. To function well with modern Linux software, the video card and monitor should be capable of 1024×768 resolution or better, although lower resolutions will work. A network card is an absolute necessity. If the network card supports network booting via the Preboot Execution Environment (PXE) protocol, the thin client need not have a floppy disk or CD-ROM drive, but one or both of these will be required if the network card doesn’t support PXE.

Configuring ThinStation

I’ll describe ThinStation in more detail, since it’s a ready-made package that’s relatively easy to configure. Several options for obtaining and configuring ThinStation exist in its Web site’s downloads section, including a couple of source packages, a pair of prebuilt images (for CD-R and network boots), and TS-O-Matic (for highly customized configurations).
Because they’re relatively easy to set up, I describe the two prebuilt images in more detail. You should download whichever one seems more suitable for your network. The NetBoot version requires a network card that’s supported by the network booting tools, as well as working DHCP and TFTP servers on your network. The NetBoot system might or might not require a working floppy or CD-ROM drive, depending on the client’s motherboard and network card BIOS support. I describe version 2.2 of ThinStation.
You should begin by downloading the relevant files (Thinstation-2.2-prebuilt-NetBoot.zip andThinstation-2.2-prebuilt-LiveCD.zip), which you can uncompress with the Linux unzip utility. The result will be one directory tree for each zip file. How you proceed from here depends on which version you’re using.

Distributing ThinStation via CD-R

Once you’ve uncompressed the LiveCD image of ThinStation, you’ll need to prepare two disks: a CD-R and a floppy. The CD-R image is stored in the Cd subdirectory asthinstation.iso. You can use cdrecord under Linux to burn this file to a blank CD-R:

cdrecord dev=/dev/cdrom thinstation.iso

You may need to modify this command to suit your hardware; consult the cdrecord man pages for details.
The CD-R contains the ThinStation OS, including a Linux kernel, X server, and so on. This software does a remarkably good job of detecting and adapting to a wide variety of hardware; however, some configuration settings need to be set manually. For this task, you must prepare a floppy disk. Start with a FAT-formatted floppy (prepared on a Windows box or by using mkdosfs in Linux).
Mount it in Linux, copy the thinstation.conf.user file from the Floppy/thinstation.profilesubdirectory of the LiveCD directory tree, and begin modifying the on-floppy version of this file. The file format is fairly obvious and the sample file does a good job of explaining the various options.
Use the NET_USE_DHCP option to enable or disable the use of DHCP. If you don’t use DHCP, you can set the IP address, and so on. Using DHCP is almost certainly the best approach unless your network lacks a DHCP server.
Much of the remaining configuration involves setting up various session types. ThinStation supports Windows Terminal Server, Citrix Server, X, VNC, Telnet, SSH, and AS400. Each has a sample configuration section with options that begin SESSION_#, where # is a session number.
You must number your sessions starting with 0. The original file supports just one session, a Windows Terminal Server session. To use a thin client with a Linux host, you’d comment out this configuration block, uncomment the X and/or VNC blocks, and make appropriate changes. For instance, to support one X and one VNC session, you might make changes so that your file includes the following lines:

SESSION_0_TITLE="Linux X sessions"
SESSION_0_TYPE=x
SESSION_0_X_SERVER=192.168.1.2
# Default is '-query'
SESSION_0_X_OPTIONS="-indirect"
# You should set also "SCREEN_X_FONT_SERVER", below

SESSION_1_TITLE="Linux via VNC"
SESSION_1_TYPE=vncviewer
SESSION_1_VNCVIEWER_SERVER=192.168.1.2:5901

This configuration tells ThinStation to connect to the server at 192.168.1.2 for both X and VNC. The use of the SESSION_0_X_OPTIONS="-indirect" line tells ThinStation to use an indirect XDMCP request. This results in a list of available XDMCP servers when you select this session type, so you can use any remote system that accepts XDMCP logins.
The default option of "-query" results in a direct login to just one X server, which may be preferable if you’ve only got one or two systems. The VNC IP address appends a port number (5901) to the end. This is handy if you define multiple VNC configurations on the server to support different screen resolutions or other features. Note that you can include more than one session of a single type. For instance, you might have three X sessions and two VNC sessions defined.
Further down in the file you’ll find some miscellaneous additional options. I recommend you pay particular attention to the following:

• SCREEN_RESOLUTION Set the screen resolution in the obvious way using this option.
• SCREEN_COLOR_DEPTH Set the screen’s color depth with this option.
• SCREEN_HORIZSYNC and SCREEN_VERTREFRESH Set the monitor’s horizontal and vertical sync ranges with these options. You may need to consult the monitor’s manual to learn what appropriate values are. Note that very old monitors can be damaged if you set these values inappropriately.
• MOUSE_ options Several options beginning with MOUSE_ default to values that are suitable for PS/2 mice. If the thin client has an RS-232 serial, USB, or other mouse, you may need to adjust these items.

Once you’ve made your changes, unmount the floppy disk. You can then walk the floppy and CD-R over to the computer you intend to use as a thin client and test them, as described shortly, in “Using ThinStation.”

Distributing ThinStation via TFTP

If you want to boot and distribute ThinStation via your network, you can do so with the help of the NetBoot image. Just as with the LiveCD version, you must attend to two key details: the ThinStation OS itself and a configuration file. Within the ThinStation-NetBoot directory tree, the TFtpdRoot subdirectory holds a file called thinstation.nbi (autoextract).exe. This is a Windows self-extracting archive that holds the ThinStation OS. You can extract this file on a Windows machine or use WINE under Linux to extract it.
The extracted file is called thinstation.nbi, and you should place it in your TFTP shared directory and ensure that your DHCP server is configured to point to this file, as described last month. If any of your computers have network cards that support direct network boots via PXE, you should also copy the thinstation.nbi.zpxe file to the same location, and point to this file using the filename line in dhcpd.conf.
If your network includes both PXE-enabled computers and those that don’t support PXE, configure DHCP to point to the thinstation.nbi.zpxe file; the disk-based boot tools described shortly are smart enough to drop the .zpxe filename extension.
In addition to the thinstation.nbi file, you’ll need to edit a ThinStation configuration file and place it in the TFTP files directory. The sample file is located in the TFtpdRoot subdirectory as thinstation.conf.network. Copy this file, without renaming it, to your TFTP server’s files directory. You can then edit the file to make the changes described for thethinstation.conf.user file for the LiveCD version of ThinStation; however, you don’t need to copy the file to a floppy disk, since clients will retrieve the file via TFTP.
If your thin clients have differing hardware capabilities, you can create custom configuration files for each client. The simplest way to do this for a small number of clients is to create a new configuration file for each computer. This file contains only the unique items for this computer — say, SCREEN_RESOLUTION if the computer has a higher- or lower-resolution screen than others.
Name the new file thinstation.conf-ID, where ID is the computer’s IP address or MAC address. For instance, thinstation.conf-192.168.1.27 holds the customizations for the thin client with an IP address of 192.168.1.27, or thinstation.conf-000C7696A373 holds customizations for the thin client with a network adapter MAC address of 00:0C:76:96:A3:73. A more sophisticated method of creating customizations, which may be preferable for networks with lots of systems, is detailed in the _HowTo-NetBoot.txt file that comes with the NetBoot distribution.
Once these files are all copied to your TFTP files directory, you may need to prepare a boot floppy or CD-R. These images are stored in the BootDisk subdirectory. You can prepare a boot floppy by placing a formatted floppy disk in the drive, entering the BootDisksubdirectory, and typing:

dd if=eb-net.dsk of=/dev/fd0

If your target thin client lacks a floppy disk but has a CD-ROM drive, you can usecdrecord to burn the eb-net.iso file to CD-R:

cdrecord dev=/dev/cdrom eb-net.iso

You may need to tweak one or both of these commands for your system.
If your thin client supports PXE network booting, you shouldn’t need either the boot floppy or boot CD-ROM, but you may need to enter your BIOS setup utility to configure the boot devices. Be sure that booting from the network is an option, and that it’s higher in priority than other valid boot devices (such as a hard disk, if that disk is bootable).
Some plug-in network cards have boot ROMs that support PXE booting. When using such cards, you may need to disable other valid boot devices in your main BIOS. Consult the network card’s documentation for details.

Using ThinStation

To begin using ThinStation, you should first ensure that your servers are all configured and running, as described last month. Boot your thin client using whatever boot media you’ve prepared. If all goes well, you’ll see a series of boot messages appear on the screen, followed by a selection screen that lists your session options. Select one to test it.
Check to be sure you can log in fully and run programs. When you log out, you may be returned to the session selection screen or to an XDMCP login screen. If you see the XDMCP login screen but want to try another session, press Ctrl+Alt+Backspace to kill X; this will return you to the session selection screen.
Unfortunately, things don’t always go according to plan, and thin client troubles can be tricky to debug. Some common symptoms and likely solutions include:

• A failure to fully boot, with a repeated listing of network modules — ThinStation locks itself into an endless loop testing its network drivers when it can’t detect a network card. If this happens, you may need to swap in a new network card or use the TS-O-Matic or Main Distribution option to create a custom ThinStation distribution that includes support for your card. A similar symptom can occur if your boot file (as specified by the filename option in your DHCP configuration) doesn’t exist. Be sure the filename matches.
• A blank screen when you select an X session — ThinStation sometimes fails if you select an X session too quickly after the session list appears. Reboot and pause for a few seconds before selecting the X session.
• A corrupt or blank display when you select a session — This can happen when you’ve specified incorrect video timing (horizontal and vertical sync values) for your monitor. Review your documentation and try again.
• An “X”-shaped cursor on a gray background after you select an X session — This problem can occur when your XDMCP server isn’t properly configured. Review that part of the configuration. You might find it necessary to change XDMCP servers; I find that GDM and XDM are easier to configure than KDM.

In addition to these issues, firewall configuration can cause problems. Your host computer must not block incoming access to any of the vital ports. Such blocks can manifest themselves as problems at various points along the way.
With any luck, you won’t run into serious problems. Once it’s running, a thin client can be used much like a conventional desktop system. The fact that it’s running remotely will cause a speed hit, particularly on display-intensive applications. For typical office productivity tools, though, thin clients can be very usable tools.