LTSP past and future

For those of you not yet familiar with LTSP, it’s the Linux Terminal Server Project which goal is to transform a regular workstation into a terminal server that can be used by thin clients. Thin clients are either old computers recycled as thin clients or specialized minimal computers (usually disk less and without moving parts) that are used to boot off the network.

Thin clients evolving

Until now, LTSP was mainly used to do something of these good old P2s unused in the back of the computer lab but things are gently starting to change. Even if you can still use it with old computers running everything on the server and so not using much CPU on the thin clients we’re now seeing way more powerful thin clients appearing (usually Atom-based) where it’d be a waste just to use them as regular all-server-side thin clients.


1520-PXE from Diskless Workstation

Localapps are finally there

Starting with Jaunty’s LTSP one now has the possibility to choose which application will run on the server and which will run locally.

For these of you not living all day in LTSP’s world, our issue was that these thin clients just weren’t using their CPU, everything running on the server. In order to decrease the load on the servers and use the thin clients a bit more, we got the idea of running some of the softwares locally, showing them just like regular application (you usually can’t tell which one are remote and which one are local). They can access the same files and settings as their remote equivalent could, making them from a user point of view almost identical to traditional remote applications (just a bit faster).

This is achieved using LTSP’s localapps and a bit of XDG magic. Basically you can now install firefox in your LTSP chroot, set LOCAL_APPS_MENU to True in your lts.conf and here you go with your usual firefox running locally on your thin client. The XDG magic takes care of adding the application in the menu if this one isn’t installed on the server and if it’s already installed on the server, will tweak the launchers to start the localapp.
As a result you’ll see a decreased CPU usage on the server and also spare a lot of bandwidth as you’ll be accessing the content directly and rendering locally instead of getting the X11 stream directly.

New X and multi-head support

X configuration was also improved a lot, in most case you won’t need to do anything as most common thin clients are already known and fixed and everything else will rely on X’s auto-detection.

You can also play with X RandR extension now and try dual or tri head setups with you thin clients just by playing with XRANDR_MODE_X and XRANDR_OUTPUT_X (X starting at 0 for the first defined screen), it’ll automatically generate a Virtual setting if required by your driver so you can then dual-head.
I’m currently using with my laptop as a thin client hooked up into a 1920×1080 screen using HDMI, its own screen at 1680×1050 and another external screen at 1280×1024 using VGA, all that with LTSP.

And even compiz !!!

For these of you who like eye candies, compiz work perfectly with LDM_DIRECTX set to True (so X11 doesn’t get encapsulated in SSH), then just run “env SKIP_CHECKS=yes compiz –replace” in a shell and you’ll get compiz (or set it in as autostarted application).
Warning: Using SKIP_CHECKS will start compiz without doing any checks, this is needed as the checks won’t work with LTSP but you’ll need to make sure your video card supports compiz without doing it or you may crash your X server.

Clustering for large networks

Since I’ve been at Revolution Linux I’ve been working on LTSP-Cluster which is a set of component on top of LTSP to make it load-balanced and easily manageable on very large networks.
Jaunty is the first release with LTSP-cluster integrated on the thin client, so if you’re managing a large centralized LTSP setup, you may want to have a look at our wiki.

Its core components are:
The Control Center, a web interface (PHP) used to access your network logs, thin clients hardware, organize your thin clients in a tree and set attributes (equivalent of lts.conf) based on the MAC address, position in the tree or even on the hardware of the thin client. Due to some design issue and difficulty to maintain, it’s being rewritten but will at least at the beginning keep the same database to make migration easier.

The Loadbalancer, made of two components, an agent to run on your servers and a server, the server will gather the various information from the servers and return the best server every-time it gets a request from the Control Center.

The Account Manager, a python service to run on the server that’ll create new accounts on the fly for autologin users and will also manage regular accounts, doing the cleanup and ensuring you aren’t logged in twice on the network.

We also have a few more components to do NX integration of the load-balancer and generation of pxelinux’s configuration files. The howto for a generic setup in OpenVZ is present on our wiki though anyone interested in improving the documentation is greatly welcome (just contact me and I’ll answer your questions and give your write access to the wiki so you can contribute).

