Linux Terminal Servers for Any Business

How businesses can tap the power of thin clients with Linux Terminal Server (LTS).

A Linux Terminal Server offers any business an elegant and cost-effective way to integrate the power of open source. In this article, I review some basics of network topology and offer suggestions about how to install a prototype server. I top it off with some tips for business-specific installations and configuration guidance.

A Linux Terminal Server allows almost any business to gain the benefits of open source and the power of Linux immediately. What makes an LTS distinct is that it integrates well, without burden to infrastructure or people. Moreover, the performance of an LTS dramatically showcases Linux power. One LTS can serve graphics and applications to many desktop PCs simultaneously.

By placing the LTS into an existing subnet, colleagues can access the many useful applications and features with almost no effort—and at their convenience.

A great deal of effort has been put into the Linux Terminal Server Project (LTSP) to make it seamless. LTS simplifies installation by isolating the integration work exclusively on the server.

With an LTS, even the most hesitant users experience the benefits of open source in their organizational context. No re-installs are required. No major licensing or policy changes. And most important of all, the financial costs are negligible.

As an illustration, I recently found that a local real-estate company had needs that perfectly matched with an LTS. Among the many available applications, I demonstrated the ease of The GIMP to alter photos downloaded from the agents' cameras. Then I included simple bash scripts to automate the uploading of the enhanced images to their Web site. The GIMP exemplifies the many outstanding open-source programs they could access easily through the LTS.

This simple example demonstrates how a business that never considered Linux or open source could quickly gain access to applications with very little cost in time or money. Above all, the agents could access the LTS from their own desktops without any alterations.

Now, let me share some of the basics of integrating an LTS into your business.

First, choose your network topology and server based on your specific business context. Next, choose your method of installation and follow the on-line instructions. Finally, configure your server to support thin-client connections. You'll find that most installations work smoothly and quickly. To help guide your steps, I include tips for some of the more essential configurations.

Basic Network Topology and Options

If you look at most of the existing installations of LTS, you'll find that they implement a closed subnet configuration. In such a configuration, the LTS serves thin clients within its own controlled subnet and provides routing to the overall organization's network through a second Ethernet port.

Utilize this closed subnet configuration to isolate thin clients, such as in a work lab. Sometimes, this configuration also provides a reasonable solution for business, where a team or department needs the access and features of an LTS.

Figure 1. Closed Network Integration, Relying on the LTS

This is a superb solution when your business starts a new department and wants to manage hardware and software licensing costs tightly, or when capital budgets could better be used for staffing. In this scenario, the business gains dramatically as LTSP does not require robust desktop PCs.

They may exist as outdated PCs or as simple diskless workstations. Often such connectivity costs less than $300 per seat. Ironically, it costs more per seat just for software licensing in most business situations.

Figure 2. Basic Integration into an Existing Subnet, Offering Access to the LTS

As shown in Figure 2, the LTS also can benefit an organization when installed into an existing subnet. The other computers do not rely on the LTS, but they gain access to the LTS and its many applications and features.

I assume in both cases, your LTS sits snuggly behind your business firewall. Also, both examples allow authentication servers, network file stores and broadband connectivity through additional tools like Samba and WinBind. However, I recommend you begin with a simplified installation. You always can adjust or expand the LTS' role and features once operational.

Figure 2 represents a prototype LTS that offers anyone on the subnet access while remaining largely “invisible” to the other servers on the network. In most cases, this setup requires only one Ethernet connection and reserved IP addresses for a particular subnet.

Now, I'll share some specifications that will help you choose a reasonable business server.

For every simultaneous thin client you want to connect, you should have about 128MB of RAM. The more the better, but this provides a good start. For a real-world example, I've seen that a thin client running KDE with Writer and a Firefox browser will use about 115MB.

I recommend that you use at minimum a 7,200rpm disk drive with a decent onboard cache. SATA or SCSI are standard for most business servers, and you should use these if possible.

Obviously, if you can acquire a more powerful processor or dual-processing capability, so much the better. I've even seen 2.4GHz processors with plenty of RAM (2GB+) do quite well. If you must make a choice, place emphasis on RAM over processor speed.

