From LTSPedia
Jump to: navigation, search

(Pronounced: Moo Cow)


Current state of LTSP

LTSP currently (Up through LTSP-4.2) includes all of bits that the client runs. In fact, we've thought of LTSP as a complete distribution of Linux that just happens to sit on top of a host distro. In the early days (before LTSP-4), we took the binaries from a Redhat system (various versions) and bundled them into tarballs and called that LTSP. This was clearly not the proper way to run an open source project. There was no way to actually build LTSP from the ground up.

Starting with LTSP-4.0, we actually built every bit of it from source code, using the LBE (LTSP Build Environment). This worked out pretty well. We were able to take the source code of each component, and build it. To accomplish this, we had to first build a chroot environment, including the compilers, linker, libraries, shell, header files and utilities. Then, we chroot to that new environment and build the actual LTSP packages.

While the LBE works pretty well, there are some drawbacks to this, including:

  1. The amount of code that needs to be compiled. (In the worst case, glibc needs to be compiled 3 times. Once to build the minimal set of tools needed to setup the chroot env, a second time to actually build the chroot environment, and a third time to build the glibc that the LTSP clients would use)
  2. The amount of time it takes to build.
  3. The lack of tools and documentation to help developers add additional packages to the LBE
  4. The LTSP built from the LBE cannot be properly integrated into a distribution, because it doesn't fit well with the distribution build systems.

But, the single largest problem with building all of the code for LTSP is the fact that for 95) is the init scripts and the configuration information. Basically, the stuff that goes in /etc for the client. (5% is probably an overstatement).

So, why are we responsible for building and shipping 100% ?

A New Approach

An important point I want to make is that what we're outlining below is just an experiment at this point. We're going to try it to see if it works. If it works as we hope, it will likely become the basis for the next major release of LTSP. If it doesn't work, well... at least we'll have learned something.

Rather than shipping the 100% that makes LTSP special, and use the distros packages for the rest.

The developers of a distribution have a significant investment in the packages that they've created, and they continually update the packages as bugs are fixed and security holes are tightened up. Why not leverage the work that they've done, and use those packages to build the LTSP tree that the thin clients will use?

What I'm suggesting is that we rip out the LBE, and throw it away. My original reason for creating the LBE was so that ALL installations of LTSP would be running the same bits. My intention was that we'd provide additional application packages, like firefox and xmms, that could be installed into an existing LTSP deployment. Lets call this the "LTSP-centric" way of thinking. The problem is, this places a huge burdon on us, to produce all of the apps that anyone would want to run locally, including all of the supporting libraries. If we switch to a "Distro-centric" view of the world, we can take advantage of all of the work that the distro developers have put into their distro. For example, If you want to install firefox into an LTSP tree on a Debian system, you'd run the following commands:

chroot /opt/ltsp/i386
apt-get install mozilla-firefox

The apt-get command would take care of also installing all of the dependencies required for firefox. The result is that thin clients running from a Debian host would be executing mostly Debian-supplied bits. Whereas, thin clients running from a Fedora host would be executing mostly Fedora-supplied bits.

This idea greatly reduces the amount of code that we are responsible for, but it also means that the LTSP installer will need to be smart enough to know how to grab the host distros packages and install them in a sub-directory, for the client to use.

Also, the LTSP specific packages wouldn't need to be built in a chroot environment. They could be built by the distribution maintainers, using their own build system.

By using the distributions packages for the LTSP tree, this will allow people to install any packages that they want into that tree. Including, for instance, firefox. The distros package management tools would be used, to deal with dependencies. This should be much easier than the current method of trying to build firefox as a local app in the LBE.

