Back to Home

Thinstation - “losing weight” with thin clients up to version 2.5

thinstation · smart card · rdp · 2X

Thinstation - “losing weight” with thin clients up to version 2.5

image
Good day, Habr!

Relatively recently, a new version of the popular Thinstation thin client , namely 2.5, was released. And, of course, it carries both new buns and new rakes, plus a minimum of documentation for the new version.

In this article (and it is designed for beginners , especially for those who are new to Linux), I will describe how to quickly build a thin client and make its use quite safe. Under habrakat use of smart cards , 2X firm RDP-client and a happy ending. Welcome!


Formulation of the problem


So we have:
  • A few pieces of iron, proudly referred to as thin clients. For example, a couple of dozens of new HP HSTNC-001L-TC cars .
  • A configured terminal server to which thin clients will cling. Let it be MS Windows Server 2003 or 2008.

And now what, in fact, we want:
  • Download thin clients over the network (i.e. diskless).
  • Thin clients support MS RDP versions 6+ or even 7, as It is safer and cooler .
  • And not just MS RDP, but with support for TLS 1.0 .
  • Authorization of users using smart cards (i.e., forwarding a smart card from a thin client to a server).
  • Take over the world .

Where do we start?


For diskless loading of our thin clients (and they will be loaded using the PXE protocol), we need to configure a DHCP server and TFTP server. What is it, for what, how is the network boot (PXE) and how to configure it well and written in detail here . As a TFTP server for Windows, I can recommend tftpd32, which can be downloaded here . Despite the name, there are versions for the x64 platform.

Further, if you wish, you can read a little about Thinstation here , here and here (under the list of files to download). Information in Russian can be found here.although it is already somewhat outdated. There they sign up the creation and configuration of Thinstation images version 2.2.2, much of the same is true for 2.5. Directly version 2.5 is devoted so far only one page . So, let's begin.

First build


Since Thinstation is based on Linux, we need a computer with Linux installed to build the thin client (thanks, KO!). I used Ubuntu 11.10. We will also need to install Git (if it is not already) and use it to clone our repository with the image generator:

sudo apt-get install git-core
cd /home/user/
git clone --depth 1 git://thinstation.git.sourceforge.net/gitroot/thinstation/thinstation
cd thinstation

After the image generator is downloaded, you need to run the script:

./setup-chroot

At the first launch, this script will collect the necessary packages and deploy the entire infrastructure for the further generation of our boot images.

The time has come to collect our first, so far “fat”, image. This large image with support for a very wide list of hardware is needed to then generate a small profile to support our specific hardware. I want to note that this is one of the main advantages of the new version of Thinstation: now you don’t have to manually compile a list of drivers that should be included in the image - it is automatically generated by the script.

As the developers advise, the assembly should be done inside the chroot session, so from the setup-chroot.sh script we don’t exit (we press only “Q” to hide the script’s welcome message) and write the following commands in the console there:

cd ts/2.5
nano build.conf

In the build.conf file , uncomment the line " package extensions ". If you have the Internet through a proxy, then uncomment the line " param httpproxy " and specify our proxy server settings in it (for example, like this: " param httpproxy user : password @ proxy: port "), save the file and continue the assembly:

./build --allmodules

We look at the long footsteps of the build script log, agree to download additional packages if he asks, and wait for the process to finish. Now copy the contents of the directory " /home/user/thinstation/ts/2.5/boot-images/pxe " (and this is our assembled boot image) to the root of the TFTP server and try to load the thin client over the network for the first time.

And here we can meet the first long-awaited rake. If your thin client has a small amount of RAM , then we return to editing the build.conf file and comment out some heavy package, for example, “ #package chrome ”, repeat the assembly and see an almost 2-fold reduction in the overview. Now the download should go.

Even after that, with a probability close to 100%, the thin client will not fully load. But we do not need this. We are waiting for the bootloader to show us a picture with the inscription “Thinstation” and a progress bar. After that we press Ctrl + Alt + F3 and we see the console with the invitation to enter. Enter the following login-password pair " root - pleasechangeme " and run the script:

hwlister.sh

This script will generate us profile files for a specific hardware of our thin client. Usually there are two of them: " module.list " (a list of drivers for our hardware) and " vbe_modes.list " (graphic modes). Now they need to be copied to the Linux machine. This can be done, for example, through a TFTP server (it must allow recording). In the thin client console, enter:

cd /
tftp -p -l module.list -r module.list 192.168.0.1
tftp -p -l vbe_modes.list -r vbe_modes.list 192.168.0.1

, where 192.168.0.1 is the address of our TFTP server. Let's go back to the Linux machine, create the " /home/user/thinstation/ts/2.5/machine/my_machine " folder there and copy our two received files into it from the root of the TFTP server.

Scary Beast - Smart Card


So, so that our users can log in to the system using smart cards, several things are necessary:
  • Actually, the smart cards themselves. For example, such .
  • Smart card readers (card readers). For example, such .
  • And, of course, our terminal server must be properly configured to use smart cards for authentication. This server setup is a big topic. About it separately you can see and read . In addition, to support specific smart cards, it is necessary to install the manufacturer's software on the terminal server. For the Aladdin cards I have chosen as an example, it is here . At this stage, we assume that we have already managed to configure the terminal server and it allows users to log in using smart cards.

