Thin general line: we are transferring the office to thin clients running Thinstation. Installing and configuring the Thinstation thin client

EVGENY BUSHKOV

Detailed setup guide
thin clients based on the Thinstation distribution and the NX protocol

NX technology, developed by Nomachine, provides new connectivity options and can revitalize old computers as thin clients.

Before going directly to the description of NX, I will list some trends that are becoming obvious to many today large companies our country:

Computer equipment is becoming cheaper and more accessible than before. At the same time, its productivity doubles every 1.5-2 years according to Moore's law. This leads to the accumulation of equipment that has not exhausted its service life, but is already outdated.
Client-server applications developed at enterprises by programmers from automated control systems departments during the perestroika years still work on old technology, but no longer meet the requirements of the time.
Modern software And OS cannot be made to work on computers with processors of previous generations (i386, i486, etc.).
It is no secret that in many organizations in our country, for a long time, many programs and operating systems that employees installed on their own initiative have been illegally used. At first this was seen as a matter of course, but then it was justified by the financial situation. Now that our country is joining the WTO, the government is forced to quickly correct this situation; therefore, pressure on enterprises from internal authorities has increased to abandon illegally used software and operating systems.

There is an obvious contradiction between the second and third points: it is necessary either to find a way to effectively use old technology to perform modern tasks, or to abandon this technology. If there are enough funds, then the choice is clear. But what to do if there are no funds or there is no way to write off such equipment, and it’s a shame to just throw it away? And how to solve the no less acute problem of “licensed purity” of the programs used, which is mentioned in the fourth paragraph?

Terminal technologies come to the rescue, which allow you to use old computers, and also partially remove the issues of “license purity” if you use solutions based on Open Source products.

The magazine has already published several articles on working with the Thinstation distribution [,]. In this article, I will talk about the specifics of setting up and operating experience in my enterprise with thin clients based on the Thinstation distribution and NX technology developed by Nomachine.

Until recently, in the world of terminal communications there were few known successful network protocols high-level, capable of effectively compressing and encrypting traffic between the thin client and the server. The most famous and popular of them are RDP from Microsoft and ICA from Citrix. Both protocols are used by servers based on MS Windows OS. I was interested in the possibility of using thin clients with servers on Linux based. As a basis for the thin client, a small distribution kit, a sort of Linux designer, Thinstation was almost immediately chosen as the most steadily developing and popular in our country and abroad. But with the choice of the protocol that would be responsible for communication with the server, I had to tinker and experiment. I will list the main criteria by which the protocol was selected. Firstly, we wanted to use as much as possible wide range We have plenty of old computers with processors starting from i486, with a minimum amount of memory. Secondly, they brushed aside commercial products: We didn't want to incur additional costs. Thirdly, good support for the Russian language and Cyrillic alphabet is necessary, as well as the presence of a familiar way for users to switch between layouts - key combinations . Fourthly, within a local network, we do not need to support encryption, but compression and minimization of network traffic are important.

Finding a solution

First of all, I paid attention to VNC as the most common and available in any Linux distribution, as well as being an easy-to-set up product. When you need to connect to a remote desktop of a Linux server with workstation Windows or Linux, the first thing that comes to mind is VNC. Download the latest version of the Thinstation distribution, then unzip the resulting archive file in your home directory. Let's assume that the path to the distribution looks like this: ~/thinstation. The file responsible for the build parameters is located here: ~/thinstation/build.conf. It has detailed comments. About setting it up, as well as how to force the Thinstation image to boot using network card with a junk chip, I won’t go into detail, this has already been written about in the mentioned articles. I will briefly list the steps to configure the client: edit ~/thinstation/build.conf and create an image by running the ~/thinstation/build script. We copy the finished image file ~/thinstation/boot-images/etherboot/thinstation.nbi to the TFTFP server. We add an entry about the MAC address of the thin client’s network card to the dhcp.conf configuration file of the DHCP server. In the TFTP server directory, create a file with settings for this MAC address and/or edit the thinstation.conf.network file. My settings working system can be seen in the listing of the section “Configuring and creating a Thinstation image” and in Fig. 1.

In order to add a VNC client package to the image, uncomment the line “#package vncviewer” in configuration file~/thinstation/build.conf. If the tftp server directory is located in /tftpboot (as it is for me), then edit the file /tftpboot/thinstation.conf.network so that the lines appear in it:

SESSION_0_TYPE=vncviewer
SESSION_0_TITLE="VNC" !}
SESSION_0_VNCVIEWER_SERVER=10.10.10.10:5901

Replace the IP address 10.10.10.10 with the address of your VNC server.

Now let’s check the image assembled with the new parameter in operation: turn on the thin client, wait for the Thinstation image to download and launch, connect to the VNC server. Please note that switching layouts occurs using the “right Alt” key. Actually, it is not the VNC client that is to blame here, but the Thinstation file from the keymaps-ru Cyrillic support package. In order not to spend a long time searching for a solution to the problem, I generated an xkb file on the configured SUSE-10.0 system as follows:

xkbcomp:0 ru.xkb
xkbcomp -xkm ru.xkb ru.xkm

The xkbcomp utility converts the description of the XKB layout into one of the formats. The first command generates a dump of the current layout from the source, which is the X-display “:0”. The second command compiles the resulting file into a system-readable binary form. We replace original file to yours:

cp -f ru.xkm ~/thinstation/packages/keymaps-ru/x-common/lib/kmaps/xkb

After assembling the image, we get normal switching of layouts according to . But the VNC client is unacceptably slow. On computers with a processor lower than the P-200, a sort of “slide show” begins, when any action on the remote desktop is accompanied by a leisurely drawing of these changes on the thin client monitor screen. There are many VNC solutions that use similar methods of encoding data during transmission, all using the Remote FrameBuffer (RFB) protocol. They differ in the number of functions, data encoding parameters, and the number of supported platforms. For example, RealVNC supports server and client for Windows, UNIX, Microsoft PocketPC and Mac OS X, TightVNC includes server and client for Windows and UNIX, VNC for DOS - client for DOS, UltraVNC - server and client for Windows, OSXvnc - server and client for Mac OS X. I tested RealVNC and TightVNC: the second product (both server and client) is subjectively a little faster, but both create a “slideshow” effect on weaker computers. We'll have to try something else as a communication protocol between the client and server. Let's leave VNC alone for now; we'll have to come back to it later. This is where I turned to NX.

Support for the Nomachine NX client first appeared in Thinstation version 2.1 in 2005, and the latest is currently 2.2, which will be implied below. To build an image with the NX package, direct access to the Internet was previously required; in the latest versions of Thinstation, it became possible to specify the path to the file with the “file://” prefix. The client used and supported by the Nomachine NX distribution is still at version 1.5.x, although quite some time has passed since the release of the new version NX 2.0. In the build.conf configuration file, uncomment the “package nx” line, also at the end of the file we will find the “param nxurl” line: indicate the path to the pre-downloaded file, or leave it as it is (you need Internet access). We copy the resulting generated image to the directory of the tftp server, copy the file thinstation.conf.sample from the root of the distribution there, rename it to thinstation.conf.network and edit it: look for #SESSION_0_TYPE=NX and edit the lines related to this session ( here with number 0), entering the necessary parameters.

We turn on the thin client and load the created image, checking the performance. Progress is obvious: the “slideshow” stops on PCs with a P-100, P-120 and higher processor. This is not what we would like to achieve as a result, so PCs with i486 processors will not be able to be used here. We called such PCs “superthin” clients and configured them to work with DOS programs using a combination of FreeDOS and sshdos on the client side and Dosemu on the Linux server side. I won’t talk about them in this article. Nevertheless, this is a good result, let's look at the hardware requirements from the developers of Thinstation and the NX client: the former recommend an i486 processor and 16 MB of memory, the latter recommend a processor with a frequency of 400 MHz and 128 MB of memory. Let us empirically determine the P-120 processor and volume as the minimum required configuration for a thin client to work with the NX package. random access memory 32 MB. I have tested some other clients, in particular XRDP, VNC for DOS, but for one reason or another real alternative I didn't find NX. Now it's time to take a closer look at NX technology.

Review and Brief Description of Nomachine NX

The NX architecture is a set of Open Source technologies and commercial tools designed to make network computing easy and distributed. It consists of server software that allows any UNIX computer to become a terminal server, and clients for a wide range of platforms and operating systems. Nomachine chose as the basis for the NX architecture the well-known and widely used X-Window system, on which the GUIs of Linux and other UNIX operating systems are based.

Most available network solutions was not designed as the primary means for users to access the desktop. Protocols such as RDP and VNC are much simpler than X (and therefore well suited for thin clients), but their simplicity does not compensate for the lack of efficiency and functionality. For example, these protocols are used to draw remote screen transfer of large volumes of image data. Although RDP is a more efficient protocol than RFB (the protocol used by VNC), it was not originally designed for daily use by network devices, but only as an extension to the OS. X-Window is graphics subsystem(not an OS extension), and X applications interact with it using the X protocol, so the OS doesn't have special level, responsible for broadcasting screen updates to the network protocol.

The main disadvantages of X-terminal networks are redundancy and delays in the transfer of X-protocol graphics data. Since the advent of X-Window, the user's desktop has acquired all sorts of graphic elements and effects that have increased demands on data networks.

