Designing a Centralized Linux Thin Client Solution with LTSP and Apache Guacamole

Managing many desktop computers can become difficult when each machine has its own operating system, user accounts, applications, browser settings, and local files. This is common in computer laboratories, schools, libraries, training centers, internet access areas, and shared office environments.

A centralized Linux thin client design can reduce that complexity.

Instead of installing and maintaining a full desktop operating system on every endpoint, the client machines boot from the network. The desktop image comes from a central LTSP server. User accounts come from a central directory. User home directories come from a central file server. Browser-based remote access can also be provided through Apache Guacamole.

This article introduces the design of a centralized Linux thin client solution using LTSP, Univention Corporate Server, LDAP, NFS, XFCE, Google Chrome kiosk mode, and Apache Guacamole.

This is Part 1 of the series. It focuses on the overview, architecture, use cases, benefits, and network plan. The actual installation steps begin in Part 2.

Series Scope

This series uses Ubuntu 24.04 LTS for the LTSP server and Guacamole gateway with proxy DHCP, UCS LDAP authentication, NFS-mounted home directories, XFCE, and kiosk behavior.

This series also follows an APT-based installation approach. Snap packages are not used.

The planned article series is:

What This Solution Does

This solution provides centralized desktop access for users who do not need a fully installed operating system on each endpoint.

A thin client powers on and boots from the network using PXE. The LTSP server provides the boot files, client image, and desktop environment. After the graphical login screen appears, the user signs in using a UCS account. The user’s home directory is mounted from UCS through NFS.

Depending on the user or use case, the session can load a normal XFCE desktop or launch Google Chrome in full-screen kiosk mode.

Apache Guacamole adds a separate access path. It provides browser-based remote access to desktops, servers, or internal systems through HTTPS.

The design supports two main access models:

LTSP handles the local thin client experience. Guacamole handles browser-based remote access.

Lab Architecture

The lab design uses four machines:

This separates the major services cleanly.

The UCS server handles identity and user storage. The LTSP server handles network boot and desktop delivery. The Guacamole gateway handles browser-based remote access. The thin client acts as the endpoint.

Lab IP Address Plan

The reader should not guess the IP addresses. Before building the system, define the server addresses clearly.

This article series uses the following sample lab plan:

The original LTSP draft clearly used UCS at 192.168.100.75 for LDAP authentication and NFS /home mounting. The Guacamole draft used 192.168.100.137 as the HTTPS endpoint and also connected Guacamole LDAP authentication to UCS at 192.168.100.75.

For this updated series, the LTSP server uses 192.168.100.136 as the sample IP address. Replace it with your actual LTSP server address.

Recommended DNS or host records:

192.168.100.75   ucs01.pinoylinux.intranet ucs01
192.168.100.136  ltsp01.pinoylinux.intranet ltsp01
192.168.100.137  guac01.pinoylinux.intranet guac01

Recommended thin client DHCP range:

192.168.100.100-192.168.100.199

Use static IP addresses for the infrastructure servers. Use DHCP for thin clients.

High-Level Architecture

The LTSP access flow looks like this:

Thin Client
     |
     | PXE / iPXE boot
     v
LTSP Server
     |
     | Graphical login through LightDM
     v
UCS LDAP
     |
     | User identity, UID, GID, groups
     v
UCS NFS /home
     |
     | User files and desktop settings
     v
XFCE Desktop or Google Chrome Kiosk Session

The Guacamole access flow is separate:

User Browser
     |
     | HTTPS
     v
NGINX Reverse Proxy
     |
     v
Apache Guacamole
     |
     v
guacd
     |
     v
Remote Desktop, Server, or Internal System

The two paths can work together in one environment.

LTSP provides local network-booted desktops. Guacamole provides remote access through a browser.

Main Components

LTSP Server

The LTSP server is the core of the thin client environment.

It provides the client boot image and supports PXE or iPXE boot. In the original lab notes, LTSP used a chrootless image model where the server’s root filesystem was used as the client OS image.

This model is useful because the administrator maintains the image from the server side. When packages or configuration changes are needed, the administrator updates the server and rebuilds the LTSP image.

