Gentoo and the Linux Terminal Server Project

The Linux Terminal Server Project (LTSP) makes it easy to set up Linux-based thin clients. It packages up all the necessary software and adds custom-written scripts and packages to make the whole process incredibly easy. But the world of LTSP is changing.

Project MueKow (pronounced "Moo-Cow") is a complete rethink on how to handle the creation and distribution of LTSP. In the current 4.x series, the project builds and packages essentially form an entire Linux distribution. Developers Jim McQuillan and Scott Balneaves realized this doesn't make sense because they only add value to a small proportion of packages—5% would be optimistic. Everything else is simply an additional burden that detracts from the time they can spend on the project's real focus. And from a user and distribution perspective, all those packages outside of the distribution's package management create more opportunities for outdated packages, security holes, and other fun problems. MueKow will become LTSP-5.

Four months ago, LWN briefly referred to a story about the future of LTSP, which inspired your author to start a native Gentoo port. What makes Gentoo a solid platform for LTSP? Its source-based nature gives it a number of benefits. Not only can one infamously customize the optimization flags with which packages are compiled, but one can also decide which features to include and which to exclude. For example, one can choose to leave out Kerberos support in Gentoo. In a binary distribution, packages may link against and depend upon Kerberos unconditionally. With diskless clients, including unnecessary features raises the number and size of files that must be transported across the network. This problem gets increasingly severe as one scales up to more clients. Once the Gentoo port is done, the automated client builder will take care of removing unneeded cruft.

Many people use Gentoo not because it is source-based but because of the power and flexibility of the package manager, portage. One feature that makes portage powerful for embedded setups and diskless clients is its ability to install packages into an arbitrary chroot without requiring that the package manager itself be installed there. A simple command such as `ROOT="/opt/ltsp" emerge packagename` will install that package, all of its run-time (not build-time) dependencies, and package metadata to /opt/ltsp. Software installed in a chroot can later be easily updated or uninstalled using similar commands. This integration of the client chroot with the server installation may be unique to Gentoo.

For a distribution to qualify as LTSP-compliant, the LTSP project defined a set of requirements:

• Netboot thin clients with PXE and Etherboot
• Local devices with a FUSE filesystem called LTSPFS
• Network-transparent sound and video
• Screen scripts, including XDMCP, ldm/sdm, rdesktop, telnet, shell
• Boot thin clients with 32MB memory or more
• Use LTSP tools such as getltscfg
• Pass VCI (Vendor Class Identifier) string from the client to the server (in initramfs)
• Transparent pass-through printing
• Network swap using methods such as NBD, iSCSI or NFS
• Configurable location of the LTSP chroot tree
• Control per-client options with a single file, lts.conf

A native LTSP port fulfills the LTSP-5 requirements by adding LTSP-specific packages, porting the automated client builder's distribution-specific plugins, and writing the needed init scripts. Those three steps pretty well take care of the distribution's role in fulfilling the LTSP-5 requirements. The rest is a matter of server configuration. As the packaging and init script porting are fairly trivial once you understand an individual distribution's quirks, we will spend most of our time discussing the client builder. Adding LTSP-specific packages amounts to making a map of the packages installed on an LTSP-4 system, determining which are installed by default, and adding a metapackage to pull in the rest. Many distributions will not have much to port in the init scripts, but Gentoo has a BSD-style, dependency-based initialization process for which the LTSP init scripts will require significant rewriting.

To build a client environment, one runs a script called ltsp-build-client. It creates the chroot, installs the client packages and sets up reasonable defaults. The LTSP client-root builder is a fine piece of work. It's entirely written in shell, and its core is beautifully created so one can simply drop in a new shell-script plugin and have it instantly start working. Each distribution has its own directory for plugins in /usr/share/ltsp/plugins/ltsp-build-client, as a number of tasks are expected to be distribution-specific, but there is a common directory for those few distribution-neutral tasks. Files in the distribution directories can override common files with the same name, and they can use files from another distribution. This is particularly useful in the case of related distributions such as Ubuntu and Debian, both of which already have mostly working LTSP-5 ports. In addition to distribution-level overrides, system administrators can install their own overrides of distribution plugins in /etc/ltsp/plugins/ltsp-build-client.

LTSP has no shortage of interesting projects, such as enhancing support for local devices and selectively running applications on the client rather than the server. To get involved or learn more, join the #ltsp channel on irc.freenode.net or visit the home page.

Index entries for this article
GuestArticles	Berkholz, Donnie

---

to post comments