The folks at the have done a phenomenal job of supporting volumes of configurations and flavor variances. However, as a basic guide, using PCI cards and Digital Signal Processor (DSP)-based sound cards will ensure an easier integration.

Once you've decided on the topology and server, choose your installation method.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Problems with S3 Trio 3D

Dušan's picture


Linux Terminal Server Project is fine for using old computers. I use some on our Primary School and they do their job. But although we have problems with using old computers with S3 Trio 3D grphic card. Local machines can't run in X windows. Can you give me some help with that?

edubuntu as clients

Anonymous's picture

I did not know one could use edubuntu as clients in a business environment ?.
what do the people at edubuntu think about that ?

Another LTS to explore

jwattspc's picture

Great Article.

In addition to LTSP, K12LTSP and Edubuntu, you also use FreeNX which is based on NoMachine's code and provides some X performance enhancements.

Use in production

Craig ringer's picture

I've been using LTSP in production for more than two years now and I've been really happy with it. The main suggestions I'd make here are:

- DON'T use the auto-setup unless you're using a server dedicated to just LTSP. You're much better off understanding what settings are required and making the necessary changes yourself. This will help with any future troubleshooting and upgrades, and also helps ensure the LTSP config doesn't step on the toes of anything else.

- Get fast thin clients. These machines don't run apps, but that doesn't mean they do no work. In particular, you want video hardware with decent XFree86/Xorg RENDER extension performance and you want a thin client with a decent amount of RAM. The former helps ensure snappy display performance especially when handling a fair bit of text, and the latter will boost speed and improve stability with apps that use lots of server side resources (like firefox). Remember that the thin client _does_ need to render the app's GUI, so just because 32MB P100s will work doesn't mean they're a good idea.

- Get thin clients with DVI and decent monitors. Seriously.

- If your server is going to support more than a few clients, or the clients do much more than use email, a web browser, and an office suite, strongly consider getting an NCQ enabled SATA disk on the server or a decent SCSI disk. Disks optimised for multi-user loads help a *LOT*.

- There is no such thing as "too much RAM" for any server, something that holds true for LTSP servers as much as any other. Make sure you have at least enough RAM, but if you can get more, do so. You won't regret it when Firefox 2.0 comes out with the latest in Memory Hog(TM) technology.

In terms of client hardware, personally I'm really happy with the Via Mini-ITX board based thin clients I'm using. Video is snappy, 256MB of RAM is plenty (yet still almost free given modern RAM prices), the 600MHz Via Eden is more than enough CPU grunt to drive a nice 1280x1024 panel, they're cheap, they come in tiny, silent and fanless chassis with no moving parts to fail, the network interface is reliable, and they're well supported by everything.

Now, a few comments on parts of the article:

"Your LTS must run in runlevel 5"
This is not quite right. On red hat derived distros where the display manager is run from inittab at runlevel 5, that's right, though of course all that really matters is that hte display manger is running. On debian derived distros it has little to do with runlevel, as the display manager managed by System V init, not inittab, and runs by default at the normal multi-user runlevel (2). Users of debian-derived distros should NOT alter the default runlevel; instead just make sure the display manager is started at your runlevel using update-rc.d .

Debian users should also be sure to use dhcp3d not the older 2.x version. This has its config in /etc/dhcp3/ so don't get confused.

You should never need to check the logs to see if the DHCP server failed to start due to config errors. If your distro's init scripts are worth anything, they will run `dhcpd -t' to validate the config before restarting the server. If they don't, then you should test the config manually BEFORE restarting dhcpd (and file a bug with your distro too).