Issues to think about:

  • This method needs to work well on all distros
  • Multiple architectures. We really need to be able to install ppc binaries on an x86 server. People were very excited at LinuxWorld-Boston to see an iBook running as an LTSP Thin Client, booted from an x86 server.
  • When installing an x86 LTSP tree onto an x86 Host, we can use the hosts package management tools, but when the architectures don't match, then we can't use the host tools. pre/post install scripts would fail, and we'd have a real mess. Possibly, we'd have to drop a base tarball in place, which is just enough to get a client booted, and then continue the installation on the client. The client in this case would need to be privileged, to have read-write access to the NFS export.
  • Package administration could be done by chroot'ing into the LTSP tree, and run the pkg mgmt tools. But, when the LTSP and Host architecture don't match, we can't do that. Instead, we'd have to use a priviliged client to run the pkg mgmt tools.
  • We need to find a way to make the LTSP init-scripts compatible with the distribution' standard sysvinit.
  • We'll need a lightweight print spooler, so that local apps (firefox) will have a way to print. We don't necessarily want to spool the print jobs on the thin client. We'd be better off just handing the print jobs over to a server-based printer server.
  • Kernels. We should be able to use the distro supplied kernels. There's really nothing special about the LTSP supplied kernels, other than the nfs-swap patch. We should be able to provide a script to generate the initrd that contains the NIC detection code and then does a pivot-root, just like it does now. The script should also run mknbi-linux against the kernel and initrd, to create the file that is downloaded by etherboot. User-built kernels should be easy to use as well.

Steps to build the LTSP Root-Tree

This outline for building the root-tree is very incomplete. As we go through the process of figuring this out, we'll try to keep this document updated. It's our hope that others, more familiar with the various distributions will jump in, and help.

The following is a rough outline of the process that we'll need to go through, to build the /opt/ltsp/i386 tree:

  1. Make the /opt/ltsp/i386 directory
  2. Use a distro-specific tool, install the base packages. We determine the tools to use, based on the host distro.
Host Distro Base Install Tool
Debian debootstrap --arch i386 sarge /opt/ltsp/i386
Fedora yum --installroot=/opt/ltsp/i386 groupinstall Core
Redhat/SuSE/Mandrake rpm
Gentoo start with a stage2 or stage3 tarball
Slackware installpkg -root /opt/ltsp/i386 -tagfile (custom tagfile)

  1. Install any LTSP supplied packages
  2. Do chroot /opt/ltsp/i386 and use the tools provided by that distro to continue installing packages.


If this works as we think, it will do the following for us:

  • It will be much easier to integrate LTSP into Linux distributions.
  • Installing LTSP will be much faster. Most of the packages will be on the distro installation media.
  • Just about any application can be installed locally, using the packages made for the distro.
  • Preparing kernels for the thin clients will be very simple.
  • If the distros do integrate LTSP, they can also help to keep ltspadmin updated to

work with future releases of that distro.

  • If this experiment works out, it will greatly reduce the number of packages that we are

are responsible for, and it should lower the barriers for other developers wanting to help out with LTSP. This should free us up to work on the really cool stuff, like seemless local device support, better authentication and encryption, local application support and who knows what else.

Over the past couple of years, several people have suggested that we adopt the packaging method from the (insert favorite distro here) distro. I've chosen not to follow that strategy, because if we had chosen to use Debians package management tools, then the Redhat and Gentoo folks would feel alienated. If we chose the RPM, then the Redhat/Mandrake/Suse folks would be happy, but the Debian and Gentoo people wouldn't be happy. You get the picture?

But this new line of thinking involves using whatever package management system is on the host that you are installing on. This new line of thinking began when I got a phone call from Mark Shuttleworth, asking about integrating LTSP into Ubuntu (Debian based distro). Mark explained what he was looking for, and after several emails and a phone conversation with Eric Harrison, I began to think about how we could do this. Then, thanks to the energy of Scott Balneaves during the week we spent in Boston for Linux World 2005, I saw how to actually make it work.

Finally, during a meeting in Portland, Oregon on Feb 24th with Eric Harrison (k12ltsp), Matt Zimmerman (Ubuntu) and myself, we decided to give it a try. At this point, the plan is to integrate LTSP into the next release of Ubuntu (After Hoary Hedgehog). Most of the work that goes into the Ubuntu/LTSP integration will also help us integrate LTSP into the other distributions.

As for the name MueKow, it was part of an inside joke between sbalneav and myself. Somehow, the name stuck. If the experiment works out, this will likely become LTSP-5.0.

-- JimMcQuillan - 28 Feb 2005

Updates by:
-- EvanHisey - 01 Mar 2005

