Linux in a Windows World/Remote Login Tools/Linux Thin Client Configurations

From WikiContent

< Linux in a Windows World | Remote Login Tools
Revision as of 21:46, 11 March 2008 by Docbook2Wiki (Talk)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
Linux in a Windows World

Chapter 11 presented information on using GUI remote login protocols—namely, the X Window System and Virtual Network Computing—to control one computer from another one. This technique can be handy in many situations, as described in Chapter 11. One specific application of this technique deserves elaboration, though: thin client computing. In a thin client environment, one computer (the thin client) is configured with a minimal OS installation and is dependent on another computer (the server) to handle most computing tasks, aside from input/output. This approach to computing can greatly simplify system administration by centralizing most administration tasks on a single larger server. It also enables you to extend the life of aging computers; even a 486 system might make an acceptable thin client! It does require a server that's powerful enough to handle multiple simultaneous logins, though. Thin clients are best used by workers who need to run a handful of low-resource applications. You don't need to use thin clients for everybody; you can mix thin clients with more conventional desktop systems.


You can use Linux as a thin client OS, on the server side, or both. Windows systems can function as servers, although Windows needs special software to handle multiple simultaneous users.

This chapter begins with an overview of thin client computing—what it is and when you might want to use it. Next up is a look at the hardware you'll need to deploy a thin-client network, including the thin clients themselves, their servers, and the network infrastructure requirements. The next topic is configuring Linux as a thin client, which builds on the VNC client and X server topics in Chapter 11. Finally, this chapter looks at how to configure a Linux system as a server for Linux or non-Linux thin client workstations.


The Role of Thin Client Computing

Thin client computing can be a great way to stretch limited computing budgets and simplify system administration headaches. It's not the best solution to all problems, though. Deciding when to use thin client computing requires understanding the different forms it can take and the advantages and disadvantages of these forms.

Types of Thin Client Computing

In practice, the term thin client computing covers a range of configurations, from extremely simple thin clients that use powerful remote login servers to much more capable thin clients with substantial onboard software that uses remote login servers for file storage and software not provided on the thin client. In fact, it can sometimes be difficult to draw the line between thin client configurations and traditional desktop systems that use remote login servers for occasional uses or specialized tasks. Different people can draw this line in different places or by using different definitions. For instance, one common definition uses the presence or absence of a hard disk on the client as a deciding feature: if a system has no hard disk, it's a thin client. Not all thin client definitions include this feature, though.

In practice, thin client computing is essentially a return to an older model of computing that was common in the 1960s through the 1980s, in which dumb terminals were the primary means of accessing the mainframes and minicomputers of the day. Typically, employees, students, or other users would use the dumb terminals (which provided text-only displays) from their desks or from public computing environments. After the advent of X for Unix, some dumb terminals were replaced by X terminals , which were essentially dumb terminals capable of running an X server. In fact, X terminals are still available today and can make excellent thin clients for Linux systems.


An X terminal runs an X server, but in the language of the thin client world, the X terminal is a thin client. This is yet more confusing fallout from the peculiar client/server relationship in X, as described in Chapter 11.

Although you can use old-style dumb terminals (or computers that run terminal emulators to stand in for dumb terminals) with Linux, modern thin client computing relies on GUI remote login tools to run GUI programs. Chapter 11 describes two protocols that are commonly used in thin client computing, but the range of possible protocols is actually wider than that:

The X Window System
X can make an excellent thin client protocol when accessing Linux (or other Unix-like OSs). You can run Linux and X on older or stripped-down systems or use dedicated X terminals as thin clients. You can't easily use X to access Windows servers, though, except in limited ways.
VNC, or the Remote Frame Buffer (RFB), as the protocol is more properly known, is a useful thin client tool. Linux can function as a VNC server or client, enabling you to reuse old computers. You can also run a VNC server on Windows systems to provide remote access, although VNC doesn't provide multi-user access to Windows. (Using VNC to access Linux isn't so limited.) Some dedicated thin client appliances support VNC, so it can provide remote access to Linux from such thin clients.
The Remote Desktop Protocol is Microsoft's favored thin client protocol and is supported by Microsoft's Terminal Server software package. Linux RDP client packages are available, such as rdesktop ( that lets you configure a Linux system as a thin client for a Microsoft server.
The Independent Computing Architectureprotocol is favored by Citrix, which provides tools to access Microsoft Windows servers using thin clients that support the ICA protocol. Citrix ( provides a free ICA client for Linux, so Linux can function as a good ICA thin client OS.

Typically, to provide remote access to Linux systems, you'll use X or VNC. To access Windows systems, VNC, RDP, or ICA will work, although only the latter two protocols support multiuser access. (Technically, changes to the underlying OS enable multiuser access; the protocols simply connect to that new feature.) Thus, RDP and ICA are the protocols of choice for thin clients accessing Windows servers.

When to Use Thin Client Computing

This chapter has already alluded to some of the advantages of thin client computing, namely hardware cost savings. This isn't the only reason to use this approach, though. Here are some common advantages of thin client computing:

Hardware cost
By recycling old computers as thin clients or buying new stripped-down computers or dedicated thin clients, you can reduce your expenditures on new desktop systems and upgrades to desktop computers.
Thin clients, being much simpler than conventional desktop systems, are less likely to break down, all other things being equal. This can reduce the need for tedious hardware troubleshooting sessions.
Reduced noise and power consumption
Particularly if you use dedicated thin client hardware or old computers without hard disks, thin clients are likely to be quieter and consume less power than full desktop computers. This also results in less heat, which can help lower air conditioning bills. One partial exception to this rule is if you reuse old CRT monitors rather than buy new LCD monitors. CRT monitors consume a lot of power compared to new LCD monitors, replacing CRTs with LCDs can further reduce your power consumption.
Decoupling users from hardware
In a thin client environment, any user can use any thin client computer. Users see their own desktop environments and their own files, no matter which thin client is used. This feature can be great in public computing centers or when you want to upgrade hardware or move users between offices.
Administrative effort
Administering a single login server computer and dozens of thin clients is typically simpler than administering dozens of desktop computers.
In some sense, this advantage is a corollary of the last one. Simple thin client computers are less likely to become infected by worms or otherwise compromised than are typical desktop systems. This advantage is particularly great if the thin clients are simple dedicated units with their OSs in ROMs or if they can boot from files stored on a network server. If you use Linux systems with their own hard disks as thin clients, an intruder might be more likely to gain access to and modify the clients. Thin clients can also benefit by the fact that it's seldom necessary to give them public IP addresses; they can reside on entirely private subnets that link only to your local servers and to each other. This can be even more secure than a conventional desktop behind a network address translation (NAT) router, because the thin clients can't initiate outside connections (say, because of a viral infection).

Ultimately, most of these advantages boil down to cost, either for hardware or for labor in maintaining all of a site's computers. These advantages are offset by disadvantages, though, some of which are in the same areas as the advantages:

Hardware cost
The cost benefit on the client is at least partially offset by the fact that you'll need to invest more in the server or servers that users will access. The login server must typically be substantially more powerful than individual workstations, although precisely how much more powerful depends on your site's computing needs. Light uses, such as word processing, may need a server scaled to the needs of a typical user plus a small increment in RAM and CPU speed for each additional user. CPU- or RAM-intensive tasks such as running scientific simulations may not work well at all with a centralized approach unless you invest in a very powerful server. As a general rule of thumb, a high-end IA-32 system (say, one that sells for about $3,000) can usually support about 30 users.
Although thin clients are likely to be more reliable than individual desktop systems, this approach is essentially one of putting all your eggs in one basket. If the login server computer or your main network infrastructure fails, no user will be able to do any work. For this reason, you should be particularly careful in buying or building a login server for a thin client environment; buy the most reliable hardware possible, and whenever possible, employ reliability-improving tools, such as a Redundant Array of Independent Disks (RAID) array. Keep backups of your data and have backup hardware on hand so that if a critical server hardware component fails, you can quickly replace it. Using server clusters or having redundant servers can also be useful techniques to improve reliability. Also, if you use old PCs as thin clients, their reliability advantage over new desktop systems may evaporate, but the thin clients are cheap and easy to replace should they break.
Local devices
Using some types of local hardware devices, such as sound cards, scanners, and CD-ROM drives, can become tricky in a thin client environment. Solutions to these problems do exist, but they often require extra configuration to work well. For instance, you might need to configure a thin client computer as a file server to give users access to a local CD-ROM drive.

Thin clients can be deployed in any number of environments, from two-user small offices to academic or corporate sites with thousands of users. Depending on the type of work being done and the server's speed, a single server can support anywhere from a handful of concurrent users to several dozen; thus, large sites are likely to have multiple servers.

The thin client approach tends to work best with applications that are relatively undemanding in terms of the CPU and display. CPU-heavy tasks such as raytracing or scientific simulations work best when all users have their own CPUs, and graphics-intensive tasks, such as watching real-time video, make huge demands on network infrastructure when deployed on thin clients. Tasks that are better suited for thin client environments include word processing, light spreadsheet use (so long as spreadsheets aren't doing extremely lengthy computations), reading email, web browsing, using a corporate database, and other basically textual tasks. These jobs require users to read for long periods of time, and much of the interaction involves typing, which changes the onscreen display slowly.

Hardware Requirements

One of the advantages of thin client computing is that it minimizes the hardware requirements, at least for the computers at which users actually sit. The server hardware, though, must be heavy duty, at least if it's to support more than a few users. Thus, you must evaluate your hardware requirements very differently for the two sides of the thin client/server coin. You must also consider the hardware that connects these two sides of the coin, because a deficiency in your network infrastructure will severely degrade a thin client network.

Server Requirements

The trickiest part of determining your thin client network's hardware needs is in deciding what sort of hardware to use on the server. This task is made extremely difficult by the fact that it varies so much depending on the type of work done at your site. Different programs make different demands on memory and CPU time, and these demands scale differently to multiuser loads.

The scaling question is an important one. For instance, suppose you've determined, through experimentation, that a desktop system needs a 2-GHz Pentium 4 CPU, 512 MB of RAM, and a 60-GB hard disk to operate comfortably for a typical user. An obvious, but probably wrong, extrapolation would be that a 10-user server would need a 20-GHz Pentium 4 CPU, 5 GB of RAM, and a 600-GB hard disk—10 times the single desktop system's values. (Of course, some of these specifications, such as a 20-GHz Pentium 4 CPU, can't be met!) Most desktop computer CPUs are idle most of the time; processing user keystrokes and mouse clicks as they use a word processor, web browser, or most other user applications takes little CPU time. Likewise, a great deal of RAM is consumed by the OS kernel and other overhead items that's not duplicated in a multiuser environment. In addition, shared libraries can greatly reduce the memory footprint of adding new users when they all run more or less the same programs. Similar comments apply to disk space. Depending on the applications used, a 10-user system might need only a 3-GHz CPU, 1 GB of RAM, and 120 GB of disk space to provide performance comparable to a 2-GHz CPU/512-MB RAM/60-GB disk single-user desktop system, or it might need something more powerful.

Beyond a certain point (typically about two or three dozen users), scaling a single server becomes impractical. Thus, if you need to serve several dozen to thousands of users, you should look into multiserver configurations. In this configuration, load balancing can become an important issue, but this topic is beyond the scope of this book.

In early 2005, desktop users can still usually work quite well with single-CPU Intel Architecture 32 (IA-32) systems. In any but the smallest thin client configurations, though, your server should have more CPU power, and is likely to benefit from a shift to a multi-CPU or 64-bit system. Of these two features, multiple CPUs are likely to be more important than 64-bit CPUs. The latter are most likely to be necessary if the total memory exceeds 4 GB; unless they use special tricks, IA-32 systems are limited to 4 GB of RAM. Although 64-bit multi-CPU systems tend to be expensive, each one can serve quite a few users, which greatly reduces the per-user cost.

The login server systems for thin clients also need fast and robust disk subsystems. In the past, this has usually meant RAID arrays based on SCSI drives, and indeed SCSI RAID systems are still a good, if expensive, choice for this role. Recently, though, SATA RAID hardware has become common, and such systems often at least approach the performance of SCSI RAID systems, although they tend to produce higher CPU loads, so SCSI still beats out SATA.


Many motherboards include SATA controllers that claim to be RAID-enabled; however, most or all of these are actually fairly ordinary non-RAID controllers with minimal BIOS hooks and drivers that enable RAID functionality in software. Linux also provides software RAID drivers, but for the best possible performance, particularly at RAID levels 4 and 5, which provide error correction features for improved reliability, you need a true hardware RAID driver with support for the server's OS.

Of course, the login server needs the best available network hardware. Most systems sold today include gigabit Ethernet. To do any good, though, the gigabit Ethernet or other high-speed network connector must either be matched with equivalent hardware on the clients or fed via a switch or router that can combine slower client feeds into a faster link to the server.

Client Requirements

The requirements of the thin client depend to some extent on your site's needs. For instance, you might need extra-large displays, clients that can handle multiple protocols, or clients with their own built-in web browsers. Much of the appeal of thin client computing, though, is that the thin clients themselves are commodities; you can reuse old PCs as thin clients, buy dedicated thin client hardware, or both. You can replace one thin client with another one (even a very different one) with little impact on its user's ability to work.

If you intend to recycle old PCs as thin clients, the basic needs are fairly minimal: the computer must be functional and have some form of network connection. In theory, even an RS-232 serial port for using the Point-to-Point Protocol (PPP) will do, but in practice, Ethernet or some other network protocol is needed. The computer must have a working monitor, keyboard, and mouse. If you intend to run Linux on the system, it must have an 80386 or better CPU and sufficient RAM for your distribution. In practice, a fast 80486 or slow Pentium-class CPU and 16 MB or even 32 MB of RAM is likely to be desirable. Older computers are unlikely to have speedy video hardware by today's standards, but most should suffice for simple GUI programs. The biggest problem with old video hardware is the amount of RAM they hold, which influences the maximum display sizes (in pixels) and color depths they support, as summarized in Table 12-1. You can use older Macintoshes or other computers with CPUs other than those in the IA-32 line, but some of the Linux distributions that work best as thin clients are designed exclusively for IA-32, so your configuration task is likely to be harder with these computers.

Table 12-1. Video RAM and supported video modes

Resolution 8-bit (256 colors) 16-bit (65,536 colors) 24-bit (16,777,216 colors 32-bit (4 billion colors)
640 480 300 KB 600 KB 900 KB 1.2 MB
600 800 469 KB 938 KB 1.4 MB 1.8 MB
1024 768 768 KB 1.5 MB 2.3 MB 3.0 MB
1280 1024 1.3 MB 2.5 MB 3.8 MB 5.0 MB
1600 1200 1.8 MB 3.7 MB 5.5 MB 7.3 MB

Both dedicated thin clients and those built from old computers may require some hardware replacements, such as upgraded monitors, video cards, and mice. Mice are particularly worthwhile upgrades because many GUI Linux programs assume the user has a three-button mouse. They can work with two-button mice using a chord (pressing both buttons simultaneously) as a stand-in for the middle (third) button, but this is a bit awkward.

If you intend to purchase dedicated thin clients, you should study their specifications very closely. Many thin clients are intended for use solely with Windows, using RDP or ICA. Such clients won't work with Linux servers; for that, the thin client should support either X or VNC. If the client will be used with both Linux and Windows servers, be sure it supports all the necessary protocols.

To operate as fully diskless systems, many thin clients must have network cards with ROMs that support booting from the network. Such configurations also require you to configure a system to respond to the boot requests and deliver appropriate files to the thin client. (This topic is described in more detail later, in Section 12.3.) If you're trying to recycle older PCs, you may therefore need to use a local boot disk (a floppy disk, CD-ROM drive, or even a hard disk) or replace network cards that don't enable you to boot from the network.

Network Hardware Requirements

Because thin client computing requires transferring large amounts of data, you must pay careful attention to your network infrastructure. An outdated network will likely perform so poorly as to make a thin client configuration impractical, even if everything else is done right.

Generally speaking, on a network of up to a dozen or so users, you must have a 100-Mbps local network that uses switches. Up to a few dozen, a similar configuration will work, but you should upgrade the server's network card to support gigabit Ethernet and use a switch that can handle the gigabit/100-Mbps interface.

If your network hosts more than a few dozen users, you may need to upgrade it further or segment it in some way. (Such a network will also probably require multiple servers.)

No matter the details of your network hardware, you should attend to its reliability and monitor its performance. Flaky old network cables, overheated switches, and other problems can cause degraded performance or complete loss of connectivity. If you're considering switching an existing network to a thin client model, you might need to look into replacing some or all of your network infrastructure to deal with the increased demand. On the other hand, a fairly recent network may be up to the requirements just fine. You'll have to evaluate your network hardware yourself.

Linux as a Server for Thin Clients

Thin clients rely on servers to do any good. Most obviously, this reliance is on the login servers themselves. Chapter 11 describes two such servers, XDMCP (for use with X) and VNC. For the most part, the configurations described in that chapter work well with thin clients, although there are a few caveats. Thin clients booted from the network also rely on DHCP and TFTP, so knowing how to configure these two servers is important.

Linux Distribution Selection and Configuration

In principle, you can use any mainstream Linux distribution as a login server for thin clients. Distributions that are geared toward desktop use, such as Mandrake and Xandros, can provide lots of eye candy and be very friendly to users, but these features may generate more in the way of video (and hence network) activity than you'd like, because they might use lots of animation and demand large or color-intensive displays. Thus, you might prefer starting with a distribution that provides less fluff, such as Debian, Gentoo, or Slackware, and build it up to the point that you want and no further. This can help you control network and server load.

For the most part, you can configure a Linux login server for thin clients just as you'd configure any other desktop system. Appendix B describes some of the issues involved in such a configuration. When planning this configuration, remember that the video display involves a network access, so features such as animated icons will consume network bandwidth. Because thin clients may be running on small or low-bit-depth displays, you may also need to test your applications on such systems, and perhaps adjust their default configurations.

XDMCP and VNC Options

Fortunately, very little needs to be done to XDMCP and VNC configurations to support thin clients. The configurations described in Chapter 11 should work fine with X terminals and thin clients that support VNC.

For XDMCP, though, one feature you may want to be sure you support is indirect accesses. Some X terminal thin clients can't present a list of available servers by themselves; they need the help of an XDMCP server that's configured to provide this list. This can be accomplished on the XDM and KDM servers by editing the Xaccess file to include an appropriate line:


You can also specify a pattern of hostnames for the asterisk (*), which lets only specified computers receive the server list. In GDM, the equivalent configuration can be found in the gdm.conf file, which is usually in /etc/X11/gdm:


This line should appear in the [xdmcp] section of the file. In either case, you must then configure your thin client to make an indirect query of the XDMCP server that supports indirect lookups.

Of course, all this is necessary only if you want your users to be able to use more than one computer from their thin clients. If each thin client should connect to precisely one system, you can configure it to make a direct connection to the remote system and be done with it.

If you're running VNC on the Linux system to enable remote logins via thin clients, chances are you'll want to link VNC to an XDMCP server. This configuration enables users to type their usernames and passwords when logging in, rather than logging in via a text-mode protocol, running a VNC server, and then connecting to a specified port. Linking VNC to XDMCP is described in Chapter 11, so consult it for details.

DHCP Configuration

Thin clients are generally much simpler to configure if you use DHCP to help configure them, particularly if you want the thin client to download its OS from a TFTP server. DHCP configuration is described in more detail in Chapter 15, so if you're not already familiar with DHCP configuration, consult that chapter.


Many thin clients actually use a protocol known as BootP for automatic configuration via a BootP server. DHCP provides a superset of BootP functionality, though, and common DHCP servers can configure BootP clients. Thus, I describe DHCP configuration using the common Linux DHCP server. This configuration should work with clients that use BootP.

In addition to the common options described in Chapter 15, you may want to add more options for the benefit of thin clients:

allow booting
This global option enables support for clients that boot remotely.
allow bootp
This global option adds support for BootP, which is necessary for some thin clients.
option x-display-manager
This option delivers the name of the XDMCP server for the network. Some X terminals use this information to locate an XDMCP server, but not all do so. This option is important only if you're using X as a remote GUI access tool.
option tftp-server-name""
You can tell thin clients where to go to find their boot files with this option, which takes the hostname of the Trivial File Transfer Protocol (TFTP) server as an option.
This option normally appears within a parameter block for a group of servers. It has an effect similar to that of the tftp-server-name option, and you should normally give it the same hostname or IP address as a value.
This option also typically appears in a group with other options. It specifies the filename that a server is to download from the TFTP server. For Preboot Execution Environment (PXE)-enabled PXES clients, this should often be /pxes/pxelinux.0, which is essentially a PXE boot loader. For EtherBoot clients, it should be the filename of the network bootable image you specified when you enabled this support when configuring PXES. In either case, this filename is specified relative to any chroot environment used by the TFTP server, if the TFTP server is run that way. For dedicated thin clients, consult their documentation; they may come with a floppy disk or CD-ROM with files that the TFTP server should deliver, and this parameter will do the job.

Consider Example 12-1, which shows a short but typical configuration for enabling network booting. Many of these options are described in Chapter 15, so consult it for details. This listing points to an XDMCP server and a TFTP server in the opening lines. It also creates a group with options for PXE-bootable hosts, including an additional pointer to the TFTP server and a reference to the file that's to be delivered to the clients. (To use EtherBoot rather than PXE, change the filename to point to an appropriate .nbi file.) Two specific clients are defined in this group; you can create other groups with other options. This might be handy if your thin clients have different needs, in terms of features such as default resolutions or even the OSs they run. You can mix Linux-based PXES clients with dedicated X terminals, for instance, by creating separate groups for each set of systems and identifying individual clients by their hardware Ethernet addresses.

Example 12-1. Sample /etc/dhcpd.conf file to support booting thin clients

allow booting;
allow bootp;

# Standard configuration directives...
option domain-name "";
option domain-name-servers,;
option routers;
#option resource-location-servers server.your.domain;
#option font-servers server.your.domain;
option x-display-manager;
option tftp-server-name "";

max-lease-time 120;
default-lease-time 120;

subnet netmask {

# Options for PXE-bootable hosts
group {
    server-name "";
    filename "/pxes/pxelinux.0";
    get-lease-hostnames true;
    use-host-decl-names on;

    host thin1 {
        hardware ethernet 00:0C:76:96:A3:73;

    host thin2 {
        hardware ethernet 00:80:C6:F9:3B:BA;

TFTP Configuration

Configuring your DHCP server to deliver information to clients is only part of the job. To do any good, clients must be able to download Linux files from a server. The TFTP protocol was designed for this task; it's a very simple file transfer protocol that's useful for clients with minimal software, such as systems that haven't yet fully booted.


Despite the similarity in names, TFTP is not closely related to FTP. Most importantly, an FTP server can't handle requests from TFTP clients; you must install a TFTP server.

Most Linux distributions ship with a TFTP server, typically in a package called tftp. This server is usually launched through a super server such as inetd or xinetd. A typical xinetd configuration, stored in /etc/xinetd.d/tftp, looks like this:

service tftp
  socket_type  = dgram
  protocol     = udp
  wait         = yes
  user         = root
  server       = /usr/sbin/in.tftpd
  server_args  = -s /tftpboot
  disable      = no

This configuration is fairly typical of xinetd-launched servers that use UDP. If your distribution uses xinetd, chances are it ships with such a configuration file, but it may be disabled by default; you must change disable = yes to disable = no.

This example also passes an argument to the TFTP server: -s /tftpboot. This option tells the TFTP server to use the chroot( ) system call, which "locks" the running program in the specified directory, making the server treat that directory as if it were the root directory for the system. This is a useful security feature, and it has implications for file access and naming; all files served by the TFTP server must reside in the specified directory tree, and references to files omit the name of the chroot directory. For instance, the file /tftpboot/pxes/pxelinux.0 is referred to as /pxes/pxelinux.0 in client configurations. Because boot clients receive their filenames from a DHCP server, this means you must use these truncated filenames in DHCP server configurations.


In theory, you should be able to install and run the TFTP server on any computer on your network. Unfortunately, some thin clients seem to assume that the DHCP and TFTP servers are one and the same. Thus, if you have problems getting some thin clients to boot, you may want to consolidate both functions on a single computer.

Linux as a Thin Client

Because of its low cost and flexibility, Linux can make an excellent thin client OS. You can load Linux on computers that aren't powerful enough to run the latest software, configure Linux to run appropriate thin client software, and the computer can then access more powerful Linux, Windows, or other computers.

In many respects, the simplest thin client configuration is to use a traditional Linux distribution or a dedicated thin client package to run Linux as a thin client, using a basically traditional hardware configuration, including a local hard disk or at least a CD-ROM drive. Perhaps the most appealing way of doing the job is to use a dedicated thin client distribution, which provides you with precisely the tools you need—no more and no less—to use Linux as a thin client. However you do it, you can run Linux without a hard disk using a bootable Ethernet card and configuring a system to deliver Linux OS files to computers that boot with such a card.

Distribution Selection and Installation

Your first choice is what distribution to use on the thin client computers. The needs of a thin client are such that a good desktop or server distribution may not be the best choice for a thin client. Many popular distributions, such as Fedora, Mandrake, and SuSE, install many unnecessary desktop or server applications that, in fact, may be undesirable on a dedicated thin client. These distributions also often require a lot of disk space or memory—features that may be lacking on the older computers you want to convert to thin client status.

Among mainstream Linux distributions, those that install small standard package sets by default are likely to be the best choices for thin client use. For instance, Debian, Gentoo, and Slackware can all be installed in well under 1 GB of disk space, omitting such large packages as GNOME, KDE, Mozilla, and Even if users will ultimately run these packages, they'll probably be run from the server, not on the thin client. Slimmer Linux installations are likely to lack a few components you need, at least in their minimal installations. Most notably, you'll probably have to install an X server (XFree86 or Depending on the protocols used by your server, you may also need to install a thin client package, such as a VNC client.

Another option, and one that's arguably superior even to the slimmed-down mainstream distribution option, is to use a distribution that's dedicated to thin client use. Notable in this regard are the PXES (, LTSP (, and ThinStation ( distributions. These are distributions that support the PXE system, which is a way for computers to boot over a network from a remote server. These distributions are useful tools if you want to divest yourself of a local hard disk, as described in Section 12.4.4, but you can also install these thin client distributions directly on a local hard disk or on a CD-ROM to use on computers with network cards that don't support direct network boots.

Configuring PXES

Because PXES is designed explicitly for thin client use, this section describes it in more detail. You can download PXES in several forms from its web site. The CD-R image (.iso) file is a quick way to get started, particularly for testing its operation. This image file, though, is very generic; it runs in 800 600 mode by default and may not take proper advantage of your network's resources. To best use PXES, you should download the pxes-base and pxesconfig packages, both of which are available in RPM and tarball forms. You can then create a PXES image that's customized for your needs and can be booted from a hard disk, from a CD-R, or from the network. This section uses PXES Version 0.8-9 as an example; if you use another version, it may differ slightly from what's described here.


Before you can use PXES (or any other thin client), you need to have a remote login server configured. Chapter 11 describes this topic for Linux systems. Some configurations also require you to run a TFTP server to deliver OS files to the PXES thin clients. (The TFTP server can run on the same computer as the remote login server, or it can be on another system.) The basics of TFTP configuration are described in the earlier Section 12.3.4.

Once you've downloaded the base and configuration packages, install them on an existing Linux distribution. (This system doesn't need to be the same as your ultimate login server; it's just a platform for customizing the PXES client files.) You can then use the configuration utility to enter details of your network's configuration and create a custom PXES image, which you can then burn to a CD-R, place on a hard disk, or deliver to thin clients via TFTP. The configuration tool uses a wizard to guide you through the configuration steps:

  1. Create an entry in your /etc/fstab file for a special loopback device the configuration tool can use to create a small RAM disk that will hold the PXES distribution:
    /tmp/pxes.initrd  /tmp/pxes  ext2  loop,noauto,user,owner  0 0
  2. As root, type pxesconfig to launch the utility. The first screen of the PXES configuration wizard should appear.
  3. Click Next in the wizard's window. The result should resemble Figure 12-1.

    Figure 12-1. pxesconfig uses a wizard to guide you through the PXES configuration tools

    pxesconfig uses a wizard to guide you through the PXES configuration tools

  4. Select the "Initialize ram disk contents" item in the "Initial ram disk" area of the window. The program will warn you that the current RAM disk's contents will be destroyed. However, because the package doesn't ship with a default RAM disk, nothing is destroyed unless you've already run the program. This action makes a few more options available.
  5. If you want to use a kernel other than the default provided with the package, specify it on the Kernel File Name line. Chances are the default kernel will work fine. Be sure to note the location of the kernel and the other files specified on this page of the wizard.
  6. Check one or both of the "Enable network bootable image generation" or "Enable ISO 9660 bootable image generation" options if you want to use EtherBoot for network booting or a CD-R disc for booting thin clients using local CD-R drives. I recommend you check both options, simply so you'll have both in case you ever want them. The ISO-9660 image is particularly handy for testing PXES without having to rely on your TFTP server, the client's ability to boot from the network, and so on.
  7. Click Next. The result is a screen for specifying various hardware characteristics, as shown in Figure 12-2. Chances are you can leave all these options alone, and PXES will autodetect the hardware, but if you know what hardware your clients use, you can enter appropriate values.

    Figure 12-2. PXES can autodetect most hardware types

    PXES can autodetect most hardware types

  8. Click Next to configure local hardware, as shown in Figure 12-3. For initial testing, you may want to leave these options disabled; however, if you want to give your users access to their local hardware, enabling these options will be necessary in the long run.

    Figure 12-3. PXES can grant login servers access to the thin client's devices

    PXES can grant login servers access to the thin client's devices

  9. Click Next. The PXES configuration wizard gives you a choice of types of protocols to support. You can specify multiple options, such as an X session using an XDMCP server as well as ICA. One of the selected protocols must be the default. The local X session option provides a minimal local X session, from which you can launch additional sessions. This can be handy if users need to access multiple remote systems simultaneously.


    Some features are grayed out by default. These require the installation of extra software, some of which is commercial. Consult the PXES documentation for information on these protocols.

  10. Click Next to configure assorted X options, as shown in Figure 12-4. The default options usually work, but the defaults also support only 800 600 displays. If your thin clients can do better than this, you may want to change this option. When connecting to modern Linux systems, XFree86 4.x often works better than XFree86 3.3.6, as well. If you know the capabilities of your thin client's monitor (in terms of horizontal and vertical refresh rates), enter the correct values. If you don't do this, you may not be able to use the monitor in your preferred resolution.

    Figure 12-4. PXES lets you specify Linux-like options for your thin client's video card and monitor

    PXES lets you specify Linux-like options for your thin client's video card and monitor

  11. Click Next, and the wizard displays a brief summary of your configuration.
  12. Click Next. At this point, the configuration options diverge depending on the protocol options you selected earlier. For instance, if you chose to support XDMCP, the tool asks you to enter XDMCP options, as described for XDMCP clients in Chapter 11. You may run through several such screens, one for each protocol.
  13. After entering information on your protocols, the configuration tool presents general configuration options. You can have it delay starting X or connecting to remote servers, run a local Telnet server for administrative purposes, and enable the use of per-client configuration files (which can be handy if your thin clients vary substantially in their hardware or other features).
  14. Click Next, and the system informs you that configuration is complete and is about to be saved.
  15. Click Finish to finalize the configuration. The system presents a status dialog box as it prepares an initial RAM disk image and performs various other tasks. When this dialog box reports that configuration is complete, dismiss it, and pxesconfig terminates.

The result of all this processing is one or more files you can use to boot a Linux-based thin client:

The kernel file
Although it's delivered with PXES rather than generated by it, you should note the location of the kernel file, particularly if you want to perform a direct network boot of the thin client.
This file, located in /tftpboot/pxes by default, holds the initial RAM disk image, which is a tiny but complete bootable Linux filesystem that's passed to thin clients in one way or another.
This file is a compressed read-only filesystem image that's equivalent to the initrd image. Its advantage is that it's usually smaller than an initrd image. It's usually stored in /tftpboot/pxes by default.
This file is generated only if you select the network bootable image option. It's stored in /tftpboot/pxes by default and is necessary for some types of network boots.
This file, stored in /tmp by default, is a CD-R image file and is created only if you chose the ISO image option when configuring PXES. You should burn it to CD-R if you intend to boot your thin client using a CD-ROM drive.

Testing Your PXES Image

Now that you've created a PXES system, it's time to use it. One good way to test it is to use the CD-R image file. Using a Linux program such as cdrecord or a GUI front-end such as X-CD-Roast, burn the image file to a CD-R disc. (Alternatively, you can transfer the image file to a Windows, Mac OS, or other computer and use its CD-R drive.) You can then place the CD-R you've created in the CD-ROM drive of a computer that's configured to boot from its CD-ROM drive and boot the computer. Testing in this way eliminates the possibility of errors in certain network-specific servers and configurations, such as TFTP. If the CD-R boot works, you can move on to a network configuration and be sure that any problems you encounter there are network-related, rather than problems with the basic PXES configuration.

When booting a PXES image, you're greeted by a boot prompt that asks you what protocol you want to use. Type the number associated with the protocol (such as 2 for XDMCP), followed by the Enter key. If you just press the Enter key, PXES boots and runs the default protocol you selected when configuring the system. Once you select the protocol, you'll see typical Linux kernel boot messages scroll by.

After a few seconds of kernel messages, the system will be booted. Depending on your configuration options for the protocol you selected, you may now be asked for certain details, such as the hostname of the remote system you want to use. After you enter this information, or if you entered this information in the configuration phase, the screen will clear and you'll see either a system-selection screen (similar to the XDMCP chooser shown earlier in Figure 11-6) or a GUI login screen for the computer you've contacted. You should now be able to log in and use the computer as if you were sitting at its console.

If you pick the screen option when booting PXES or if you chose Local X Windows Session as your default option and run this default, PXES boots into a simple Linux desktop with a handful of icons along the left edge of the screen for initiating various types of connections. When launched, these tools can open connections to other computers in their own windows, as shown in Figure 12-5. This figure shows an indirect XDMCP login session and, in front of that, a VNC session open to a Linux system that's configured to interface to its own local XDMCP server.

Figure 12-5. PXES can display separate windows on different remote systems

PXES can display separate windows on different remote systems

When you're done with a PXES session, log out of the remote system as you normally would. Usually, PXES will then redisplay your login or system-selection menu, enabling you to begin again. If you want to shut off the computer, simply flip its power switch. Unlike normal disk-based Linux systems, a PXES thin client doesn't need to be shut down with a special command. Although it's got a local filesystem, it's a temporary one in a RAM disk, and it will be recreated from the boot medium the next time PXES boots. Thus, you needn't be concerned about corrupting the local PXES computer's filesystem.

Booting a Thin Client from the Network

PXES is a great tool; however, using it by booting off of a CD-R isn't optimal. After all, much of the appeal of PXES is being able to use it with diskless workstations that can boot automatically from the network, and relying on CD-Rs—which can be lost or damaged, as well as the CD-ROM drives to read them—reduces the appeal of PXES.

As already noted, the PXE part of the PXES name refers to a network boot protocol. This protocol is promoted by Intel as a way to boot diskless workstations; however, PXES uses it to enable network boots of a Linux-based thin client. You should consult the documentation for your thin client's motherboard to determine if it's PXE-enabled. If it is, enable the PXE boot option in the BIOS to boot the system from the network. This option also requires a supported Ethernet card; consult your motherboard's documentation to learn what works.


Some motherboards' PXE support requires you to press a key, such as F12, at a specific point in the boot process. This can be tricky to do because it's easy to miss this point. You might even prefer using a floppy-assisted boot rather than rely on such an unintuitive network boot feature.

If your computer isn't PXE-enabled, you may still be able to boot from the network, but you'll need a network card that supports network boots in its own BIOS. Many low-cost cards sold today lack this support, so you may need to replace the card. Sometimes you can add an EPROM chip to the card to add this support; check the EtherBoot project ( for information on doing this. If your system supports EtherBoot, you need to enable that support when you configure PXES, as described earlier, and specify the EtherBoot files when you configure your DHCP server, as described in the earlier Section 12.3.3.

As a last resort, you may be able to boot partially from the network, by employing a boot floppy that contains the minimal code necessary to have the network card continue the boot process from the network. One way to accomplish this goal is to use the universal boot floppy that's distributed as part of Thinstation ( This floppy disk includes boot code that's compatible with EtherBoot; when you boot from the floppy, it continues the boot process as if your network had an EtherBoot-compatible network card.

However it's done on the client side, the client relies on two servers to obtain information and an OS: a DHCP server and a TFTP server. These servers may be your remote login server, but they need not be; you can use some other computer to fill these roles.


By keeping the computers most people use simple and placing most programs on remote GUI login servers, you can reduce your overall computing costs and reduce your total administrative effort. Using such thin clients does impose certain needs, though; although the thin client computers themselves can be simple, they require more powerful login servers and better network infrastructure than you'd otherwise need. Linux can play a role in thin client computing as an operating system with which you can turn outdated desktop systems into thin clients, as the server the end users log into, or both.

Personal tools