LTSP 5 - Making Thin Clients Phat


Last year, I wrote about our school district's implementation of LTSP. In the article, I pointed out the significant limitations a thin client environment gives you. While I don't think my article was the reason the issues were addressed, less than a year later just about every limitation I highlighted has been eradicated. Welcome LTSP 5.

To be fair, many of the problems I had back in 2003 were solved in LTSP 4.2. The differences with version 5, however, are so significant, that it seems to warrant lots of praise. First, let's look at the philosophy change:


MueKow (pronounced "Moo Cow") is a complete change to the way the thin client environment runs. In previous versions of LTSP, there was an entire "operating system" that was the thin client environment. The OS was hosted on a Linux system, but the thin clients actually ran their own operating system mounted over NFS. MueKow changes this by having the thin clients run 95% of their environment from the host operating system. What this means is that the thin clients are actually running Suse, or Ubuntu, or Fedora, instead of running LTSP hosted from the major distro.

While a bit confusing, the new system means that installing applications for the thin clients is as simple as chroot'ing to the LTSP directory, and installing whatever apps you desire. This means MUCH less burden on the LTSP developers, because they're no longer responsible for compiling and installing every application. Thankfully, it frees them up to make the 5% of the LTSP environment that is unique even more awesome. And they've been doing just that.

Tasty Treats from my Test Server

In preparation for a massive upgrade over the summer, I installed LTSP 5 yesterday running on Edubuntu. While the installation process isn't totally clear, the process did go without too many hitches. When booting up my thin client, I was thrilled at the new interface! Here's a quick list of things that made me grin:

  • The new display manager, ldm, is simple, clean, and effective.
  • X traffic is all routed through SSH, which means security.
  • Plugging in a USB storage device mounts the drive on the desktop, exactly like a regular workstation. End users will expect this, sysadmins will be awed. (This worked in 4.2 as well, but it's extremely cool)
  • Audio with PulseAudio is amazing. Nothing to configure, nothing to set, just wonderful sound on the thin client
  • Multimedia sync. Oh. My. Word. I don't know what secret sauce allows this to work so well, but audio/video sync seems awesome. I suspect PulseAudio is the hero, but whatever the reason, it's incredible.
  • Hardware support is great. I tried a handful of thin clients, and everything was auto detected, and booted right up.

So There's Nothing I Can do to Help?

There are a few things that have always been lacking with LTSP. One is documentation. The developers and users have always more than made up for it with quick and courteous help via IRC and email. Hopefully with the drastic new version, we'll see some drastic new documentation. I say that partially to spurn myself into being part of the solution. Feel free to join me. :)

The other area that hurts LTSP is the lack of a GUI configuration. After a few years of editing the config file by hand, it's not a big deal. Heck, for most things I actually prefer a text based config file. It is, however, a bit overwhelming for a new user. Considering many LTSP installs are done by teachers as opposed to sysadmins -- a GUI is really important. Thankfully, OpenSUSE Easy-LTSP is part of the Google Summer of Code 2008!

Yay! Gimme More, Gimme More!

Getting started with thin clients is quite simple. LTSP version 5 is already integrated into Fedora9, AltLinux, openSUSE-Edu, Debian, Ubuntu, and *almost* into Gentoo. If you are using a different distro, just drop on over to and pick up a copy to install yourself. The development team hangs out at the Freenode IRC network in the #ltsp channel. They're friendly, helpful, and pretty tolerant of dumb questions. (I know this from experience!)

Thin clients are a perfect fit for me in education. They're a perfect fit for a business environment. They're also a perfect solution to fill a household with computers. With all that perfection going on, how can you resist trying it out? :o)


Shawn Powers is a Linux Journal Associate Editor. You might find him on IRC, Twitter, or training IT pros at CBT Nuggets.


Comment viewing options

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

Trying to understand thin client

gtirtha's picture

I was just want to setup LTSP server. But I am trying to understand the client configuration.

According to my understanding: a PXE capable n/w adapter, RAM, processor (obviously) are enough to make a minimal Thin client.

Is my perception is right? As I came to know client will get the kernel through PXE bootloader via n/w and then kernel will have initramfs which will initialize the peripherals in client and will mount NFS from server as read only. The x-terminal can be run using some initial script.

Is it also possible to have some other bootloader (like u-boot) in flash memory of client and that will load kernel and mount NFS from server. In this case PXE capability is not required.

I am just trying to understand the system so that I can keep my investment for clients minimal.

