Building X terminals with Linux

Summary

In 2000 we abandoned per-seat workstations in favour of low-cost thin-client computers (xterminals) built from PCs about to be scrapped. They provide an environmentally friendly alternative to cluttering up landfill sites, use much less power and create less noise than the typical desktop PC and have proved to be a resounding success for the business. Our cost of ownership has gone through the floor, the xterminals require zero maintenance and allow us to switch and swap desks as we wish. It's hard to find a bad thing to say about them. They have been a pleasure and delight since we first started to use them. We are a demanding group of software developers and yet we think that in many ways they are an improvement rather than a retrograde step. There's almost a perverse pride in being able to say that our most powerful workstation is a Pentium P90 with 32MB of RAM.

This article is an updated version of the original writeup which was done just after we made the switch.

Building X terminals

I hate the sound of fans. The PC in its modern guise is an evil thing, sitting underneath most peoples' desks, polluting the office with heat and noise, as well as costing an arm and a leg to maintain. I've always wanted to get rid of the monstrosity under my desk and to be able to work in peace and quiet. The classic way to do that is to get rid of the PC and install a diskless workstation of some kind, ideally one with low power consumption and particularly no fans. So I did.

There are lots of forms of workstation: the dreaded NC (now thankfully an idea that is largely defunct), 'real' expensive (i.e. Sun or similar) workstations, various other makes and models (e.g. traditional xterminals from Wyse, etc) and those supported by The Linux Terminal Server Project . I decided to have a go at building the latter.

Since first writing this piece, it's interesting to notice that thin clients appear to be gainining ground. As well as a large number in use by WindowsT users for the Terminal ServerT and the Citrix MetaFrameT protocols, there seems to be an increase in the number of VNC -aware thin clients offered for sale commercially. From our experience they are most popular for call-centre or kiosk-style applications

How X Works

Lots of people use Linux , happily accepting the X graphical environment but not really understanding how it works. I was largely in that category myself, but with a least an inkling of what it tries to do.

Unlike the window systems that most people are familiar with, X is inherently networked - the idea is that the display is remote (over the network) from the programs that use it to show their output. As a consequence, an X display provides graphical services to programs that choose to use them, so the X display is called the X server and the programs the clients. This seriously confuses anyone used to thinking of their web browser (for example) as being the client and the remote computer as the server. In the X world client and server are the other way around.

Most Linux users use the internal network of their PC or laptop to replace the network component shown above, so it looks just like an `ordinary' window system, but even when the client programs and the graphical server are located on the same computer, internal networking is being used. That means that if you know how to authorise a remote client, you can tell it to use your chosen display to do its output. It's way beyond the scope of a note like this to go into the ins and outs of it, but we find that the ability to run remote client packages is extremely useful.

As just one example, we have a small number of licensed commercial software packages (Star Office, Kylix) sitting on a central server. Our users don't need minute-by-minute access to those packages on a daily basis, but when they do need it, they simply use ssh over to the host that has the package and run it from there, displaying on their own desktop xterminal. Ssh is particularly good for doing that, since it also provides a secure proxy channel for the X data and means that you don't have to get involved in X authentication issues (a very good thing).

If you haven't tried doing it before and want to try it, get an X server running on one system on your network (we'll call it 'serverbox') and follow these steps to run an application on another system (called 'clientbox'), replacing names as necessary:

Beware: this is a poor model for granting authority to clientbox; it gives everyone on clientbox the opportunity to grab your keyboard and mouse. Only use it in a trusted environment or for a demo. To learn more about X authentication and permissions, you will have to do some serious background reading.

You can obtain a similar effect if you have ssh set up correctly and use it to connect to the remote system. In that case, ssh "tricks" the remote application into talking to a proxy connection for X so that ssh can transfer the data to your local system, drawing it on the local display. The great benefit of that scheme is that it's not only secure, but it also hides away any nasty authentication issues from you. In general, that's the easiest safe way to get remote applications using a local display.

Next page>>