ltsp¶
Run the specified LTSP applet with applet-options. To get help with applets and their options, run `man ltsp applet` or `ltsp —help applet`.
APPLETS¶
The following applets are currently defined:
- dnsmasq: configure dnsmasq for LTSP
- image: generate a squashfs image from an image source
- info: gather support information about the LTSP installation
- initrd: create the ltsp.img initrd add-on
- ipxe: install iPXE binaries and configuration in TFTP
- kernel: copy the kernel and initrd from an image to TFTP
- nfs: configure NFS exports for LTSP
LTSP clients also have some additional applets, like initrd-bottom, init and login, but they’re not runnable by the user.
OPTIONS¶
LTSP directories can be configured by passing one or more of the following parameters, but it’s recommended that an /etc/ltsp/ltsp.conf configuration file is created instead, so that you don’t have to pass them in each ltsp command.
-b, —base-dir=/srv/ltsp This is where the chroots, squashfs images and virtual machine symlinks are; so when you run ltsp kernel img_name , it will search either for a squashfs image named /srv/ltsp/images/img_name.img, or for a chroot named /srv/ltsp/img_name, if it’s a directory that contains /proc. Additionally, ltsp image img_name will also search for a symlink to a VM disk named /srv/ltsp/img_name.img. $BASE_DIR is exported read-only by NFSv3, so do not put sensitive data there. -h, —help Display a help message. -m, —home-dir=/home The default method of making /home available to LTSP clients is SSHFS. In some cases security isn’t an issue, and sysadmins prefer the insecure NFSv3 speed over SSHFS. $HOME_DIR is used by ltsp nfs to export the correct directory, if it’s different to /home, and by LTSP clients to mount it. -o, —overwrite[=0|1] Overwrite existing files. Defaults to 1 as administrators are not supposed to manually edit LTSP autogenerated files, but maintain local content into separate files (e.g. /etc/exports.d/local.exports). If you manually maintain ltsp.ipxe, it might be a good idea to set OVERWRITE=0 in ltsp.conf. -t, —tftp-dir=/srv/tftp LTSP places the kernels, initrds and iPXE files in /srv/tftp/ltsp, to be retrieved by the clients via the TFTP protocol. The TFTP server of dnsmasq and tftpd-hpa are configured to use /srv/tftp as the TFTP root. -V, —version Display the version information.
FILES¶
/etc/ltsp/ltsp.conf All the long options can also be specified as variables in the ltsp.conf configuration file in UPPER_CASE, using underscores instead of hyphens.
ENVIRONMENT¶
All the long options can also be specified as environment variables in UPPER_CASE, for example:
BASE_DIR=/opt/ltsp ltsp kernel . EXAMPLES¶
The following are the typical commands to install and maintain LTSP in chrootless mode:
# To install: ltsp image / ltsp dnsmasq ltsp nfs ltsp ipxe # To update the exported image, after changes in the server software: ltsp image / The following are the typical commands to provide an additional x86_32 image, assuming one uses VirtualBox. If you specifically name it x86_32, then the ltsp.ipxe code automatically prefers it for 32bit clients:
ln -rs $HOME/VirtualBox\ VMs/x86_32/x86_32-flat.vmdk /srv/ltsp/x86_32.img ltsp image x86_32 ltsp ipxe About¶
Linux Terminal Server Project helps in netbooting LAN clients from a single template installation that resides in a virtual machine image or a chroot on the LTSP server, or the server root (/, chrootless). This way maintaining tens or hundreds of diskless clients is as easy as maintaining a single PC.
LTSP has been redesigned and rewritten from scratch in 2019 by alkisg in order to support new technologies like systemd, updated desktop environments, Wayland, UEFI etc. Only the new version is actively developed, while the old one is now called LTSP5 and is in minimal maintenance mode.
LTSP automatically configures and uses the following tools:
- iPXE: network boot loader that shows the initial client boot menu and loads the kernel/initrd.
- dnsmasq or isc-dhcp-server: DHCP server that assigns IPs to the clients, or ProxyDHCP server when another DHCP server is used, e.g. a router.
- dnsmasq or tftpd-hpa: TFTP server that sends ipxe/kernel/initrd to the clients.
- dnsmasq: optional DNS server for DNS caching or blacklisting.
- mksquashfs: creates a compressed copy of the template image/chroot/VM to be used as the client root /.
- NFS or NBD: serve the squashfs image to the network.
- tmpfs and overlayfs: make the squashfs image temporarily writable for each client, similiarly to live CDs.
- NFS or SSHFS: access the user’s /home directory which resides on the server.
- SSH or SSHFS or LDAP: authenticate users against the server.
What are you waiting for? Continue to the installation page!
Installation¶
All the terminal commands in the documentation should be run as root, which means you should initially run sudo -i on Ubuntu or su — on Debian.
Server OS installation¶
The LTSP server can be headless, but it’s usually better to install the operating system using a «desktop» .iso and not a «server» one. All desktop environments should work fine, but MATE receives the most testing. Any .deb-based distribution that uses systemd should work; i.e. from Ubuntu Xenial and Debian Jessie and onward. If you choose Ubuntu, you may also consider removing snap to avoid some issues.
Adding the LTSP PPA¶
The LTSP PPA is where stable upstream LTSP releases are published. It’s mandatory for distributions before 2020 that have the older LTSP5, and optional but recommended to have in newer distributions. Follow the ppa page to add it to your sources, then continue reading here.
Installing LTSP server packages¶
The usual way to transform a normal installation into an LTSP server is to run:
apt install --install-recommends ltsp ltsp-binaries dnsmasq nfs-kernel-server openssh-server squashfs-tools ethtool net-tools epoptes gpasswd -a administrator epoptes Replace administrator with the administrator username. If you’re not using the PPA, also replace ltsp-binaries with ipxe . Description of the aforementioned packages:
- ltsp: contains the LTSP code, it’s common for both LTSP servers and LTSP clients.
- ltsp-binaries: contains iPXE and memtest binaries.
- dnsmasq: provides TFTP and optionally (proxy)DHCP and DNS services. Possible alternatives are isc-dhcp-server and tftpd-hpa, but only dnsmasq can do proxyDHCP, so it’s the recommended default.
- nfs-kernel-server: exports the virtual client disk image over NFS.
- openssh-server: allows clients to authenticate and access /home via SSHFS.
- ethtool, net-tools: allow disabling Ethernet flow control, to improve LAN speed when the server is gigabit and some clients are 100 Mbps.
- epoptes: optional; allows client monitoring and remote control; the gpasswd command allows the sysadmin to run epoptes.
All those packages can also be displayed with apt show ltsp | grep ^Suggests .
Network configuration¶
There are two popular methods to configure LTSP networking. One is to avoid any configuration; this usually means that you have a single NIC on the LTSP server and an external DHCP server, for example a router, pfsense, or a Windows server. In this case, run the following command:
Another method is to have a dual NIC LTSP server, where one NIC is connected to the normal network where the Internet is, and the other NIC is connected to a separate switch with just the LTSP clients. For this method to work automatically, assign a static IP of 192.168.67.1 to the internal NIC using Network Manager or whatever else your distribution has, and run:
You can read about more ltsp dnsmasq options, like —dns or —dns-servers, in its man page.
Maintaining a client image¶
LTSP supports three methods to maintain a client image. They are documented in the ltsp image man page. You can use either one or all of them. In short, they are:
- Chrootless (previously pnp): use the server root (/) as the template for the clients. It’s the easiest method if it suits your needs, as you maintain only one operating system, not two (server and image).
- Raw virtual machine image: graphically maintain e.g. a VirtualBox VM.
- Chroot: manually maintain a chroot directory using console commands.
In the virtual machine and chroot cases, you’re supposed to install the ltsp package to the image, by adding the LTSP PPA and running apt install —install-recommends ltsp epoptes-client , without specifying any other services. In the chrootless and virtual machine cases, if you’re using separate partitions for some directories like /boot or /var, see the ltsp image man page EXAMPLES section for how to include them. When the image is ready, to export it in squashfs format and make it available to the clients over NFS, run the following commands.
Virtual machines need to be symlinked before running ltsp image :
ln -s "/home/user/VirtualBox VMs/debian/debian-flat.vmdk" /srv/ltsp/debian.img ltsp image debian For a chroot in /srv/ltsp/x86_32:
You need to run these commands every time you install new software or updates to your image and want to export its updated version.
Configuring iPXE¶
After you create your initial image, or if you ever create additional images, run the following command to generate an iPXE menu and copy the iPXE binaries in TFTP:
In LTSP5, syslinux was used, but iPXE replaced it as it’s much more powerful. You can read more about it in the ltsp ipxe man page.
NFS server configuration¶
To configure the LTSP server to serve the images or chroots over NFS, run:
For finetuning options, see the ltsp nfs man page.
Generate ltsp.img¶
A new procedure that wasn’t there in LTSP5 is provided by the following command:
This compresses /usr/share/ltsp, /etc/ltsp, /etc/ and the server public SSH keys into /srv/tftp/ltsp/ltsp.img, which is transferred as an «additional initrd» to the clients when they boot. You can read about its benefits in its man page, for now keep in mind that you need to run ltsp initrd after each LTSP package update, or when you add new users, or if you create or modify /etc/ltsp/ltsp.conf, which replaced the LTSP 5 «lts.conf».
Questions¶
Questions? Start a discussion or come to the online chat room.