What planet are you from TP Jr.?

Tachyon_1's picture

I'm not sure what planet Terrell Prude Jr. lives on, but I want to move there.
Apparently on this magical planet there's plenty of money to go around, all the schools are well funded and have a full time I.T. Dept.
It must be wonderful there... I bet the students all dress nice, treat each other with kindness and respect, and resolve their disputes with a game of rock/paper/scissors.

Anyway, back here on earth, especially in the U.S. where der fuhrer...I mean the 'education president' has cut the heck out of education spending, many schools are lucky to have working computers and 'only' 40 kids per class, never mind an I.T. Staff. I'm sure there are many schools where the cost savings in hardware requirements, software licensing fees, and support staff is what allows them to have any computers at all.

The writer of this article obviously is aware of this reality and rightly asks that it be accounted for in the design of the administration of the LTSP system. I thought he was very insightful in that regard. It's pretty clear that one of the primary reasons for choosing an LTSP system in the first place would be cost savings, and ease of administration, and reduction in support staff through central management.


Your tone, and what I think your point is

Terrell Prude' Jr.'s picture

Given the tone of your response, I debated whether it'd even be worth it to respond to it. I decided to see through your invective to get at what I think your real point is. But I must ask you, is this how you teach your kids to speak to people?

You are addressing one of the issues of why LTSP is chosen. Cost is certainly one of them, and it can be a powerful driver. LTSP certainly fits that bill, and it's one reason why I give yearly workshops on it. Some districts, as you point out, don't have *any* IT staff.

However, there are a whole lot of schools that have at least part-time IT staff, and of those, many have full-time staff. In both cases, yes, those IT staff need to be consulted anytime you add something with a DHCP server to a network or, for that matter, anything else set up for routing. That's what they're there for. You are risking DoS'ing the school unnecessarily if you don't consult with them first. You sound here like they shouldn't even be consulted, and that just doesn't make much sense.


Teachers generally shouldn't be sysadmins in the first place

Terrell Prude' Jr.'s picture

Shawn Powers wrote:

"The other area that hurts LTSP is the lack of a GUI configuration. After a few years of editing the config file by hand, it's not a big deal. Heck, for most things I actually prefer a text based config file. It is, however, a bit overwhelming for a new user. Considering many LTSP installs are done by teachers as opposed to sysadmins -- a GUI is really important."

I disagree. Strongly.

Given that LTSP includes a DHCP server (*very* dangerous in the hands of the untrained), I don't want a teacher actually configuring LTSP. Network engineering is not their area of expertise; teaching kids is. They need to consult with, and work with, their IT staff. I've never understood this seeming hatred by so many teachers to actually work with the IT staff. There are exceptions, sure. But they are indeed exceptions.

Think about it. If you put a DHCP server on the network and don't do things right, you can DoS your entire school LAN. I've had that kind of thing happen far, far too many times on my schools's networks (home wireless access points, anyone?). No, thanks.

The current tool is just fine, and it works very well. "If it ain't broke, no need to fix it"...and it definitely isn't broken. The target audience for actually setting up and configuring LTSP is not "computer newbies." It is sysadmins.

That said, I do heartily agree that LTSP is an excellent fit for schools and businesses alike. As long as it's done *properly*.


We may have to agree to disagree

Shawn Powers's picture

I know several instances that LTSP is used in schools due to lack of money. That same lack of money has forced teachers into network administrator mode. I'll agree the situation isn't ideal, but sadly, it happens.

Many, many schools that do have full IT departments have MS-centric folks that aren't willing to administer an LTSP server. If teachers want to take advantage of the old computers by using LTSP, they're often on their own.

And as far as the target audience being sysadmins, I dunno -- the last couple times I've installed K12LTSP, it's been dead simple. It even automatically detected which ethernet card to run DHCPD on.

Even if we disagree on implementation, it is hard to argue LTSP's merit for school districts, that's for sure. :)

Shawn Powers is a Linux Journal Associate Editor. You might find him on IRC, Twitter, or training IT pros at CBT Nuggets.

Those MS-centric IT staff: how to handle them

Terrell Prude' Jr.'s picture

Hello Shawn,

You have three good points in your response here, and they're worth addressing.

1.) The cost issue is obvious, and there, I agree with you. I was speaking of schools that *do* have a full-time IT staff (my district, for example). However, if a school--or district--cannot afford that, then you do what you can with what you have.

