LTSP5 allows thin clients to be customized unlike ever before. This article shows you how.
In my last column, I walked through the process of setting up an LTSP server and explained the boot process for thin clients. If you need only a simple thin-client environment consisting of a single server with a few clients, that article is really all you need. If you want more power from your LTSP setup, Part II of the series is where things start to get really cool. I'm going to assume you have a basic LTSP server set up and that your thin clients are booting successfully.
LTSP thin clients don't need a configuration file in order to work. To take advantage of the really cool things it can do, however, you need to create one. The file is called lts.conf, and it lives in your tftp root directory. For Ubuntu running 32-bit clients, this means /var/lib/tftpboot/ltsp/i386/. Although it may seem like a strange place for a config file to live, keep in mind that the entire LTSP chroot is converted into an NBD block image. Changing the configuration within that image takes a lot of work, so instead of keeping the config inside the LTSP chroot, it's next to the kernel image and fetched during bootup from tftp. That means any changes made to lts.conf are picked up by the thin client on reboot without the need to re-create the chroot NBD image.
Oodles of configuration options can be set within lts.conf. To get a description of them, be sure you have the ltsp-docs package installed, and type man lts.conf at the command line. The format is fairly simple. Everything under the [default] section will be applied to all thin clients. For options pertaining only to certain devices, a new section is created in square brackets with either the device's IP address or the MAC address—either works. Here is my lts.conf file:
# This is a sample lts.conf file # It's stored in /var/lib/tftpboot/ltsp/i386/ [default] VOLUME = 50 LDM_DIRECTX = True LDM_XSESSION = "gnome-session session=classic-gnome" CUPS_SERVER = 192.168.1.100 DNS_SERVER = 192.168.1.1 SEARCH_DOMAIN = example.com # The following is a powerful thin client [00:a4:5a:44:42:ff] LOCAL_APPS = True LOCAL_APPS_MENU = True LOCAL_APPS_MENU_ITEMS = firefox,vlc,tuxtype
Let's start with the [default] section. The man page for lts.conf will give you an explanation for all the options I've set here, but a couple aren't obvious even after reading the description. The VOLUME setting is fairly easy to understand. For some reason, the thin clients I use are maxed out by default, and the Ubuntu login sound rattles windows and can knock out loose dental fillings on startup. It's loud. By setting the VOLUME level in lts.conf to 50, the volume is happily at half its normal level. Users can change the level, but on every reboot, it is set back to 50%.
The next line is LDM_DIRECTX. This line tells the client to forgo the normal encrypted connection to the server and connect directly via X. This is less secure, but it saves on CPU load. You'll have to determine which is more important in your environment. Keep in mind some older thin clients will really slow down unless you set this option.
LDM_XSESSION tells the thin client, or more precisely the display manager LDM, what type of session to load. In Ubuntu 11.04, I force this to the classic GNOME desktop. That's not an option with more recent versions of Ubuntu, but I leave the option here so you can see it if you want to tweak it for other less-common desktop environments.
The printers can be installed on each server, or if you have a central CUPS server, you can specify it here with the CUPS_SERVER directive. This makes it very simple to set up printing on multiple LTSP servers. Because there is nothing to install, just point to the existing CUPS server, and you're ready to go. (This also applies for local apps, which I'll cover in a minute.)
The DNS_SERVER and SEARCH_DOMAIN settings usually aren't needed. There was a strange bug for years that required the settings in some circumstances. If you have problems resolving DNS on your thin client for whatever reason, setting these options is a good thing to try. I leave them in out of habit more than anything; however, having them here certainly doesn't hurt.
The next few lines are specified for a specific thin client. I actually have these settings in my [default] section and turn them off for particularly old thin clients, but this way I can demonstrate how to apply settings to a specific device as well. The device specified by the MAC address will take all the [default] settings, then apply the settings in its section as well. It's important to note that you can override settings in this manner. If you wanted the volume for this specified device to be 100%, you could add VOLUME = 100 to this section. I'll refer back to the LOCAL_APPS declarations in the next section.
One of the more recent issues facing thin-client proponents are inexpensive workstations. That might seem backward, but although management of thin clients is much nicer on a sysadmin, it's hard to convince users a thin client is better than a $299 computer from Walmart. In fact, if you purchase a new Atom-based thin client, it's running the same CPU and RAM a Netbook uses, most of which run Microsoft Windows! Even low-power thin-client devices are quite powerful, so LTSP takes advantage of that power by offloading some of the work to the thin client itself.
This concept is a little rough to visualize, but if you understand tunneling X11 applications over SSH, it shouldn't be too bad. Like I explained in Part I of this series, the local thin client loads a very stripped-down version of Linux over the network. It has enough to start X11 and then connect to the server where it runs all its applications. This is sort of like running all your applications over an SSH tunnel from a powerful remote server. With local apps, you're still doing that, but instead of running all apps on the server, a few of the memory/CPU-heavy ones are run locally. For the end user, this is completely transparent. As the sysadmin, however, you'll appreciate Firefox with Flash running on the thin client instead of having 50 copies of Firefox with Flash running on your server.
The first thing you need to do in order to use local apps is install the apps locally! Because the NBD image is created from the chroot environment that lives in /opt/ltsp/i386, the first step is to chroot to that, update the apt repositories and install some apps (note that you also mount the proc system once inside the chroot environment):
sudo chroot /opt/ltsp/i386 mount -t proc proc /proc apt-get update apt-get install firefox adobe-flashplugin exit sudo umount /opt/ltsp/i386/proc sudo ltsp-update-image
A quick walk-through shows that I installed Firefox and Adobe Flash inside the chroot. Then I exited the chroot and ran ltsp-image-update, which creates a new NBD image from the chroot environment. Remember the chroot isn't mounted directly, so changes made to the chroot take effect only after a new NBD image is created and the thin clients are restarted. (If you get an error about the Flash plugin not existing, you may have to add the Ubuntu partner repository to the sources.list inside your chroot.)
Now that Firefox is installed locally, peek back at the lts.conf file from earlier. The three lines look similar, but there are subtle differences. LOCAL_APPS is the directive that makes local apps possible. Without this set, the thin client will always launch applications from the server, and not its own system. LOCAL_APPS_MENU goes one step further and tells the thin clients it can rewrite the menu system so that specified applications are launched from the local computer when selected from the menu. The final directive, LOCAL_APPS_MENU_ITEMS, tells the thin client which applications are to be run from the local machine and not the server. With the settings I've listed, any time a user on the specified machine selects Firefox from the menu, it will launch Firefox as a local application. The confusing part is that for the end user, it won't be any different from launching it from a thin client not configured for local apps. The difference is easy to tell when a lab of users starts using an Adobe Flash site, however, because instead of 30 instances of Flash running on the server, each thin client runs it locally.
This new way of launching applications locally seems simple once you wrap your brain around what's actually happening. It does introduce a few frustrating things, however. Because the application (let's take Firefox as an example) is running on the thin client, any Web plugins required will have to be installed in the chroot. This also means printing has to be working inside the chroot, because Firefox is running locally, in order to print. Thankfully, that CUPS_SERVER directive takes care of things if you have a separate print server. If you have a locally installed printer on the server, you need to make sure your CUPS settings allow for other machines to connect. In that case, the thin-client local apps connect to the server's own CUPS server to print.
There are other complications, like downloaded files. Where do they go? Thankfully, the thin client automatically mounts the user's home directory over SSH, so downloads are stored in the user's folder on the server, even though they're downloaded with Firefox as a local app. Local apps are a powerful way to utilize your thin client's hardware, but keeping in mind the complications involved might help you determine when local apps are appropriate. Sometimes, they're not.
A few apps might seem logical to run as local apps to save strain on the server. One of those apps is OpenOffice.org (or LibreOffice in newer distros). Interestingly enough, some applications run so well in the shared server environment, it's silly to run them as local apps. LibreOffice is one of those. Granted, the office suite uses a lot of resources and can hog memory, but with concurrent users, that memory usage is shared by many, many people. In fact, once one user is running LibreOffice, subsequent users can start the application almost instantly, because the program is already in RAM.
The moral of the local app story is to identify which applications are bogging down your server and then see how they behave as local apps. Every LTSP release gets better and better at handling local apps, so if you were burned several releases ago, I recommend giving it a try now.
SSH Keys
One nifty feature of the new LTSP chroot model is that it's possible to tweak your thin client's system any way you like. For me, that includes activating the root user and adding public key authentication for that root user. Creating SSH keys for auto-login is something we've covered in Linux Journal many times before, but setting it up inside your chroot environment might not be something you considered.
If you have the ability to log in to your thin client over SSH (again, this requires installing openssh-server inside the chroot), you easily can reboot a thin client remotely. You also can log in and see if a particular local app is bogging down the thin client. And, because all thin clients share a single chroot environment, it means you can log in to any thin client automatically if you set up SSH keys! This means you can shut down a lab with a single bash loop or reboot a failing thin client without ever leaving your desk. SSH is awesome, and with LTSP, it's easy to set up.
VNC on Clients
If the ability to SSH in to a thin client is useful, the ability to control a thin-client screen remotely is absolutely invaluable. This is slightly more complicated, but well worth the effort (thanks to bootpolish.net for originally posting this method).
Log in to chroot:
sudo chroot /opt/ltsp/i386 mount -t proc proc /proc
Then, install x11vnc:
apt-get update apt-get install x11vnc
Next, create a vnc password file. You'll need to remember this when you want to connect:
echo "yourpassword" > /etc/vncpassword chmod 400 /etc/vncpassword chown root:root /etc/vncpassword
Then, you can exit the chroot:
Exit sudo umount /opt/ltsp/i386/proc
And the last step, which is a little tricky, is to create two files. These files tell LDM (the thin client's display manager) to start and stop VNC. The first file is /opt/ltsp/i386/usr/share/ldm/rc.d/I99-x11vnc:
# /opt/ltsp/i386/usr/share/ldm/rc.d/I99-x11vnc # LDM Script to start x11vnc XAUTH=`find /var/run/ldm-xauth* -type f` start-stop-daemon --start --oknodo --pidfile /var/run/x11vnc.pid ↪--background --nicelevel 15 --make-pidfile --exec /usr/bin/x11vnc -- ↪-display :7 -loop -passwdfile /etc/vncpassword -nossl -logfile ↪/var/log/x11vnc -auth $XAUTH
Note that the start-stop-daemon line is one continuous line ending with $XAUTH.
The second file is /opt/ltsp/i386/usr/share/ldm/rc.d/X99-x11vnc:
# /opt/ltsp/i386/usr/share/ldm/rc.d/X99-x11vnc # LDM Script to stop x11vnc start-stop-daemon --stop --oknodo --pidfile /var/run/x11vnc.pid
Once created, run sudo ltsp-update-image, and any rebooted thin clients should be accessible over VNC using the password you created in the second step. It's a complex setup, but definitely worth it.
I threw a lot of LTSP information at you in this article. If you got lost, or felt overwhelmed, my apologies. Hopefully with a few reviews, it will all make sense. If nothing else, I urge you to try getting local apps working. Harnessing the power of modern thin clients is a great way to stretch your server budget, because with the thin clients running programs like Firefox, your server can handle many more actual thin-client connections.
My next column will finish up the LTSP series as I discuss scaling. LTSP can be scaled in multiple ways, all of which have advantages and disadvantages. The great thing about Linux is that regardless of the number of thin clients you add, you'll never have to pay license fees!
