Part Two

Linux Terminal Server Project (LTSP)

In a typical network environment (like we have at the school), workstation computers (sometimes called "fat clients") are all attached to a central file server. The software that each person uses is purchased and installed on each workstation. If an upgrade is needed for any of that software, it must be purchased and installed multiple times, once on each workstation. This usually means having a paid consultant come and perform the upgrade. Because the workstations are really "stand-alone" machines, they each must be capable of running any software locally (since that's where it runs). That implies that your hardware must be upgraded regularly to keep up with the ever more demanding requirements of software. This means buying more memory, larger and faster hard drives, faster processors (CPU), etc. for every workstation when software upgrades are made. These add significantly to the cost of this sort of configuration. Further, all of these components can and do break down, putting a halt to any work at that machine (ask Mary Chris about this). When new computers are purchased with newer versions of application software (newer Microsoft Word, for instance), the older machines with an older version of Word may not be able to read documents created by that newer version. This means that you are forced to upgrade all your workstations even if you are happy with the version you have.

The idea of a terminal server is that you replace the "fat clients" with "thin clients." A thin client is simply a dumb terminal without much in the way of computational ability in and of itself. These thin clients are attached to a server where everything happens. When someone sits down at a terminal (client) they log into the server, just like they do in a more conventional network. The difference is that now, instead of running software on the client, it is actually running on the server. The only thing the client computer needs to deal with is updating the screen and forwarding keyboard and mouse activity to the server. From the users' perspective of course there is no real difference. As far as the user is concerned, as long as the computer works they won't really care where the work is happening. From a technical perspective, however, it means that the workstations need not have more than a bare minimum (32MB say) of memory, not much in the way of a processor (a ten-year old processor like a 486 would work fine), and no hard drive. In fact, there are thin clients available that don't even have fans in their power supplies (since so little power is actually needed) and therefore have no moving parts. No hard drives in the workstations also means the room will be much quieter than one with eight or more standard computers running. Thin clients can easily be built from old Pentium or Pentium II computers like those which were donated for our lab. Three obvious advantages of a terminal server configuration are that

the cost of each client is reduced considerably,
the reliability of the clients is increased, and
hardware upgrades are rarely needed.

While the clients are "lighter" than those needed in a traditional network, the server may need to be a bit more robust. A traditional file server might have a single Pentium 4 processor, 512 MB of RAM, and a 20 or 40 GB hard drive. A terminal server, on the other hand, might have dual processors, 2GB of RAM and three SCSI (read "faster but more expensive") hard drives. It would therefore cost a bit more, say $2,500 as a starting point, than a standard file server, which might cost as little as $1,500. But the money saved on the server won't actually go very far when it comes to buying workstation machines. In practice, the cost difference is usually smaller than that since SCSI drives are usually recommended for all file servers.

Let's look next at overall hardware costs. In a school like ours with 15 or so workstations, if you are upgrading each workstation every three years, that means 5 computers each year (plus any new teachers we get, we are going to be getting new teachers for a while more, right?). If, on the other hand, you only have to upgrade thin clients every six to eight years and they cost less than half what a standard computer costs, you can see that the savings will be significant. Since five year old computers can easily be used as thin-clients and these are easily available as donated hardware, it's likely you would never have to buy any workstations at all. I'll leave it up to you to do the actual math. A network with 16 client workstations in a traditional network configuration requires a file server, sixteen workstation machines and software licenses for each workstation. It also requires a significant amount of time to maintain and support. Also, when a workstation breaks down, the cost of even one replacement machine means it can take months before it is in place. With thin clients, however, everything resides on the server so the staff or faculty member can use any other client machine on campus without even noticing the difference. It's as though every machine is theirs. For our lab, the workstation hardware has been donated but hardware upgrades will be needed. We currently have no software licenses, either for the operating system or application software. On the other hand, the only cost for an LTSP network is the hardware needed for the server. Our existing workstations and those we can easily have donated are more then enough for thin clients. If (when) one of the workstations breaks down, since no software needs to be installed, it's a simple matter to swap one box for another.

When it comes time to upgrade software, it only needs to be upgraded in one place (the server) since it doesn't actually reside on the clients at all. In an internet connected environment (which we should have by the time you read this) upgrades can be made from a remote location. That is, an administrator doesn't actually have to come to the school to make changes to the system except in situations of power or hardware failure. Further, since everything runs on the server, upgrading one software package will have the effect of upgrading all the workstations so upgrades take less time (and everyone knows what time equals). Since Linux is immune to all the thousands of Windows viruses found on the internet, another potential source of problems is eliminated. Also, Linux is designed to be used in a multi-user environment where Windows is designed for one user. The practical advantage to this is that the user on a Linux system does not have the permissions to modify the computer's configuration as they do on Windows. Because of this, we don't have to worry so much about a bright student getting into the system and making changes (not that any of our students would ever do that sort of thing).

It should be said that there are Windows based options for terminal server configurations. The problem is that they don't really have the savings of a Linux terminal server. First, the Microsoft options do not run on thin clients at all but require standard computers that run Windows so there are no hardware savings. Second, Microsoft requires you to buy a Windows license in addition to a terminal server license for each workstation so instead of needing fewer licenses you actually need to buy more! With LTSP, the software for the server and all workstations is free (as in speech and beer).

So, what are the disadvantages of a terminal server configuration?

The first and most obvious disadvantage is the cost of the server. An "off the shelf" server of this type (such as a Dell or a Compaq) might cost $4,500 and even one built as cheaply as possible (while not unnecessarily sacrificing quality) might cost $3,000. I believe that cost is offset by other savings but it does have to be spent (or donated) all at once.
Second, there is a single potential point of failure. If the server goes down, everything goes down. This is less of an issue than it might seem at first, however, since it is really true in a standard configuration, also. If a standard file server goes down, there is no way to access your files so even if you have a workstation that is working, you cannot really do much actual work. Including a battery backup and a small gasoline generator in the budget to run the server and a few clients might be wise.
Third and possibly most important is that it is possible that our current technology consulting company is probably not capable of dealing with this sort of configuration. There are consultants that offer these services [see Appendix B] but most that deal in the Microsoft world (like ours) do not. That means that at the very least we'd have to change technology consultants. Depending on our contract and relationship with our current contractor, that may not be something we'd want to do quickly (or maybe it is, I don't know). The reality is that a consultant that offers this sort of arrangement will probably spend less time on site than the current consultant does now. They will rarely have to physically come to the school and it is likely that the need for their involvement will be reduced considerably.

Beyond the basic LTSP, there is a group of folks that have taken the basic LTSP packages and adapted them specifically for the K12 environment. They have also gathered together free (speech and beer again) educational software and packaged the whole thing as something called K12LTSP. This is freely available on the internet and is what I used to install everything on David's computer. There is also a fairly large and very active community of users who are available twenty-four hours a day, seven days a week to help with problems. I've been subscribed to a K12LTSP mailing list since December, 2002 and am constantly amazed at the cooperation and support available. I'm also impressed by how widespread the use of K12LTSP is. There are hundreds of schools in the USA, Canada, Australia, Brazil, and the UK (etc.) using it and finding considerable savings. Many have stated outright that without LTSP they would not be able to afford computer labs in their schools. Some (fewer) are using it for the general school administration, also. One reason this is less common is that office systems are already established and converting is never as easy as starting from scratch. Also, many schools have standardized software systems based on Windows that they are required to use. For our purposes, however, I believe we should examine how a terminal server might work as our main network configuration school-wide in addition to running our lab.

Continue to Part 3: Options and Costs

Return to Part 1: Free and Open Source Software (FOSS)
Return to Table of Contents