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

All the clients run the same Operating System

Single point of failure

Hardware

Minimum specifications

Server

Clients

Switch

Things to look out for

Monitors

Uniform equipment

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

Boot PROMs

Dual-booting

Other resources

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