Terminal server elevation using the example of LTSP and CentOS 5.4

Intro

Now the idea of using thin clients has become very popular, and in particular - for the organization of training classes in universities and not only. So for my favorite university I had to work hard.
Not so long ago, I was given the task of selecting and configuring a terminal server on CentOS 5.4. Why CentOS - I’m not going to attach my mind, but most likely it was the preference of our system administrators, who will later support the terminal server. Well, I was not given the right to choose.

The task for me was new, it seemed quite interesting, and not trivial at first glance. Having studied a lot of information that Google told me, my choice fell on LTSP ( Linux Terminal Server Project ). This software uses the XDMCP protocol for authentication between the X-server and the X-client, as well as the xrdp project, which allows terminal clients (thin clients) to connect to both * NIX systems and Windows.

There are many distributions that already use this software and which were specially created for terminal servers, such as K12LTSP and Skolelinux . And this solution also comes with an alternative Ubuntu disk.
In my case, everything was a little complicated by the fact that there are no ready-made solutions for CentOS, these packages are not located in repositories either. When setting up and installing, I attacked some rakes, whose solution took a lot of time. Having looked for possible solutions for installing LTSP on my favorite Habré, I didn’t find anything, so the idea to write an article was born

I hope that this information will be useful to someone and will try to describe the installation and configuration process in as much detail as possible.
')

How does all this work?

I think there is not much to tell. Thin clients are usually diskless stations themselves. When enabled, they attempt to boot using a network card using PXE . Because PXE limits the size of the boot loader to 32 kilobytes — a two-step boot is used when the first boot loader receives and starts a secondary one, which already receives and starts an image of the operating system. After that, the OS kernel created by LTSP is loaded, which mounts the NFS file system stored on the terminal server and starts the terminal client that connects to the terminal server.
The result of all the above should be a server where DHCP, TFTP, NFS, as well as the terminal server itself are raised.

And so let's get started

The first thing I needed to do was install CentOS 5.4 x86_64. I want to stipulate right away that I have little experience with CentOS. For some reason, it turned out that I dislike the entire RedHat line and the distros based on it. As a graphical shell, I preferred KDE (well, I dislike Gnome and that's it), although later I regretted it a bit, since A number of problems arose with KDE and CentOS.

First of all, we go to the site and download the disk image with LTSP packages ( http://ltsp.mirrors.tds.net/pub/ltsp/isos/ ). I chose version 4.1.1 because frills of newer versions (such as sessions via ssh and so on, I did not need). Next, we mount this image and install the ltsp-utils.0.11-o.noarch.rpm package.

#rpm –i ltsp-utils.0.11-o.noarch.rpm

Then we get the command line utilities ltspadmin and ltspcfg . The first utility is used to configure the installation and the LTSP installation itself, the second one - to configure the already installed terminal server. Run the ltspadmin utility .

First of all, we need to configure the installer, respectively, we select the Configure the installer options menu item. The first question we are asked to determine where we will receive the packages. You can use the site of the project itself, but it is wiser to indicate the path to the image we have mounted. In my case, this is file: /// media / CDROM / . Please note that on the way 3 slashes are used, as indicated in the installation documentation.

The next question is the path where the LTSP will be installed. By default, it points to / opt / ltsp . I see no reason to change it. If you specified the address (which is set by default) as the path to the location by the package http, then you need to specify the address http (or ftp if the packets are on ftp) of the proxy server. At the end, we confirm the settings are correct and returns us to the previous menu item. Now we can proceed to the installation of the terminal server.

After installation we will have:

LTSP packages in the / opt / ltsp folder
files needed to load PXE clients in the / tftpboot / lts / folder

Installing DHCP and TFTP servers.

To download our thin clients over the network, we need a DHCP and TFTP server. I did not find the TFTP server in the CentOS distribution, and I decided to install DHCP manually - this is more reliable. Accordingly, we install them:

# yum install dhcp.x86_64 tftp-server.x86-64

Next, you need to open port 69 for the UDP protocol in the firewall of our terminal server. To do this, use the console utility system-config-securitylevel-tui. Click the button “Refine” and set up the rules of our firewall

In my case, I have 2 interfaces on the server: one looks at the network of classes - the second is the managment interface. We select the interface through which our thin clients will knock on the tftp-server and add it to the trusted ones, as well as open the 69th port for it.

LTSP configuration

For configuration, we can use the Configure LTSP utility menu item of ltspadmin or directly call ltspcfg. In the menu that appears, select the manual setting:

We are going through all 11 points. Point 8 can be skipped in principle. After completion, we will have almost everything you need.
It is worth paying attention to points 3 and 7. In point 3 a sample configuration file of the DHCP server ( /etc/dhcpd.conf.sample ) will be created, which needs to be edited. After the changes - he got the following look from me:

# # Sample configuration file for ISC dhcpd # # Make changes to this file and copy it to /etc/dhcpd.conf.sample # ddns-update-style none; default-lease-time 21600; max-lease-time 21600; #option domain-name "ltsp"; # <--Fix this domain name option option-128 code 128 = string; option option-129 code 129 = text; subnet 192.168.130.0 netmask 255.255.255.0 { use-host-decl-names on; option log-servers 192.168.130.254; range dynamic-bootp 192.168.130.1 192.168.130.253; ## . option root-path "192.168.130.254:/opt/ltsp/i386"; ## . option broadcast-address 192.168.130.255; option routers 192.168.130.254; option subnet-mask 255.255.255.0; if substring (option vendor-class-identifier, 0, 9) = "PXEClient" ## - PXE { filename "lts/2.6.9-ltsp-3/pxelinux.0"; ## CentOS tftp -s, . /tftpboot/lts/..... } next-server 192.168.130.254; ## <- . ! }

I want to draw attention to the fact that the path to the PXE bootloader is not full, because in RedHat and CentOS it runs with the –s key, respectively, the folder of the tftp server in the path we omit. There was also a problem with the idea that next-server option should be specified only when the DHCP and TFTP servers are on different servers. But without this option, the boot is stubby until I duplicate myself as next-server.

At this stage, I was glad that the configuration was completed and tried to boot from the thin client. But it was not there! As a result, Iksa was launched, but there was no connection to the terminal server. As it turned out, the standard session manager on CentOS is gdm (Gnome), and since I didn’t have Gnome at all, kdm didn’t even try to start it. In order for OS to use kdm it is necessary to make some changes to the configuration file, namely - / etc / sysconfig / desktop (if there is no file, you must create it):

DISPLAYMANAGER="KDE"

The next disappointment was that when X was started on the terminal client, they fell because the server stupidly rejected any attempts to open remote sessions. Changing is not a problem, the problem for me was that I could not find the standard KDE configuration files. At CentOS, they are “hidden” in a completely different place. As a result, its location can be determined as follows:

# locate Xaccess

Next in the specified file we are looking for a line.

#* #any host can get a login window

And uncomment it. Restart X, we boot our thin client - and voila! Everything is working!

findings

As a result, we received a computer class based on the use of thin clients. About their benefits is not worth telling. According to the statements, the general recommendation has always been this: 256 MB of RAM for the server itself, plus 60 MB for each connected client (it is sometimes advised to allocate 100 MB to the terminal). Since all the programs are executed on the server, it does not hurt to have a margin of computing power: a dual-core or dual-processor system will work especially well. When working with many clients, it would be nice to use a 64-bit processor, not only because of the additional performance, but also because it can work with a large amount of memory, which is often the most important factor limiting performance. How this will work in reality is not yet known. If this topic is interesting to anyone, I will write about the results in the next post.