The LTSP documentation describes LTSP images as compressed filesystems used as the network root filesystem for LTSP clients. https://ltsp.org/man/ltsp-image/

PXE and iPXE

PXE allows a computer to boot through the network instead of booting from a local disk.

In this design, the thin client starts, receives an IP address, loads the network boot files, and starts the LTSP environment.

iPXE provides the boot menu and boot logic used by LTSP.

Proxy DHCP

The LTSP server can use proxy DHCP.

This is useful when the network already has a router, firewall, or DHCP server assigning IP addresses. The existing DHCP server still gives IP addresses. The LTSP server only provides PXE boot information.

This reduces changes on the existing network.

The original LTSP draft used a single-NIC proxy DHCP setup with ltsp dnsmasq.

Univention Corporate Server

Univention Corporate Server, or UCS, acts as the central identity and home directory server.

In this design, UCS provides:

LDAP directory
User accounts
Groups
UID and GID values
NFS-based /home directories
Central user management

The UCS manual includes domain services, LDAP directory functions, user management, and the UCS web interface as part of the platform. https://docs.software-univention.de/manual/5.2/en/contents.html

LDAP Authentication

LDAP provides centralized identity.

Instead of creating users locally on the LTSP server and each client, users are created in UCS. The LTSP server checks UCS when users log in.

LDAP tells Linux:

The username
The UID
The GID
The group membership
The home directory path
The login shell

This is important because Linux uses UID and GID values for file permissions.

NFS Home Directories

NFS provides centralized user files.

In this design, UCS exports /home through NFS. The LTSP server and thin clients use that shared /home path so users get the same files and settings when they move between terminals.

The original LTSP draft mounted UCS /home using:

192.168.100.75:/home  /home  nfs  defaults  0  0

That confirms UCS was used as the NFS home directory source in the lab design.

NFS is important because /home stores user files, desktop settings, browser profile data, application settings, and kiosk startup files such as .xsession.

Without NFS, a user may lose files or settings when using a different thin client. With NFS, the user’s home directory follows the user.

LightDM and XFCE

LightDM provides the graphical login screen. XFCE provides the lightweight desktop session.

The original LTSP draft configured LightDM to hide the user list, show manual login, use the GTK greeter, start XFCE, and disable guest access.

This is useful in an LDAP environment because users type their UCS username manually instead of selecting from local users.

Google Chrome Kiosk Mode

Some thin clients need only one web application.

For that use case, Google Chrome can launch automatically in full-screen kiosk mode after user login. The original lab notes used Chromium through .xsession, but this updated Ubuntu 24.04 series uses Google Chrome Stable through Google’s APT repository to avoid Snap.

Google provides Linux software repositories for APT-based systems such as Debian and Ubuntu. https://www.google.com/linuxrepositories/

Apache Guacamole RDP Gateway

Apache Guacamole provides browser-based remote access.

Users do not need to install a separate RDP, SSH, or VNC client. They open a browser, log in to Guacamole, and access the systems assigned to them.

The Apache Guacamole manual covers its architecture, installation, database setup, securing a Guacamole install, extensions, and administration. https://guacamole.apache.org/doc/gug/

The original Guacamole draft used guacd, Tomcat, MySQL, LDAP authentication, NGINX reverse proxy, and HTTPS. It also configured the LDAP backend to point to UCS at 192.168.100.75.

What Happens When a Thin Client Boots

The thin client workflow is:

1. The thin client powers on.
2. The thin client requests a network boot.
3. DHCP gives the client an IP address.
4. LTSP proxy DHCP provides PXE boot information.
5. The client loads iPXE.
6. The LTSP server provides the client image.
7. LightDM appears on the client.
8. The user logs in with a UCS account.
9. The system checks UCS LDAP.
10. The user home directory mounts from UCS through NFS.
11. XFCE starts, or Google Chrome launches in kiosk mode.

This gives users a centralized desktop experience without installing a full local operating system on every endpoint.

What Happens When a User Uses Guacamole

The Guacamole workflow is:

1. The user opens a browser.
2. The user goes to the Guacamole HTTPS URL.
3. NGINX forwards the request to Guacamole.
4. Guacamole authenticates the user.
5. Guacamole connects through guacd.
6. The user accesses an assigned RDP, SSH, or VNC session.

This is useful for admins, support teams, and users who need remote access through a browser.

Use Cases

Computer Laboratories

Computer laboratories often need many desktops with the same settings and applications.

LTSP helps by allowing the administrator to maintain a central client image. Users can log in using UCS accounts and access their files from NFS-mounted home directories.

Digital Classrooms

Schools can use thin clients for classroom terminals.

Students can log in from any available machine and still get their own files and desktop settings. Teachers and admins can keep the environment consistent.

Libraries

Libraries often need public access terminals.

A kiosk browser session can open a catalog, search page, learning portal, or public information system. This reduces user access to unnecessary desktop functions.

Training Centers

Training centers need repeatable desktop environments.

LTSP helps keep the training setup consistent. If a client fails, another client can boot the same environment.

Shared Office Terminals

Some workplaces use shared terminals for HR systems, attendance systems, internal portals, warehouse access, or front desk tools.

A centralized login and NFS home directory setup lets users access the same account and files across shared devices.

Remote Administration

Guacamole helps administrators or support users access internal systems from a browser.

This avoids installing remote desktop clients on every admin device.

Benefits

Centralized Management

The administrator manages the image, user accounts, and access paths centrally.

This reduces repeated manual work on each client machine.

Reuse of Existing Hardware

Old or low-spec computers can often be reused as thin clients if they support network boot and meet the basic desktop requirements.

This can reduce hardware replacement costs.

Consistent User Experience

Users get the same login process, desktop behavior, and file access from any thin client.

This is useful in schools, libraries, labs, and shared offices.

Centralized User Accounts

UCS provides a central place to manage users and groups.

When a user is added, updated, disabled, or removed in UCS, the change can apply to the thin client environment.

Centralized Home Directories

NFS-mounted home directories keep user files and settings on the central server.

This makes backup planning easier because user data is stored in one controlled location.

Flexible Desktop or Kiosk Mode

The same platform can support normal XFCE desktop users and locked-down browser kiosk users.

This makes the design useful for both general desktop access and single-purpose web terminals.

Browser-Based Remote Access

Guacamole adds a browser-based remote access path for desktops, servers, and internal systems.

This is useful for support, admin work, and controlled remote access.

Design Considerations

This architecture must be planned carefully.

The UCS server is important because it provides user identity and home directories. If UCS is unavailable, users may not be able to log in or access files.

The LTSP server is important because thin clients depend on it for booting.

The Guacamole server is important for users who depend on browser-based remote access.

The network is also important. PXE boot, NFS home directories, and remote sessions all depend on stable network connectivity. Wired LAN is strongly recommended for thin clients.

Security should be reviewed before production use. LDAP should use encryption in production. NFS exports should be limited to trusted networks. Guacamole should be served through HTTPS. Admin accounts should use strong passwords. Firewall rules should allow only required traffic.

Design Summary

This design separates responsibilities clearly:

The result is a centralized Linux thin client environment that can support shared desktop terminals, browser kiosks, and remote access.

What Comes Next

In Part 2, we will build the LTSP server on Ubuntu 24.04.

We will prepare the server, install LTSP, configure proxy DHCP, generate the LTSP image, create the iPXE boot files, and test the first PXE boot from a thin client.

References

LTSP Documentation
https://ltsp.org/docs/

LTSP Image Manual
https://ltsp.org/man/ltsp-image/

Apache Guacamole Documentation
https://guacamole.apache.org/doc/gug/

Univention Corporate Server 5.2 Manual
https://docs.software-univention.de/manual/5.2/en/contents.html

Univention Corporate Server File Share Management
https://docs.software-univention.de/manual/5.2/en/shares/index.html

Google Linux Software Repositories
https://www.google.com/linuxrepositories/

Ubuntu Server Documentation
https://documentation.ubuntu.com/server/