In Fig. Figure 1 under the number 1 shows traditional work on the X protocol: there is no compression, the requirements for network bandwidth and delays are critical. Let me remind you that in the X-Window ideology, the X server runs on the terminal, and on the terminal server there is an X client that sends requests to the terminal X server.

In the simplest case, you can run applications with graphical output using the -X option of the ssh command, for example, "ssh -X me@server firefox". You can add the -C parameter for compression (the ZLIB library is used). You can also optimize the speed of node interaction by increasing network throughput. But there is a limit above which increasing bandwidth will no longer affect the speed of this interaction. The reason for this is the intense request/response exchange of modern X applications.

NX uses three primary methods to speed up applications: compression, caching, and suppression of excessive X protocol traffic.

All three methods combine to achieve a 70x improvement in the remote X GUI experience while using the highest level of compression on low-bandwidth, high-latency links (in the NX client settings, “modem” corresponds to maximum compression, and “lan” – no compression). In Fig. 1 under number 2 shows the relationship of NX components: compression/decompression and caching are carried out on NX Proxy modules, traffic passes between them via the NX protocol, the requirements for the quality of communication lines are minimal, it is stated that they can operate up to speeds of 9600 bps.

Similar to nxagent broadcasting X traffic, there is another agent (“nxviewer”) that translates RFB/VNC traffic to the NX protocol. This improves connection efficiency by up to 10 times compared to running a regular vncviewer linking a local X display to remote server VNC. We will make sure of this.

In Fig. 1 under number 3 shows the possibility of simultaneous operation of different agents NX, RDP, VNC. At the same time, NX agents effectively translate foreign protocols into their own and then transmit traffic through NX Proxy.

NX Proxy– this component is precisely responsible for compression/decompression: in client mode it encodes requests from X clients and decodes responses from the X server, in server mode – vice versa.
NX Agent– the term “agent” is used to describe the component to which the generated image is passed before being transmitted to the network through a proxy.
NX Viewer– a modified Nomachine regular VNC client that translates VNC/RFB traffic into the NX protocol.
NX Desktop– RDP client that translates RDP traffic into the NX protocol.

Nomachine has opened the source codes of most of its developments and libraries, they can be downloaded by anyone from . Builds from Nomachine itself are available for all clients free of charge, there are also various options assemblies of NX servers, supplied for a fee: an annual subscription to NX Enterprise Server with an unlimited number of users and the number of processors 1-2 costs $1494, the most complete solution with load balancing and node management based on NX Advanced Server will cost $3,494. In addition there is an NX variant Free Edition, which can be downloaded for free, but has a limit on the number of simultaneous connections and users equal to two, so if you want to administer a Linux server from home using a regular analog modem, then this solution cannot be found better, safer and easier. I will also note the presence of client versions of NX Client Desktop Edition for PlayStation 2 (with using Linux Kit), as well as NX Client Embedded Edition for Sharp Zaurus 5xxx and HP/Compaq iPAQ. They can also be downloaded for free. So, if you are on a business trip and only have a PDA with you, nothing prevents you from connecting and working remotely on your Linux server.

Building and Running NX

In turn, based on open source, the community developed a version of the NX server part called FreeNX, as well as KNX, a client for connecting to the server from under X. FreeNX is a set of shell scripts that, together with open libraries from NX, form the server part ( backend).

At the beginning of working with NX, I used a PC with SUSE 10.0 as a server. FreeNX was already being assembled as part of the distribution, but, firstly, it was more than a year old, and, secondly, having encountered the first difficulties while working, I decided that it was time to assemble the server part from the source code myself. I will talk about the assembly from the source code of version 1.5 as the most time-tested, and then I will clarify what features there are for assembling version 2.0 (2.1).

Currently, the source code for version NX 2.0 is posted on the Nomachine website, this version is recommended by the company, and the source code for version 1.5 is also available there special link. Download the latest versions of the following tarballs from the page: nx-X11, nxagent, nxcomp, nxcompext, nxdesktop (if you need RDP support), nxproxy, nxscripts, nxviewer (if you need VNC support). nx-X11 is version 4.3 of Xfree86, which has modified Nomachine X libraries. Some of the sources will be unpacked directly into the nx-X11 tree, so we will expand it first, the order of unpacking the remaining tarballs is not important, the main thing is that they are all unpacked in one directory. There we download and unpack FreeNX scripts from the address . You will also need two patches, download them from here [,]. Our assembly directory will look like this:

freenx-0.4.4
nx-X11
nxcomp
nxcompext
nxdesktop
nxproxy
nxscripts
nxviewer
freenx-lfs_hint.diff
NX-lfs_hint.diff

To build, you will need the following packages (they can be installed from your Linux distribution): libjpeg-devel, libpng-devel, openssl-devel, netcat, expect. A description of the assembly can also be found here.

# Apply NX patch
patch -p0< NX-lfs_hint.diff

# Assembling X - the longest part, can take up to an hour
pushd nx-X11
make World
popd

#nxproxy
pushd nxproxy
./configure --prefix=/srv/NX
make
popd

# Build the RFB agent
pushd nxviewer
xmkmf -a
cp -a /usr/X11R6/lib/libXp.so* ../nx-X11/exports/lib/
make 2> /dev/null
popd

# Building the RDP agent
pushd nxdesktop
./configure --prefix=/srv/NX --sharedir=/srv/NX/share
make
popd

# The entire server part will be located in the /srv/NX directory, create some of the subdirectories
mkdir -p /srv/NX/bin
mkdir -p /srv/NX/lib
mkdir -p /srv/NX/man/man1
mkdir -p /srv/NX/share/doc

# Install the collected libraries and agents
cp -a nx-X11/lib/X11/libX11.so.* nx-X11/lib/Xext/libXext.so.* nx-X11/lib/Xrender/libXrender.so.* /srv/NX/lib
install -m 755 nx-X11/programs/Xserver/nxagent /srv/NX/lib

# Create an nxagent script that will manage all programs
cat > nxagent<< "EOF"

#!/bin/sh

NXCOMMAND=$(basename $0)

export LD_LIBRARY_PATH=/srv/NX/lib:$LD_LIBRARY_PATH
exec /srv/NX/lib/$NXCOMMAND $(1+"$@")
EOF

# And install it:
install -m 755 nxagent /srv/NX/bin

# Install compression and proxy libraries
cp -a nxcomp/libXcomp.so.* /srv/NX/lib
cp -a nxcompext/libXcompext.so.* /srv/NX/lib
install -m 755 nxproxy/nxproxy /srv/NX/lib
ln -snf nxagent /srv/NX/bin/nxproxy

# Installing the RFB agent
pushd nxviewer
make install DESTDIR=/srv/NX
mv /srv/NX/usr/X11R6/bin/nxviewer /srv/NX/lib
ln -snf nxagent /srv/NX/bin/nxviewer
chmod 755 /srv/NX/bin/nxviewer
mv /srv/NX/usr/X11R6/bin/nxpasswd /srv/NX/bin
popd

# Installing the RDP agent
pushd nxdesktop
make install
mv /srv/NX/bin/nxdesktop /srv/NX/lib
ln -snf nxagent /srv/NX/bin/nxdesktop
chmod 755 /srv/NX/bin/nxdesktop
rm -rf /srv/NX/usr
popd

# Installing scripts

# Install FreeNX
mkdir -p /srv/NX/etc
mkdir -p /srv/NX/var
mkdir -p /srv/NX/var/db
mkdir -p /srv/NX/home
mkdir -p /srv/NX/home/nx
pushd freenx-0.4.4

# Apply the freenx patch, mainly here the paths are corrected to match /srv/NX
patch -p0< ../freenx-lfs_hint.diff
cp -a nxnode /srv/NX/bin
cp -a nxserver /srv/NX/bin
cp -a nxsetup /srv/NX/bin
cp -a nxkeygen /srv/NX/bin
cp -a nxnode-login /srv/NX/bin
cp -a nxloadconfig /srv/NX/bin
cp -a nxclient /srv/NX/bin
cp -a nxprint /srv/NX/bin
install -m 755 node.conf.sample /srv/NX/etc
popd

# Add user and group nx
groupadd -g 77 nx
useradd -c "FreeNX user" -d /srv/NX/home/nx -g nx -s /bin/bash -u 77 nx
chown -R root.root /srv/NX
chown -R nx.nx /srv/NX/home/nx

# Next, an important point: before running, read the command launch parameters: /srv/NX/bin/nxsetup –help.
# If you want to use key-based user authentication, remove the –setup-nomachine-key option.
# To work with thin clients, you don’t need to change anything
/srv/NX/bin/nxsetup --install --uid 77 --gid 77 --setup-nomachine-key

# Check if the NX server is running:
/srv/NX/bin/nxserver --status

The answer should be something like this:

NX>100 NXSERVER - Version 1.4.0-44 OS (GPL)
NX> 110 NX Server is running
NX>999 Bye

Install the freenx configuration file:

mv /srv/NX/etc/node.conf.sample /srv/NX/etc/node.conf

In the configuration file we find the following line and uncomment it:

ENABLE_1_5_0_BACKEND="1"

There you can also enable logging for the first time:

NX_LOG_LEVEL=6

Now you can install the Nomachine NX client on any Linux (you can also use KNX) or Windows computer and check the operation of the NX server. You can work with the server both in application mode and in remote desktop mode.

