
Good day, Habr!
Relatively recently, a new version of the popular
Thinstation thin client was released, namely 2.5. And, of course, bears in itself both new buns, and a new rake plus a minimum of documentation on the new version.
In this article (and it is designed for
beginners , especially for those who are not very familiar with Linux), I will describe how to quickly build a thin client and make its use safe enough. Under habrakat use of
smart cards , a RDP client of firm
2X and a happy end. Welcome!
')
Formulation of the problem
So, we have:- Several pieces of iron, proudly referred to as "thin clients." For example, a couple of dozen have not been new HP HSTNC-001L-TC .
- Configured terminal server to which thin clients will cling. Let it be MS Windows Server 2003 or 2008.
And now what, in fact, want:- Download thin clients on the network (diskless that is).
- Support for thin clients MS RDP versions 6+ or even 7, since it is more secure
and cool . - And not just MS RDP, but with TLS 1.0 support .
- User authorization using smart cards (i.e. forwarding a smart card from a thin client to a server).
Grab the world .
Where do we start?
For diskless booting of our thin clients (and they will be loaded via the PXE protocol) we will need to configure a DHCP server and a TFTP server. What is it for, how is network booting (PXE) and how to set it up well and is described in detail
here . As a TFTP server under Windows, I can recommend tftpd32, which can be downloaded
here . Despite the name, there are versions for the x64 platform.
Further, if there is a desire, 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 signs the creation and configuration of images of Thinstation version 2.2.2, much is also relevant 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, it means we need a computer with Linux installed to build a thin client (thanks, KO!). I used Ubuntu 11.10. We will also need to install Git (if it does not already exist) 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
When you first start this script will collect the necessary packages and deploy the entire infrastructure for the further generation of our boot images.
It is time to collect our first, so far, "fat" image. This large image with the support of 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 need to compile a list of drivers that should be included in the image - it is generated automatically by the script.
As the developers advise, the assembly should be performed “inside chroot session”, therefore
we do not exit the
setup-chroot.sh script (press only “Q” to hide the script’s welcome message) and write the following commands in the local console:
cd ts/2.5 nano build.conf
In the file
build.conf we uncomment the line "
package extensions ". If you have internet through a proxy, then uncomment the line "
param httpproxy " and specify its proxy server settings in it (for example, "
param httpproxy user : password @ proxy: port "), save the file and continue building:
./build --allmodules
We look at the long wrapper of the build script log, agree to download additional packages if he asks, and wait for the process to finish. Now we copy the contents of the directory "
/home/user/thinstation/ts/2.5/boot-images/pxe " (and this is our compiled boot image) to the root of the TFTP server and try downloading 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 little RAM, then we go back to editing the
build.conf file and comment out some heavy package, for example "
#package chrome ", repeat the build and see a decrease of almost 2 times. Now the download should go.
Even after that, with a probability close to 100%, the full load of the thin client will not occur. But we do not need this. We are waiting for the loader to show us a picture with the inscription “Thinstation” and a progress bar. After that, press Ctrl + Alt + F3 and see the console with an 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: "
module.list " (a list of drivers for our hardware) and "
vbe_modes.list " (graphics modes). Now they need to be copied to a Linux machine. This can be done, for example, through a TFTP server (it must allow writing). In the console of the thin client, 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 folder "
/home/user/thinstation/ts/2.5/machine/my_machine " and copy our two received files from the root of the TFTP server into it.
Scary beast - smart card
So, in order for our users to log in to the system using smart cards, several things are needed:
- Actually, the smart cards themselves. For example, such .
- Devices for reading smart cards (card readers). For example, such .
- And, of course, our terminal server must be properly configured to use smart cards for authentication. This server setting is a big topic. About her 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 selected by me as an example of maps of the company Aladdin it is here . At this stage, we will 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 collect drivers for a Linux card reader. On the manufacturer's website we find 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 the
README and see that for the assembly we will need to install the PCSC Lite package (there is
here , I installed the latest version of
ccid-1.4.5 at that time), and we also need the source code
libusb-0.1.12 (
it is not going with older versions) .
We put PCSC Lite, in the folder with the drivers for the card reader, copy the
usb.h file from the
libusb sources. Now we start the usual:
./configure make make install
Since Thinstation already contains the PCSC Lite package, we can simply copy our drivers to the Thinstation collector, 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 the reader is loading the thin client, the card reader will be detected and working normally. In version 2.5,
such perversions for working with smart cards, as for 2.2.2, are no longer needed.
RDP clients
Now a little about how the client we will connect to the terminal server.
At the moment, the most famous clients for Microsoft RDP for Linux-based systems are
rdesktop and its fork -
FreeRDP .
But! rdesktop does not support TLS 1.0, and
FreeRDP does not know how to work with smart cards. And this causes frank sadness!
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 of charge and also supports MS RDP version 7.0 and is actively developing. What was my luck when I found out that this client is a member of Thinstation!
The finish line: configure and build
Careful configuration is a big topic, so we read
here in the "
Configuration Files " section what each file is for and where it should be. That 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 - choose the Xorg-driver. This is where the problems arose, because the native driver for my SIS chipset did not fit and I had to figure out in practice which of the remaining ones would work. Vesa works well with my chipset. Perhaps here it is necessary to select the parameter in practice.
- package ccidreader is a 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 needs the Alsa package for work, therefore we include it.
- param fastboot false - if this parameter is set to true , then our boot image will be split into the main and loadable part. Unfortunately, my network card did not load the whole image, therefore we generate an image as a whole.
- param basepath config - specifies which folder on the TFTP server will contain the configuration files for clients ( 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 it cheatfully gets access to the Thinstation console, will not be able to log in under the root. And this is good)
- param 2xurl - specifies where the 2X client will be downloaded from. It will be downloaded only once when you first 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 Ctrl + Alt + Backspace to re-initialize the graphics mode and again get into the console.
And finally, an example of the description of the launch session for a client 2X (
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, fullscreen.
- -C - smart card redirect.
- -u user -p password - logical, user-password. But! After all, 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 password, and the Segmentation fault will spit out you. And this is complete nonsense. However, after long conversations with the support service, 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 quietly log in using a smart card, as if it should be so.
- -s ssl: // myTerminalServerIp - the address of the server to which we will connect. ssl indicates that TLS 1.0 will be used.
With the configuration finished. Now we collect the client: run the
setup-chroot.sh script and enter:
cd ts/2.5 ./build
The resulting image is added to the root of the TFTP server. Also in the root of the TFTP server, create the folder "
config " (the one we specified in
build.conf ) and copy the file
thinstation.conf.network into it.
All is ready! We start, check, see the login window of the terminal server and rejoice! Happy end!
PS Perhaps I missed something in this article. I would like to hear questions and comments. Thank!