Chapter 5 - Thin-Client Computing

An Edubuntu 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 is discussed in the section called “Linux Terminal Server Project”.

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.

TODO: Add image of 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 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.

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 utilize low cost workstations as either graphical or character-based terminals on a GNU/Linux server.

K12LTSP is based on the Fedora Project and the LTSP terminal server packages (see the section called “About the K12LTSP distribution”). 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 the section called “Glossary”) diskless workstations from an application server.

How the lab works

There is a shorter version of this in the section called “Thin client startup process”.

  1. "Power On Self Test" (POST). When you turn on the workstation, it will go through its Power On Self Test (POST; for this and other acronyms, see the section called “Glossary”).
  2. Find the boot ROM. During the self test, the BIOS will search for expansion ROMs. The network card contains an Etherboot boot-ROM, which is an expansion ROM. The BIOS will detect the ROM on the network card (it doesn't know about the network card, it only notices the ROM).
  3. Boot. Once the POST is complete, execution will jump into the Etherboot code.
  4. Find the network card. The Etherboot code will scan for a network card. Once it detects the card, the card will be initialized.
  5. DHCP request. The Etherboot code will then broadcast a DHCP request to the local network. The request will include the MAC address of the network card.
  6. DHCP request received. The dhcpd daemon on the server will see the broadcast request from the workstation, and look in its configuration file for an entry that matches the MAC address of that workstation.
  7. DHCP request reply. The dhcpd daemon will construct a reply packet, containing several pieces of information. This packet will be sent back to the workstation. The reply information includes:
    • an IP address for the workstation,
    • the netmask setting (see the section called “Glossary”) for the local network,
    • the pathname of the kernel to download (this is a filesystem path on the server),
    • the pathname of the root filesystem (see the section called “Glossary”) to mount as the root of the client filesystem,
    • optional parameters to be passed to the kernel, via the kernel command line.
  8. Boot ROM configures TCP/IP interface. The Etherboot code will receive the reply from the server, and it will configure the TCP/IP interface in the network card with the parameters that were supplied. Once this is done, the client computer has an IP address on the network.
  9. Download the kernel using TFTP. Using TFTP (Trivial File Transfer Protocol), the Etherboot code will contact the server and begin downloading the kernel.
  10. Kernel downloaded. Once the kernel has been completely downloaded to the workstation, the Etherboot code will place the kernel into the correct location in memory.

  11. TODO: Add other stuff here

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 slipup 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. Heterogenous 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 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 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're 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 Edubuntu 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 Edubuntu is no exception.

Online games will be laggy

  • 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. But then, playing online games (as well as other games for that matter), is not a goal of the Edubuntu project.

All the clients run the same Operating System

  • Since it's really only one instance of Edubuntu serving all the desktops and applications, all the clients in the lab will necessarily offer an Edubuntu 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 Edubuntu, 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 Disk 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 Disk 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 the section called “Switches / Hubs”), 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.

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 other Edubuntu users to assist each other with skills and equipment. Heterogenous 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.

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 the section called “Glossary”), 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 Edubuntu! It is even possible for the standalone workstations to access the Edubuntu network, and to use the classroom server as a fileserver. Since Edubuntu is implemented using standard protocols, this will work no matter what operating system is installed on the workstation computers.

Other resources

EdubuntuDocumentation/EdubuntuCookbook/Chapter_5_-_Thin-Client_Computing (last edited 2009-04-29 23:04:26 by adsl201-244131014)