Setting up and creating a Thinstation image

From the NX server side, let's now move on to creating the Thinstation image. The distribution itself can be downloaded here. When assembling the image, we will try to reduce the number of modules and packages as much as possible, throwing out everything unnecessary. Since many computers selected as thin clients will have different hardware and peripherals, I would like to move individual packages out of the framework of a common image for all. Thinstation has this option: pkg means to build as a separate downloadable package with the pkg extension, package means to be included in a common image. The packages lprng, sshd, samba-server and others are definitely collected as downloadable. You can specify all packages with X video card drivers as pkg, but then when building the image, several additional packages will appear that everyone will need to load, and as a result, the total size of the loaded data will be larger. Let's do it simpler: one of the most frequently used video drivers, namely S3, will be specified as package, the rest - pkg. Modules can also be moved outside the kernel, but so far this feature has not worked correctly, and they take up very little space within the kernel. Below is my build.conf configuration file:

module serial
module intel-agp
module via-agp
module 8139too
module floppy
module vfat
module supermount
pkg xorg6-ati
pkg xorg6-i810
pkg xorg6-nv
package xorg6-s3
pkg xorg6-s3virge
pkg xorg6-sis
pkg xorg6-trident
package keymaps
package nx
pkg lprng
pkg sshd
pkg samba-server
param rootpasswd please changeme
param xorgvncpasswd please changeme
param bootlogo false
param boot resolution 800x600
param defaultconfig thinstation.conf.buildtime
param basename thinstation
param basepath .
param knownhosts ./known_hosts
param localpkgs true
param fulllocales false
param bootverbosity 3
param nxurl file://home/zhen/sources/nx/bin/nxclient-1.5.0-141.i386.tar.gz

If you will be printing to a printer connected to a thin client using lprng, you will need to make a small modification to the file thinstation/packages/lprng/etc/init.d/lprng. To do this, replace the line:

echo "$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:lf=/var/log/spooler.log:sh:sf" >> /etc/printcap

echo "$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:if=/bin/lpf:lf=/var/log/spooler.log:sh:sf" >> /etc/printcap

Adding local filtering eliminated the staircase problem when printing. Additionally, I created the following script to test whether printing is working in ~/thinstation/packages/base/bin/my:

#!/bin/sh
echo PRINTER TEST to /dev/printers/0 1>&2
for i in 1 2 3 4 5 6 7 8 9;
do
echo PRINTER /dev/printers/0 $i > /dev/printers/0;
done
echo -e \\r\\f > /dev/printers/0
exit 0;

When it is not clear what exactly is not working, you can run this script on the thin client console: /bin/my.

To prevent a warning window about an unfamiliar host from appearing every time when connecting an NX client to the server, create a known_hosts file in the Thinstation root:

ssh-keyscan -t rsa nxserver_ip>>~/thinstation/known_hosts

As “nxserver_ip” you must specify the IP address of the NX server. This way the client will know about the digital fingerprint of the NX server's RSA key during authentication.

After successful execution of build, copy thinstation/boot-images/etherboot/thinstation.nbi and thinstation.nbi.zpxe, as well as all pkg files from thinstation/boot-images/pkg-packages to the /tftpboot directory on the tftp server. The thinstation.nbi.zpxe file I was creating did not work, in this case you can download the BootPXE535.zip file from this address, this archive contains a universal loader loader-native.zpxe, everything should work with it.

Thinstation configuration files are quite well commented, but the setup process itself and the sequence of actions are not always obvious, so I will still mention some of the difficulties that I had to encounter and the subtleties.

In Fig. Figure 3 shows the main steps to put the thin client into operation. First, add information about the MAC address of the network card to dhcpd.conf. Don't forget to specify the tftp-related settings in the subnet description; they are set by the “next-server” and “option root-path” directives. My tftp and dhcp services are located on the same FreeBSD server, this makes setting them up easier. All settings files are located in /tftpboot. Then in the thinstation.hosts file we write in order: an arbitrary host name (it is better that it includes information about the location of the terminal), MAC address, groups of which the terminal is a member, at the end of the line you can place comments after the “#” sign, for example :

otd146_57158 00e04d08d710 smb_flop_hard TUX1C monitor #very important PC

Here, in order: the host name, in my case, consists of the department number and inventory number, then the MAC, and then a listing of the names of the configuration files that will be used by this host.

Next, we create a settings file thinstation.conf-MAC, I use the MAC address in the name, although you can use the IP address or name from thinstation.hosts. Note that here the MAC address in the file name only uses capital letters. Groups are described in files called thinstation.conf.group-GROUPNAME. The thinstation.conf-MAC file contains those settings that apply only to this terminal and are not included in other groups. For example, all general monitor settings are described in the thinstation.conf.group-monitor file, and one parameter “SCREEN_VERTREFRESH” is moved to the thinstation.conf-MAC file. This is due to the fact that different monitors are used, and the screen frame rate setting can be changed; this and other parameters can be configured for each terminal or for all at once. The same goes for mouse settings. By default, the setting is made for a PS/2 mouse. If a mouse is used connected to the COM1 port, then two parameters “MOUSE_PROTOCOL=Microsoft” and “MOUSE_DEVICE=/dev/ttyS0” are specified, if to the COM2 port, then the second parameter is /dev/ttyS1.

My common configuration file /tftpboot/thinstation.conf.network is almost empty. All information from it is included in separate files group settings, which are referenced in thinstation.hosts. Since two terminal servers with different versions of NX are used and each client uses only its own server, the configurations are placed in separate text files (NX and TUX1C), in addition, different Thinstation images are used. Also, do not forget that the file names thinstation.nbi and thinstation.nbi.zpxe are interrelated: if the line is specified in dhcpd.conf:

thinstation.nbi.zpxe";

then the thinstation.nbi image will be used, in my case there are several images, and accordingly the entries in dhcpd.conf are different for each terminal.

NX2 build differences

Our system uses two NX servers. One runs NX, compiled from source code versions 1.5, and 1.5.x clients are used to work with it. The other one is running NX version 2.0. I'll tell you what the differences are in the operation and assembly of this version. The server has 64-bit Opterons installed and uses the SLES 10.0 x86_64 system. So, I couldn’t build NX on this server the same way as was the case with NX 1.5 on a 32-bit system, even when I tried to explicitly specify the build for a 32-bit system:

make World BOOTSTRAPCFLAGS="-m32"

Apparently, these are features of the 64-bit system and its libraries. A little later, I found a note on the Nomachine website that said that the NX source code was developed for 32-bit systems, but it can also be used on 64-bit systems. Since I still have a computer with SLED 10.0 x86 installed and the versions of all libraries, kernel and programs are exactly the same as SLES, I decided to build NX on it, and then transfer the directory with the build result regular copying on a 64-bit system. That’s what I did: everything worked as if nothing had happened. We download files with the same names as when building version 1.5, only with suffixes 2.0 (or 2.1). Everything compiles exactly the same as in the case of NX 1.5, with some exceptions: firstly, I did not apply the NX-lfs_hint.diff patch, secondly, a new version of the FreeNX 0.5 scripts has appeared, supporting the new NX 2.0, its you can pick it up here, thirdly, the freenx-lfs_hint.diff file, which makes changes to the nxloadconfig file from FreeNX 0.4, does not fit the new version of FreeNX, it needs to be edited. Here is the output of the diff command, showing the difference between the original and the edited nxloadconfig file:

Nxloadconf_orig 2006-07-01 22:03:39.000000000 +0500
+++ nxloadconfig 2006-10-16 12:32:19.000000000 +0500
@@ -56,12 +56,12 @@
NX_LICENSE="OS (GPL)"

Part one: Some lyrics

The following text by the author does not claim to be the ultimate truth and should not be used to judge the average statistical level of IT infrastructure in small companies in our vast country. The article was written based on conversations with numerous familiar IT people (mostly at the “student” and “just out of college” level), who began their careers as IT specialists in small companies.

Let's imagine an average office of a small trading company from an IT point of view:

several dozen weak computers for the secretary, managers, accounting department and, of course, the main Boss;
one, two or three machines performing the following roles:
- windows domain controller (there are often cases when there is not even a domain in the company’s network, and all computers work in a peer-to-peer network);
- file server;
- mail server (instead, external free mail servers are sometimes used, ranging from mail.yandex.ru and gmail.com to ten-dollar hosting for N mailboxes);
- http proxy for filtering access to external resources and logging “where anyone goes” (often missing)
- router/firewall on the border with external network to restrict access to the outside and vice versa (often any entry-level SOHO router priced up to $100 is used as a border router; it also acts as a DHCP server (for dynamically distributing IP addresses to employee workstations);
- other things, the list of which can be quite large;
several printers, often connected locally to employee workstations and shared over the network using standard Windows tools (alternatively, printers can be networked initially or connected through hardware print servers).
in advanced cases - one terminal server (under Windows) for accounting (1C runs on it and there is also a database thereof, and accountants, connecting to the terminal server via standard Windows tools(remote desktop), work with it on a terminal server (locally), which, firstly, gives more convenience, and secondly, speeds up the work of 1C itself (usually 1C with the database is installed on the computer of one of the accountants, and the rest are connected access it from your computers, working with a database shared over the network).

All this equipment is connected into a single local network through one/several cheap 100Mbit switches. And this works in a single NT/Active directory domain (although there are options for peer-to-peer workstations without any domains).

All Windows machines usually have some kind of antivirus installed (although there are exceptions). Not common network versions of these programs (the same Avast), although, again, in more advanced (from an IT point of view) offices, there are network versions of antiviruses with centralized management and updating of antivirus databases.

The above situations vary from case to case, since the configuration of the network, hardware and software is influenced by both the knowledge/skills/desires (and, importantly, laziness) of the system administrator(s), and the understanding of the authorities (represented by the main Boss) " what exactly is this system administrator of ours doing when everything is already working perfectly” (from the latter it follows how much money is allocated for IT equipment and the salary of the future specialist). If little money is allocated (and this is usually the case - managers of trading companies are usually far from IT and have little understanding of what is happening there), then the Enikey employee who has gained enough knowledge leaves for another company. Another student takes the place of the one who left and everything repeats all over again.

I think it is unnecessary to say that in such offices the department system administration consists of one person who combines an engineer for installing/maintaining an office network, a system administrator as such (i.e. the very person who is responsible for the performance of the server park at the software and hardware levels and the implementation of new functionality) and an enikeyshika - “ errand boy” who deals with solving problems for users, wiping mice, changing printer cartridges and similar things.

As a result, small companies often have a fairly diverse fleet of user machines ranging from pentium2/128Mb ram/5Gb hdd to P4 Celeron/1Gb ram/80Gb hdd. All machines, of course, have Windows (98, 2000 and XP Home/Pro) and different versions of software (the machines were installed at different times). It comes to the point that anti-virus software on machines is also from different manufacturers.

And it falls to the difficult lot of the system administrator (and part-time Enikey specialist) to support this entire zoo day and night. But iron sometimes breaks:

the fans begin to buzz obnoxiously (they need to be cleaned and lubricated or replaced with new ones);
power supplies fail;
hard drives are crumbling;
network cards (both built into the motherboard and external ones stop working and require replacement);
the rest of the iron usually flies much less often, but nevertheless flies too

When a hard drive (or computer motherboard) fails, the operating system on the restored machine often has to be rearranged from scratch in this or a very similar sequence:

install Windows;
install the necessary drivers (the entire hardware fleet is different - remember?), having previously determined the model of the motherboard in this machine and downloaded the latest versions of drivers from the Internet or found the ones you need on your file server;
we enter the machine into the domain (if it is configured);
install the necessary software (office, browser, email client, total commanders, ICQ, jabbers, punto switchers, etc.) - in the case of a domain Active Directory Some software can be installed automatically, but not everyone has it configured, and not everyone knows its capabilities;
install antivirus;
plus additional dances with a tambourine, individual for each organization’s specific network around the new workstation;

After successfully completing all points (this procedure takes about two hours), we report to the Boss that workplace The employee is saved and can begin work.

The happy owner of the restored computer sits down at his workplace, after which it turns out that (since the domain profiles were not movable or there was no domain at all, the “my documents” link led to the local drive C:, and about the fact that everything important is needed save on a network drive - on the server, the employee forgot):

I had a folder here with important documents - where is it?
I also saved photos from Turkey there, is it possible to restore them?
there were many important shortcuts and a hundred more documents on the desktop - where did they go?
in favorites (this is about bookmarks in the browser), my favorite sites are no longer there - where can I look for them now? and so on…

Sound familiar? It’s good if it’s not the hard drive that fails, but just motherboard. Or some of the information on the crumbled disk can be restored. But all these procedures take up the working time of the system administrator, which could be spent with much greater benefit playing a network shooter or... studying IPv6 - after all, everyone is already switching to it and will switch very soon, addresses in the IPv4 space have already ended for about five years :)

As a result, supporting the IT infrastructure of a small company for a system administrator turns, for the most part, into supporting the performance of user workstations, namely:

reinstall Windows;
set to new car all the necessary software;
restore everything that was lost;
install new programs for those in need;
carry out preventative maintenance on the case (vacuum the dust in the system unit);

And in the remaining time (if the system administrator is not very lazy), you need to try to learn something new, upgrade the software on the server (servers) and put a new network service into operation. Those. There is just no time left for basic duties (exactly what a system administrator should do most of the time).

How to get out of this vicious circle?

One of the options for solving the problem described above is to abandon “thick” workstations (where this can be done) and switch to .

A “thick” workstation means any computer with an installed OS, which processes the majority of user information. Those. the browser, office and everything else is executed locally on the user’s workstation, the system unit of which hums under his desk or somewhere nearby.

You need to understand that the requirements of modern operating systems (not necessarily Windows) keep pace with modern hardware - in other words, for relatively comfortable work in Windows XP, an old (but fully functional and relatively powerful) Celeron class machine 800Mgz/128Mb Ram/10Gb HDD can not enough. It is, of course, possible to work under a modern OS on such hardware, but this operating system and applications will slow down quite often, if only because of the small amount of onboard memory and old (read: slow) hard drive.

A thin client, in short, can be defined as a diskless computer, the work of which consists only of connecting to a remote server and displaying information received from the server on the screen. Typically such a server is called a terminal server or terminal server. All processing of user information occurs on it (to which many, although not an infinite number, of thin clients can be connected simultaneously).

Typically, thin clients are made on the basis of weak (and, accordingly, low-power) hardware - often this is a single motherboard on which everything is integrated. The processor and memory can also be tightly soldered to the motherboard. Some thin clients have a flash disk (inserted into the IDE connector of the motherboard), on which a specialized OS (WinCE or others) is flashed.

Comparison of the Clientron U700 thin client with a standard workstation chassis.

As a result, when you turn on the thin client (they are also called terminals), the OS is loaded from the built-in flash disk (usually it takes less than 30 seconds to load), after which a dialog for connecting to the terminal server appears on the screen. Some of these clients can only connect to Windows Terminal Server or Citrix Metaframe, others can also connect to terminal servers of other operating systems. In any case, the price of such solutions also includes the price of a license for WindowsCE flashed onto the built-in flash drive. We talked about similar solutions earlier:

Windows terminal
Thin client
Windows terminal

Of course, other companies have similar solutions. Including without a built-in OS (for which, in the case Microsoft Windows CE, you need to pay extra, and the flash drive is a penny, but it’s worth it).

Terminal clients without a built-in flash disk, load when turned on the desired image OS over the network, after which they spend the same couple of tens of seconds loading. After which we are ready to work, which means displaying a menu with a list of terminal servers to connect to or automatic connection to one of the hard-coded terminal servers (depending on the settings) - the user will only have to enter a login and password. After entering it correctly, he gets into his session on the terminal server and can start working.

The undoubted advantages of terminal solutions on specialized thin clients or proper self-assembled computers:

lack of a hard drive (which gets hot and breaks);
lack of fans (only radiators are installed on the processor and power supply, which are enough to dissipate the heat generated during operation);
low power consumption;
theoretical low cost (when self-assembling, you can select very cheap components, since hardware performance is not required; but manufacturers will ask twice as much for specialized thin clients)
minimal time costs for maintenance (if such a piece of hardware breaks down, it is enough to disconnect the broken one and connect a spare one for five minutes; and this is the minimum downtime for an employee’s workplace, as well as the minimum time spent on fixing the breakdown of the system administrator)
all software for user work is configured centrally on one (two/three/...) terminal servers this is much simpler than maintaining a zoo of software on the “thick” employee workstations

Don’t forget about user data: the terminal does not store anything locally (all user data is located on remote servers). As a result, it’s easy to set up automatic backups of everything and, if something happens, restore an “accidentally deleted” document.

In general, there are a lot of advantages, but there are also disadvantages:

if the network fails, employees’ workstations “turn into a pumpkin” (and employees on “thick” clients can continue to type a document, for example, in OpenOffice);
if the terminal server fails, the employees’ workplaces again “turn into a pumpkin” (but this can be solved by installing several - for example, two - terminal servers; if one of them fails, the second one will replace it, or the employees will simply reconnect to the second server manually)
thin clients are not suitable for everyone: for example, people who constantly watch videos or work actively with graphics (in Photoshop) or do magazine layout are better off doing this on a local “thick” client (but thin clients are great for most other employees who need only a browser with the Internet, mail, creating and editing documents in Openoffice and working with 1C).

The last disadvantage, which we will not consider here, is licensing policy(not to say a rip-off) on the part of Microsoft. Working on a terminal server running the OS of this well-known company requires large quantities various licenses:

Windows Server license
CAL (Client Access License) licenses for connecting to a Windows server and their number must be no less than the number of clients connecting to the server (usually the Windows server already includes a certain number of such licenses from five and above)
licenses for working with a terminal server (their number must also be equal to the number of connected clients)

Don’t forget about separate licenses for all software used (for example, Microsoft Office) in an amount equal to the number of clients connected to the server. If CALs for Microsoft Office can still be circumvented by refusing of this product and having installed a replacement for it in the form of, for example, OpenOffice, then it is somewhat more difficult to get rid of the terminal server itself in the form of Windows 2000/2003 TS :) Although this is possible in some cases.

There is, however, one more “minus” (besides the fear of the new) that often stops people from implementing such solutions - for some reason many people think that these thin clients need to be bought (and they are not very cheap - from $200 and above). What should we do with the entire fleet of existing computers?

It is to answer the last question that this series of articles was written. It will cover thin client software.

