Thinking Thin

Once upon a time, there was the mainframe. All application processing was centralized to this enormous beast, and desktop equipment did nothing but display its output. Then the personal computer arrived, ending the tyranny of the mainframe. Individual users suddenly were empowered to install their own applications. Software development and innovation boomed. The personal computers were networked. Thus, the mainframe was slain.

But all did not live happily ever after. The cost of maintaining a workstation on every desktop outgrew the purchase cost long ago.The fact that the dominant operating system is like a Petri dish for viruses and spyware has exacerbated the situation to a point that should be considered intolerable. It has to be faced that, in most situations, it is not desirable to allow the user to install software. The only sane management decision is to draw a clear line between users and administrators.

This can be accomplished in large part by using a secure system like Linux on the desktop. Viruses and spyware disappear, and maintenance costs can plummet. But, there is still a full system on every desktop that must be maintained. Hard drives fail. Fans fail. Major OS updates are not automatic. Desk space is consumed.

One solution is a step forward that feels like turning back the clock. The thin client is the modern equivalent of the text terminal. It provides a low-profile, low-maintenance appliance for the desktop. Application processing is off-loaded to a centralized system called a terminal server. Linux has emerged as the OS of choice on the thin client, even when the terminal server runs MS Windows. But let's not go halfway. Let's explore in detail how to deploy a Linux thin client with a Linux terminal server.

What makes a client thin? Most important, thin clients have minimal local software that can be stored on a Flash memory module that is read-only for the local user. This is usually a standard CompactFlash card or a Disk On Module (DOM), which is Flash memory with an IDE interface. A small portion of Flash is made writable for saving configuration information, but in a properly configured system, the user will not be able to modify this. Once configured, it is very nearly an appliance as far as the user is concerned.

Because most of the processing is performed by the terminal server, a slower CPU can be used; 533MHz is typical. This diminishes the cooling requirements greatly, which means fewer or no fans. The silence is golden.

Because there are no internal drives or expansion cards, motherboard components are reduced, allowing very small form factors. The small form factor, reduced cooling requirements and lack of drives mean a very small enclosure. The model I typically use measures 9.5" tall and 1.75" wide, and has a maximum power consumption of 30W. The smaller power supply also means a smaller UPS. Compare a 700 VA workstation UPS costing $120 US and weighing 17 pounds to a 350 VA thin-client UPS costing $40 US and weighing 11 pounds.

Figure 1. Igel 364 LX

Figure 2. Igel 364 LX Internals

Thin clients have two distinct modes of operation: client and standalone. In standalone mode, the thin client isn't really a client. All necessary applications are loaded in Flash and executed locally, which can drive the purchase cost up by increasing the Flash requirements. The most common application of this is a Web appliance. Any decent thin client will have the ability to boot directly into a Web browser and even prevent the user from exiting the browser or modifying its configuration.

Here is a big caveat to thin clients: vendor dependence. You can't simply download the latest version of Firefox and install it on a thin client as you can with a workstation. The manufacturer must provide a special image for your make and model. This is something that needs to change, but for now, the software that the manufacturer makes available is a crucial factor in selecting a thin client. If you want Firefox on a standalone thin client, the manufacturer has to provide it. If you want Flash and Java to work, the manufacturer must provide the plugins. Don't expect the plugins to be current releases either. The size of some plugins has outpaced even the plummeting cost of memory. In particular, Acrobat and Java have grown so enormous that it is more reasonable to use an older release than pay for the additional Flash and RAM required to run them.

How software is made available depends on the manufacturer. There are basically two methods. One is to provide individual modules. This allows you to pick and choose, but more labor is involved in preparing the clients. The other method is for the manufacturer to provide monolithic images with all the options needed. This can be practical if the manufacturer is flexible about providing custom images.

When using thin clients in client mode, the applications are all normal installations on the terminal server, which is simply a high-performance server with enough horsepower to do the application processing.

In client mode, the thin client has a dual nature. It is a client in respect to the application services provided by the terminal server, but it is also a server in respect to providing those applications with access to local hardware. The local hardware being served up is primarily a keyboard, video and mouse (KVM), but there also can be local audio, USB storage devices and printers.

Thin clients are available with Linux, Windows CE and Windows XP Embedded. Barring some desire to use Internet Explorer in standalone mode, there really isn't any reason to consider anything but Linux for a thin client. Even if the terminal server is MS Windows, the fact that Linux is running on the thin client is completely transparent to the user. CE and XP only add software license costs to each client, and XP doubles the Flash and RAM memory requirements on the client (128MB minimum Flash and RAM for Linux vs. 265 Flash and RAM for XP). Because of this, the most commonly deployed thin-client configuration today is Linux thin clients connecting to MS Windows terminal servers.