Distro Notes

Ubuntu development

The proposal for LTSP integration into Ubuntu can be found at, and documentation at LTSP is now deeply integrated into Ubuntu, so any Ubuntu chroot can be turned into a network-bootable image. Please send testing feedback to the LTSP or Ubuntu devel lists

Fedora Core 3 Testing

I did an initial build using Fedora Core 3 to test this tonight. The basic commands I executed:

mkdir /opt/muekow
mkdir /opt/muekow/i386
mkdir /opt/muekow/i386/etc

# Set up the key area for yum and then copy over the local key to the chroot area
mkdir -p /opt/muekow/i386/var/cache/yum
cp /var/cache/yum/.gpgkeyschecked.yum /opt/muekow/i386/var/cache/yum/

# Pull in the fedora-release-3-8.i386.rpm so yum will run
# Local
rpm --root=/opt/muekow/i386 -Uvh --nodeps --force fedora-release-3-8.i386.rpm
# Remote
# rpm --root /opt/muekow/i386 -Uvh --nodeps --force
# Note - the transfer kept failing for me so I installed from the local RPM

rpm --root=/opt/muekow/i386 --import
rpm --root=/opt/muekow/i386 --import
rpm --root=/opt/muekow/i386 --import
rpm --root=/opt/muekow/i386 --import
rpm --root=/opt/muekow/i386 --import

yum -c /opt/muekow/i386/etc/yum.conf --installroot=/opt/muekow/i386 groupinstall Base

# Adding X
yum --installroot=/opt/muekow/i386 groupinstall "X Window System"

# Adding XFCE to the build
yum --installroot=/opt/muekow/i386 groupinstall XFCE

After performing the build, the install directory was nearly 2GB. with the /var/cache directory comprising approximately 430MB of that. I performed 3 group installs (XFCE is not a core requirement, so it could be reduced) just to pull in the basics (base and x) and yum pulled in a pile of extra junk.

Since this is an unacceptable size (in my mind) even prior to turning it into an NFS mountable root, I'm going back to the drawing board to figure out which packages are truly required and which aren't.

My goal is to provide the 4 original screen.d services as well as providing a 5th service - a core desktop environment running from the NFS share itself that is able to remotely connect to a variety of other desktop environment in windowed mode. For normal thin client services, such as those at a school or in a corporate environment, there is typically a server that those thin clients connect to and use as their standard machine (XDM, Microsoft Terminal Services, Citrix, etc.) The goal of my build is to provide a service for a lab-oriented environment in which someone routinely connects to dozens of different servers on a daily basis and would like to have those services running in independent windows on a desktop. About the only true local services that I want available are: An X terminal, a web browser, Samba (for using local devices), sound, and a terminal emulator that can use the local resource's comm port.

I'll be looking at package reduction over the next couple days, and then figure out how to build a sane initrd environment for all of this so the NFS share doesn't have any conflicts.

-- DaveFenwick - 06 Mar 2005

Debian development

Based on the LTSP packages from Ubuntu, an LTSP package has been included in Debian. This work is coordinated by Petter Reinholdtsen and Vagrant Cascadian, in coordination with Matt Zimmerman at Ubuntu. LTSP is integrated into Debian(etch), and no external packages are needed to use it:

To test the current debian packages, Install ltsp-server on a debian/etch system, and make an LTSP chroot like this:

# Fetch and install server package from debian/unstable
apt-get install ltsp-server

# Generate LTSP chroot based on etch
ltsp-build-client --dist etch

# Export LTSP chroot using NFS, adding insecure to allow qemu user-net to mount it
echo "/opt/ltsp          *(ro,no_root_squash,async,insecure)" >> /etc/exports
/etc/init.d/nfs-kernel-server reload

# TODO: document dhcp configuration (/etc/ltsp/dhcp.conf include file)

# Test client using qemu
# install qemu
apt-get install qemu

# Add ssh host key for the qemu user-net IP address to get ldm login working in qemu
ssh-keyscan -t rsa,dsa localhost|sed s/^localhost/ >> \

# do a qemu test run...

This build should give you an LTSP client root of about 310 MiB.

Personal tools