This small, but with many capabilities and, importantly, OpenSource software, allows you to turn almost any ancient computer into thin clients. The minimum hardware described on its home site for the hardware used is a Pentium 100Mhz and 16Mb of RAM. Oh yes, a hard/flash drive is also not needed - when computers are turned on, they can download the thin client image (about twenty megabytes) over the network (although it is also possible to install the Thinstation client on a hard or usb drive). In our age of operating systems that happily gobble up gigabytes of disk space after installation, this is impressive, isn’t it?

Thinstation is based on Linux, but to use it you do not need knowledge of Linux as such - you just need to install dhcp and tftp servers on your network and configure them accordingly (both of these servers are also included in Windows Server products). Thus, even on a network where they don’t know anything other than Windows, using the Thinstation client will not cause any difficulties.

Thinstation can work with the following terminal servers:

Microsoft Windows Servers RDP protocol or via nxclient (Windows NT4TSE, W2k Server, W2k3 Server or Windows XP in single-user mode);
Citrix servers via ICA protocol (on MS Windows, SUN Solaris and IBM AIX servers);
Tarantella Servers
*nix-like servers using X11 protocol;
connection to VNC servers (tightVNC);
connection to SSH and Telnet servers;

In order to boot Thinstation over the network, the computer only needs a built-in or external network card that supports the PXE standard (there are other options, but, for example, all built into system board network cards work exactly according to this protocol).

PXE stands for Pre-boot eXecution Environment. This standard was first implemented by Intel. The first sign of the presence of a PXE BIOS on board the built-in network card is the “Enable Boot ROM” item next to the network card activation item in the BIOS. If the built-in network card does not support booting over the network (or is absent altogether), you can use any external network card with the “Boot ROM” option (this issue will be discussed in detail below).

Now let's take a quick look at the process of downloading the Thinstation client over the network.

The network card via the PXE protocol requests the DHCP server for the following information: IP address, subnet mask, gateway, as well as the IP address of the TFTP server (on which the images are located, in this case, ThinStation) and the name of the image that it will try to download.
The DHCP server returns the requested information (noting that the IP address issued to the client is occupied by such and such a client)
The client connects to the TFTP server whose IP address was just given to it and downloads the PXE boot loader file from it (the name of which was again given to it by the DHCP server)
The downloaded PXE loader is executed and, in turn, downloads a configuration file from the TFTP server, which contains the names of the Linux kernel files vmlinuz and the image file system initrd. These files are downloaded and control is transferred to the Linux kernel
After unpacking and loading the Linux kernel with a mounted file system image, Thinstation again accesses the TFTP server to download the configuration files it needs (among other things, the addresses of terminal servers to which you need to connect are written there), and then launches the required terminal client (in our In this case, it will be rdesktop) and expects the user to enter his login and password to connect.

At first glance, the described scheme looks complicated. But in fact, setting it up takes half an hour to an hour and in the future it works completely autonomously. Booting the thin client from the moment of the first request to the network via PXE (this moment coincides with the moment the OS starts loading from the hard drive) takes 20...30 seconds.

As noted above, Thinstation can work with different terminal servers. But we will discuss in the next articles the easiest way to implement (but I remind you once again about purchasing many client licenses required for official work), let's consider only the combination of Thinstation with Microsoft Terminal Server.

First, we need to have a configured terminal server from Microsoft. This server can operate both as part of a domain (in this case it is more convenient to manage user accounts - they are shared, especially if there are several terminal servers on the network), and outside the domain - in a peer-to-peer network. The second case differs from the first in that the necessary users will have to be created locally on each server and the current lists of users and their rights will have to be synchronized manually.

The second point of our program will be DHCP setup and TFTP servers. The first one is in charge of the dynamic distribution of IP addresses for workstations, and also reports from which IP address (from which tftp server) and what file name the computer needs to download as a boot image of the thin client. And the second tftp server actually provides thin client images and configuration files for them. These settings can be either global (for all diskless terminals networks), and local for certain groups of machines or single thin clients.

Both of these services can be raised both as part of a Windows server (by launching and configuring the corresponding services), and as separate daemons as part of a *nix server; we will look at this using the example of a server with Gentoo Linux installed.

And the third point is setting client machines transferring them to downloading over the network and considering standard pitfalls.

But more about this in the next articles of our series.

Detailed guide to setting up thin clients

Based on Thinstation distribution and NX protocol

NX technology, developed by Nomachine, provides new connectivity options and can revive old computers as thin clients.

Before moving directly to the description of NX, I will list some trends that are becoming obvious today for many large companies in our country:

1. Computer equipment is becoming cheaper and more accessible than before. At the same time, its productivity doubles every 1.5-2 years according to Moore's law. This leads to the accumulation of equipment that has not exhausted its service life, but is already outdated.

2. Client-server applications developed at enterprises by programmers from automated control systems departments during the perestroika years still work on old technology, but no longer meet the requirements of the time.

3. Modern software and operating systems cannot be made to work on computers with processors of previous generations (i386, i486, etc.).

4. It is no secret that in many organizations in our country, for a long time, many programs and operating systems that employees installed on their own initiative have been illegally used. At first this was seen as a matter of course, but then it was justified by the financial situation. Now that our country is joining the WTO, the government is forced to quickly correct this situation; therefore, pressure on enterprises from internal authorities has increased to abandon illegally used software and operating systems.

Terminal technologies come to the rescue, which allow you to use old computers, and also partially remove the issues of “license purity” if you use solutions based on Open Source products.

The magazine has already published several articles on working with the Thinstation distribution. In this article, I will talk about the specifics of setting up and operating experience in my enterprise with thin clients based on the Thinstation distribution and NX technology developed by Nomachine.

Until recently, in the world of terminal communications, there were few known successful high-level network protocols capable of effectively compressing and encrypting traffic between a thin client and a server. The most famous and popular of them are RDP from Microsoft and ICA from Citrix. Both protocols are used by servers based on MS Windows OS. I was interested in the possibility of using thin clients with Linux-based servers. As a basis for the thin client, a small distribution kit, a sort of Linux designer, Thinstation was almost immediately chosen as the most steadily developing and popular in our country and abroad. But with the choice of the protocol that would be responsible for communication with the server, I had to tinker and experiment. I will list the main criteria by which the protocol was selected. Firstly, we wanted to use the widest possible range of old computers with processors starting from i486, with a minimum amount of memory; we have plenty of such equipment. Secondly, commercial products were rejected: we did not want to incur additional costs. Thirdly, good support for the Russian language and Cyrillic alphabet is necessary, as well as the presence of a familiar way for users to switch between layouts - key combinations . Fourthly, within a local network, we do not need to support encryption, but compression and minimization of network traffic are important.

Finding a solution

First of all, I paid attention to VNC as the most common and available in any Linux distribution, as well as being an easy-to-set up product. When you need to connect to a remote desktop of a Linux server from a Windows or Linux workstation, the first thing that comes to mind is VNC. Download the latest version of the Thinstation distribution, then unzip the resulting archive file in your home directory. Let's assume that the path to the distribution looks like this: ~/thinstation. The file responsible for the build parameters is located here: ~/thinstation/build.conf. It has detailed comments. I won’t talk in detail about setting it up, as well as how to force the Thinstation image to boot using a network card with a boot chip; this has already been written about in these articles. I will briefly list the steps to configure the client: edit ~/thinstation/build.conf and create an image by running the ~/thinstation/build script. We copy the finished image file ~/thinstation/boot-images/etherboot/thinstation.nbi to the TFTFP server. We add an entry about the MAC address of the thin client’s network card to the dhcp.conf configuration file of the DHCP server. In the TFTP server directory, create a file with settings for this MAC address and/or edit the thinstation.conf.network file. The settings of my working system can be seen in the listing of the section “Configuring and creating a Thinstation image” and in Fig. 1.

Figure 1. NX component relationships

In order to add a VNC client package to the image, uncomment the line “#package vncviewer” in the configuration file ~/thinstation/build.conf. If the tftp server directory is located in /tftpboot (as it is for me), then edit the file /tftpboot/thinstation.conf.network so that the lines appear in it:

SESSION_0_TYPE=vncviewer

SESSION_0_TITLE="VNC" !}

SESSION_0_VNCVIEWER_SERVER=10.10.10.10:5901

Replace the IP address 10.10.10.10 with the address of your VNC server.

xkbcomp:0 ru.xkb

xkbcomp -xkm ru.xkb ru.xkm

cp -f ru.xkm ~/thinstation/packages/keymaps-ru/x-common/lib/kmaps/xkb

We turn on the thin client and load the created image, checking the performance. Progress is obvious: the “slideshow” stops on PCs with a P-100, P-120 and higher processor. This is not what we would like to achieve as a result, so PCs with i486 processors will not be able to be used here. We called such PCs “superthin” clients and configured them to work with DOS programs using a combination of FreeDOS and sshdos on the client side and Dosemu on the Linux server side. I won’t talk about them in this article. Nevertheless, this is a good result, let's look at the hardware requirements from the developers of Thinstation and the NX client: the former recommend an i486 processor and 16 MB of memory, the latter recommend a processor with a frequency of 400 MHz and 128 MB of memory. Let us empirically determine the minimum required configuration for a thin client to work with the NX package as a P-120 processor and 32 MB of RAM. I tested some other clients, in particular, XRDP, VNC for DOS, but for one reason or another I did not find a real alternative to NX. Now it's time to take a closer look at NX technology.