The additional packages you need for ltsp-cluster services aren’t yet in Ubuntu, so you’ll need to use the PPA to install the loadbalancer server/agent and the control center. Code is available on Launchpad: https://launchpad.net/ltsp-cluster

Trying it out

Starting with Hardy, LTSP is now part of the Ubuntu Alternate CD-Rom.
It can be installed by selecting the “LTSP server” option from the cdrom boot menu, installation is easier if you have two network cards, one for internet and the other for your thin client LAN.
Complete instructions can be found here: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall (also valid for Jaunty)

Resources

If you’re interested by LTSP, want to try it out or just get more information, these are useful resources:
Ubuntu LTSP help: https://help.ubuntu.com/community/UbuntuLTSP
Edubuntu handbook for LTSP: http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/server.html
LTSP’s website: http://www.ltsp.org
IRC: #ltsp (please mention what distribution and version you’re using) or #edubuntu (LTSP used to be part of Edubuntu)

About Stéphane Graber

Project leader of Linux Containers, Linux hacker, Ubuntu core developer, conference organizer and speaker.
This entry was posted in Planet Ubuntu. Bookmark the permalink.

9 Responses to LTSP past and future

  1. Aloriel says:

    Hum, if you are interested in LTSP I recommend you try TCOS.

    Cheers.

    1. stgraber says:

      Looking at that website, I’m not really sure what TCOS tries to achieve.
      It seems to work in a similar way to LTSP, introducing tools we already have (or tools we integrated) and uses technologies we chose to get rid of like XDMCP as they weren’t always reliable and were limited when it comes to feature (security and ease of use of X properties in the case of XDMCP).

  2. Joris Rossi says:

    Congratulations, Stéphane.
    We were waiting for just the informations you mention here.
    We are a team of the Linux User Group of Rimini (Italų) and we are investigating and deploying LTSP networks especially in schools.
    We have immediately translated this page in Italian, now available here: http://www.riminilug.it/tiki-index.php?page=LTSP+passato+e+futuro

    Ciao
    Joris Rossi

    1. stgraber says:

      Thanks a lot for that translation, I’m happy to know that this blog post was useful to you.

  3. Krsnendu Dasa says:

    Nice summary. Inspiring.

    I tried using the compiz command on one kind of terminal with some problems. How do I troubleshoot compiz on thin clients? I’ll also try it on some other clients and see how it goes.

    Thanks for you dedication to this project. I think it is the most compelling reason to upgrade in Ubuntu right now.

    1. stgraber says:

      When compiz is started manually it shows you the various tests it does and the result.
      Though the main issue is that most interesting tests need Xorg.0.log to work correctly, SKIP_CHECKS just skip all these checks making copmiz to crash when the video card doesn’t support it.

      The ideal way of testing it would be (if you can) to boot a LiveCD and try it from there, if it doesn’t work, it won’t work with LTSP, if it does, then it should work with LTSP and it may be LDM_DIRECTX not being set or a bug that I haven’t seen yet.

  4. Shwetav says:

    I have followed the wiki at https://wiki.stgraber.org/LTSP-Cluster/Documentation/OpenVZSetup to set up everything. Things work fine up-till the following point
    http://192.168.0.21/ltsp-cluster-control/Terminal/?mac=00:D0:B7:B4:EE:DA/ip=192.168.0.252/bootservip=192.168.0.21/code=1
    returns the following
    [Default]
    Warning: Invalid argument supplied for foreach() in /usr/share/ltsp-cluster-control/Terminal/index.php on line 343
    CLUSTER_CONFIGURED=”False”

    It appears that I have to populate attributes in the postgresql database named ltsp.
    However in absence of documentation I am forced to reverse engineer the code to solve this.
    Any help or documentation will be really helpful.

  5. csamik says:

    Thank you for this writing.

    I try to search the web for any explanation of the XRANDR specific lts.conf entries, but can’t find anything. You mentioned to have a working solution.

    Could you send me the xrandr-specific part of your lts.conf?

    I have a notebook in an LTSP environment, and would like to be able to use in dual-head mode.

    Thank you

  6. vedic mathematic says:

    Great Work.Thanks for such greatful post.I appreciate the hardwork.

    Nice
    vedic math blog

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.