Thin-client Computing

An Edubuntu lab computer laboratory consists of a classroom full of thin client workstations communicating with a classroom server. The specific implementation of thin client computing used in Edubuntu labs is discussed in Thin Client Boot Walkthrough.

What is Thin Client Computing?

Thin client and fat client (also called "thick" or "rich" client) are mostly marketing terms for different configurations of computer. A thin client asks a central server to do most of its processing, and keeps as little hardware and software as possible on the workstation side. Ideally, the user of a thin client should have only a screen, keyboard, mouse and enough computing power to handle display and network communications --- you don't even need (or want) a hard drive. The less you have, the less there can go wrong.

A fat client does as much processing as possible itself and only passes data required for communications and storage on to the server. A standalone PC is the typical fat client with which everyone is familiar.

<img src="illustrations/ch04/fat_client.png" />Fat client

A thin client may be a software program executing on a generic PC, or it may be a hardware device, called a terminal, designed to provide only user input and display functions. Because old PCs (whether retired, written off, obsolete or just out of fashion) are easier to find than specialised thin client hardware, Edubuntu labs uses them as thin clients, with the appropriate software. Because they don't do much work themselves, the hardware requirements for these "old" PCs are very basic. Since every client in a thin client network asks a central server to do its work, all the individual workstations look the same: they all share the same server, and they all behave exactly like the server would if you were using it directly.

In addition, although everyone who uses the lab can have their own computing environment stored on the server, with their own files, desktop, and so on, the individual workstations can't get viruses or be misconfigured by curious learners --- there simply isn't anything to configure! The thin client doesn't have enough brains to get confused.

This means that the lab computers are trivial to keep up and maintenance is restricted to the server in the back room.

Thin clients are cheaper and require less administration than fat clients. On the other hand, they tend to require far greater network bandwidth, as display data will probably need to be passed to the thin clients. They can't do a single thing on their own --- for each and every action, they need to talk to the server. This means that a server for a room full of thin clients must be much more capable than a server used by fat clients.

One of the advantages that this configuration entails, is that all the software resides on the server, and so you only have to upgrade it once. In a fat client configuration, every workstation has its own copies of the software, and so any upgrade needs to be rolled out to every workstation.

<img src="illustrations/ch04/thin_client.png" />Thin client

Linux Terminal Server Project

The Linux Terminal Server Project ( LTSP) is a configuration of Linux that allows you to connect lots of low-powered thin client terminals to a Linux server. The LTSP provides a simple way to utilise low cost workstations as either graphical or character-based terminals on a GNU/Linux server.

K12LTSP is based on RedHat Fedora Linux and the LTSP terminal server packages (see Section 7.1.1 for more detail). It's easy to install and configure. It's distributed under the GNU General Public License. That means it's free and it's based on Open Source software.

Once installed, K12LTSP lets you boot (see Section 16.4) diskless workstations from an application server.

How the lab works

Thin client startup process

  1. As soon as you switch on a thin client, it does a Power On Self Test ( POST). This is the part where you normally see numbers counting, and a prompt to press F1, F2, or DEL to enter setup.
  2. After the POST is completed, control is given over to your network card's boot PROM (Programmable Read-Only Memory). This is a small piece of memory on the network card that allows a computer to boot from the network. The two methods of booting off the network are called Etherboot and PXE (Pre-boot eXecution Environment). If you see one of these words, then your network card is configured.
  3. If your network card detects a connection to a switch, it will attempt to search for the server using DHCP. DHCP is the thin client's way of screaming "I am here! Please find me! Give me an address so that I can boot up!" The server will then give the thin client an address, called an IP (Internet Protocol) address. If a thin client is stuck at this point, it often means that the switch is on, but the server doesn't respond, or is not plugged in, or DHCP is not running on the server.
  4. DHCP tells the thin client that it should use FTP (File Transfer Protocol) to download the Linux kernel (a file called vmlinuz.ltsp) from the server. If a thin client gets stuck here, it's often a problem with the FTP server or a firewall blocking the FTP port. Perhaps the FTP server is not being started automatically?
  5. The next step is to gain access to a filesystem on the server over NFS (Network File System). This is the filesystem that all thin clients use to boot Linux after the kernel load, and can be found on the server at /opt/ltsp/i386.
  6. XDMCP is the X Display Manager Copier. It sends the graphical user interface (GUI) from the server to your thin client. If XDPCP doesn't start, it's often because GDM (Gnome Display Manager) isn't starting up. This is normally where the problem lies if you get a grey screen with an X cursor.

