Serving Up the All-Linux Office

Ah, François, the restaurant looks wonderful tonight. Do have another look around, and make sure that each workstation has the necessary tools. I want this to be perfect.

Bonsoir, mes amis, and welcome to Chez Marcel, home of fine Linux cooking and marvelous wine. Please sit down and be comfortable. François, run along and fetch the wine. Vite! Better make it the 1999 Châteauneuf-du-Pape.

Those of you who have been visiting my restaurant for some time no doubt will take pleasure in the fact that many companies (and individuals) are looking for alternatives to their desktop operating system. Linux is the natural choice and offers many relatively painless ways to make that switch. Unfortunately, modern Linux distributions running KDE and GNOME can demand a great deal of system resources, and many companies looking to make a switch have modest PC hardware. Luckily, Linux makes it possible to set up workstations with minimal Linux installations that offload most of the work to a powerful, central server.

This type of setup is the thin-client design. Exactly how thin this client can be depends on which approach you choose. As you would expect with all fine ingredients, there are many ways to prepare something. Fresh lobster steamed and served with drawn butter and garlic is certainly excellent, but it is not the only way. The same holds true for what we prepare in our Linux kitchens, in this case thin-client implementations. In fact, one approach lets you set up Linux workstations without re-installing the client PC.

Probably the easiest way to achieve our thin-client goal is to run a Linux workstation with an X server and not much else. Rather than starting up KDE or GNOME, you can use OpenSSH:

startx /usr/X11R6/bin/xterm

The resulting desktop is far from interesting. You get a plain old X desktop with nothing but an X terminal running and no window control whatsoever. What can you possibly do with this? For one thing, you can connect to your server using OpenSSH, like this:

ssh -C -X -l user_name server_name

The -C option sets up data compression in the secure stream, while the -X enables the forwarding of X requests. Once you find yourself at the command prompt, you can launch a desktop session on the remote host by typing startkde or wmaker or whichever desktop you prefer. Suddenly, you will find yourself running a full graphical desktop session on the remote server.

Note that the server's /etc/ssh/sshd_config file must have X11 forwarding turned on before the client request can be accepted. Here is what the parameter in that file should look like:

X11Forwarding yes

If you needed to change the parameter, you also will need to restart sshd with service sshd restart. This kind of a remote desktop setup works wonderfully and can be quite useful even if you already run a graphical Linux desktop. It is particularly useful if having access to a desktop on the server would otherwise require you to go to the computer room, which happens to be across the building.

If you want to run your own desktop and one on the server, switch to one of your virtual consoles by pressing Ctrl-Alt-F2 (or F3 or F4...) and start a second X session like this:

startx /usr/X11R6/bin/xterm -- :1

The -- :1 option (note the double hyphen) brings up a second graphical desktop—yet another boring xterm on a boring background. From here, you can use ssh to connect to your server and start whatever desktop session you like. To switch back to your regular session, press Ctrl-Alt-F7 or Ctrl-Alt-F8 for the second session. The downsides of this setup are that this isn't exactly thin and, even with compression, the OpenSSH stream can seem a bit slow.

The best way to do an X display session (and to thin down the client) is to use XDMCP, the X Display Manager Control Protocol. From the Linux command line on the client PC, you would simply type:

X -query server_name

Magically, you would have a graphical login screen exactly as it is running on your server. Ah, mes amis, as you might expect, a little preparation must go into this recipe before we can execute that simple command, but the preparation is simple. While François refills your glasses, I will explain.

In order to get a graphical login screen presented to a querying host, the /etc/X11/xdm/Xaccess file needs to have the following lines uncommented:

*                        #any host can get
                             #a login window
*     CHOOSER BROADCAST  #any indirect host
                         #can get a chooser

You also need to have xdm running (or kdm or gdm), which means your server comes up in runlevel 5. Those of you who boot up into a graphical login screen probably can skim the next few lines. To start services in runlevel 5, you must set the initdefault in your /etc/inittab file to 5:

id:5:initdefault:

If you aren't booting up into a graphical desktop, the 5 above should be a 3. One last thing needs to be set in that /etc/inittab file. Look down at the bottom, and you should see something like this:

# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon

Log out and restart your X server so that the new changes take effect. Then, from the workstation, simply run X -query ip_address (the IP address of your server, of course). If you are running XDM, things should work. But, many of you will be using KDE's KDM login manager, and you may find yourself looking at a flat gray screen with an X in the center (although you can move that X around, it isn't very interesting). That's because XDMCP access to KDM requires a little bit more tweaking.

KDE uses a kdmrc file. On my system, it is located in /etc/kde/kdm. Look for the following lines and make sure that the Enable parameter in the [Xdmcp] section is set to true:

[Xdmcp]
# Whether KDM should listen to XDMCP requests.
Enable=true

As François brings out the double-butter Brie to go with your wine, let me tell you about the thinnest clients of all, diskless workstations. Several options are available for this approach; I will concentrate on one for today. However, given how important a tool this is for Linux desktop deployment in the workplace, I feel it is my duty as proprietor, in this home of fine Linux fare, to point out a handful of other projects worthy of your consideration. I will share some of these with you before closing time, but for now, let's talk about booting these workstations.

Boot diskettes, with the appropriate driver for your Ethernet card, can be created using the tools from the Etherboot web site, etherboot.sourceforge.net. Building from source is simply a matter of untarring the distribution, changing to the src and typing make. There is an even easier way to do this, however, thanks to the folks at ROM-o-matic.net (rom-o-matic.net). They maintain a collection of boot ROMs generated from the Etherboot Project. Simply select the release level (latest is usually best), the card type (3c509, tulip, etc.) and click Get ROM. The downloaded file then can be transferred to a diskette:

cat eb-5.0.6-yournic.lzdsk > /dev/fd0

