Open Source

Create powerful thin client systems with the Linux Terminal Server Project

See how you can use the Linux Terminal Service Project to turn old PCs into effective Linux terminals.


Thanks to new thin client technology, the old dumb terminals weren’t such a dumb idea after all. With IT budgets getting cut in this shrinking economy, any way to stretch out the life-span of existing hardware is a smart move. On the Linux front, it is possible to give life to even the slowest of hardware with the Linux Terminal Server Project (LTSP). With this amazing thin client solution, you can have your end users up and running on diskless terminals with any graphical applications you choose.

In this Daily Drill Down, I will show you how to get LTSP up and running so you can regain more control over your enterprise-computing environment.

Installing LTSP
Installing LTSP is very simple. From the LTSP Web site you can download the LTSP components necessary for a complete installation. You can choose to download RPM, DEB, or source tarballs. You will need four basic components:
  • ·        lts_core
  • ·        lts_kernel
  • ·        lts_x_core
  • ·        lts_x_fonts

In addition, you will need to run a DHCP server and a Trivial File Transport Protocol (tFTP) server on the Linux system you will be using as the LTSP host.

For more information
If you need more information on setting up a DHCP server on Linux, see “Installing a DHCP server under Linux.” For more information on the tFTP protocol, run the command man tftp.

Finally, for each workstation that you will be using as a thin terminal client, you will need to generate a boot floppy. You have two choices: you can modify the bootrom on the network card, which may require special equipment, or you can use a floppy disk to boot. Since floppy drives are inexpensive, and this method is easiest, I'll use a boot floppy in this Daily Drill Down.

Go to the ROM-o-matic site and you will be able to select the network card your workstation uses. In this demonstration, a workstation with a D-Link DFE-530TX card was used. This setup uses the rtl8139 chipset, so the network card ROM selected was the rtl8139. Make sure that the ROM output is set to bootable floppy, and then click Get ROM.

To generate the boot floppy, insert a blank floppy and use the dd if=eb-5.0.4-rt18139.lzdsk of=/dev/fd0 command (changing the file name to match the file you downloaded).

Hardware compatibility
If you can't determine what driver to use, you can find out from the Red Hat site (for Red Hat systems), from the Mandrake Linux site (for Mandrake Linux systems), or by doing a search on either the ZDNet Linux Hardware Database or Etherboot, which lists a lot of different network card manufacturers and tries to correlate network card models with the appropriate kernel driver.

Insert the newly generated floppy into your workstation and boot from it (make sure to set the BIOS to boot from floppy). The ROM should find your network card and report the MAC address, or hardware Ethernet address, of the card.

Configuring the LTSP Server
Before you can configure the server, make sure that both DHCP and tFTP daemons are installed (on all recent distributions, these are included with a standard server installation and can be checked with the commands rpm -q dhcp and rpm -q tftp). Install the LTSP files downloaded from the LTSP Web site using RPM, DEB, or tarballs (whichever your system requires). If you downloaded source files, you will need to compile the software first.

Nonstandard installation directory
If installing via RPM, make note that RPM will install LTSP into the /opt/ltsp directory (as opposed to the standard /usr/bin or /usr/sbin).

Configuring your system to run the LTSP server involves executing a script on the server called ltsp_initialize in the /opt/ltsp/templates directory. This will modify your system configuration files to allow the client system to access the server. The ltsp_initialize script will modify your Gnome Display Manager (GDM), KDE Display Manager (KDM), or X Display Manager XDM configuration files (depending on which you employ) to allow for remote client access to your chosen display manager and logon. The ltsp_initialize script will also modify your /etc/exports file to export the LTSP root and swap file systems, create an example /etc/dhcpd.conf file, and enable tFTP in inetd.

Once ltsp_initialize is complete, double-check a few files to ensure that things are correctly configured, as LTSP makes no guesses about network setup and instead defaults to using a 192.168.0.0 network. For example, you will want to modify your /etc/exports to look like that in Listing A if you are using a 10.0.0.0 network.

The entries in Listing A will export the two file systems, the LTSP root file system (/opt/ltsp/i386) and the LTSP swap files (/var/opt/ltsp/swapfiles) to any client system in the 10.0.0.0 network. Next, edit the /etc/dhcpd.conf.example, which defaults to 192.168.0.0 addressing. If you are using a 10.0.0.0 network, the /etc/dhcpd.conf file would look something like that in Listing B.

