Building Diskless Terminal Servers with LTSP

Administering hundreds of physical desktop workstations in enterprise call centers or educational computer labs is a massive hardware and software maintenance burden. Hard drives fail, operating systems require patching, and upgrading hardware across the entire fleet is cost-prohibitive.

LTSP (Linux Terminal Server Project) provides an incredibly elegant virtualization solution. By deploying LTSP, you can convert aging physical PCs into diskless thin clients. Workstations boot directly over the network via PXE, pull a compressed operating system image into RAM, and establish secure remote desktop sessions back to central application servers.

In this guide, I will share the architectural blueprint for structuring an LTSP diskless terminal environment, configuring PXELINUX boot menus, delivering X2Go Thin Client Environment (TCE) sessions over HTTP squashfs images, and designing failover scenarios.

Prerequisites

You will need a central Linux server configured with TFTP, DHCP, and HTTP services, alongside target thin-client workstations configured to boot over PXE.

---

Step 1: Structuring the PXELINUX Boot Menu (pxelinux.cfg/default)

When a diskless thin client powers on, it requests an IP address from DHCP and downloads the PXELINUX bootloader via TFTP. We configure the boot menu to offer two distinct operating system environments: a lightweight X2Go Thin Client Environment (x2go-tce) and a standard Fedora live desktop environment.

Create the PXELINUX menu configuration file /var/lib/tftpboot/pxelinux.cfg/default:

# /var/lib/tftpboot/pxelinux.cfg/default
DEFAULT x2go-tce
PROMPT 0
TIMEOUT 50
MENU TITLE Linux Diskless Boot Menu
MENU COLOR TITLE 1 #ffffff #000000 std
MENU COLOR SEL 0 #ffffff #444444 std
MENU COLOR TABMSG 0 #999933 #000000 std
MENU COLOR UNSEL 0 #aaaaaa

# Option 1: X2Go Thin Client Environment (TCE)
LABEL x2go-tce
    MENU LABEL Boot X2Go Thin Client (TCE)
    KERNEL vmlinuz.amd64
    APPEND initrd=initrd.img.amd64 root=live:http://10.11.99.219/x2go-tce-filesystem.squashfs ro rd.live.image rd.luks=0 rd.md=0 rd.dm=0

# Option 2: Fedora Diskless Live OS
LABEL fedora-live
    MENU LABEL Boot Fedora Diskless Live Desktop
    KERNEL fedora/vmlinuz
    APPEND initrd=fedora/initrd.img root=live:http://192.168.141.2/squashfs.img ro rd.live.image rd.luks=0 rd.md=0 rd.dm=0

Understanding the Boot Parameters

• root=live:http://...: Instructs the kernel to fetch the root filesystem image over HTTP instead of traditional NFS, dramatically reducing TFTP/NFS server overhead and accelerating boot times.
• rd.live.image: Tells the Dracut boot initramfs that it is booting from a live network image.
• rd.luks=0 rd.md=0 rd.dm=0: Disables unnecessary LUKS encryption, software RAID (md), and Device Mapper discovery during boot to optimize startup speed.

---

Step 2: Delivering Remote Desktop Sessions (X2Go and Oracle SGD)

Once the thin client boots into the lightweight Linux operating system in RAM, it establishes a remote display session back to a centralized application server.

1. X2Go TCE Sessions

If booting the x2go-tce image, the workstation launches the X2Go Client instantly. X2Go utilizes the NX 3 core protocol over SSH, providing incredibly fluid graphical desktop performance even over high-latency or low-bandwidth connections.

2. Oracle Secure Global Desktop (SGD) Webtops

Alternatively, if your enterprise utilizes Oracle Secure Global Desktop, thin clients can launch a kiosk browser directly to your SGD Webtop portal:

https://server.induslevel.com/sgd/index.jsp?clienttype=h5c

---

Step 3: Designing Failover and Future-Proofing Scenarios

When operating a diskless terminal infrastructure, the network and central boot servers represent a single point of failure.

1. High Availability Boot Servers

To ensure bulletproof reliability, deploy two identical TFTP/HTTP boot servers behind a Virtual IP (VIP) managed by Keepalived or Keepalived/Pacemaker. If the primary boot server experiences hardware failure, the VIP fails over instantly, ensuring thin clients can continue booting without interruption.

2. HTTP Load Balancing

Because root filesystem images (squashfs.img) are transferred over HTTP, you can distribute the boot load across a cluster of Nginx web servers, preventing network interface saturation during morning shift changes when hundreds of PCs power on simultaneously.

References

• Linux Terminal Server Project Official Site
• Oracle SGD Webtop Configuration Guide