Now we need to find and build drivers for the Linux card reader. On the manufacturer’s website we find the drivers here , download and unpack:

cd /home/user/
wget http://www.athena-scs.com/downloads/asedriveiiie-usb-3.7.tar.bz2
tar -xjf asedriveiiie-usb-3.7.tar.bz2
cd asedriveiiie-usb-3.7

We read README and see that for the assembly we need to install the PCSC Lite package (there, here I installed the latest version of ccid-1.4.5 at that time ), and we also need the libusb-0.1.12 source code (it’s not going to be used with older versions ) .

We put PCSC Lite, in the folder with the source drivers for the card reader, copy the usb.h file from the libusb sources . Now run the usual:

./configure
make
make install

Since Thinstation already contains the PCSC Lite package, we can simply copy our drivers to the Thinstation builder, like this:

cp -LR /usr/lib/pcsc/drivers/ifd-ASEDriveIIIe-USB.bundle /home/user/thinstation/ts/2.5/packages/ccidreader/lib/pcsc/drivers
cp /etc/udev/rules.d/50-pcscd-asedriveiiie.rules /home/user/thinstation/ts/2.5/packages/ccidreader/etc/udev/rules.d

All is ready! Now, when loading a thin client, the card reader will be detected and work normally. In version 2.5, such distortions for working with smart cards, as for 2.2.2, are no longer needed.

RDP clients


Now a little about which client we will connect to the terminal server.
Currently, the most famous clients for Microsoft RDP for Linux systems are rdesktop and its fork, FreeRDP . But! rdesktop does not support TLS 1.0, and FreeRDP is not able to work with smart cards. And it causes outright sorrow!

After a long search, another 2X RDP client was discovered. You can download it here . It turned out that he can do all of the above, is free and also supports MS RDP version 7.0 and is actively developing. What was my account when I found out that this client is part of Thinstation!

Finishing line: configure and assemble


Careful configuration is a big topic, so we read here in the " Configuration Files " section why each file is needed and where it should be. This article describes the configuration of Thinstation version 2.2.2. Here I will talk about what has changed in the new version and give examples of my configuration files: build.conf , thinstation.conf.buildtime and thinstation.conf.network .
So, I comment on the parameters from the configurations in the examples:

build.conf:
  • machine my_machine - remember, we generated a profile for iron and put it in the " my_machine " folder ? This is it!
  • package xorg7-vesa - select the Xorg driver. Here problems arose because the native driver for my SIS chipset did not fit and I had to find out in practice which of the remaining ones would work. Vesa works well with my chipset. Perhaps here you will have to select a parameter in practice.
  • package ccidreader - PCSC Lite package that will allow us to work with smart cards.
  • package 2x, package alsa-lib - this is our wonderful RDP client. True, in practice it was revealed that he needed the Alsa package to work, so we included it.
  • param fastboot false - if this parameter is set to true , then our boot image will be divided into the main and loaded part. Unfortunately, my network card refused to load the whole image, so we generate the whole image.
  • param basepath config - indicates which folder on the TFTP server the configuration files for clients will be located ( thinstation.conf.network , for example).
  • #param rootpasswd etc. - comment on the parameters that set any passwords. If the root password is commented out, then no one, even if he cheats access to the Thinstation console, will be able to log in under the root. And this is good)
  • param 2xurl - sets where 2X client will be downloaded from. It will be downloaded only once the first time you run the build script.

thinstation.conf.buildtime:
  • DONT_VT_SWITCH_STATE = TRUE - will not allow the user to switch to the console via Ctrl + Alt + F3.
  • DONT_ZAP_STATE = TRUE - will not allow the user to reinitialize the graphic mode via Ctrl + Alt + Backspace and again get to the console.

And finally, an example session description for a 2X client ( thinstation.conf.network ):

SESSION_0_TITLE="2X"
SESSION_0_TYPE=2X
SESSION_0_2X_OPTIONS="-m MX -C -u user -p password -s ssl://myTerminalServerIp"
SESSION_0_AUTOSTART=ON

where:
  • -m MX - client mode, MS RDP, full screen.
  • -C - redirect a smart card.
  • -u user -p password - logically, user-password. But! We want to log in using a smart card, not a password! It's simple: the fact is that the current 2X client will not start without user parameters and a password, but it will spit you out of a Segmentation fault. And this is complete nonsense. However, after lengthy conversations with customer support, they promised to solve this problem in the next release. In the meantime, we simply write a non-existent user and password at random and calmly log in using a smart card, as if it were necessary.
  • -s ssl: // myTerminalServerIp - address of the server to which we will connect. ssl indicates that TLS 1.0 will be used.


With configuration finished. Now we collect the client: run the setup-chroot.sh script and enter:

cd ts/2.5
./build

We add the resulting image to the root of the TFTP server. Also, in the root of the TFTP server, create the " config " folder (the one we specified in build.conf ) and copy the thinstation.conf.network file into it .
All is ready! We start, check, see the login window of the terminal server and rejoice! Happy end!

PS Maybe I missed something in this article. I would like to hear questions and comments. Thanks!

Read Next