Linux Terminal Server Project (LTSP) is a free and open-source terminal server for Linux that allows many people to simultaneously use the same computer. Applications run on the server with a terminal known as a thin client (also known as an X terminal) handling input and output. Generally, terminals are low-powered, lack a hard disk and are quieter and more reliable than desktop computers because they do not have any moving parts.

This technology is useful in schools as it allows the school to provide pupils access to computers without purchasing or upgrading expensive desktop machines. Improving access to computers becomes less costly as thin client machines can be older computers that are no longer suitable for running a full desktop OS. Even a relatively slow CPU with as little as 128 MB of RAM can deliver excellent performance as a thin client. In addition, the use of centralized computing resources means that more performance can be gained for less money through upgrades to a single server rather than across a fleet of computers.

By converting existing computers into thin clients, an educational institution can also gain more control over how their students are using computing resources as all of the user sessions can be monitored on the server. See Epoptes (A Lab Management Tool).

The founder and project leader of LTSP is Jim McQuillan, and LTSP is distributed under the terms of the GNU General Public License.^[2]

The LTSP client boot process

1. On the LTSP server, a chroot environment is set up with a minimal Linux operating system and X environment.
2. Either:
   1. the computer will boot^[3] from a local boot device (like a harddisk, CD-ROM or USB disk), where it loads a small Linux kernel from that device which initializes the system and all of the peripherals that it recognizes, or
   2. the thin client will use PXE or Network booting, a part of the onboard Ethernet firmware, to request an IP address and boot server (the LTSP server) using the DHCP protocol. A PXE bootloader (PXElinux) is loaded which then retrieves a Linux kernel and initrd from a Trivial File Transfer Protocol (TFTP) service usually running on the LTSP server. Using the utilities in the initrd, the kernel will request a (new) DHCP IP address and the address of a server from which it can mount its root filesystem (the chroot mentioned above). When this information is retrieved, the client mounts the path on its root filesystem via either the Network File System (NFS) or Network Block Device (NBD) services running on the LTSP server.
3. The client then loads Linux from the NFS mounted root filesystem (or NBD filesystem image) and starts the X Window system. At this XDMCP login manager on the LTSP server. In case of the newer MueKow (LTSP v5.x) setup, the client first builds an SSH tunnel to the LTSP server's X environment, through which it will start the LDM (LTSP Display Manager) login manager locally. From this point forward, all programs are started on the LTSP server, but displayed and operated from the client.

Scalability

Initially, the MILLE-Xterm project, funded by Canadian public agencies and school districts in the province of Quebec, created a version of LTSP integrating four subprojects: a portal (based on uportal), an open-source middleware stack, a CD with free software for Windows/Mac and, finally, MILLE-Xterm itself. The MILLE-Xterm project's goal was to provide a scalable infrastructure for massive X-Terminal deployment.^{[citation needed]}

MILLE means Modèle d'Infrastructure Logiciel Libre en Éducation (Free Software Infrastructure Model for Education) and is targeted at educational institutions.

As of 2009, MILLE-Xterm was integrated back into the LTSP as LTSP-cluster, a project specializing in the large scale deployment of LTSP. One of the main differences between LTSP and LTSP-cluster is the integration of a web-based central control center that replaces the traditional "one configuration file per thin client" as is the method of client customization through LTSP's lts.conf file in the main LTSP. LTSP-cluster allows organizations to centrally manage thousands of thin clients and their parameters from a central location.

In LTSP-cluster high-availability and high-performance thin-clients are specified through the optional use of redundant components. Services that can be load-balanced and made highly available are:

• DHCP server
• TFTP server
• Boot servers (root filesystem for the thin clients)
• Application servers
• Control center (PostgreSQL database + web frontend)^[5]

LTSP-Cluster can support Linux application servers as well as Windows application servers and provides a similar level of support, centralized management, high-availability, and load-balancing features for both platforms.

Also included is support for virtual desktops for remote users using NX technology. The NX protocol can allow remote Windows and Linux sessions to be accessed from a web browser with very low bandwidth (40 kbit/s) requirements and tolerance for high-latency connections. The NX client runs on various operating systems including Linux, Mac, and Windows.

Fat clients

LTSP v5.x added support for a thin client type known as "fat clients". With the advent of inexpensive, relatively powerful computer hardware, the idea to run applications locally on the thin client while offering the manageability of a thin client solution became a reality. In the case of a LTSP fat client, the root filesystem is not a rudimentary chroot but a full Linux installation as a chroot. The fat client uses LDM to authenticate to the LTSP server and mounts user home directories using SSH and FUSE. The local CPU and RAM is used on the fat clients, which provides a few benefits.

1. the LTSP server does not suffer from users abusing resources and affecting the performance and availability of the LTSP server to other users
2. multimedia and 3D applications perform better and utilize less network bandwidth

LTSP is unique in offering the ability for a computer to mount its root filesystem over a network and run applications locally. On the Windows platform, the closest equivalent solution is to use a technology like Intel vPro to run a client-side hypervisor and mount the root filesystem image using iSCSI.