There are four common thin-client protocols:

A distinction should be made between these protocols and remote framebuffer protocols like VNC. VNC provides remote control of a desktop that is still local, while thin-client protocols provide remote desktops.

X is nothing if not modular. Modularity is a good thing, but seeing how all the pieces of X fit together can be daunting for a new user. Below is a summary of the main modules and their interactions that will make the rest of this article accessible to readers with no previous X networking experience.

All access to the physical display is through the X server. This is a source of confusion for new users, because the display is intuitively client-side. But, the display is the service to which it provides access, hence the name. The clients for an X server are X applications that use it to display their output. We will see relationships later in this article where the X server acts as a client to other services.

The display manager (DM) is the heart of the terminal server. X servers and DMs have a dual client-server/server-client relationship. An X server can, as a client, initiate a connection to a DM on UDP port 177. The DM will then connect to the X server as a client on TCP port 6000 to display a graphical login screen to the user. A client can have multiple displays (windows or virtual terminals), in which case, the second display would be on port 6001 and so on. The protocol for this communication is XDMCP. If the X server and the DM are on the same system, they communicate using a UNIX socket.

The X server and DM are about displays and pixels. Neither has any concept of a window or a widget. These are handled by the window manager (WM).

Although the window manager provides the fundamental functionality and the major aspects of the look and feel, that is not enough to consider it a fully usable system. The desktop environment (DE) completes the user interface with utilities, such as control panels and toolbars, and basic applications, such as calculators and text editors.

There is often one additional component used: an X font server. The name of this server is xfs. In relation to xfs, an X server is a client that connects to an xfs server on TCP port 7100. X servers also can be configured to retrieve fonts from a filesystem folder.

The main decisions to make when deploying thin clients and a terminal server are the DM and the DE. The X server is built in to the thin client, and the DE will have a default WM that there is usually no reason to change. There are two dominant DEs in use today: GNOME (GNU Network Object Model Environment) and KDE (K Desktop Environment). Both have extensive features, and they are about equal in market share. GNOME is written in C and uses the GTK+ libraries. KDE is written in C++ and uses the Qt libraries. Both GNOME and KDE have their own WMs, named Metacity and KWin, respectively. They each also provide their own DMs, GDM and KDM, one of which is normally used in place of the standard XDM provided with X.

Start by installing your distribution of choice. The specific file locations given below are for Fedora 5. Most distributions install only one DE by default, so make sure to select the desired DE during installation. Although many distributions, including Fedora, give the choice of GNOME or KDE, some have opted to provide only one DE.

GNOME and KDE coexist well. One is set as the system default, but both GDM and KDM allow you to select GNOME or KDE desktops on the fly for each login. The system default DM, on the other hand, is the only DM that will be used.

To select the system default DE and DM, edit /etc/sysconfig/desktop. It should have only two lines:

   DESKTOP="DE"
   DISPLAYMANAGER="DM"

DE is either GNOME or KDE, and DM is either XDM, GNOME or KDE.

If the system does not automatically boot to a graphical login, change the default runlevel (initdefault) to 5 in /etc/inittab.

To use a font server, run ntsysv and select xfs to run at boot. Also, configure xfs by editing /etc/X11/fs/config and remove the line no-listen = tcp to allow outside connections to xfs.

KDM is configured using the file /etc/kde/kdm/kdmrc, which is in INI format. To allow remote connections, set Enable=true in the Xdmcp section. You probably also will want to customize the X-*-Greeter section, which controls the appearance of the login screen. Note that if the UseTheme parameter is true, many other parameters in this section will be overridden. KDM also can be configured using the KDE Control Panel, but it loses all the comments in kdmrc. I prefer to edit kdmrc directly.

GDM also has an INI format configuration file (/etc/gdm/custom.conf). Simply set Enable=true in the xdmcp section. The GDM configuration file is not heavily annotated, so the GUI configuration tool gdmsetup may be preferable. Run gdmsetup locally on the terminal server. On the Remote tab, change Style to Plain, Plain with face browser or Same as local. If in doubt, choose Plain.

For any DM, access is controlled by the file /etc/X11/xdm/Xaccess. Simply add the IP address or DNS name of each allowed host. A * on a line by itself will allow connections from any host.