Review and Brief Description of Nomachine NX

Most available networking solutions were not designed as the primary means for users to access the desktop. Protocols such as RDP and VNC are much simpler than X (and therefore well suited for thin clients), but their simplicity does not compensate for the lack of efficiency and functionality. For example, these protocols use large amounts of image data to render a remote screen. Although RDP is a more efficient protocol than RFB (the protocol used by VNC), it was not originally designed for daily use by network devices, but only as an extension to the OS. X-Window is a graphics subsystem (not an OS extension), and X applications interact with it using the X protocol, so the OS does not have a special layer responsible for translating screen updates to the network protocol.

NX uses three primary methods to speed up applications: compression, caching, and suppression of excessive X protocol traffic.

n The idea of difference compression is based on the Differential X Protocol Compressor (DXPC) project, created in 1995, the terms client and server proxy are already mentioned there. Nomachine picked up the idea and developed its own product. NX is claimed to be 10x superior to standard library ZLIB.

n Nomachine has also developed a clever caching mechanism for X traffic that uses the familiar proxy term "cache hits". This mechanism reduces network traffic when transmitting the same data blocks, and when these data blocks change, the thread calculates and transmits only their difference.

n Before NX, there was no reliable way to suppress excessive X protocol traffic on long-distance links. NX can do this by translating remote-end X traffic (from the application to nxagent) into NX protocol traffic.

All three methods combine to achieve a 70x improvement in the remote X GUI experience while using the highest level of compression on low-bandwidth, high-latency links (in the NX client settings, “modem” corresponds to maximum compression, and “lan” corresponds to no compression) . In Fig. 1 under number 2 shows the relationship of NX components: compression/decompression and caching are carried out on NX Proxy modules, traffic passes between them via the NX protocol, the requirements for the quality of communication lines are minimal, it is stated that they can operate up to speeds of 9600 bps.

Similar to nxagent's translation of X traffic, there is another agent (“nxviewer”) that translates RFB/VNC traffic to the NX protocol. This improves connection efficiency by up to 10 times compared to a regular vncviewer linking a local X display to a remote VNC server. We will make sure of this.

n NX Proxy– this component is precisely responsible for compression/decompression: in client mode it encodes requests from X clients and decodes responses from the X server, in server mode – vice versa.

n NX Agent– the term “agent” is used to describe the component to which the generated image is passed before being transmitted to the network through a proxy.

n NX Viewer– a modified Nomachine regular VNC client that translates VNC/RFB traffic into the NX protocol.

n NX Desktop– RDP client that translates RDP traffic into the NX protocol.

Nomachine has opened the source codes of most of its developments and libraries, they can be downloaded by anyone from . Builds from Nomachine itself are available free of charge to all clients; there are also various options for NX server builds, supplied for a fee: an annual subscription to NX Enterprise Server with an unlimited number of users and 1-2 processors costs $1,494, the most complete solution with load balancing and managing nodes based on NX Advanced Server will cost $3,494. In addition, there is an option NX Free Edition, which can be downloaded for free, but has a limit on the number of simultaneous connections and users equal to two, so if you want to administer a Linux server from home using a regular analog modem, then it is better, safer and easier this solution cannot be found. I will also note the presence of client versions of NX Client Desktop Edition for PlayStation 2 (when using the Linux Kit), as well as NX Client Embedded Edition for Sharp Zaurus 5xxx and HP/Compaq iPAQ. They can also be downloaded for free. So, if you are on a business trip and only have a PDA with you, nothing prevents you from connecting and working remotely on your Linux server.

Building and Running NX

At the moment, the sources of version NX 2.0 are posted on the Nomachine website, this version is recommended by the company, and there is a special link to the sources of version 1.5. Download the latest versions of the following tarballs from the page: nx-X11, nxagent, nxcomp, nxcompext, nxdesktop (if you need RDP support), nxproxy, nxscripts, nxviewer (if you need VNC support). nx-X11 is version 4.3 of Xfree86, which has modified Nomachine X libraries. Some of the sources will be unpacked directly into the nx-X11 tree, so we will expand it first, the order of unpacking the remaining tarballs is not important, the main thing is that they are all unpacked in one directory. There we download and unpack FreeNX scripts from the address . You will also need two patches, download them from here. Our assembly directory will look like this:

n freenx-0.4.4

nnx-X11

nnxcomp

nnxcompext

nxdesktop

nnxproxy

nxscripts

nxviewer

n freenx-lfs_hint.diff

n NX-lfs_hint.diff

# Apply NX patch

patch -p0< NX-lfs_hint.diff

# Assembling X - the longest part, can take up to an hour

pushd nx-X11

make World

popd

#nxproxy

pushd nxproxy

./configure --prefix=/srv/NX

make

popd

# Build the RFB agent

pushd nxviewer

xmkmf -a

cp -a /usr/X11R6/lib/libXp.so* ../nx-X11/exports/lib/

make 2> /dev/null

popd

# Building the RDP agent

pushd nxdesktop

./configure --prefix=/srv/NX --sharedir=/srv/NX/share

make

popd

# The entire server part will be located in the /srv/NX directory, create some of the subdirectories

mkdir -p /srv/NX/bin

mkdir -p /srv/NX/lib

mkdir -p /srv/NX/man/man1

mkdir -p /srv/NX/share/doc

# Install the collected libraries and agents

cp -a nx-X11/lib/X11/libX11.so.* nx-X11/lib/Xext/libXext.so.* nx-X11/lib/Xrender/libXrender.so.* /srv/NX/lib

install -m 755 nx-X11/programs/Xserver/nxagent /srv/NX/lib

# Create an nxagent script that will manage all programs

cat > nxagent<< "EOF"

#!/bin/sh

NXCOMMAND=$(basename $0)

export LD_LIBRARY_PATH=/srv/NX/lib:$LD_LIBRARY_PATH

exec /srv/NX/lib/$NXCOMMAND $(1+"$@")

EOF

# And install it:

install -m 755 nxagent /srv/NX/bin

# Install compression and proxy libraries

cp -a nxcomp/libXcomp.so.* /srv/NX/lib

cp -a nxcompext/libXcompext.so.* /srv/NX/lib

install -m 755 nxproxy/nxproxy /srv/NX/lib

ln -snf nxagent /srv/NX/bin/nxproxy

# Installing the RFB agent

pushd nxviewer

make install DESTDIR=/srv/NX

mv /srv/NX/usr/X11R6/bin/nxviewer /srv/NX/lib

ln -snf nxagent /srv/NX/bin/nxviewer

chmod 755 /srv/NX/bin/nxviewer

mv /srv/NX/usr/X11R6/bin/nxpasswd /srv/NX/bin

popd

# Installing the RDP agent

pushd nxdesktop

make install

mv /srv/NX/bin/nxdesktop /srv/NX/lib

ln -snf nxagent /srv/NX/bin/nxdesktop

chmod 755 /srv/NX/bin/nxdesktop

rm -rf /srv/NX/usr

popd

# Installing scripts

cp -r nxscripts /srv/NX/share/doc

# install FreeNX

mkdir -p /srv/NX/etc

mkdir -p /srv/NX/var

mkdir -p /srv/NX/var/db

mkdir -p /srv/NX/home

mkdir -p /srv/NX/home/nx

pushd freenx-0.4.4

# Apply the freenx patch, mainly here the paths are corrected to match /srv/NX

patch -p0< ../freenx-lfs_hint.diff

cp -a nxnode /srv/NX/bin

cp -a nxserver /srv/NX/bin

cp -a nxsetup /srv/NX/bin

cp -a nxkeygen /srv/NX/bin

cp -a nxnode-login /srv/NX/bin

cp -a nxloadconfig /srv/NX/bin

cp -a nxclient /srv/NX/bin

cp -a nxprint /srv/NX/bin

install -m 755 node.conf.sample /srv/NX/etc

popd

# Add user and group nx

groupadd -g 77 nx

useradd -c "FreeNX user" -d /srv/NX/home/nx -g nx -s /bin/bash -u 77 nx

chown -R root.root /srv/NX

chown -R nx.nx /srv/NX/home/nx

# If you want to use key-based user authentication, remove the –setup-nomachine-key option.

# To work with thin clients, you don’t need to change anything

/srv/NX/bin/nxsetup --install --uid 77 --gid 77 --setup-nomachine-key

# Check if the NX server is running:

/srv/NX/bin/nxserver --status

The answer should be something like this:

NX>100 NXSERVER - Version 1.4.0-44 OS (GPL)

NX> 110 NX Server is running

NX>999 Bye

Install the freenx configuration file:

mv /srv/NX/etc/node.conf.sample /srv/NX/etc/node.conf

In the configuration file we find the following line and uncomment it:

ENABLE_1_5_0_BACKEND="1"

There you can also enable logging for the first time:

NX_LOG_LEVEL=6

Figure 2. KDE NX session in desktop mode from Windows XP

Setting up and creating a Thinstation image

module serial

module intel-agp

module via-agp

module 8139too

module floppy

module vfat

module supermount

pkg xorg6-ati

pkg xorg6-i810

pkg xorg6-nv

package xorg6-s3

pkg xorg6-s3virge

pkg xorg6-sis