As you can see in Listing B, LTSP is configured so that dhcpd will give the workstation identified with the MAC address 00:50:BA:42:F7:0E an IP address of 10.0.5.51 and a domain name of ws001.mylan.net. The configuration in Listing B also tells LTSP to boot from the kernel /tftpboot/lts/vmlinuz-2.4.18-ltsp-1. The /tftpboot prefix should not be specified as it is assumed, and the kernel name should be replaced with whichever kernel is installed. (As of the time of this writing, the 2.4.18 kernel is the latest LTSP kernel.)

If you have more workstations that will be used as thin clients, just continue to add more host sections to your dhcpd.conf file. Remember to save the file as /etc/dhcpd.conf and not /etc/dhcpd.conf.example.

Finally, change to the /opt/lts/i386/etc directory and modify the lts.conf file. This is the configuration file that LTSP uses for its primary configuration. In the lts.conf file, the [Default] section is for the server itself. The SERVER keyword must be changed to the IP address of the LTSP server, and everything else can use default entry.

Now it’s time to configure the workstations. The [ws001] section is for workstation number 1; the ws001 entry specified in the dhcpd.conf file. The workstation section configures such things as which X server to use (this is only relevant if you need to use an XFree86 3.3.6 server) and the runlevel to start in. The defaults will usually work fine; in fact, you can (and probably should, to begin with) comment out all of these sections.

The lts.conf file is heavily commented and shows a few different illustrations of how to configure LTSP on the client side. (For example, it shows how to configure and use a printer connected to a client machine and how to load additional modules if required.)

Keep in mind that every time this file is changed, the client system(s) will have to be restarted in order to see any of the changes.

Restarting the services and firing up the clients
At this point, you will need to restart a few services. On most systems, this can be accomplished by using these commands:
# /etc/rc.d/init.d/portmap restart
# /etc/rc.d/init.d/nfs restart
# /etc/rc.d/init.d/dhcpd restart
# /etc/rc.d/init.d/xinetd restart


This will restart (or start) the portmap, NFS, dhcpd, and xinetd daemons with the new configurations. If you're using the older inetd, restart it instead of xinetd. To make this all transparent, you should ensure that these services will start at bootup. Starting the above services at boot can be a simple matter of adding the above commands into the /etc/rc.d/rc.local file.

If the server is already at runlevel 5 (graphical login), you should be able to start the client systems from the boot floppy. If not, you will need to start in runlevel 5 by rebooting the server or executing the telinit 5 command at the server’s command prompt.

This will restart the system into runlevel 5, for the graphical login. You may be satisfied with whichever display manager your Linux distribution uses by default (on Mandrake Linux, for example, it's KDM, the KDE display manager), or you can switch to a different display manager. This is somewhat system dependant, but on Mandrake Linux you can modify the /etc/sysconfig/desktop file and set the DISPLAYMANAGER equal to gdm (DISPLAYMANAGER=gdm).

Check your documentation
Refer to your distribution's documentation on how to change the display manager if you don't want to use the default.

At this point, head on over to the client system, insert your boot floppy, and boot from it. The system will use tFTP to obtain the kernel to boot from, and once it has done that will use dhclient to obtain an IP address and other network information. Finally, once it has an IP address and knows a little something about the network, it will mount the root filesystem via NFS and then connect to the display manager you are running. You should find yourself very quickly at a graphical login, just as you would if the system was running locally.

Key benefits
During this entire process, the only hardware used on the client system will be the CPU, memory, and the floppy drive, and you'll find the bootup and the Desktop significantly faster than on a traditional Linux workstation. Applications are run on the LTSP server, meaning that no overhead is incurred on the client system. This also means that a lack of powerful hardware will not hamper the speed with which your applications run.

By deploying LTSP, you can use old 486 or Pentium systems as your end-user machines. The systems can further be stripped to not contain any hard drives, reducing the cost of those systems (remember, all that is required is a floppy drive).

Maintenance costs would also be reduced. Instead of maintaining each client system, you only need to maintain the LTSP server. This could save a lot of time maintaining and configuring each system. Provided you kept copies of the boot ROM images available, the most maintenance you might have to perform on these systems would be isolated to hardware—and perhaps regenerating the odd boot floppy.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

Editor's Picks