I find it very useful to set up static IPs locked to MAC address in DHCP for all the thin clients in an address range outside the default allocation range. By also giving them informative reverse DNS entries (I use `ltsp-BEEF' where BEEF is the last 4 digits of the client's MAC address) it's also easier to tell what client is active where, using what network resources, etc. You can also tell at a glance if a machine is an LTSP thin client or some other workstation.

Reverse DNS entries are also important for fast, reliable NFS. Make sure they're defined on your network, and match the forward lookup.

Anyway, that's about it for me. Hope these comments have been handy.

Extra note

Craig Ringer's picture

One other thing - the use of "Hub" in the diagram above hopefully refers to a switching hub, ie "switch". You don't want to use a dumb broadcast hub in an LTSP environment. Traffic isn't normally heavy, but if you have a couple of people on flash-heavy websites, viewing huge images in their mailboxes, or working with the GIMP (yes, it works great over remote X11) you will start to run into collision problems with a hub.

10/100 switches are really cheap even for large port counts. Get one.

Also, remember that while X11 isn't too demanding in terms of bandwidth, latency is absolutely critical because of the stupid number of round trips made by current X11 clients. I wouldn't want to run them over even a fast WAN for this reason.

Standard in product and service lines ISP next to IP-TV

Pundit's picture

All internet service providers should offer the ltsp desktop in their product- and servicelines.

It's real easy to setup and install a 10,100,1000, 10000 and more of computers (clusters), in a few minutes, hours.

A winning product-.serviceline has a line wifi-,net-,prowerline-bootable ltsp desktop.
1. ltsp grahical desktop
2. IP-tv
3. high-speed connection

The thin client only needs a simple low-tech 1 Watt net-CPU, optimized for encoding/decoding multimedia and data.

Design a smart and fair franchisable support-organization around the product- and servicelines and you have the next IPO, and facilitate world-wide channelmembers giving optimal support to their local customers with uniform support and fair supportrates.( no outrageous expensive phone numbers for customersupport). One person/employee can support and monitor the administration tasks of 10,hundreds, thousands millions of systems. That is scalable administation and scalable manageability.

The business could change the face of the earth, because a big advantage for the early and late majority of consumers, the other 5 billion not connected people, is they don't need to buy the next generation energy guzzling antiquated cpu/os combination and safe a lot on the electricity bill. Connecting 5 billion people with the unsophisticated 'commercial hit' technologies of today would require some more Three Gorges Dams ( 18 billion Watt equivalent to 18 normal nuclear power plants ), Hoover Dams (2 billion Watt) or many nuclear power plants world-wide.

LTSP services

Craig Ringer's picture

A few issues arise here:

- Current X11 clients are not good at handling significant latencies due to the number of round trips made. This can be improved, but it does make running X11 thin clients over a WAN less than ideal at present.

- Streaming would need to be done with an LTSP local app; X11 can only draw raw video, so it'd be VERY bandwidth heavy to rely on a remote player. Given that, why bother with LTSP, rather than a cut down local computer? A little Via Eden box or a Geode system uses very little power, can be booted from solid-state storage, and would fit the bill quite nicely with a little ASIC to accelerate common video decoding tasks. Such an accelerator would be required in an LTSP based model too, unless you want a powerful CPU in the local client.

As I've noted earlier I use and like LTSP. I just don't think this is a useful or practical use of it.

Unclear Section: "First Time Login as Root"

Anonymous's picture

This section starts out instructing the reader to login on the LDS as root from a client PC. How do I do that? Telnet?

In the next paragraph it talks about changing the boot order of the client PC. What does logging in to the server as root have to do with changing the boot order on the client? Why log in to the server and then immediately reboot my client?

Overall a good article. But this section leaves me confused.

Readers may also be interested to know that Windows users can also easily log in to a Linux server by installing an Xserver on their computer. This will provide a complete Linux environment. The user cannot distinguish that he is not actually running Linux on his/her PC. I have found the free Xserver "Xming" to be very useful for this.

"Readers may also be

Craig Ringer's picture

"Readers may also be interested to know that Windows users can also easily log in to a Linux server by installing an Xserver on their computer. This will provide a complete Linux environment. The user cannot distinguish that he is not actually running Linux on his/her PC. I have found the free Xserver "Xming" to be very useful for this."

One such X server is the Cygwin X server, an XFree86 port to win32 that's available free as part of Cygwin.

Unfortunately, I've found that many Linux apps assume you're using a recent XFree86/Xorg, and cope poorly with servers that behave in any way differently, support different extensions, etc. Some apps even run into problems with Cygwin's X server, for example, despite it being based on fairly recent XFree86 (even Xorg now?) code.

Consequently I don't tend to recommend use of X11 apps on win32 without testing the app with the desired X server and making sure it behaves its self.

Unclear section on login with thin-client

MarkRais's picture

I appologize if there was some confusion in the section. Perhaps a component of what/how the LTS and thin-clients work needs to be clarified.

The LTS serves thin-clients on the existing subnet. In other words, you are actually connecting through your thin-client to the LTS.

In the section referenced above, you ask "how do I do that? Telnet?" which misses the point. If you BOOT UP your laptop, or desktop PC on the same subnet as the LTS and use NETWORK boot as specified, it will actually become a thin-client and link to the LTS.

The, while viewing the LTS login screen on your PC, you can simply type the login and password and enter the LTS.

"What does logging in to the server as root have to do with changing the boot order on the client?"

Again the question is derived from the point above. If you do not change the boot order of another PC or laptop connected to the same subnet, then it can not be served by the LTS and won't become a thin-client connection. Only by changing the boot order to allow the PC to boot using PXE protocol, will it connect properly as a thin-client to the LTS.

Once this happens, of course, you will instantly gain access to all features and functions of the LTS.

It's well worth trying this out in a micro-scale with a prototype server and then seeing what I mean.

hope this helps,

I got it. Thanks!

Anonymous's picture

I get it. Thanks!

RAM requirements

Chris de Vidal's picture

Excellent article! Just one problem: You said, "For every simultaneous thin client you want to connect, you should have about 128MB of RAM."

Fortunately, libraries and binaries are shared in memory. I recall reading an LTSP article years ago that said for example the first OpenOffice user brings it up slowly and the rest are lightning quick because libraries and binaries are shared. They had something like 1GB of RAM for 150 users running Netscape and OpenOffice.

So the actual RAM requirement per user might be in the order of say 20MB.

Someone want to confirm this? I was amazed when I read it so I do think that is correct.


Craig Ringer's picture

The initial RAM footprint for a session can be that small, yes. If you start actually _USING_ it you'll find lots of apps keep caches, or demand-load more of themselves, etc. The session tends to grow considerably. I'd consider 50Mb/session an optimistic estimate for a modern desktop, and be strongly inclined to allow more.

The only effective way to test is to bring up one session, measure RAM usage, then bring up another session, USE it for a few hours, and measure RAM use again.

Low memory usage

Pundit Wekker's picture

Absolutely correct. Because of shared libraries, memory usage on the server can easily be optimized to 20MB for each client.

The diskless client comes usually installed with 32MB to run the X server but 4MB, 10MB and 16MB installed should be no problem. In a work environment you furnish a productive desktop pleasant. simple and non-distracting with the lightning fast fvwm window manager.

Because of the very low power consumption of the diskless thinclient, low heat dispensation (saving on airco) and steadily rising price per kWh electricity the payback period of your investment is dramatically reduced. Also your daily operational cost will be reduced . For example the net bootable VIA mini-ITX you can buy with many different kind of computer covers/cases and consumes 11 Watt only.

If you are still using hubs in your network I advise you to upgrade them to switches. Switches will speedup every client because with switches no collisions between tcp/ip packets occur.

For ready made thinclients Neoware is a good choice.

Yes, you can get per-client RAM use down

Criag Ringer's picture

Yes, you can get per-client RAM down a fair way. On the other hand, apps like Firefox, OO.o and Thunderbird are absolute pigs for memory (let alone Evolution, which I've clocked at >500MB), and tend to bloat as they fill caches and load more of themselves as they are used. This means that session start-up RAM use measurements are useless, you MUST consider RAM use after the session has been in active use for some time.

excellent article, thanks

Anonymous's picture

excellent article, thanks

If you call this a new

Nicholas's picture

If you call this a new solution, you must have been in hibernation for the last 30 years or something...

Terminals are not really something new, but tried and true technology from the Unix dinosaur age!