pkg xorg6-trident

package keymaps

package nx

pkg lprng

pkg sshd

pkg samba-server

param rootpasswd please changeme

param xorgvncpasswd please changeme

param bootlogo false

param boot resolution 800x600

param defaultconfig thinstation.conf.buildtime

param basename thinstation

param basepath .

param knownhosts ./known_hosts

param localpkgs true

param fulllocales false

param bootverbosity 3

param nxurl file://home/zhen/sources/nx/bin/nxclient-1.5.0-141.i386.tar.gz

echo "$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:lf=/var/log/spooler.log:sh:sf" >> /etc/printcap

echo "$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:if=/bin/lpf:lf=/var/log/spooler.log:sh:sf" >> /etc/printcap

Adding local filtering eliminated the staircase problem when printing. Additionally, I created the following script to test whether printing is working in ~/thinstation/packages/base/bin/my:

#!/bin/sh

echo PRINTER TEST to /dev/printers/0 1>&2

for i in 1 2 3 4 5 6 7 8 9;

echo PRINTER /dev/printers/0 $i > /dev/printers/0;

done

echo -e \\r\\f > /dev/printers/0

exit 0;

When it is not clear what exactly is not working, you can run this script on the thin client console: /bin/my.

To prevent a warning window about an unfamiliar host from appearing every time when connecting an NX client to the server, create a known_hosts file in the Thinstation root:

ssh-keyscan -t rsa nxserver_ip>>~/thinstation/known_hosts

As “nxserver_ip” you must specify the IP address of the NX server. This way the client will know about the digital fingerprint of the NX server's RSA key during authentication.

Figure 3. Thinstation thin client configuration files

otd146_57158 00e04d08d710 smb_flop_hard TUX1C monitor #very important PC

Next, we create a settings file thinstation.conf-MAC, I use the MAC address in the name, although you can use the IP address or name from thinstation.hosts. Note that the MAC address here uses only capital letters in the file name. Groups are described in files called thinstation.conf.group-GROUPNAME. The thinstation.conf-MAC file contains those settings that apply only to this terminal and are not included in other groups. For example, all general monitor settings are described in the thinstation.conf.group-monitor file, and one parameter “SCREEN_VERTREFRESH” is moved to the thinstation.conf-MAC file. This is due to the fact that different monitors are used, and the screen frame rate setting can be changed; this and other parameters can be configured for each terminal or for all at once. The same goes for mouse settings. By default, the setting is made for a PS/2 mouse. If a mouse is used connected to the COM1 port, then two parameters “MOUSE_PROTOCOL=Microsoft” and “MOUSE_DEVICE=/dev/ttyS0” are specified, if to the COM2 port, then the second parameter is /dev/ttyS1.

My common configuration file /tftpboot/thinstation.conf.network is almost empty. All information from it is placed in separate group settings files, which are referenced in thinstation.hosts. Since two terminal servers with different versions of NX are used and each client uses only its own server, the configurations are placed in separate text files (NX and TUX1C), in addition, different Thinstation images are used. Also, do not forget that the file names thinstation.nbi and thinstation.nbi.zpxe are interrelated: if the line is specified in dhcpd.conf:

thinstation.nbi.zpxe";

then the thinstation.nbi image will be used, in my case there are several images, and accordingly the entries in dhcpd.conf are different for each terminal.

NX2 build differences

make World BOOTSTRAPCFLAGS="-m32"

Apparently, these are features of the 64-bit system and its libraries. A little later, I found a note on the Nomachine website that said that the NX source code was developed for 32-bit systems, but it can also be used on 64-bit systems. Since I still have a computer with SLED 10.0 x86 installed and the versions of all libraries, kernel and programs are exactly the same as SLES, I decided to build NX on it, and then transfer the directory with the result of the build by normal copying to a 64-bit system. That’s what I did: everything worked as if nothing had happened. We download files with the same names as when building version 1.5, only with suffixes 2.0 (or 2.1). Everything compiles exactly the same as in the case of NX 1.5, with some exceptions: firstly, I did not apply the NX-lfs_hint.diff patch, secondly, a new version of the FreeNX 0.5 scripts has appeared, supporting the new NX 2.0, its you can pick it up here, thirdly, the freenx-lfs_hint.diff file, which makes changes to the nxloadconfig file from FreeNX 0.4, does not fit the new version of FreeNX, it needs to be edited. Here is the output of the diff command, showing the difference between the original and the edited nxloadconfig file:

--- nxloadconf_orig 2006-07-01 22:03:39.000000000 +0500

+++ nxloadconfig 2006-10-16 12:32:19.000000000 +0500

@@ -56,12 +56,12 @@

NX_LICENSE="OS (GPL)"

# Where can different nx components be found

-NX_DIR=/usr

+NX_DIR=/srv/NX

PATH_BIN=$NX_DIR/bin # if you change that, be sure to also

change the public keys

PATH_LIB=$NX_DIR/lib

-NX_ETC_DIR=/etc/nxserver

-NX_SESS_DIR=/var/lib/nxserver/db

-NX_HOME_DIR=/var/lib/nxserver/home

+NX_ETC_DIR=$NX_DIR/etc

+NX_SESS_DIR=$NX_DIR/var/db

+NX_HOME_DIR=$NX_DIR/home/nx

# Advanced users ONLY

AGENT_LIBRARY_PATH="" #Calculated

@@ -265,7 +265,7 @@

[ -z "$AGENT_LIBRARY_PATH" ] && AGENT_LIBRARY_PATH=$PATH_LIB

[ -z "$PROXY_LIBRARY_PATH" ] && PROXY_LIBRARY_PATH=$PATH_LIB

[ -z "$APPLICATION_LIBRARY_PATH" ] && APPLICATION_LIBRARY_PATH=$PATH_LIB

-[ -z "$APPLICATION_LIBRARY_PRELOAD" ] && APPLICATION_LIBRARY_PRELOAD="$APPLICATION_LIBRARY_PATH/libX11.so.6.2:$APPLICATION_LIBRARY_PATH/libXext.so.6.4:$APPLICATION_LIBRARY_PATH/libXcomp.so.1:$APPLICATION_LIBRA RY_PATH/libXcompext.so.1:$ APPLICATION_LIBRARY_PATH/libXrender.so.1.2"

+[ -z "$APPLICATION_LIBRARY_PRELOAD" ] && APPLICATION_LIBRARY_PRELOAD="$APPLICATION_LIBRARY_PATH/libX11.so.6.2:$APPLICATION_LIBRARY_PATH/libXext.so.6.4:$APPLICATION_LIBRARY_PATH/libXcomp.so.2.1.0:$APPLICATION _LIBRARY_PATH/libXcompext.so.2.1 .0:$APPLICATION_LIBRARY_PATH/libXrender.so.1.2"

[ -z "$KDE_PRINTRC" -a -n "$KDEHOME" ] && KDE_PRINTRC="$KDEHOME/share/config/kdeprintrc"

[ -z "$KDE_PRINTRC" -a -z "$KDEHOME" ] && KDE_PRINTRC="$HOME/.kde/share/config/kdeprintrc"

@@ -511,8 +511,8 @@

[ -z $(echo "$ENABLE_ROOTLESS_MODE" | egrep "^$") ] && \

ERROR="yes" && echo "Error: Invalid value\"ENABLE_ROOTLESS_MODE=$ENABLE_ROOTLESS_MODE\""

- [ -z "$(strings $PATH_BIN/nxagent | grep "NXAGENT - Version 1.5.0")" ] && \

- ERROR="yes" && echo "Error: Could not find 1.5.0 version string in nxagent. NX 1.5.0 backend is needed for this version of FreeNX."

+# [ -z "$(strings $PATH_BIN/nxagent | grep "NXAGENT - Version 1.5.0")" ] && \

+# ERROR="yes" && echo "Error: Could not find 1.5.0 version string in nxagent. NX 1.5.0 backend is needed for this version of FreeNX."

[ -z $(echo "$ENABLE_USESSION" | egrep "^$") ] && \

ERROR="yes" && echo "Error: Invalid value \"ENABLE_USESSION=$ENABLE_USESSION\""

Nxloadconfig must be edited before running the /srv/NX/bin/nxsetup command. In the configuration file /srv/NX/etc/node.conf, uncomment the line:

ENABLE_2_0_0_BACKEND="1"

Now let's see what needs to be changed in the Thinstation distribution ( latest version now 2.2) to support NX 2.0 on the client side. At the time of writing, only client version 1.5 was supported. We take from the address NX client, which does not require support for XFT libraries, in the form of a tar.gz archive (at the moment it is nxclient-2.1.0-9.i386.tar.gz), unpack it in the home directory, copy the files and create the missing ones links.

#!/bin/sh

tar -xzf nxclient-2.1.0-9.i386.tar.gz