2.) Regarding those MS-centric staff, I used to be an MCSE myself, so I know that mindset very well. I address that issue here:

3.) True, K12LTSP is dead-simple, and the installation's all GUI. But the article appeared to be talking about *LTSP*, meaning Jim McQuillan's upstream project. ltspadmin, the primary admin tool for it, is indeed geared more toward sysadmins. Perhaps I misunderstood?

I think we also agree that LTSP, whether the upstream project or one of the turnkey distros (e. g. K12LTSP/Edubuntu) is a heck of a good thing for any school, and that it should be used a lot more.



The Adminblogger's picture

Hi there,

we're using thinclients at our company and all our users report slow responsiveness when interacting with applications such as firefox,, thunderbird etc.

Rendering webpages with lots of tables is a pain in the ass with firefox on remote X-Server, same with switching tabs: after you click with the mouse button switching tabs needs < 0.5 seconds to complete - which isn't that much but it's noticeable by the users.

Scrolling in firefox which is seamless on a dedicated desktop can be slow on thinclients too, especially when static backgrounds are involved.

The concept is really great but we decided to migrate from linux-thinclients to linux-desktops for the sake of speed.

The thinclients are Via 500MHz CPUs, the Server is Dual-Xeon 3GHz with 8GB RAM.

An addition

Hasan Ceylan's picture

"Scrolling in firefox which is seamless on a dedicated desktop can be slow on thinclients too, especially when static backgrounds are involved."

That actually is a bug in firefox and being dealt with now-a-days. It maxes up your cpu. It does happen on fat clients.

Where the CPU is shared by a number of users this becomes an issue.

But hey, you always have the chance to run some applications on the client side right? This is what it is for - to isolate CPU and RAM hog application from the shared resources. The installation still resides on the LTSP server, therefore no management fo clients.


Shawn Powers's picture

While it reduces security, using "LDM_DIRECT = true" will make things much zippier. It allows the client to not encrypt all the data through SSH (which is a CPU drain). Also, I've had good luck with using IceWM instead of Gnome or KDE. It just seems to go faster.

Shawn Powers is a Linux Journal Associate Editor. You might find him on IRC, Twitter, or training IT pros at CBT Nuggets.


Anonymous's picture

Hi, had the same problem.

Using faster thin clients, 1GHz an above, will help a lot.

Setting X_COLOR_DEPTH = 16 is faster.


More reflections

Andrew Z.'s picture

One more complaint. Certain web pages with certain use of Adobe Flash would crash the X server so hard that the keyboard did not even work (bug 7365). I never really figured this out, but maybe it was specific to our Dell OptiPlex hardware or the related drivers.

Though we ran VOIP on the same network without any special configuration other than QOS-enabled switches, we had no issues with bandwidth for either VOIP or LTSP.

With some hacks, I could sometimes get Palm Pilot sync working over LTSP.

The older article by this author mentions not playing audio CDs. I came up with a hack for it, and it's on the LTSP wiki.

Audio volume

Andrew Z.'s picture

I setup an LTSP 4 system and ran it for several years. It had over 20 concurrent sessions, and secure remote access via a Java VNC applet was easy to setup. Overall it was an excellent system to save money and maintenance time, but I had two major complaints

1. I made a bad choice choosing Fedora. It is too progressive, buggy, and reaches EOL too quickly. For an individual desktop, OK, but for a server, no thank you. If I did it over again, I would have chosen CentOS or maybe Ubuntu LTS. However, at the time years ago (2005?), the latest Fedora looked really appealing with certain features not available elsewhere.

2. There was no way in LTSP 4.2 with the ESD (ESounD server) to control the audio volume using the GNOME audio applet. Users had to control volume through their speakers. Perhaps PulseAudio in LTSP 5 is better?

FWIW. I started a page to collect the pros and cons. The whole LTSP wiki site has great information.

There's a CentOS version of K12LTSP

Terrell Prude&#039; Jr.'s picture

"If I did it over again, I would have chosen CentOS or maybe Ubuntu LTS."

You're in luck. Thanks to Eric "Mr. K12LTSP" Harrison, there is indeed a CentOS version of K12LTSP, which is a turn-key, ready-to-roll, LTSP-ifyed GNU/Linux distro. You don't need to download diddly-squat extra. Here's the download link. Look for K12LTSP 5.0-EL.

If you like Debian/Ubuntu, then consider Edubuntu. It's the same thing as K12LTSP, but with an Ubuntu base.