Linux Terminal Servers for Any Business

How businesses can tap the power of thin clients with Linux Terminal Server (LTS).
Installation Using a Complete Distribution

Using a Complete Distribution offers one of the easiest and fastest means of integrating an LTS. In many cases, I've been able to install a server within an hour. I also save a lot of time as I do not have to install individual applications that I find useful.

For instance, the release, although intended primarily for schools, includes everything a business server requires and then some. Some of the packages in this release include:

  • Samba: file-sharing tools for integrating in a Microsoft environment.

  • 2.x: complete office suite of tools useful in business.

  • Rdesktop: remote desktop sharing with Windows Terminal Services.

Prior to installation, take time to read some of the documents and errata available on the Web site, and be sure to familiarize yourself with your business network and server hardware.

On occasion, I've seen video driver failures on the server. This has nothing to do with thin clients and their video. It also does not require any setting changes in the lts.conf file. Instead, the easiest solution and one that circumvents a lot of video issues is to install the package with this parameter at the boot prompt: linux skipddc. This is a failsafe, and you should use it only when you cannot reconcile the server's video issues. This removes any graphical capabilities from the server itself and performs a text-only installation. It automatically starts the server at runlevel 3.

Once you have completed the installation, you can force the run level to 5 using this command:

init 5

For further guidance, please look back over the Installation section above.

You may disable SELinux to allow proper installation and configuration. You always can restore some of the SELinux functions later.

I strongly recommend that you include nearly everything except the educational and gaming packages. If you prefer to slim down the install, leave out a few server options you know you won't need, such as a News server, but try to include some of the development tools. I know you'll need them eventually.

The Complete Packages come with a number of logos that you may change to reflect your business. For example, you may want to change this graphic: /opt/ltsp/templates/k12linux/k12ltsp.jpg. Using GNOME, type the command: gdmsetup. Using KDE, type the command: kcontrol.

In the KDE Control Center, select System Administration, then the Login Manager.

Hopefully, you now have a ready LTS!

Final Prototype Configuration

Whether you used the Installation process or chose to go with a Complete Package, you should now have an operational server.

For most business situations, you also must make a few minor configuration changes to the dhcpd.conf and lts.conf files.

Network Configuration

In the lts.conf file, ensure that the IP address correctly matches the address of your server.

In the dhcpd.conf file, ensure that you choose one of the options to declare your subnet and to allow thin-client connections. For example:

subnet netmask {
   range dynamic-bootp;
   use-host-decl-names       on;
   option log-servers;

The basic example above allows the dynamic assignment of IP addresses from the business DNS for a particular subnet. The range assigned to the LTS for thin clients is 243–253, allowing up to ten thin clients connectivity. In this example, I assigned my LTS as 254.

Once you set up your network configurations properly, connect a thin client.

First Time Login as Root

Reboot the LTS, or restart all of your LTS-related services. Then, connect to the LTS via a laptop or desktop on the same subnet and login as root.

Most PCs today include a Boot Order menu. Press the F12 key or something similar on the thin client to access the menu. On older systems, you need to enter the full BIOS configuration (F2 or Del key) and choose Boot Up Configuration.

On older systems, you also may need to choose the MBA (Managed PC Boot Agent) and configure it for PXE protocol.

Now, choose Network Boot. After a few seconds, the LTSP software should enable the thin client.

At this point, you'll see the graphical login screen.



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!