cp ~/NX/bin/* ~/thinstation/packages/nx/usr/NX/bin

cp -fl ~/NX/lib/libXcomp.so.* ~/thinstation/packages/nx/usr/NX/lib/

ln -sf libXcomp.so.2.1.0 ~/thinstation/packages/nx/usr/NX/lib/libXcomp.so.1.5.0

cp ~/NX/share/keys/server.id_dsa.key ~/thinstation/packages/nx/usr/NX/share/keys

cp ~/NX/share/keyboards ~/thinstation/packages/nx/usr/NX/share/

cp -R ~/NX/share/images ~/thinstation/packages/nx/usr/NX/share/

touch ~/thinstation/packages/nx/build/installed

After these steps, the NX package is considered installed in the Thinstation package tree, now we assemble the image by running build and copy it to the tftp server. Well, the image is ready and placed in the tftp server directory, but that’s not all. It turns out that the new version of NX client on the thin client interprets the settings from the thinstation.conf.group-TUX1C(NX) files differently. After some research, it turned out that the NX session settings file should be created in the root of the thin client file system. I had to make a small patch for Thinstation, I saw the idea on one forum:

# The patch simply copies the NX client settings file(s) from the standard location to the root

ls $HOME/.nx/config/.>nxsessions

if [ -s nxsessions ] ; then

(cat nxsessions) |

while read filename ; do

probe=$(filename%*.nxs)

if [ "$filename" != "$probe" ]

then

cp $HOME/.nx/config/$filename /$probe

done

rm nxsessions

This piece of code should be inserted at the end of the file ~/thinstation/packages/nx/etc/init.d/nx.init before the last “exit 0” command. After this, you need to rebuild the Thinstation image. Now the NX session on the thin client starts as intended. In general, the new version works more stable, sessions are managed more correctly, plus compression algorithms have been updated in the latest sources, and some errors have been fixed. Previously, to clean up and close unfinished sessions and processes, you had to turn to cron:

1 0 * * * root /srv/NX/bin/nxserver –cleanup

It is also convenient that the NX 2.1 client works with servers of both versions.

Figure 4. NX session in application mode (1C)

In the next issue, read the continuation of the article, in which I will talk about the operating features, additional settings of NX and Thinstation, and also offer solutions to some possible problems.

1. Borisov A. Thin client - a step towards mainframes? //System Administrator, No. 11, November 2005 – pp. 32-38.

2. Markelov A. Using diskless Linux stations with network loading. //System Administrator, No. 11, November 2004 – pp. 12-14.

So, you don’t need a lot of effort to make a thin client from a regular computer. For a minimal understanding of this article, you need to have at least a vague idea of:

Time passes, hardware becomes obsolete physically and morally, management as usual does not have money to buy new computers in the organization, in this case there is an opportunity to “breathe life” into museum trash. For thin client Any will do a rarity with a single-core processor frequency of 1 GHz and RAM 128 MB, and the most important detail is the motherboard with a network card that supports PXE boot. We won’t need a hard drive or a floppy drive at all, we will be making a real thin client, and not a pathetic parody! ;)

How to make a thin client from an old computer (method 2)

Preparing the thin client and additional equipment.

Of course, first assemble a more or less living unit from junk, as I said above, we don’t need a hard drive at all, as for the disk drive and other peripherals, it all depends on the task at hand that our thin client must cope with, I had enough of the peripherals at work only monitor, keyboard, mouse, USB devices The management considered it unnecessary (except for the keyboard and mouse, of course), because the desire to make the system more closed exceeded the wishes of the users (strangely enough, I agreed with them on this, all functions removable media replaces mail and internal file storage, and for those who need to work with large files and performance from PCs did not translate to thin clients at all). After you are convinced that the hardware is working, you need to configure the boot from the network card in the BIOS and disable all other boot methods. This is done differently on different mats. boards, but the essence comes down to one thing.

For the thin client to work, we need a server that will act as a remote workstation to which our thin client will connect. I will not dwell in detail on the consideration of all types of remote workstations; we will focus on the most popular Terminal Server from Microsoft. We will assume that you already have a server on which to deploy Terminal Server, for example, on Windows Server 2008 R2. If there is no need to connect users outside the organization, then we will consider setting up the connection only “inside”. Let our terminal server have an internal IP 192.168.0.5.

DHCP

Now let’s configure DCHP to distribute IP addresses to our thin clients and additional parameters. You can read how to configure DHCP on Windows Server 2008 here, for Linux Server here. In this article I will only indicate what needs to be adjusted to the finished circuit.

To configure in Windows Server 2008 R2: let's go to the area parameters

Select Configure parameters and add a parameter:

066 Host name of the download server and indicate the IP address of our TFTP server (in our case 192.168.0.4)

067 Download file name, enter pxelinux.0

and don't forget to restart the DHCP service.

Setting in Ubuntu Server :

Will be later

TFTP server

Settings, in Ubuntu Server 14.04 LTS . You can also use the tftpd32 program for Windows systems

Thinstation distribution

You can get acquainted with the capabilities of this distribution on the developer’s website http://thinstation.github.io/thinstation/. In order to get a working distribution with the ability to download from a TFTP server, you need to assemble it, I will not consider how this is done, but will use a ready-made distribution with the ability to download over a PXE network version of the assembly (mirror) compiled with the allmodules option (for this there is a separate thanks to nik0el ). Download the archive and unpack it, now you need to scatter the files. I will look at the example of a configured TFTP server in Windows Server 2008 R2.

Let's put all the files and folders as is in C:\TFTPRoot

Now let's start setting up the main files that you will edit to suit your needs:

thinstation.conf.network - responsible for default connection settings for all thin clients

thinstation.conf.sample -

thinstation.hosts - specifies individual settings

thinstation.conf.group-... - instead of dots, the name of the group is indicated (1280@75 - resolution and frequency, user - name of the thin client assigned in the thinstation.hosts file, etc.)

Below are slightly edited parameters according to our IP addresses:

thinstation.conf.network

SCREEN=0
WORKSPACE=1SESSION_0_TITLE="Terminal Server"!}
SESSION_0_TYPE=rdesktop
SESSION_0_SCREEN=1
SESSION_0_RDESKTOP_SERVER=192.168.0.5
SESSION_0_RDESKTOP_OPTIONS="-u "user""
SESSION_0_AUTOSTART=On#SESSION_#_TITLE="Big Bad Server Donald"!}
#SESSION_#_TYPE=freerdp
#SESSION_#_SCREEN=1
#SESSION_#_SCREEN_POSITION=2
#SESSION_#_FREERDP_SERVER=192.168.1.1
#SESSION_#_FREERDP_OPTIONS="-u username -p password"
#SESSION_#_AUTOSTART=OffRDESKTOP_SOUND=Off
RDESKTOP_FDD=Off
RDESKTOP_CDROM=Off
RDESKTOP_HDD=Off
RDESKTOP_USB=Off
RDESKTOP_1394=Off
RDESKTOP_COM3=Off
RDESKTOP_COM4=Off
RDESKTOP_SLOWLINK=On
RDESKTOP_COMPRESSION=On
RDESKTOP_COLOR_DEPTH="16"
#RDESKTOP_DOMEN=mydomen
RDESKTOP_USB_NO_MOUNT_DIR=OnFREERDP_USB_NO_MOUNT_DIR=On # Mount USB Drive On/Off
FREERDP_USB=Off # Mount USB Drive On/Off
FREERDP_SOUND=On # Audio, On/Off
FREERDP_KEYMAP=419 # Keymap number
FREERDP_CONSOLE=Off # Connect to console, On/Off
FREERDP_SLOWLINK=Off # Slow Network Link, On/Off
FREERDP_COMPRESSION=Off # RDP Compression, On/Off
FREERDP_CDROM=Off # CDROM Drive present, On/Off
FREERDP_CDROM_SATA=Off # SATA CDROM present, On/Off
FREERDP_FDD=Off # Floppy Drive present, On/Off
FREERDP_USBFDD=Off # USB Floppy present, On/Off
FREERDP_HDD=Off # HDD Drive present, On/Off
FREERDP_1394=Off # FireWare HDD present, On/Off
FREERDP_COM3=Off # Redirect COM1, On/Off
FREERDP_COM4=Off # Redirect COM2, On/OffKEYBOARD_MAP=en_us
TIME_ZONE="Europe/Moscow"
AUDIO_LEVEL=67
AUTOPLAYCD=On
DAILY_REBOOT=On
CUSTOM_CONFIG=off
RECONNECT_PROMPT=menu
NET_TELNETD_ENABLED=On
SCREEN_RESOLUTION="1024x768"
SCREEN_HORIZSYNC="30-65"
SCREEN_VERTREFRESH="75"
SCREEN_COLOR_DEPTH="16"
MOUSE_PROTOCOL=IMPS/2
MOUSE_RESOLUTION=100
MOUSE_ACCELERATION="1"
X_DRIVER_OPTION1="swcursor On"
PRINTER_0_NAME=parallel
PRINTER_0_DEVICE=/dev/printers/0
PRINTER_0_TYPE=P
PRINTER_1_NAME=usb
PRINTER_1_DEVICE=/dev/usb/lp0
PRINTER_1_TYPE=U

thinstation.hosts

# NAME MAC GROUP #COMMENT #thinstation01 0013D409A812 1024@75 cdrom fdd usb #192.168.0.21 user 000A5E1ADCAA 1280@60 cdrom usb #192.168.0.10

Here we assign a name for the thin client's Mac address and indicate the settings groups. In the example, this is a group with settings for the monitor, drive and usb ports.

Misadventure

Now make sure the servers are up and running. Start the thin client, after downloading the distribution and launching it completely, a window will open for entering the username and password to log into our terminal server. In the example, I used the rdesktop client to connect, and there are about 10 varieties that you can choose and customize.

There is a second method described in the article