From LTSPedia
Jump to: navigation, search
This article, like all articles in the Dev namespace can only be edited by LTSP developers.

This is a blueprint for a new LTSP project, which might be called LTSP 6 or it might even have a completely new name as it will almost be a complete rewrite. GSoC or Outreachy projects are welcome to implement parts or all of this.



LTSP (Linux Terminal Service Project) allows diskless workstations to be netbooted from a single server image, with centralized authentication and home directories. But the project shows its age; the initial thin-client focused design is no longer suitable for the netbooted fat client/wayland era, and it contains a lot of stale source code.

Project goals

LTSP 6 will only need to keep about 10% of the LTSP 5 code base, so knowledge of the current code base isn't necessary. The best way to describe the new project requirements is by analyzing the related server-side and client-side tasks.

Server side

The server side of LTSP 6 consists of:

  • A web server that sends configuration and code to the clients over https, in various boot phases (initramfs, boot, login...). That means that it can be implemented either in python (maybe with twisted) or even in php.
  • An `ltsp` tool that supports a few verbs:
    • ltsp dnsmasq: configures dnsmasq for netbooting (was: ltsp-config dnsmasq)
    • ltsp tftp: prepares or updates the tftp dir (was: ltsp-update-kernels)
    • ltsp httpd: configures apache or some other web server, to provide https://server/ltsp/* pages.
    • ltsp export <source>: generates a squashfs image from a source (was: ltsp-update-image). The source may be a VM disk image, or a chroot, or the server /. Building a chroot (ltsp-build-client) needn't be part of LTSP 6.

Client side

  • The clients get the kernel and initramfs from the LTSP server. But they're actually getting two initramfs's, one the stock distro initramfs, and an additional one prepared by `ltsp tftp`, that contains all the code and configuration to be ran at the initramfs state. This code allows the client to locate the server and boot from it using NBD, NFS or AoE. In LTSP 5, that code lived in /usr/share/ltsp/ltsp_config.d, /usr/share/ltsp/init-ltsp.d and /usr/share/initramfs-tools/*ltsp*. For better cross-distro compatibility, the initramfs-tools based LTSP implementation might imitate some of the kernel parameters defined by dracut (e.g. root:live:http://path/to/squashfs.img).
  • In LTSP 5, LDM is used for authentication, but it doesn't support PAM so it needs to be replaced with something else. LightDM and libpam-sshauth are probably the best candidates for that.
  • Thin clients relied on remote Xorg which hasn't been well supported in recent years. So LTSP 6 should probably only support fat clients, unless Wayland implements some protocol similar to XDMCP.
  • As part of the GSoC/Outreachy project, only a minimal set of the current lts.conf directives needs to be implemented. The rest can be gradually implemented in the future by the LTSP developers.
Personal tools