Et voilà! Our diskette is done. Pop it into the workstation PC and reboot. When the system comes up off the card, it will pause for a few seconds by default, giving you the opportunity for a local or network boot—network is the default. The problem is, your client has nothing to connect to after it boots. This is where the Linux Terminal Server Project at www.ltsp.org comes into play. The whole point of the project is to make the setup and operation of thin-client Linux as simple as possible, non?

All right, let's put that workstation out of our minds for a few minutes and concentrate on the server. You will need a couple of additional things, starting with a DHCP server (the dhcp package from your Linux distribution) and a TFTP server (most likely, the tftp-server in your distribution). You'll also need to install the packages for your NFS server. Any major distribution will have these on the CD(s), so you won't need to look far for them.

In the case of TFTP, you will find yourself with an entry in /etc/xinetd.d for the service. Unfortunately, although the package install will create an entry, it also will be disabled by default. So, make sure the service (/etc/xinetd.d/tftp) has this line:

disable = no

Then, restart xinetd to activate the TFTP dæmon.

If you haven't already done so, now would be a good time to get the LTSP packages themselves. The site does offer tarred and gzipped packages for everything, but it also provides precompiled RPM packages for Red Hat, SuSE, Mandrake and others. Debian users also will find prepackaged DEBs available. If you choose to work from the tarred bundles, simply extract them and run the install.sh script in each package. Speaking of packages, these are the ones you will need—I'm listing RPMs here, but the packages are in the order you need them: ltsp_core, ltsp_kernel, ltsp_x_core and ltsp_x_fonts. There are a few additional local application packages, such as Netscape, but we will leave them for now.

This is the spot where things got a bit interesting on my setup. I installed LTSP on three different machines and found that their order was quite important. I needed to have dhcpd running for the LTSP configuration step, but starting the dæmon required that I have a valid /etc/dhcpd.conf file in place. Because I didn't have such a setup, the autoconfig was failing so I decided to create my own dhcpd.conf file; it isn't difficult. Have a look at the following configuration. It should be sufficient to get you going, keeping in mind, of course, that the IP address of my domain (and my root-path server IP) certainly will be different from yours:

subnet 192.168.22.0 netmask 255.255.255.0 {
    option domain-name "yourdomain.dom";
    option root-path "192.168.22.10:/opt/ltsp/i386";
    range dynamic-bootp 192.168.22.128 192.168.22.254;
    default-lease-time 21600;
    max-lease-time 43200;
    }
host baroque {
    filename "/lts/vmlinuz-2.4.18-ltsp-1";
    hardware ethernet 00:50:FX:5B:XX:56;
    fixed-address 192.168.22.5;
            option host-name "baroque";
    }

Note that I have created at least one host. The filename is correct for the latest LTSP distribution, but the hardware or MAC address for the Ethernet card (besides being fictional here) must be a valid one for your client. Start dhcpd with the command service dhcpd start.

Once you've installed your DEBs, RPMs or tarred packages and started the various services, you can thank the folks at LTSP because the other work pretty much has been done for you. All you need to do is execute an initialization script, which is provided:

cd /opt/ltsp/templates
./ltsp_initialize

After you type the command, you will be warned that the script is about to update some important system files, specifically /etc/dhcpd.conf, /etc/exports and a few others (Figure 1).

Since NFS has been updated with new exports and DHCP configuration information has been changed, you should restart the NFS dæmon as well as the DHCP dæmon:

service nfs restart
service dhcpd restart

We are almost done, mes amis. In seconds, we will have a top-of-the-line, yet modest, Linux thin-client installation. Because all the software for LTSP is in the /opt/ltsp, we need to make a little side trip there for some configuration. Start by editing the file /opt/ltsp/i386/etc/lts.conf. Specifically, look for this line:

SERVER = 192.168.22.10

Make sure that it reflects the IP address of the host you are using as your server. This lts.conf file is a good one to get to know. It allows you to tweak individual workstation configurations on the off chance that the defaults don't work for a particular one. Here's a configuration I created for my workstation called baroque (it needed to be configured with an old serial mouse):

[baroque]
       XSERVER            = vesa
       X_MOUSE_PROTOCOL   = "Microsoft"
       X_MOUSE_DEVICE     = "/dev/ttyS0"
       X_MOUSE_BUTTONS    = 3
       LOCAL_APPS         = N
       SWAPFILE_SIZE      = 64m
       RUNLEVEL           = 5

Remember, as you add workstations (and bring more on-line), you need to put these in the /etc/dhcpd.conf file. Yes, you do need to restart the dhcpd service when you make changes, but that is all.

Now that we have that out of the way, put in your diskette, boot up your workstation, and in a few seconds, you should see your kernel image being downloaded to the workstation via TFTP. A configuration boot-time dialog will scroll past, followed by an automatic X configuration. Incidentally, if X is giving you a hard time at this stage of the game, you can change the workstation's entry in the lts.conf file to runlevel 3 instead. You'll then boot up into a text-only screen.

Closing time is fast approaching, mes amis, but I did say I would tell you about similar projects. You may want to look at Solucorp's X terminal toolkit (www.solucorp.qc.ca), headed up by Jacques Gélinas of Linuxconf fame. You also might pay a visit to Diego Torres Milano's site at pxes.sourceforge.net and have a look at his PXES Linux thin-client package.

Thank you, mes amis, for sharing this evening here at Chez Marcel. I do hope that your experience in thinner Linux has been a good one and that you will consider it in your place of business. The cost benefits along with simplified administration make it a perfect choice in this cost-conscious world. Update the server, and you update everyone; back up the server, and you've backed up every workstation—it doesn't get any easier than that. François, please refill our guests' wineglasses a final time. Until next month. A votre santé! Bon appétit!

Resources