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.
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:
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:
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.
TFTP is delivered with most Linux distributions, or you can download a copy from http://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 read disable=no. You may also need to set the server_args line; it should use the -s option and point to a directory in which boot files are to be stored:
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:
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:
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 by telinit 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).
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:
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 \
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:
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.
Next: Client Configuration
At this point, you should have one or more server computers configured to support thin clients, but without thin client software installed. Next month I describe how to remedy this important omission, with information on configuring the ThinStation client software to work with the Linux clients you’ve just configured.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62