Benefits

  • Easy maintenance
    If a user reconfigures a workstation in a fat client computer lab, all the other users of that workstation will have to cope with these changes. This means that if someone inadvertently sets the workstation to use black type on a black background, for example, then no-one will be able to see what's going on.

    In contrast, in a thin client lab, every user has their own files, their own email, and their own desktop environment that they can change to their liking without influencing anyone else, all stored on the classroom server. A configuration mistake like the above will inconvenience only themselves.

  • Cheap hardware
    Most of the equipment in a computer lab are workstations for learners to use. There may be one or two printers, network switches and a server, but they are far outnumbered by between 20 and 40 client workstations.

    In an Edubuntu lab, these can all be really old, used, previous-generation computers. This is because the demands on these machines is so slight that almost anything will do. All those stacks of old computers everywhere that no one knows what to do with are suddenly useful, and saving schools vast amounts of cash that they would normally have to outlay on relatively new equipment so they can run contemporary software.

    The thin client paradigm also means that requirements for uniformity among terminals is relaxed. As long as they conform to a couple of basic requirements (network boot, SVGA graphics card, enough RAM) it doesn't matter if they have idiosyncratic hardware. Only the server configuration needs to be maintained. Heterogeneous hardware doesn't make life difficult for the admin.

    The thin-client network in the lab ensures that each terminal, no matter what its own computing characteristics, behaves with all the speed and capability of the server, so each user has an experience of top quality, smooth, fast computing. Unfortunately, this does mean that if some of your client workstations are powerful, modern machines, they may not be fully utilised in a default Edubuntu lab configuration, as they will still be letting the server do all the work.

  • Less theft
    In an Edubuntu lab, the most accessible hardware is also the easiest to replace and the hardest to use outside the lab. an Edubuntu lab client workstation on its own, without the classroom server, is more or less useless. It's too bulky for a doorstop, and it can't run modern software. It doesn't even have a hard drive.

  • Mobile desktops
    As the terminals only serve to display a session from the classroom server, it doesn't matter which one you use. If one breaks while you've using it, you can move to the next one, log on, and pick up where you left off. If someone is using the workstation where you were working, go to another one and log in there to regain access to your desktop.

  • Data easy to back up
    All the data in an Edubuntu lab resides on the disk array of the classroom server. Instead of having to backup 20 or 40 individual hard drives, it's possible to backup only one, and still get a complete backup of everyone's data.

Drawbacks

Every solution will have some drawbacks, and an Edubuntu lab is no exception. I'll just mention a few in passing.

  • Unreal Tournament will be lethargic or lag in response rate
    Graphics-intensive applications such as games will not perform well, as all the display information will have to be pushed over the network by the server. This is hundreds of times slower than driving a local graphics card. Playing action games, however, is not a goal of the Edubuntu lab project.

  • All the clients run the same OS
    Since it's really only one instance of Linux serving all the desktops and applications, all the clients in the lab will necessarily offer a Linux environment. It is possible for the server to run software such as Wine (which enables many Windows programs to run under Linux) or VMWare (which allows the server to run instances of other operating systems), but in these cases the underlying system will still be Linux, and the server will still be doing all the work.

  • Single point of failure
    While it's very convenient that the thin-client workstations are interchangeable and that you can access your desktop from anywhere, it does mean that a catastrophic failure of the server will put all client workstations out of commission.

Hardware

Minimum specifications

Server

  • Memory The server should have 2GB RAM or more (512MB for the base system, and 50MB for each additional client). As long as you're using it all up, more RAM means more speed (it doesn't help to have RAM that you don't use). Too little RAM will bring your server to a crawl as it starts swapping memory to the hard drive. If you run out of memory, performance will be unacceptable.

  • Hard drive SCSI is faster than IDE: We've seen LTSP servers slow to a crawl when more than 10 clients are running from IDE drives. SCSI drives are better equipped to handle the multiple read/write requests.

  • Network Your server will have at least one Ethernet card to create a private network ( 192.168.0.x). This card connects to a switch for terminals. If there is a school network to which you need to connect, or if the school has a internet connection via the server, it will have a second Ethernet card, which will get an IP address on the second network.

