The Open-Source Classroom

One of my very first articles for Linux Journal was in August 2007 about the Linux Terminal Server Project (LTSP). The other article I wrote in that issue was about my MAME arcade system. Oddly enough, five years later, the most common questions I get from readers are about LTSP. And, the most common questions from my students are still about the arcade system! A lot has changed in the past half-decade, so in my next few articles, I explore the new face of thin clients.

The term “thin client” often refers to a specific type of computer, but when it comes to LTSP, “thin client” means any computer that boots via the network and runs its operating system from a remotely mounted image. The “thin” moniker is used because there is no need for the workstation to have a hard drive. This type of system offers several advantages over traditional workstations:

The LTSP process works like this:

In versions of LTSP before 5.0, the root directory was a specialized system mounted over NFS. It was stripped down to contain only the bits required to get X11 running, and then it pointed clients to the server via XDMCP. This had the advantage of requiring very minimal resources on the workstation (I'm talking requirements as low as Pentium I CPUs and 32MB of RAM or less). This also meant it was very difficult, or even impossible, to customize the workstation's operating system.

Version 5 of LTSP, code-named MueKow, changed the way the network-mounted system was created and maintained. Instead of a specialized Linux system, it used a chroot environment containing a minimal install of the same operating system running on the server. Workstations still booted the same way, but now the chroot environment could be updated and customized. There also were other changes under the hood, like using SSH instead of XDMCP and creating a custom display manager (LDM). An NBD (network block device) server was used instead of NFS, increasing network efficiency as well.

A big motivation for changing the way LTSP managed its underlying operating system was that workstations, even outdated ones, were far too powerful to waste. Because traditionally, all applications ran on the powerful LTSP server, it would become overloaded quickly when users tried to run Adobe Flash or Java apps. With the new chroot environment, it became possible to run some apps locally and some apps on the server. This meant servers could handle more thin clients connected to them, and that workstations shared the load. It also meant a runaway by an application like Firefox would use 100% of the workstation CPU, and not the server. I'll dive into local apps in Part II of this series, but I wanted to mention it now as it was a prime motivation for MueKow.

LTSP 5's new methodology does increase the system requirements for the thin clients themselves. Basically, whatever server system you're running (Ubuntu 11.10, for example) must be supported for the thin-client hardware. Because Ubuntu 11.10 requires at least a Pentium 4, so does LTSP 5 running on Ubuntu 11.10. (The Ubuntu kernel might actually boot on a Pentium 3, but if you're sticking with recommended CPUs, P4 is where it's at.) Because very little actually is running on the thin client itself, it's possible to skimp on RAM. Although a minimum of 256MB is recommended, I've used 128MB systems successfully.

Figure 1. Old workstations make perfect LTSP thin clients. These machines were donated as junk, but they'll make excellent student workstations.

So what this all means is that LTSP has shifted the responsibility of defining “minimal configuration” to the server's operating system. In general though, it's good to have thin-client machines with the following:

If the computer doesn't support PXE booting, it's possible to use gPXE to boot the computer from the network. Although not terribly difficult to configure, gPXE is beyond the scope of this article. For more information, check out www.etherboot.org.

LTSP requires a good network infrastructure. There's really no way to sugarcoat it; it just does. Because the operating system is mounted over the network, any time the thin client needs to access its “hard drive”, it has to communicate over the network. Thankfully, LTSP 5 is more efficient at this than previous versions, because instead of the traditional NFS-mounted filesystem, LTSP 5 uses NBD. The Network Block Device serves a single file, which is an image of the underlying file structure. This distinction means NBD is significantly faster and strains the network less than NFS. Even with that, however, LTSP requires a good network infrastructure. A gigabit-switched backbone with at least 100Mbit switched connections for each thin client is recommended. Anything less will really affect performance.

Thankfully, by default, LTSP runs in a split network environment. That means the server has two Ethernet cards. One card connects to the main network, and the other creates a NAT to which the thin clients can connect. This is a great way to isolate a thin-client lab, especially when a beefy network infrastructure isn't available. This method means the thin clients must be connected physically to the same switch as the NAT side of the server, but for smaller installations, that's usually not a problem. (I'll talk about larger thin-client installs in later articles.) When failover and high availability come into play, a good site-wide network infrastructure is really required.

Part of the confusion behind LTSP is that it's very flexible, so a “standard” install is a misnomer from the beginning. Like I just mentioned, the default installation method is to use a server with two Ethernet cards and create a private NAT'd network for the thin clients to live on. One huge advantage to this sort of install is that a modern workstation-class computer can act as a server for a small handful of thin clients. A dual-core workstation with 4GB of RAM easily could host 4–5 thin clients and still work as a desktop workstation itself. This setup is very attractive for teachers who want to provide terminals for their classrooms.

Every LTSP install is slightly different, so it's also difficult to judge how big a “server” needs to be to support X number of thin clients. You can make some educated guesses, but honestly, the best way is to test and see. If Ubuntu recommends 512MB of RAM, you can see the aforementioned workstation/server has eight times as much RAM as is required. Based on that rough figure, 4–5 thin clients should be able to share the resources of the server computer and still run efficiently. That's obviously a very rough figure, but you need to start the trial and error somewhere!

Because LTSP depends so much on the network in order to function, your server, whatever size, really should have gigabit Ethernet. Thin clients can run just fine with 100Mbit connections, but the server should have gigabit. Once you have your server ready to install, and your thin clients (whether they are old workstations or fancy new thin-client devices) ready to boot from the network, it's time to install LTSP.

I recommend Ubuntu for your first LTSP experience. The simple reason is that most LTSP folks use Ubuntu, so it's easier to find support. Before version 5, LTSP was pretty closely tied to Red Hat-based operating systems. Now, with the MueKow concept, LTSP no longer is tied to a specific distribution. For the purpose of this article, however, I'm assuming Ubuntu is the distribution used. (It should be fairly easy to adapt to other distributions.)

If you have a server with two Ethernet cards, Ubuntu's Alternate CD can set up everything you need automatically. Boot up your server computer from the Alternate CD, and press F4. You'll see “Install an LTSP server” as one of the options (Figure 2). If you select that option, Ubuntu installs like normal, and at the end of the install, you'll see it build the chroot environment for LTSP.

Figure 2. Ubuntu's Alternate CD makes installing an LTSP server simple.

Once the installation is complete, any thin clients connected to your second Ethernet card should be able to boot via PXE directly into an Ubuntu session. While I'm a big fan of magic, I also like to know how it works. So in a nutshell, here's what's going on behind the scenes during the install:

I mentioned the abstract process thin clients use when booting from the server. Now that you know how LTSP 5 is set up, let me elaborate a bit. When you power up your thin clients, this is what happens:

With this basic install of LTSP, all applications are executed on the server. This is a confusing concept for many folks, but I explain to my users that a thin client is basically a remote keyboard/mouse/monitor for the server. When a user starts Firefox, for example, the application starts on the server—you just control it remotely. If you're familiar with X11 forwarding over SSH, the concept should be easier to wrap your brain around.

Because everything is done on the server machine, any users or applications added to the server computer are available on the thin clients. This means LTSP users are simply users on the Ubuntu box, and they can be added or deleted using the standard Ubuntu tools.

Even with my explanation of how thin clients boot and what the server does in the background, you'll notice there are still some mysterious things going on. Sound probably “just works” on the thin client, although that's usually not the case with remote X11 apps. A few other hurdles have been conquered with LTSP 5 that historically were a problem. Things get much more complex when you start running some applications locally on the thin client and some applications remotely—but that's for next month's article.

Now that you have a fully running Ubuntu system on all your thin clients, see if you can find some of the limitations of such a system. If you have a classroom of kids to use as guinea pigs, have them use Adobe Flash-based Web sites, and see if you can notice your server slowing down. Install a printer on your server, and notice how all the thin clients automatically have access to it. Notice how LibreOffice loads lightning fast after it's been opened on one machine (it gets loaded into memory).

LTSP is a powerful way to utilize older hardware. It also can make system maintenance minimal, because there is only a single install of Ubuntu to keep updated. To be honest, I've barely scratched the surface in this article—you can tweak LTSP to do some amazing things. In my next few articles, I'll cover local apps, print servers, network tweaks, load balancing and more. If you have a few older computers and a second Ethernet card, I urge you to give LTSP a try. By the time you're done, you'll be able to make your thin clients dance an Irish jig. (Or whatever the geeky network equivalent of Irish jigs might be!)