Despite the incredible irony of moving back to mainframe-style computing with modern thin clients and terminal servers, there is a certain attractiveness to running thin clients vs. desktops in environments where users do not require hardcore local computing power, especially in terms of graphics.
Why Go Thin?
The attractiveness largely comes down to management of independent desktop systems + centralized resources vs. thin clients + terminal server. However, there is another attractive feature of going thin: It can be really cheap! I understand that enterprise operations do not have this kind of "cheap" very high on their list of requirements when it comes to connecting users to network resources but I'll ignore that fact for the sake of those who may in fact see benefit from a cheap solution. Besides, even large enterprises that are married to Tier-1 vendors are looking for manageability (which could likely would be why a lot of people turn to the Tier-1s) and this provides manageability!
Cheap, Cheap
So how does one build terminal services and a thin client architecture on the cheap? It starts with recycling aging desktop systems that no longer have the computing power required to run full blown local OS installations and software. Re-using these otherwise near-end-of-life systems is a trade up, though. Unless you still have active service contracts for these systems, the support costs for bad hardware could drag you down... unless you got spares ready to go. If you do still have active support contracts, all the better. In our environment all the thin clients are PII-era white-box machines without any service contracts. When something dies, I yank it out and install a new one. If a system dies altogether and we don't have replacement parts, the system is decommissioned. We haven't run out of thin clients yet, but it will eventually happen. At that point, we will be forced to review our thin client strategy and make a decision on which way to move forwards. I'll briefly discuss that at the end of the article.
LTSP
The core of our Linux-based thin client environment is
LTSP (Linux Terminal Server Project). LTSP provides a means of managing thin client configurations centrally. It should be noted that my experience with managing LTSP ends at version 4.x. I have not yet played around with or implemented LTSP 5.
LTSP provides your thin client systems with a boot image (usually via the network) and once booted, the thin client will pull down it's configuration from the LTSP server. A "nice" LTSP-based thin client environment has a few requirements:
- PXE boot capable thin clients
- DHCP server
- TFTP server
The DHCP and TFTP can and often do all reside on the same physical or virtual system but that's obviously not required. You'll also want to have several other basic network services like DNS, NTP and what not but I assume your network already has such services up and running already.
I won't go over the LTSP installation as the project already has much better documentation that I could hope to produce on the subject. No purpose in duplicating the effort for a poor result! Chances are however that your modern distribution includes LTSP, you just might have to give it a "yum install" or "apt-get install" to pull it down from the repositories and get it installed.
I Know the Pieces Fit!
All these pieces fit together and here's how.
First the DHCP and TFTP servers must be configured to boot your thin clients from the network and provide the boot image your systems will require. For the DHCP server, I used ISC dhcpd and the configuration for networking booting thin clients looks something like this:
group {
# Thin client configuration group
use-host-decl-names true;
next-server 192.168.x.x;
filename "lts/2.6.17.8-ltsp-1/pxelinux.0";
option root-path "192.168.x.x:/opt/ltsp/current/i386";
option font-servers 192.168.x.x;
host thin01 {
hardware ethernet 00:11:22:33:44:55;
fixed-address 192.168.x.y;
}
}
The most LTSP-relevant parts of this configuration are the "next-server", "filename", "root-path" and "font-servers" part of the main configuration and of course the correct MAC address ("hardware ethernet") and IP address ("fixed-address") assignments for each thin client. Of course, you don't have to use fixed addresses for your thin clients, you can just as easily use a pool. I find it useful to maintain a fixed IP on each client however so I always know which client is which by network address instead of just by MAC.
In the example above, "next-server" refers to the address of the TFTP server that hosts your LTSP boot images, "filename" refers to the relative path to the LTSP boot image that your thin clients will be using, "root-path" refers to the root of your LTSP installation (on the server) so the thin client knows were to look for required configurations and files. The "root-path" is shared from the terminal server using NFS in our case and "font-servers" should be fairly self-explanatory if you know a little bit about X11 server architecture.
TFTP is relatively simple. Most TFTP servers are managed via xinetd so I'll provide an example for that case. Here's an approximation of the "/etc/xinetd.d/tftpd" configuration in use in our environment:
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
The only really different/relevant parts of this configuration are the "server_args" and "disable" options. The "server_args" can be used to define the TFTP server's root directory with the "-s /path" option. The "disable" option must be set to "no" and the xinetd server HUP'ed (or restarted) for the TFTP to start and accept connections.
Everything In A Neat Little Package
Once you have DHCP and TFTP setup, you should be able to boot PXE clients. After they've booted, your thin clients will be instructed to run sessions in virtual terminals as per the main LTSP node configuration. If your users are instructed in the use of virtual terminals, this can have several advantages. Say you don't only have a Linux terminal server, you also have a Windows terminal server or ever several terminal servers. In this case, you can have your "client" (local X server) for the Linux server in the 1st vt and the windows terminal server client (running inside another X display) in vt2, etc. You also have the option of using
XDMCP so users are presented with a choice of which terminal server to connect to, this can be your vt3 or the only option you present, it has the same flexibility as any other vt. The caveat for this is that XDMCP does not work with RDP, only X11 so you're left with one terminal, vt1 with your XDMCP provided X11 server choice dialog and vt2 with your Windows terminal server.
At this point you only really need to tweak a single system, the Linux terminal server, to change your users environment. They want the latest Gnome or KDE do they? Upgrade the server, upgrade everything. That's nice. Same goes for security patching, you just update the one system instead of X number of desktops. If you wanted to update your thin client boot images, you could do that as well. A script called "ltsp-build-client" is provided that automates the build process.
Well that was cool. Not really sure where to go from here with this now that I've said I won't talk about LTSP configuration. Hmmm. Posting it anyways.
The purpose of techslaves.org is to unite technical people with the intention of providing a community to share ideas, experiences and questions. We also provide an avenue for online publication of member articles, files, pictures, etc. although we must admit that this part of the site is certainly the least active in terms of updated content.