Clients

  • Memory Client workstations should have at least 32MB of RAM. Clients aren't that dependent on swap space for extra memory capacity, since memory usage on them is reasonably constant because they don't execute applications: they only display them.

  • Hard drive Client workstations should not have hard drives.

  • Network Each client workstation should have one network card with a boot ROM to enable booting from the network.

Switch

An Ethernet hub is not acceptable (see Section 8.2.1), it's too slow for network boot and NFS. Having a fast Ethernet switch will make your life better and more colorful.

The number of ports on the switch must be enough for your clients and server. If you have more than 24 NICs, 2 or more 12-port/16-port fast Ethernet switches are recommended. The client ports should be 100 megabit, and there should be a gigabit port for the server. Since all clients get their display from the server, a slow link to the server would be a bottleneck for the whole lab.

<img src="illustrations/ch04/switch_blinkenlights.png" />

The front panel of the switch shows a light for every network cable that's been plugged in. The light shows whether the link is up, whether there is traffic and what its speed is.

<img src="illustrations/ch04/switch_lancables.png" />

The cables from the workstations all terminate at the switch. If you don't label them, they get very hard to tell apart!

Things to look out for

Monitors
The display size should be at least 15", and the monitor must be capable of SVGA video modes. It should also be compatible with the video card of the client

Uniform equipment
If you use the same equipment throughout your Edubuntu lab, it becomes easier to buy in bulk and to swap out components. It also makes it easier for Edubuntu labs to assist each other with skills and equipment.

Heterogeneous boxes, in comparison, are harder to keep running, and more likely to be "throw-away" --- not worth trying to resurrect. As long as they don't cost you anything, this is worth it, but you have to guard against them becoming a drain on your time and resources.

Sources for second hand equipment

Locally, PC Retro supplies tested refurbished computers. Because of the high volume of hardware required by the large number of Edubuntu labs installed, the Shuttleworth Foundation has procured the client workstations from international distributors such as Computer Aid. Other workstations have been donated by private industry.

Thin Client configuration

While there is little to do for the installation of the thin client workstations, there are a couple of things you can pay attention to.

Network cards
All the client computers need to get a network card with space for a boot PROM (see Section 16.4), so that they can start looking for the server on the classroom network as soon as they are switched on. The server also needs a network card, and it needs to be a fast one (gigabit Ethernet), as the link between the server and the switch is ten times quicker than the link between the switch and the client workstations.

Boot PROMs
Depending on the network cards you managed to get, the correct Etherboot image may need to be written to the network cards. The Diskless Remote Boot in Linux project has made available an Etherboot NIC Detection Disk which can help you to determine what you need to write to the card.

Dual-booting
The BIOS in the client workstations normally needs to be configured to boot from the network. To do this, watch the workstation screen after turning the power on --- for a couple of seconds, the BIOS will display a notice that you may press a key (such as DEL or F8, depending on the BIOS) to enter setup mode. This will enable you to specify where the computer should look for boot records during startup; for example on a CD, a floppy disk, a hard disk, or the network card. In the event that you have a relatively capable workstation with a hard drive, you may want to boot the workstation as a standalone computer from time to time. To do this, you may configure the BIOS to look for a boot record on a floppy disk before trying the network card.

One kind of scenario where this may be useful, is where you have an existing computer lab with software installed at each workstation. Boot from hard disk to access the standalone workstations, and boot from the network to have an Edubuntu lab! It is even possible for the standalone workstations to access the Edubuntu lab network, and to use the classroom server as a file server, and the Wizzy server as an internet proxy. Since an Edubuntu lab is implemented using standard protocols, this will work no matter what operating system is installed on the workstation computers.

Other resources
This cookbook can do no more than scratch the surface. Some of the other resources regarding thin-client computing available on the web include:

EdubuntuDocumentation/EdubuntuCookbook/ThinClient (last edited 2009-04-29 23:30:23 by adsl201-244131014)