This is everything necessary to allow a thin client to log in to a desktop on the terminal server, but more server configuration will be necessary later to access local thin-client hardware beyond KVM.

A thin client is not the only way to access the XDMCP server. Client software also can be run from a workstation. You can access either a desktop or directly run applications.

If X is not currently running, the following command provides a login to a remote desktop on a terminal server host:

   X -query host

If X is already running, the same command also will work, with the local desktop and the remote desktops being on separate virtual terminals (VTs). To open the remote desktop in a window, use:

   Xnest -query host

If either of these give the error “Server is already active for display 0”, select a different display number by adding :1 as the first option.

To run an X application remotely without a desktop, use:

   ssh -X -l username host

to log in, and then run the application from the command line. The ssh option -C will add compression for slow connections.

If your workstation has tsclient installed, this provides a GUI front end for Xnest as well as client software for other protocols.

Most of the above functionality can be added to an MS Windows workstation by installing Cygwin. When installing Cygwin, add the package X11/xorg-x11-xwin to the default installation. Also, add Net/openssh if you want to use SSH. The above commands should then work in a Cygwin shell. For SSH, run startx first, then run ssh in the X terminal window that it creates.

Thin clients provide GUI tools that make basic network configuration similar to any other network appliance. Beyond the basic configuration, these tools allow the creation of sessions. A session defines the server to access and the protocol to use. XDMCP can be a session, but because the thin client is running X natively, connecting to an XDMCP server might be a basic display configuration setting. How this is done depends on the manufacturer. Other protocols are always configured as sessions.

The configuration details below were tested on an Igel 364 LX. They should be general enough to work with any thin client with ESD and NFS server capabilities, but these are not features that should be assumed.

Many thin clients have no support whatsoever for local audio from a Linux terminal server. Those that do typically have only ESD. This requires that the applications be configured to use ESD (most have this option, but not all). The following also must be added to the .bash_profile of thin-client users to identify the IP:port of the thin client's ESD server:

   export ESPEAKER=${DISPLAY%%:*}:16001

Because thin clients have no built-in drives, the only local storage of interest is USB-connected. We want locally inserted devices to be accessible from a desktop icon. But as the desktop is running on the terminal server, we need to make the terminal server see these local files.

This requires a thin client with a local NFS server configured to automatically detect and share USB devices. On the terminal server, we configure the autofs dæmon to detect these remotely mounted devices automatically and mount them locally. Create a directory /etc/auto on the terminal server. For each user that is allowed to access local storage, create a file /etc/auto/username with the following contents:

   usb    -rw,soft,intr    192.168.0.64:/autofs/usb0

Replace 192.168.0.64 with the thin client's IP address, and the path /autofs/usb0 will vary by manufacturer. Create a directory /home/username/media, then add the following to /etc/auto.master:

   /home/username/media    /etc/auto/username    --timeout=15

Finally, create a symlink on username's desktop to /home/username/media/usb. The user now can insert a USB drive, and clicking the symlink will cause autofs to mount it on the terminal server.

This method works and has been used in real deployments, but it has an inherent limitation. The thin clients must have static IPs, and each user is tied to an IP address. In cases where users need to float between stations, this will not be adequate.

In many cases, it is actually required that user access be restricted to specific locations. This is easily accomplished using the PAM login access control table. First, the thin client must be given a static IP address. Then, add the following entry to /etc/security/access.conf on the terminal server:

   -:username:ALL EXCEPT 192.168.0.64

The format of this file is permissions:users:origins. So the above example removes (-) permission for user username from all addresses except 192.168.0.64.

Besides the obvious security application, this is also useful for public-access thin clients. While creating a separate generic account for each thin client (user1, user2 and so on) gives each one a separate home directory so users will not trip over each other, it is easy to log in accidentally using the wrong generic account at a given workstation. This procedure prevents that.

Thin clients have matured and are ready for widespread use. Their benefits are too compelling to ignore, and most have a commitment to Linux as their primary platform. Unfortunately, most are myopically focused on MS Windows terminal servers and are neglecting support for Linux on the server side. As they become more widely deployed, the ironic possibility of Linux systems becoming an impediment to the deployment of open source on the desktop is very real.

Some specific items that must be addressed are:

The solution is likely NX or something very similar—something that retains the modularity of the system while integrating the components into a cohesive whole. I have not yet seen a thin client with a fully functional NX client.

Resources for this article: /article/9388.