monline

After upgrading to Maverick (from Karmic) and re-creating the LTSP chroot from the Maverick repositories, I was surprised to see that the image file was almost the same size as the chroot directory (/opt/ltsp/i386) itself. As it turns out (from the changelog of the ltsp source package), some people experienced problems with compressed chroot images and the decision was made to disable image compression by default.

LTSP uses a FUSE-based filesystem (LTSPFS) for providing access to devices that are attached to the thin client, but are used on the terminal server in the user's session. The creators of LTSPFS took an unconventional approach: users cannot (and are not supposed to) manually eject these LTSPFS mounts, the system does this on it's own after 5 seconds of inactivity (at least it's 5s in Karmic). This is meant to make use of USB devices more comfortable. Unfortunately LTSPFS does not provide any means to the user to detect whether the device is still in use or not. My small modification comes here in play.

Googling in the subject and reading the user manual of TrueCrypt you get the feeling that TrueCrypt is only usable with root privileges, thus normal users are left in the cold. However, this is only partly true. The system administrator can set things up so that normal users are able to mount TrueCrypt volumes too and without opening up serious security holes.

The DebuggingLTSP page at the Ubuntu Wiki lists a number of tools that can help isolate various issues like problems with power saving modes (ie. power usage in idle state), monitoring various system performance metrics (cpu, mem, network, discs), etc.

For some time I had a problem with USB drives on my LTSP client: the attached devices did not unmount automatically and of course if I just plugged the drive from the USB slot, some changes (file modifications or deletions, etc.) were lost. Sometimes a little filesystem corruption could occur too. Just the basic stuff that can happen if you plug a removable device without unmounting it first. The more I had to use USB drives, the more frustrating this bug became. Finally I took the time to track it down and found the problem.

It appears a bunch of people created a more or less up-to-date document on LTSP last year. Seems like a good intro and quick start guide for newbies.

The right search query for this topic is something like "ltsp fuse user group". Actually I came from a pretty different direction to the solution (using pam_group in /etc/pam.d/common-auth), but once I got to pam_group, the page with the exact instructions was revealed right away.

LTSP was originally made for netbooting "thin" clients from where users log on to terminal servers and all the actual work was done on the server. This approach has the advantage that the clients can be really thin (low-power CPUs without active cooling -ie. fans-, etc. ... at least compared to high-end desktop PCs) and thus easily managable, and since the client does not necessarily have to have any moving parts, it can have a lot higher MTTF. However graphics intensive applications (like video editing, full-screen video playback, gaming, etc.) are not feasable via LTSP's thin client solution. The solution in this case is to have a full desktop linux on the clients, but to make life (ie. the system administrators' life ) a lot easier, these "fat" clients should netboot too. LTSP's chroot building framework is of great help in achieving our goal.

As I already pointed out, nethogs is a very useful app for quickly identifying the process causing the bottleneck in your network traffic of your LTSP server (or any other linux server ). However in case of LTSP it's usefulness is very limited by the fact that the processes are sorted by the incoming traffic and this cannot be changed. But no problem: open source comes to the rescue!

To cut it short, use the nethogs utility. You'll see an output like this:
Nethogs is not the perfect tool despite of its ease of use. Read more for some further tips.