Тонкая генеральная линия: пересаживаем офис на тонкие клиенты под управлением Thinstation

ЕВГЕНИЙ БУШКОВ

Подробное руководство по настройке
тонких клиентов на основе дистрибутива Thinstation и протокола NX

Технология NX, разработанная фирмой Nomachine, дает новые возможности для связи и способна оживить старые компьютеры в роли тонких клиентов

Прежде чем перейти непосредственно к описанию NX, перечислю некоторые тенденции, которые сегодня становятся очевидными для многих крупных компаний нашей страны:

Компьютерная техника дешевеет и становится более доступной, чем раньше. При этом её производительность удваивается каждые 1,5-2 года согласно закону Мура. Это приводит к накоплению техники, не выработавшей свой ресурс, но уже устаревшей.
Разработанные на предприятиях силами программистов отделов АСУ в перестроечные годы клиент-серверные приложения еще работают на старой технике, но уже не соответствуют требованиям времени.
Современные программное обеспечение и операционные системы не заставить работать на компьютерах с процессорами прежних поколений (i386, i486 и т. д.).
Не секрет, что во многих организациях нашей страны с давних времен незаконно используются многие программы и ОС, которые сотрудники устанавливали по своей инициативе. Вначале это рассматривалось как само собой разумеющееся обстоятельство, потом оправдывалось финансовым положением. Сейчас, когда наша страна вступает в ВТО, правительство вынуждено такую ситуацию спешно исправлять, в связи с этим усилилось давление на предприятия со стороны внутренних органов с требованием отказаться от незаконно используемых ПО и ОС.

Очевидно противоречие между вторым и третьим пунктами: необходимо или найти способ, позволяющий эффективно задействовать старую технику для выполнения современных задач, или отказаться от этой техники. Если имеется достаточно средств, то выбор понятен. Но что делать, если средств нет или нет возможности списать такую технику, да и просто выкидывать жалко? И как решать не менее острую проблему «лицензионной чистоты» используемых программ, о которой говорится в четвертом пункте?

На помощь приходят терминальные технологии, которые позволяют задействовать старые компьютеры, а также частично снять вопросы «лицензионной чистоты», если применять решения на базе продуктов Open Source.

В журнале уже публиковалось несколько статей по работе с дистрибутивом Thinstation [ , ]. В этой статье я расскажу об особенностях настройки и опыте эксплуатации на своем предприятии тонких клиентов на базе дистрибутива Thinstation и технологии NX, разработанной фирмой Nomachine.

До недавнего времени в мире терминальной связи было мало известно удачных сетевых протоколов высокого уровня, способных эффективно сжимать и шифровать трафик между тонким клиентом и сервером. Наиболее известные и популярные из них – это RDP от Microsoft и ICA от Citrix. Оба протокола используются серверами на базе ОС MS Windows. Меня же интересовала возможность использовать тонкие клиенты с серверами на базе Linux. В качестве основы для тонкого клиента почти сразу был выбран небольшой дистрибутив, этакий Linux-конструктор, Thinstation – как наиболее стабильно развивающийся и популярный в нашей стране и за рубежом. А вот с выбором протокола, который бы отвечал за общение с сервером, пришлось повозиться и поэкспериментировать. Перечислю основные критерии, по которым выбирался протокол. Во-первых, нам хотелось использовать как можно более широкий диапазон старых компьютеров, имеющих процессоры начиная с i486, с минимальным объемом памяти, такой техники у нас предостаточно. Во-вторых, отметались коммерческие продукты: мы не хотели нести дополнительные расходы. В-третьих, необходимы хорошая поддержка русского языка и кириллицы, а также наличие привычного для пользователей способа переключения между раскладками – комбинации клавиш . В-четвертых, в рамках локальной сети нам необязательна поддержка шифрации, но важны сжатие и минимизация сетевого трафика.

Поиск решения

В первую очередь я обратил внимание на VNC как наиболее распространенный и имеющийся в любом дистрибутиве Linux, а также являющийся легким в настройке продуктом. Когда необходимо подключиться к удаленному рабочему столу Linux-сервера с рабочей станции Windows или того же Linux, то первое, что приходит в голову, это VNC. Скачайте последнюю версию дистрибутива Thinstation , затем распакуйте полученный архивный файл в домашнем каталоге. Будем считать, что путь к дистрибутиву выглядит так: ~/thinstation. Файл, отвечающий за параметры сборки, находится здесь: ~/thinstation/build.conf. Он имеет подробные комментарии. О его настройке, а также о том, как заставить образ Thinstation загружаться при помощи сетевой карты с бутовой микросхемой, я подробно рассказывать не буду, об этом уже писалось в указанных статьях. Коротко перечислю действия по настройке клиента: редактируем ~/thinstation/build.conf и создаем образ, запустив скрипт ~/thinstation/build. Готовый файл образа ~/thinstation/boot-images/etherboot/thinstation.nbi копируем на TFTFP-сервер. Добавляем в файл настройки dhcp.conf DHCP-сервера запись о MAC-адресе сетевой платы тонкого клиента. В каталоге TFTP-сервера создаем файл с настройками для данного MAC-адреса и(или) редактируем файл thinstation.conf.network. Настройки моей рабочей системы можно посмотреть в листинге раздела «Настройка и создание образа Thinstation» и на рис. 1.

Для того чтобы добавить в образ пакет VNC-клиента, раскомментируем строчку «#package vncviewer» в конфигурационном файле ~/thinstation/build.conf. Если каталог tftp-сервера находится в /tftpboot (как это у меня), то отредактируйте файл /tftpboot/thinstation.conf.network таким образом, чтобы в нем появились строчки:

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

IP-адрес 10.10.10.10 замените на адрес вашего VNC-сервера.

Теперь проверим собранный с новым параметром образ в работе: включаем тонкого клиента, дожидаемся загрузки и запуска образа Thinstation, подключаемся к VNC-серверу. Обратите внимание на то, что переключение раскладок происходит с помощью клавиши «правый Alt». Собственно, виноват здесь не VNC-клиент, а файл Thinstation из пакета поддержки кириллицы keymaps-ru. Чтобы долго не возиться с поисками решения проблемы, я сгенерировал xkb-файл в настроенной системе SUSE-10.0 следующим образом:

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

Утилита xkbcomp конвертирует описание XKB-раскладки в один из форматов. В первой команде генерируется дамп текущей раскладки из источника, в качестве которого выступает X-дисплей «:0». Вторая команда компилирует полученный файл в понятный для системы двоичный вид. Заменяем исходный файл своим:

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

После сборки образа получаем нормальное переключение раскладок по . Вот только работает VNC-клиент недопустимо медленно. На компьютерах с процессором ниже P-200 начинается этакое «слайд-шоу», когда любое действие на удаленном рабочем столе сопровождается неторопливой прорисовкой этих изменений на экране монитора тонкого клиента. Существует множество VNC-решений, использующих схожие методы кодирования данных при передаче, все используют протокол Remote FrameBuffer (RFB). Различаются они количеством функций, параметрами кодирования данных, а также числом поддерживаемых платформ. Например, RealVNC поддерживает сервер и клиент для Windows, UNIX, Microsoft PocketPC и Mac OS X, TightVNC включает сервер и клиент для Windows и UNIX, VNC for DOS – клиент для DOS, UltraVNC – сервер и клиент для Windows, OSXvnc – сервер и клиент для Mac OS X. Я протестировал RealVNC и TightVNC: второй продукт (и сервер, и клиент) субъективно немного быстрее, но оба создают эффект «слайд-шоу» на слабых компьютерах. Придется попробовать что-нибудь другое в качестве протокола связи между клиентом и сервером. VNC пока оставим в покое, позже придется к нему еще вернуться. Вот здесь я обратился к NX.

Поддержка Nomachine NX-клиента впервые появилась в Thinstation версии 2.1 в 2005 году, а последней на текущий момент является 2.2, она и будет подразумеваться далее. Для сборки образа с пакетом NX раньше был необходим прямой доступ в Интернет, в последних версиях Thinstation появилась возможность указывать путь к файлу префиксом «file://». Используемый и поддерживаемый дистрибутивом Nomachine NX клиент до сих пор имеет версию 1.5.x, хотя уже прошло достаточно времени с момента появления новой версии NX 2.0. В файле конфигурации build.conf раскомментируем строку «package nx», также в конце файла найдем строку «param nxurl»: укажем путь к заранее скачанному файлу, либо оставим как есть(нужен доступ в Интернет). Полученный сгенерированный образ копируем в каталог tftp-сервера, туда же копируем файл thinstation.conf.sample из корня дистрибутива, переименовываем его в thinstation.conf.network и правим: ищем на предмет #SESSION_0_TYPE=NX и редактируем строчки, относящиеся к этой сессии (здесь с номером 0), внося нужные параметры.

Включаем тонкого клиента и загружаем созданным образом, проверяем быстродействие. Прогресс налицо: «слайд-шоу» прекращается на ПК с процессором P-100, P-120 и выше. Это не то, чего бы нам хотелось получить в результате, так что ПК с процессорами i486 задействовать здесь не удастся. Такие ПК мы назвали «супертонкими» клиентами и определили их для работы с ДОС-программами, используя связку FreeDOS и sshdos со стороны клиента и Dosemu со стороны Linux-сервера. В этой статье я о них рассказывать не буду. Тем не менее это хороший результат, посмотрим на требования к железу со стороны разработчиков Thinstation и NX-клиента: первые рекомендуют i486-процессор и 16 Мб памяти, вторые – процессор с частотой от 400 Мгц и памятью 128 Мб. Минимально необходимой конфигурацией для работы тонкого клиента с пакетом NX эмпирически определим процессор P-120 и объем оперативной памяти 32 Мб. Я протестировал и некоторые другие клиенты, в частности, XRDP, VNC for DOS, но по той или иной причине реальной альтернативы NX я не нашел. Теперь пришло время познакомиться с технологией NX поближе.

Обзор и краткое описание Nomachine NX

Архитектура NX – это набор Open Source-технологий и коммерческих средств, призванных обеспечить легкость и распределенность сетевых вычислений. Он состоит из серверного ПО, позволяющего любому UNIX-компьютеру стать терминальным сервером, и клиентов для широкого набора платформ и ОС. Nomachine выбрала в качестве основы для архитектуры NX известную и широко используемую систему X-Window, на которой основаны GUI Linux и других ОС UNIX.

Большинство имеющихся сетевых решений не было разработано в качестве основного средства для доступа пользователей к рабочему столу. Такие протоколы как RDP и VNC являются много более простыми, чем X (и поэтому хорошо подходящими для тонких клиентов), но их простота не компенсирует недостатка эффективности и функциональности. Например, эти протоколы используют для прорисовки удаленного экрана передачу больших объемов данных изображений. Хотя RDP и является более эффективным протоколом, чем RFB (протокол, используемый VNC), он был изначально разработан не для ежедневного использования устройствами сети, а лишь в качестве расширения для ОС. X-Window – это графическая подсистема (а не расширение ОС), и X-приложения взаимодействуют с ней, используя X-протокол, поэтому ОС не имеет специального уровня, отвечающего за трансляцию обновлений экрана в сетевой протокол.

Основными недостатками сетей с X-терминалами являются избыточность и задержки в передаче графических данных X-протокола. Со времени появления X-Window рабочий стол пользователя оброс всевозможными графическими элементами и эффектами, которые увеличили требования к сетям передачи данных.

На рис. 1 под цифрой 1 показана традиционная работа по протоколу X: сжатия нет, требования к пропускной способности и задержкам сети критичны. Напомню, что в идеологии X-Window X-сервер работает на терминале, а на терминальном сервере – X-клиент, который шлет запросы X-серверу терминала .

В простейшем случае можно запускать приложения с графическим выводом с помощью параметра -X команды ssh, например, «ssh -X me@server firefox». Можно добавить параметр -С для компрессии(используется библиотека ZLIB). Также можно оптимизировать скорость взаимодействия узлов, увеличивая пропускную способность сети. Но существует предел, выше которого увеличение пропускной способности перестанет влиять на скорость этого взаимодействия. Причиной тому – интенсивный обмен запросами/ответами современных X-приложений.

NX использует три основных метода ускорения работы приложений: сжатие, кэширование и подавление избыточного трафика X-протокола.

Все три метода совокупно позволяют достичь 70-кратного улучшения работы с удаленным X GUI при использовании наибольшего уровня сжатия на линиях связи с низкой пропускной способностью и большой задержкой (в настройках клиента NX «modem» соответствует максимальному сжатию, а «lan» – отсутствию сжатия). На рис. 1 под цифрой 2 показана взаимосвязь компонентов NX: на модулях NX Proxy осуществляется компрессия/декомпрессия и кэширование, между ними проходит трафик по NX-протоколу, требования к качеству линий связи минимальны, заявляется о возможности работы вплоть до скорости 9600 бит/сек.

Подобно трансляции X-трафика посредством nxagent, имеется другой агент («nxviewer»), который транслирует RFB/VNC-трафик в протокол NX. Это улучшает эффективность соединений до 10 раз по сравнению с работой обычного vncviewer, связывающего локальный X-дисплей с удаленным сервером VNC. В этом мы убедимся.

На рис. 1 под цифрой 3 показана возможность одновременной работы разных агентов NX, RDP, VNC. При этом NX-агенты эффективно транслируют чужеродные протоколы в свой собственный и далее передают трафик через NX Proxy.

NX Proxy – этот компонент как раз и отвечает за компрессию/декомпрессию: в клиентском режиме кодирует запросы от X-клиентов и декодирует ответы от X-сервера, в серверном – наоборот.
NX Agent – термин «агент» используется для описания компонента, которому передается сформированное изображение перед передачей в сеть через прокси.
NX Viewer – модифицированный Nomachine обычный VNC-клиент, транслирующий VNC/RFB-трафик в NX-протокол.
NX Desktop – RDP-клиент, который транслирует RDP-трафик в NX-протокол.

Nomachine открыла исходные коды большинства своих наработок и библиотек, их можно скачать всем желающим с . Сборки от самой Nomachine для всех клиентов доступны бесплатно, также есть различные варианты сборок NX-серверов, поставляемые за определенную плату: годовая подписка на NX Enterprise Server с неограниченным количеством пользователей и числом процессоров 1-2 стоит 1494$, наиболее полное решение с балансировкой нагрузки и управлением узлов на базе NX Advanced Server обойдется в 3494$. Кроме того, имеется вариант NX Free Edition, который можно скачать бесплатно, но имеет ограничение на количество одновременных соединений и пользователей, равное двум, так что если есть желание администрировать Linux-сервер из дома с помощью обычного аналогового модема, то лучше, безопаснее и проще этого решения не найти. Отмечу также наличие клиентских версий NX Client Desktop Edition для PlayStation 2 (при использовании Linux Kit), а также NX Client Embedded Edition для Sharp Zaurus 5xxx и HP/Compaq iPAQ. Их можно также скачать бесплатно . Так что, если вы в командировке, а с собой только КПК, ничего не мешает подключиться и работать удаленно на своем Linux-сервере.

Сборка и запуск NX

В свою очередь, на основе открытых исходников сообщество разработало версию серверной части NX под названием FreeNX, а также KNX – клиент для соединения с сервером из под X. FreeNX – это набор shell-скриптов, которые вместе с открытыми библиотеками от NX формируют серверную часть (backend).

Вначале работы с NX в качестве сервера мною использовался ПК с ОС SUSE 10.0. В составе дистрибутива уже шла сборка FreeNX, но, во-первых, она имела более чем годовую давность, а, во-вторых, столкнувшись с первыми трудностями при работе, я решил, что пора собрать серверную часть из исходников самому. Рассказывать буду о сборке из исходников версии 1.5 как наиболее проверенной временем, а потом уточню, какие имеются особенности для сборки версии 2.0(2.1).

В настоящий момент на сайте Nomachine выложены исходники версии NX 2.0, эта версия является рекомендуемой фирмой, а на исходники версии 1.5 там же имеется специальная ссылка. Качаем последние версии следующих тарболов со странички : nx-X11, nxagent, nxcomp, nxcompext, nxdesktop (если нужна поддержка RDP), nxproxy, nxscripts, nxviewer (если нужна поддержка VNC). nx-X11 – это версия 4.3 Xfree86, которая имеет модифицированные Nomachine X-библиотеки. Часть исходников будет распаковываться прямо в дерево nx-X11, поэтому развернем его в первую очередь, очередность распаковки остальных тарболов неважна, главное, чтобы они все распаковывались в одном каталоге. Туда же качаем и распаковываем скрипты FreeNX с адреса . Еще понадобятся два патча, качаем их отсюда [ , ]. Каталог нашей сборки примет следующий вид:

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

Для сборки понадобятся следующие пакеты (их можно установить из вашего дистрибутива Linux): libjpeg-devel, libpng-devel, openssl-devel, netcat, expect. Описание сборки можно найти также здесь .

# Накладываем NX patch
patch -p0 < NX-lfs_hint.diff

# Собираем X – самая длительная часть, может занять до часа времени
pushd nx-X11
make World
popd

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

# Сборка RFB-агента
pushd nxviewer
xmkmf -a
cp -a /usr/X11R6/lib/libXp.so* ../nx-X11/exports/lib/
make 2> /dev/null
popd

# Сборка RDP-агента
pushd nxdesktop
./configure --prefix=/srv/NX --sharedir=/srv/NX/share
make
popd

# Вся серверная часть будет находиться в каталоге /srv/NX, создаем некоторые из подкаталогов
mkdir -p /srv/NX/bin
mkdir -p /srv/NX/lib
mkdir -p /srv/NX/man/man1
mkdir -p /srv/NX/share/doc

# Инсталлируем собранные библиотеки и агенты
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

# Создаем скрипт nxagent, который будет управлять всеми программами
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

# И устанавливаем его:
install -m 755 nxagent /srv/NX/bin

# Устанавливаем библиотеки сжатия и прокси
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

# Установка RFB-агента
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

# Установка RDP-агента
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

# Установка скриптов

# Установка 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

# Накладываем патч freenx, в основном здесь правятся пути на соответствие /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

# Добавляем пользователя и группу 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

# Далее важный момент, прежде чем запускать, ознакомьтесь с параметрами запуска команды: /srv/NX/bin/nxsetup –help.
# Если хотите использовать аутентификацию пользователей с помощью ключей, уберите параметр –setup-nomachine-key.
# Для работы с тонкими клиентами можно ничего не менять
/srv/NX/bin/nxsetup --install --uid 77 --gid 77 --setup-nomachine-key

# Проверяем, работает ли сервер NX:
/srv/NX/bin/nxserver --status

Должен быть примерно такой ответ:

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

Устанавливаем конфигурационный файл freenx:

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

В конфигурационном файле находим следующую строчку и раскомментируем ее:

ENABLE_1_5_0_BACKEND="1"

Там же можно на первое время включить возможность ведения лога:

NX_LOG_LEVEL=6

Теперь можно установить клиент Nomachine NX на любой компьютер Linux (можно использовать и KNX) или Windows и проверить работу NX-сервера. C сервером можно работать как в режиме приложений, так и в режиме удаленного рабочего стола.

Настройка и создание образа Thinstation

От серверной части NX теперь перейдем к созданию образа Thinstation. Сам дистрибутив можно скачать здесь . При сборке образа будем стараться максимально уменьшить количество модулей и пакетов, все лишнее выкидываем. Поскольку у многих компьютеров, выбранных в качестве тонких клиентов, железо и периферия будут отличаться, то отдельные пакеты хотелось бы вынести за рамки общего для всех образа. Такая возможность у Thinstation есть: pkg означает собрать как отдельный подгружаемый пакет с расширением pkg, package означает включение в общий образ. Пакеты lprng, sshd, samba-server и другие однозначно собираем как подгружаемые. Можно все пакеты с X-драйверами видеокарт указать как pkg, но тогда при сборке образа появятся несколько дополнительных пакетов, которые надо будет подгружать всем, и в результате общий размер подгружаемых данных будет больше. Поступим проще: один из видеодрайверов, наиболее часто используемый, а именно S3, укажем как package, остальные – pkg. Модули тоже можно выносить за пределы ядра, но пока эта возможность работала некорректно, к тому же места в составе ядра они занимают совсем немного. Ниже представлен мой файл конфигурации build.conf:

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-ru
package nx
pkg lprng
pkg sshd
pkg samba-server
param rootpasswd pleasechangeme
param xorgvncpasswd pleasechangeme
param bootlogo false
param bootresolution 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

Если будете использовать печать на принтер, подключенный к тонкому клиенту с помощью lprng, необходимо внести небольшую модификацию в файл thinstation/packages/lprng/etc/init.d/lprng. Для этого замените строчку:

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

Добавление локальной фильтрации избавило меня от проблемы «лесенки» при печати. Кроме того, я создал следующий скрипт для проверки работы печати ~/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;

Когда непонятно, что именно не работает, можно выполнить этот скрипт на консоли тонкого клиента: /bin/my.

Чтобы при подключении клиента NX к серверу каждый раз не появлялось окошко с предупреждением о незнакомом хосте, создадим в корне Thinstation файл known_hosts:

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

В качестве «nxserver_ip» надо указать IP-адрес NX-сервера. Таким образом клиент будет знать о цифровом отпечатке rsa-ключа NX-сервера при аутентификации.

После успешного выполнения build копируем thinstation/boot-images/etherboot/thinstation.nbi и thinstation.nbi.zpxe, а также все pkg-файлы из thinstation/boot-images/pkg-packages в каталог /tftpboot на tftp-сервер. У меня создающийся файл thinstation.nbi.zpxe не заработал, в таком случае по адресу можно скачать файл BootPXE535.zip, в этом архиве есть универсальный загрузчик loader-native.zpxe, с ним все должно работать.

Конфигурационные файлы Thinstation достаточно хорошо откомментированы, но вот сам процесс настройки и последовательность действий не всегда очевидны, так что некоторые трудности, с которыми мне пришлось столкнуться, и тонкости я все-таки упомяну.

На рис. 3 показаны основные действия по включению тонкого клиента в работу. Сначала добавляем информацию о MAC-адресе сетевой карты в dhcpd.conf. Не забудьте указать настройки в описании подсети, связанные с tftp, они задаются директивами «next-server» и «option root-path». У меня сервисы tftp и dhcp находятся на одном сервере FreeBSD, это облегчает их настройку. Все файлы настроек располагаются в /tftpboot. Потом в файле thinstation.hosts прописываем по-порядку: произвольное имя хоста (лучше, чтоб оно включало информацию о размещении терминала), MAC-адрес, группы, членом которых терминал является, в конце строки можно поместить комментарии за знаком «#», например:

otd146_57158 00e04d08d710 smb_flop_hard TUX1C monitor #very important PC

Здесь по порядку: имя хоста, в моем случае состоит из номера отдела и инвентарного номера, далее MAC, и далее перечисление названий файлов конфигураций, который будут использованы этим хостом.

Далее создаем файл настроек thinstation.conf-MAC, я использую в названии MAC-адрес, хотя можно использовать IP-адрес или имя из thinstation.hosts. Заметьте, что здесь в имени файла MAC-адрес использует только заглавные буквы. Группы описываются в файлах с названием thinstation.conf.group-ИМЯГРУППЫ. В файле thinstation.conf-MAC находятся те настройки, которые касаются только этого терминала, и не включены в другие группы. Например, все общие настройки монитора описаны в файле thinstation.conf.group-monitor, а один параметр «SCREEN_VERTREFRESH» вынесен в файл thinstation.conf-MAC. Это связано с тем, что используются разные мониторы, и можно изменить настройку кадровой частоты экрана, этот и другие параметры можно настраивать для каждого терминала или для всех сразу. То же касается настройки мышки. По умолчанию настройка выполнена для PS/2-мыши. Если используется мышка, подключенная к порту COM1, то указываются два параметра «MOUSE_PROTOCOL=Microsoft» и «MOUSE_DEVICE=/dev/ttyS0», если к порту COM2, то во втором параметре указывается /dev/ttyS1.

Общий для всех файл конфигурации /tftpboot/thinstation.conf.network у меня почти пустой. Вся информация из него вынесена в отдельные файлы групповых настроек, на которые есть ссылки в thinstation.hosts. Так как используются два терминальных сервера c разными версиями NX и каждый клиент использует только свой сервер, то конфигурации вынесены в отдельные текстовые файлы (NX и TUX1C), кроме того, используются разные образы Thinstation. Также не забывайте, что названия файлов thinstation.nbi и thinstation.nbi.zpxe взаимосвязаны: если в dhcpd.conf указана строчка:

thinstation.nbi.zpxe";

то будет использован образ thinstation.nbi, в моем случае образов несколько, соответственно и записи в dhcpd.conf для каждого терминала разные.

Отличия сборки NX2

В нашей системе используются два NX-сервера. На одном работает NX, собранный из исходников версий 1.5, для работы с ним используются клиенты 1.5.x. На другом работает NX версии 2.0. Расскажу, в чем отличия работы и сборки этой версии. На сервере установлены 64-битные Opteron, используется система SLES 10.0 x86_64. Так вот собрать на этом сервере NX так, как это было в случае с NX 1.5 на 32-битной системе, у меня не получилось, даже когда я пробовал явно указать сборку для 32-битной системы:

make World BOOTSTRAPCFLAGS="-m32"

Видимо, это особенности 64-разрядной системы и ее библиотек. Несколько позже на сайте Nomachine я нашел заметку , в которой сказано, что исходные тексты NX разработаны для 32-битных систем, но их можно использовать и в 64-битных системах. Поскольку у меня еще есть компьютер с установленной SLED 10.0 x86 и версии всех библиотек, ядра и программ точно такие же, как у SLES, то я решил собрать NX на нем, а потом перенести каталог с результатом сборки обычным копированием на 64-разрядную систему. Так и сделал: все заработало как ни в чем не бывало. Качаем файлы с теми же названиями, что и при сборке версии 1.5, только с суффиксами 2.0 (или 2.1). Всё компилируется точно так же, как и в случае с NX 1.5, за некоторыми исключениями: во-первых, я не стал накладывать патч NX-lfs_hint.diff, во-вторых, появилась новая версия скриптов FreeNX 0.5, поддерживающая новый NX 2.0, её можно забрать здесь , в-третьих, файл freenx-lfs_hint.diff, который вносит изменения в файл nxloadconfig из FreeNX 0.4, не подходит к новой версии FreeNX, его нужно отредактировать. Вот вывод команды diff, показывающий разницу между оригинальным и отредактированным файлом nxloadconfig:

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)"

Привет, сегодня мы будем собирать последнюю версию загрузочного образа для тонких клиентов — Thinstation! В данной статье мы соберем загрузочный образ Thinstation, настроим и сервер для загрузки сего образа тонкими клиентами по сети, посредством протокола . Данная статья расчитана на более продвинутых пользователей, у которых есть понимание того, что такое , у кого в парке есть хотя бы одна машина с и базовый багаж знаний работы с nix подобными системами. Для тех, у кого нет таких знаний будет статья о том, как собрать такой образ из готового загрузочного диска .

Что у нас должно быть

Lunix машина (для сборки образа на ней)
DHCP сервер
Укромное местечко для TFTP сервера
Собственно тонкие клиенты
Терминальный (или любой другой сервер) для того, что бы эти тонкие клиенты туда подключались.

Оговорюсь относительно последнего пункта. Тонкие клиенты на Thinstation могут работать не только в режиме подключения к терминальному серверу, но и как самостоятельные бездисковые рабочие станции на ОС Linux с полным набором софта. Правда в пределах этой стати, мы рассмотрим только первый и самый распространенный вариант.

Приступаем к сборке. Подключаемся к нашей Linux машине (в данном случае я использую виртуальную машину на Ubuntu 14.04 на VMware Workstation, так очень удобно). Первым делом установим git, для того, что бы забрать последнюю версию Thinstation.

Apt-get install git-core

Далее перейдем в папку, в которой будем разворачивать окружение для сборки образа и начнем его качать (это довольно длительный процесс, около 40 минут. Свободного дискового пространства нам понадобится около 3GB)

Cd /home/verbin/Documents/ git clone --depth 1 git://github.com/Thinstation/thinstation.git

После окончания загрузки переходим в директорию с этим добром и заупскаем chroot скрипт, который соберет в нашу систему недостающие пакеты и подготовит инфраструктуру для последующей сборки.

Cd thinstation ./setup-chroot

По окончанию сего процесса вы увидите примерно такой вывод в консоле. Это означает что все готово для сборки нашего первого и пока что «толстого» образа. Толстого — то есть с полным набором пакетов и драйверов, для первой загрузки станции и последующего определения только необходимых нам составляющих и исключения лишних из образа.

Все работы по сборке образа Thinstation должны проводится в данной виртуальной среде. Для скрытия приветствия (README) нажимем Q и попадаем в командную строку chroot

Переходим в папку ts/5.x/ в которой находятся конфиги и скрипт сборки. Краткий ликбез по требующим внимания файлам.

build.conf — Корневой конфигурационный файл, в котором указываются необходимые драйвера, параметры и пакеты для сборки образа.
thinstation.conf.buildtime — Конфигурационный файл уже Thinstation образа, указанные в нем параметры будут «зашиты» в образ. Воздержимся от использования оного, лучше оставим это на потом и будем использовать обычные конфигурационные файлы находящиеся на TFTP сервере вместе с образом. Так — более гибко.
boot-images/ — Директория в которой после сборки образа появятся папки с образами нашего Thinstation для разных типов загрузки
boot-images/pxe/ — Собственно директория в которой после окончания сборки образа будут находится необходимые нам файлы образа для загрузки по PXE.

Сборка «толстого» образа

Сразу оговорюсь о том, что можно закоментировать пакет «package chrome» в buid.conf, так как он попросту не нужен и является одним из самых «тяжелых», значительно повышая вероятность того, что у вашего тонкого клиента не хватит оперативной памяти для запуска (так же размер самого образа вырастет мегабайт на 20-30).

Так же опишу несколько важных опций в buid.conf из раздела настроек (param)

param rootpasswd — Пароль для пользователя root в образе (для доступа к административным функциям)
param xorgvncpasswd — Пароль для подключения к станциям по VNC (если этот пакет был включен при сборке «package xorg7vnc» )
param bootresolution — Разрешение экрана при загрузке
param desktop file: — Стандартный фон (рабочий стол и загрузка системы)
param httpproxy — Настройка прокси (если загрузка файлов доступна только через proxy. В значении можно указать и авторизацию user:password@proxy:port)

Приступаем к сборке следующей командой.

./build --allmodules

Во время данного процесса могут появится запросы подтверждения загрузки недостающих компонентов, соглашаемся Y. Пока ждем окончания сборки — сконфигурируем TFTP сервер и DHCP для PXE загрузки с него (Cisco DHCP или Windows DHCP).

Сборка завершена, теперь копируем файлы образа из папки boot-images/pxe/ (полный путь: thinstation/ts/5.2/boot-images/pxe/) на наш TFTP сервер. Вполне вероятно что наш образ полностью не запустится. Нам нужно что бы образ загрузился до того состояния, когда на экране будет фоновое изображение и прогрессбар загрузки, в этот момент нужно нажать Ctrl+Alt+F3, попадаем в консоль (в противном случае, если станция не запустится даже до этого шага — это означает что не хватило оперативной памяти (убираем лишние модули в build.conf).

Итак, мы попали в консоль нашего толстого образа и видим приглашение войти (вводим root / pleasechangeme — если не меняли это в buid.conf). Далее выполняем команду

Hwlister.sh

которая сгенерирует нам файлы профиля конкретного железа тонкого клиента (module.list) и графических режимов (vbe_modes.list). Забираем эти файлы на нашу Lunix машину где проводится сборка образа (любым удобным способом, я показываю пример как это сделать через наш TFTP сервер).

Cd / tftp -p -l module.list -r module.list 192.168.1.3 tftp -p -l vbe_modes.list -r vbe_modes.list 192.168.1.3

Создаем папку для профилей нашего тонкого клиента и кладем в нее файлы module.list и vbe_modes.list

Mkdir thinstation/ts/5.2/machine/Thinclient

Финальная конфигурация и сборка

В файле build.conf

machine Thinclient — Название профиля оборудования по которому будет производится сборка.
package xorg7-vesa — Стандартный видеодрайвер (рекомендуется включать его в сборку).
package freerdp или package rdesktop — Выбираем RDP клиент который будем использовать (можно добавить оба).
package xorg7vnc — VNC сервер для удаленного управления клиентами.
param fastboot true — Значительно ускоряет загрузку бездисковых систем но могут быть проблемы из-за не совместимости с сетевой картой

В файле thinstation.conf.buildtime

DONT_VT_SWITCH_STATE=TRUE — Запретит переключение в консоль посредством Ctrl+Alt+F3
DONT_ZAP_STATE=TRUE — Запрет переинициализации графического режима через Ctrl+Alt+Backspace (тоже лазейка к консоли)

Начинаем финальную сборку находясь в папке thinstation/ts/5.2/ и

./setup-chroot ./build

Полученный образ кладем в корень TFTP сервера и там же создаем стандартный общий конфигурационный файл thinstation.conf.network в который добавим параметры подключения к терминальному серверу (обратите внимание — для freerdp клиента и rdesktop указаны разные команды подключения по RDP).

SESSION_0_TITLE="Terminal Server rdesktop" SESSION_0_TYPE=rdesktop SESSION_0_SCREEN=1 SESSION_0_RDESKTOP_SERVER=192.168.1.10 SESSION_0_RDESKTOP_OPTIONS="-d "DOMAIN" -u "USER"" SESSION_0_AUTOSTART=On SESSION_1_TITLE="Terminal Server freerdp" SESSION_1_TYPE=freerdp SESSION_1_SCREEN=1 SESSION_1_SCREEN_POSITION=2 SESSION_1_FREERDP_SERVER=192.168.1.10 SESSION_1_FREERDP_OPTIONS="-d "DOMAIN" -u "USER"" SESSION_1_AUTOSTART=On

Пример классического thinstation.conf.network можно найти . В следующих статьях рассмотрим более подробную конфирурацию тонких клиентов, индивидуальные конфигурационные файлы для разных станций и прочее.

Технология NX, разработанная фирмой Nomachine, дает новые возможности для связи и способна оживить старые компьютеры в роли тонких клиентов.

1. Компьютерная техника дешевеет и становится более доступной, чем раньше. При этом её производительность удваивается каждые 1,5-2 года согласно закону Мура. Это приводит к накоплению техники, не выработавшей свой ресурс, но уже устаревшей.

2. Разработанные на предприятиях силами программистов отделов АСУ в перестроечные годы клиент-серверные приложения еще работают на старой технике, но уже не соответствуют требованиям времени.

3. Современные программное обеспечение и операционные системы не заставить работать на компьютерах с процессорами прежних поколений (i386, i486 и т. д.).

4. Не секрет, что во многих организациях нашей страны с давних времен незаконно используются многие программы и ОС, которые сотрудники устанавливали по своей инициативе. Вначале это рассматривалось как само собой разумеющееся обстоятельство, потом оправдывалось финансовым положением. Сейчас, когда наша страна вступает в ВТО, правительство вынуждено такую ситуацию спешно исправлять, в связи с этим усилилось давление на предприятия со стороны внутренних органов с требованием отказаться от незаконно используемых ПО и ОС.

В журнале уже публиковалось несколько статей по работе с дистрибутивом Thinstation . В этой статье я расскажу об особенностях настройки и опыте эксплуатации на своем предприятии тонких клиентов на базе дистрибутива Thinstation и технологии NX, разработанной фирмой Nomachine.

До недавнего времени в мире терминальной связи было мало известно удачных сетевых протоколов высокого уровня, способных эффективно сжимать и шифровать трафик между тонким клиентом и сервером. Наиболее известные и популярные из них – это RDP от Microsoft и ICA от Citrix. Оба протокола используются серверами на базе ОС MS Windows. Меня же интересовала возможность использовать тонкие клиенты с серверами на базе Linux. В качестве основы для тонкого клиента почти сразу был выбран небольшой дистрибутив, этакий Linux-конструктор, Thinstation – как наиболее стабильно развивающийся и популярный в нашей стране и за рубежом. А вот с выбором протокола, который бы отвечал за общение с сервером, пришлось повозиться и поэкспериментировать. Перечислю основные критерии, по которым выбирался протокол. Во-первых, нам хотелось использовать как можно более широкий диапазон старых компьютеров, имеющих процессоры начиная с i486, с минимальным объемом памяти, такой техники у нас предостаточно. Во-вторых, отметались коммерческие продукты: мы не хотели нести дополнительные расходы. В-третьих, необходимы хорошая поддержка русского языка и кириллицы, а также наличие привычного для пользователей способа переключения между раскладками – комбинации клавиш. В-четвертых, в рамках локальной сети нам необязательна поддержка шифрации, но важны сжатие и минимизация сетевого трафика.

Поиск решения

Рисунок 1. Взаимосвязь компонентов NX

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

IP-адрес 10.10.10.10 замените на адрес вашего VNC-сервера.

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

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

После сборки образа получаем нормальное переключение раскладок по. Вот только работает VNC-клиент недопустимо медленно. На компьютерах с процессором ниже P-200 начинается этакое «слайд-шоу», когда любое действие на удаленном рабочем столе сопровождается неторопливой прорисовкой этих изменений на экране монитора тонкого клиента. Существует множество VNC-решений, использующих схожие методы кодирования данных при передаче, все используют протокол Remote FrameBuffer (RFB). Различаются они количеством функций, параметрами кодирования данных, а также числом поддерживаемых платформ. Например, RealVNC поддерживает сервер и клиент для Windows, UNIX, Microsoft PocketPC и Mac OS X, TightVNC включает сервер и клиент для Windows и UNIX, VNC for DOS – клиент для DOS, UltraVNC – сервер и клиент для Windows, OSXvnc – сервер и клиент для Mac OS X. Я протестировал RealVNC и TightVNC: второй продукт (и сервер, и клиент) субъективно немного быстрее, но оба создают эффект «слайд-шоу» на слабых компьютерах. Придется попробовать что-нибудь другое в качестве протокола связи между клиентом и сервером. VNC пока оставим в покое, позже придется к нему еще вернуться. Вот здесь я обратился к NX.

Обзор и краткое описание Nomachine NX

В основе идеи разностной компрессии лежит проект Differential X Protocol Compressor (DXPC) , созданный в 1995 году, там уже упоминаются термины клиентского и серверного прокси. Nomachine подхватила идею и разработала свой собственный продукт. Заявляется о 10-кратном превосходстве NX над стандартной библиотекой ZLIB.

Nomachine также разработала умный механизм кэширования X-трафика, который использует знакомый по прокси-серверам термин «попаданий в кэш». Этот механизм сокращает сетевой трафик при передаче одних и тех же блоков данных, а при изменении этих блоков данных потока вычисляет и передает только их разницу.

До NX не было надежного способа подавления избыточного трафика X-протокола на дальних линиях связи. NX может это делать, транслируя X-трафик на удаленном конце(от приложения к nxagent) в трафик протокола NX.

Подобно трансляции X-трафика посредством nxagent, имеется другой агент (“nxviewer”), который транслирует RFB/VNC-трафик в протокол NX. Это улучшает эффективность соединений до 10 раз по сравнению с работой обычного vncviewer, связывающего локальный X-дисплей с удаленным сервером VNC. В этом мы убедимся.

NX Proxy – этот компонент как раз и отвечает за компрессию/декомпрессию: в клиентском режиме кодирует запросы от X-клиентов и декодирует ответы от X-сервера, в серверном – наоборот.

NX Agent – термин «агент» используется для описания компонента, которому передается сформированное изображение перед передачей в сеть через прокси.

NX Viewer – модифицированный Nomachine обычный VNC-клиент, транслирующий VNC/RFB-трафик в NX-протокол.

NX Desktop – RDP-клиент, который транслирует RDP-трафик в NX-протокол.

Сборка и запуск NX

В настоящий момент на сайте Nomachine выложены исходники версии NX 2.0, эта версия является рекомендуемой фирмой, а на исходники версии 1.5 там же имеется специальная ссылка. Качаем последние версии следующих тарболов со странички : nx-X11, nxagent, nxcomp, nxcompext, nxdesktop (если нужна поддержка RDP), nxproxy, nxscripts, nxviewer (если нужна поддержка VNC). nx-X11 – это версия 4.3 Xfree86, которая имеет модифицированные Nomachine X-библиотеки. Часть исходников будет распаковываться прямо в дерево nx-X11, поэтому развернем его в первую очередь, очередность распаковки остальных тарболов неважна, главное, чтобы они все распаковывались в одном каталоге. Туда же качаем и распаковываем скрипты FreeNX с адреса . Еще понадобятся два патча, качаем их отсюда . Каталог нашей сборки примет следующий вид:

freenx-lfs_hint.diff

NX-lfs_hint.diff

# Накладываем NX patch
patch -p0 # Собираем X – самая длительная часть, может занять до часа времени
pushd nx-X11
make World
popd
# nxproxy
pushd nxproxy
./configure --prefix=/srv/NX
make
popd
# Сборка RFB-агента
pushd nxviewer
xmkmf -a
cp -a /usr/X11R6/lib/libXp.so* ../nx-X11/exports/lib/
make 2> /dev/null
popd
# Сборка RDP-агента
pushd nxdesktop
./configure –prefix=/srv/NX –sharedir=/srv/NX/share
make
popd
# Вся серверная часть будет находиться в каталоге /srv/NX, создаем некоторые из подкаталогов
mkdir -p /srv/NX/bin
mkdir -p /srv/NX/lib
mkdir -p /srv/NX/man/man1
mkdir -p /srv/NX/share/doc
# Инсталлируем собранные библиотеки и агенты
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
# Создаем скрипт nxagent, который будет управлять всеми программами
cat > nxagent #!/bin/sh
NXCOMMAND=$(basename $0)
export LD_LIBRARY_PATH=/srv/NX/lib:$LD_LIBRARY_PATH
exec /srv/NX/lib/$NXCOMMAND ${1+"$@"}
EOF
# И устанавливаем его:
install -m 755 nxagent /srv/NX/bin
# Устанавливаем библиотеки сжатия и прокси
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
# Установка RFB-агента
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
# Установка RDP-агента
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
# Установка скриптов
cp -r nxscripts /srv/NX/share/doc
# установка 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
# Накладываем патч freenx, в основном здесь правятся пути на соответствие /srv/NX
patch -p0 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
# Добавляем пользователя и группу 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
# Далее важный момент, прежде чем запускать, ознакомьтесь с параметрами запуска команды: /srv/NX/bin/nxsetup –help.
# Если хотите использовать аутентификацию пользователей с помощью ключей, уберите параметр –setup-nomachine-key.
# Для работы с тонкими клиентами можно ничего не менять
/srv/NX/bin/nxsetup --install --uid 77 --gid 77 --setup-nomachine-key
# Проверяем, работает ли сервер NX:
/srv/NX/bin/nxserver --status

Должен быть примерно такой ответ:

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

Устанавливаем конфигурационный файл freenx:

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

В конфигурационном файле находим следующую строчку и раскомментируем ее:

ENABLE_1_5_0_BACKEND="1"

Там же можно на первое время включить возможность ведения лога:

Рисунок 2. NX-сессия KDE в режиме рабочего стола из Windows XP

Настройка и создание образа Thinstation

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

#!/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;

Когда непонятно, что именно не работает, можно выполнить этот скрипт на консоли тонкого клиента: /bin/my.

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

Финансовый кризис заставил IT-специалистов пересмотреть традиционный подход к
организации сети в сторону "тонких клиентов". В отличие от настольных компов,
они экономичны, потребляют мало энергии, просты в сопровождении, легко
адаптируются к любой среде. Сегодня доступно несколько десятков различных
решений для такой сети, а самым популярным представителем лиги терминальных
систем является опенсорсный мини-дистрибутив Thinstation.

Терминальная сеть

Вначале определимся с назначением тонких клиентов и местом Thinstation
в процессе организации подобного сервиса. В типичной сети компании применяется
схема, ставшая усилиями Microsoft уже стандартной: ОС загружается с локального
жесткого диска, там же могут храниться и все необходимые пользователю данные. Но
менеджеры, маркетологи, секретари и прочий офисный планктон, которым для работы
требуются средства интернета, текстовый редактор и пара программ для создания
отчетов и работы с базой данных, используют мощности современного компьютера
далеко не полностью (от силы на 10%). На этом можно и нужно экономить.

Архитектура тонких клиентов предусматривает загрузку ОС и всех необходимых
данных по сети. Такой подход имеет ряд преимуществ, которые становятся очевидны
уже в сетях среднего размера:

централизованное администрирование;
быстрое развертывание (рабочее место можно организовать буквально за
5-10 минут);
повышение безопасности корпоративных данных (за счет того, что вся
информация хранится на сервере, снижается риск хищения данных и вредоносного
действия вирусов, кроме того, заметно упрощается процедура резервного
копирования);
большее время наработки на отказ (в первую очередь, в связи с
минимальным количеством механических компонентов);
снижение нагрузки на сеть (во время терминальной сессии передаются
только данные о нажатии клавиш, движениях мыши и обновлениях экрана);
отсутствие привязки пользователя к конкретному рабочему месту, юзер
может получить доступ к своему виртуальному рабочему столу с любого
терминала, подключенного к серверу (даже из своего дома, используя VPN).

Основная экономия достигается за счет минимизации затрат на приобретение
лицензий на пользовательское программное обеспечение и выбора минимальной
аппаратной конфигурации клиентской части. На рабочем столе пользователя может
стоять как старый комп, по всем параметрам непригодный для большинства
повседневных задач (процессор не ниже Pentium 100, объем оперативной памяти не
менее 16 Мб), так и специализированное устройство (например, на базе процессора
VIA Eden или AMD Geode). Последние компактны, абсолютно бесшумны и потребляют
малую толику электроэнергии (кстати, это позволяет вешать на один бесперебойник
до 10 терминалов).

С вступлением и "железочными" делами закончили, перейдем к софту. Дистрибутив
Thinstation
разработан специально для создания тонких клиентов и оснащен всеми необходимыми
приложениями, обеспечивающими подключение к сервисам по основным протоколам
удаленной работы: Citrix ICA, Microsoft RDP, VNC, NX NoMachine, 2X ThinClient,
VMWare View Open client, X11, Telnet, SSH. Систему можно загружать по сети с
помощью Etherboot/PXE или внешнего носителя (FDD/CD/HDD/CF/USB-flash). Все
настройки производятся централизованно при помощи конфигурационных файлов, что
упрощает управление терминалами.

Знакомимся: Thinstation

Текущей стабильной версией Thinstation является 2.2.2 (от 10 августа
2008 года). Основу дистрибутива составляет ядро 2.6.16.5, XOrg 6.9/XFree86
4.3.99.902, Glibc 2.3.5, GCC 3.4.4, Вlackbox 0.70.1/IceWM 1.2.25, пакет
системных программ Busybox 1.1.3, набор драйверов для различных видео и сетевых
карт, прикладные программы RDesktop, Telnet, Citrix ICA, NoMachine NX, 2X
ThinClient, VMWare View Open client, SSH, OpenVPN. Помимо указанных пакетов,
есть возможность укомплектовать загрузочный образ дополнительными программами,
драйверами и патчами. Кстати, многие предпочитают использовать более ранние
версии Thinstation , поскольку они занимают меньше места и на старых
системах работают чуть быстрее. Единственный минус: для самостоятельной сборки
загрузочного образа понадобится старая версия Glibc.

Для закачки предлагаются уже готовые LiveCD образы для VMware (Linux и
Windows), которые позволяют обойтись без настройки DHCP/TFTP-серверов и
загружаться "напрямую" в виртуальной машине. После установки в vmview/CD найдем
нужный ISO-файл. При загрузке образ будет опрашивать сменные носители (HDD, CD,
USB, FDD) в поисках настроек — файла thinstation.conf.user (о нем ниже).

Как вариант, можно самостоятельно пересобрать образ при помощи скрипта
rebuild-iso или установить дистрибутив на хард/флешку (пример приведен в FAQ на
официальном сайте).

Архив Thinstation-2.2.2.tar.gz (~50 Мб) предназначен для конечного
пользователя (под пользователем подразумевается сисадмин) и содержит уже
скомпилированные, готовые к работе пакеты. Пользователь затем самостоятельно
выбирает, что ему необходимо, и собирает образ. Доступен еще один архив —
thinstation developer (~800 Мб), – он содержит исходные тексты проекта и
предназначен для разработчиков, а также специалистов, желающих скомпилировать и
добавить свою программу в образ, локализовать систему и произвести остальные
донастройки, которые не удается сделать/применить в пакете для конечного
пользователя.

Русификация в оригинальном Thinstation выполнена лишь частично, хотя
это легко исправить, пересобрав дистрибутив, воспользовавшись стандартными HOWTO
по локализации любого Linux. Но сегодня существуют проекты, в которых вопрос
русификации решен изначально —
nixts.org и
www.itadvisor.ru/downloads . Плюс, в этих решениях произведены мелкие
доработки. По ссылкам можно скачать варианты образов и дополнительные пакеты для
Thinstation . Пользователям платформы AMD Geode LX можно обратить внимание
на ThinTonk (www.tonk.ru/support/pxe)
— дистрибутив Thinstation , собранный специально для этих тонких клиентов.
В дальнейшем будем разбирать оригинальную версию.

Собираем свою версию Thinstation

Для сборки нам потребуется рабочий GNU/Linux, его необязательно устанавливать
на живую машину, достаточно и виртуальной. Забираем архив с сайта проекта и
распаковываем:

$ tar xzvf Thinstation-2.2.2.tar.gz
$ cd Thinstation-2.2.2

Конфигурация для сборки клиента находится в файле build.conf. Ничего сложного
файл собой не представляет, внутри находятся закомментированные строки,
соответствующие модулям (драйверам) и пакетам. Кто хоть раз собирал ядро Linux,
сразу поймет, что к чему. Причем, здесь все на порядок проще. Например:

Если требуется загрузить модуль с внешнего источника или создать динамически
загружаемый драйвер, то вместо "module" пишем "module_pkg". Для удобства все
записи разбиты по группам (видео, сетевые карты и т.п.) и детально
прокомментированы. Зная, какое оборудование установлено на клиентских
компьютерах, можно без труда отредактировать настройки. Смотрим на установки по
умолчанию:

$ cat build.conf | grep -v ^# | grep -v ^$
module pcm # PCMCIA Cards
module serial # Serial Device Support
module acpi # Advanced Configuration and Power Interface support
package rdesktop # X RDP client for Windows Terminal Services (ver 1.5)

В образ, созданный из дефолтного конфига, включена поддержка популярного
железа: сеть — Realtek 8139, SIS900, VIA Rhine, видео — VESA, S3, NVIDIA, ATI,
Vmware; из файловых систем доступны FAT32, NTFS, ext2, ext3. Для первого
знакомства с дистрибутивом этого вполне достаточно, но для применения в рабочей
среде его придется подгонять под себя.

Список параметров внутри достаточно большой, поэтому следует терпеливо и
внимательно пройтись по всем настройкам, разобраться и активировать только то,
что действительно необходимо. Лишнее включать не стоит, это увеличит размер
образа, а значит, система будет дольше распаковываться при загрузке и заберет
больше ОЗУ у клиентов. Чуть ниже в списке идут пакеты, включаемые в образ, –
здесь поступаем аналогично модулям. Если используется директива "package", пакет
будет включен в основной образ; если "pkg" — пакет собирается, но его нужно
подгружать отдельно.

Не забудь снять комментарий со строки "package keymaps-ru" и установить
приложения, при помощи которых будем подключаться к выбранному серверу —
rdesktop, vncviewer, nx, ica и т. д. Последним идет раздел "Miscellaneous
Parameters":

$ sudo vi build.conf

### Пароль root для консоли, доступа по telnet/ssh и VNC-сервису
param rootpasswd p@ssw0rd
param xorgvncpasswd p@ssw0rd
### Настройки логотипа и разрешение экрана
param bootlogo true
param bootresolution 1024x768
#param desktop ./background.jpg
### Файл с установками
param defaultconfig thinstation.conf.buildtime
### Имя машины для config/tftp/scp
param basename thinstation
param basepath .
### Файлы для закачки пакетов с помощью wget, данный параметр активируется, если
подключен нужный package, например, для "package ica" сработает:
param icaurl http://download2.citrix.com/files/en/products/client/ica/current/linuxx86.tar.gz
### HTTP-соединения можно устанавливать через прокси
#param httpproxy http://192.168.1.2:8080

Теперь, когда произведены все настройки, набираем:

По окончании выполнения команды результат сборки ищи в подкаталогах
boot-images/{etherboot, initrd, iso, loadlin, pxe, syslinux}.

Кто не хочет устанавливать Linux просто для того, чтобы создать образ
Thinstation , может воспользоваться онлайн-сервисами, например TS-O-Matics (www.thinstation.net/TSoM).
Для русскоязычных пользователей предназначен ресурс
www.it-advisor.ru/TSoM ,
в котором приложения, входящие в состав Thinstation , изначально
локализованы. Просто заходим, выбираем/вводим параметры, меняем внешний вид
заставки и создаем образ. Правда, с его помощью не удастся добавить в образ свой
пакет, и придется ограничиться только тем, что предлагают разработчики.

Файлы настроек Thinstation

При загрузке клиент Thinstation считывает ряд конфигурационных файлов
(thinstation.conf.*). Параметры, которые в них описываются, в общем-то,
одинаковы, отличается лишь их назначение:

thinstation.conf.buildtime — задает параметры в загрузочном образе, его
нужно подготовить до сборки;
thinstation.conf.network — настройки по умолчанию, получаемые с
TFTP-сервера, этот конфиг используется для установки параметров для всех
тонких клиентов;
thinstation.hosts — содержит данные о клиентах (имя компьютера,
MAC-адрес, группа);
thinstation.conf.group- — совместно с thinstation.hosts
используется для объединения клиентов в группы;
thinstation.conf- — файл для индивидуальной настройки клиента
по имени компьютера, используется совместно с thinstation.hosts;
thinstation.conf- и thinstation.conf- — файл
индивидуальной настройки клиента соответственно по IP- и MAC-адресу;
thinstation.conf.user — конфигурационный файл, сохраняемый на локальных
носителях (FDD, HDD, USB-flash) в подкаталоге thinstation.profile.

При загрузке файлы с TFTP-сервера считываются в таком же порядке, как
показано выше, применяется первый подходящий клиенту загруженный файл.

В архиве имеется очень простой вариант шаблона thinstation.conf.buildtime,
более расширенную версию можно скачать с сайта проекта (thinstation.sf.net/docs/thinstation.conf.example)
или найти в образах, предлагаемых проектами
nixts.org и
www.it-advisor.ru .

Файл thinstation.hosts состоит из описания имени узла, МАС-адреса, группы и
необязательного комментария:

$ sudo vi thinstation.hosts

thinstation1 000c29d7a8e1 boss
thinstation2 000c00a5a8e2 assistant

Типичные network — user файлы выглядят следующим образом:

$ sudo vi thinstation.conf.network

### Не всегда нужна русская раскладка ("ru")
KEYBOARD_MAP=en_us
SYSLOG_SERVER=local
USB_ENABLED=On
### Имя компьютера, если не используется thinstation.hosts, символ "*"
автоматически заменяется на MAC-адрес
NET_HOSTNAME=ts_*
### Описание сессии
SCREEN=0
WORKSPACE=1
AUTOSTART=On
ICONMODE=AUTO
### Подключение при помощи rdesktop (файл может содержать описание нескольких
сессий)
SESSION_0_TITLE="Microsoft Terminal Server"
SESSION_0_TYPE=rdesktop
SESSION_0_SCREEN=0
SESSION_0_RDESKTOP_SERVER=192.168.1.100
SESSION_0_RDESKTOP_OPTIONS="-u user -a 16 -r sound"
### Настройки экрана
SCREEN_RESOLUTION="1024x768"
SCREEN_HORIZSYNC="30-65"
SCREEN_VERTREFRESH="75"
### Можно указать несколько вариантов, но удобнее зафиксировать оптимальный
# SCREEN_RESOLUTION="800x600 | 1024x768 | *"
### USB-мышь, дополнительно нужно активировать "usb-hid" в build.conf
X_MOUSE_DEVICE=/dev/input/mice

В параметрах RDESKTOP_OPTIONS следует учитывать версию сервера. Так, WinNT4 и
Win2k поддерживают только 8-битный цвет (-a 8), WinXP — 16-битный (-a 16),
Win2k3/Win2k8 — 24-битный (-a 24). Хотя использование "-a 24" на терминалах
часто не имеет смысла. Поддержка звука "-r sound" реализована, начиная с Win2k3.
Особого внимания заслуживают директивы STORAGE_PATH, STORAGE_SERVER и
STORAGE_PREFIX, при помощи которых указывается полный путь к сохраняемому
профилю (это может быть локальный диск или смонтированный NFS/SMB-ресурс). производится с жесткого или другого локального
диска, и используется thinstation.conf.user, сборку можно выполнить с
параметрами:

NET_FILE_ENABLED=Off
NET_USE_DHCP=Off

В этом случае не будет осуществляться DHCP-запрос и производиться попытка
получения конфигов с TFTP-сервера, что на порядок ускорит загрузку тонкого
клиента.

Настройка DHCP- и TFTP-сервера

Для загрузки PXE-образа с удаленной машины нам потребуется корректно
работающие DHCP- и TFTP-сервисы. ОС значения не имеет, – это может быть *nix или
Windows, главное, чтобы кто-то корректно ответил на DHCP-запрос, отправленный
сетевой картой, и выдал файлы по TFTP. Первым делом инсталлируем нужные пакеты
(пример для Ubuntu):

$ sudo apt-get install xinetd tftpd tftp

Затем обеспечиваем автозапуск сервисов. Для запуска TFTP через xinetd создаем
конфиг на основе шаблона:

$ sudo cp /etc/xinet.d/time /etc/xinet.d/tftp

$ sudo vi /etc/xinet.d/tftp

service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
### Каталог с PXE-образом
server_args = -s /srv/tftp
disable = no
}

В /etc/xinetd.conf комментируем строку "only_from = localhost". Не забываем
по окончании настроек перезапустить xinetd:

$ sudo /etc/init.d/xinetd restart

Копируем PXE-образ, ядро, initrd и каталог с настройками, созданный по
окончании работы build скрипта, в /srv/tftp:

$ sudo mkdir /srv/tftp
$ sudo cp -vR boot-images/pxe/* /srv/tftp

Проверяем работоспособность TFTP:

$ tftp server.ru
tftp> get pxelinux.0
tftp> quit

Если файл получен, значит, все в порядке. Переходим к настройке DHCP:

$ sudo apt-get install dhcp3-server

В каталоге boot-images/pxe находится готовый шаблон dhcpd.sample, который
можно использовать при создании своего конфига DHCP-сервера:

$ sudo vi /etc/dhcp3/dhcpd.conf

### Описываем нашу подсеть
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
}
### Если в сети объявится клиент с MAC-адресом 00:0C:29:d3:96:9b, назначим ему
IP 192.168.1.150 и подсунем загрузчик PXE
host term1 {
hardware ethernet 00:0C:29:d3:96:9b;
fixed-address 192.168.1.150;
filename "pxelinux.0";
}

Чтобы внесенные изменения вступили в силу, перезапускаем DHCP-сервер:

$ sudo /etc/init.d/dhcp3-server restart

Настройка сервера терминалов в Win2k8

Остался последний шаг — настроить сервис, к которому будем подключаться.
Установка роли службы терминалов производится через ссылку "Добавить роли" в
"Диспетчере сервера". Отмечаем "Службы терминалов", затем в списке необходимые
службы ролей, как минимум, "Сервер терминалов" и "Лицензирование служб
терминалов". Не забываем о новой фиче, которая появилась в Win2k8 – "Веб-доступ
к службе терминалов" (TS Web Access), при использовании которой пользователи
могут подключаться к TS, используя веб-браузер, и получать список доступных
приложений RemoteApp. Чтобы воспользоваться этой возможностью, достаточно при
сборке Thinstation установить Firefox. При выборе метода аутентификации
выбираем "Не требовать проверку подлинности на уровне сети". В этом случае к
серверу смогут подключаться клиенты с любой версией, в частности, не будет
проблем с Rdesktop, который полностью поддерживает лишь RDP 5 (частично
некоторые функции RDP 5.1 и 6), а для Win2k8 "родным" протоколом является RDP 6.
Далее следуем указаниям мастера, выбирая наиболее подходящие параметры. На этапе
"Группы пользователей" добавляем учетные записи пользователей и группы, которым
разрешен доступ к TS. По завершении установки отправляем терминальный сервер в
ребут.

Загружаемся с Thinstation , – по ходу можно увидеть бегущие строчки,
сообщающие о получении IP-адреса и загрузке PXE-образа. После чего вызываем
RDP-клиент щелчком по значку на рабочем столе — это в случае использования
готового образа; если же соответствующие настройки указаны в thinstation.conf,
подключение к серверу будет произведено автоматически, пользователю достаточно
ввести свой логин и пароль.

Дальнейшие настройки службы терминалов производятся в "Диспетчере сервера", в
одноименной вкладке. В частности, здесь можно просмотреть события, которые
помогут разобраться в возникших проблемах. Удачи в терминальных разборках!

Сценарий загрузки тонкого клиента

Сетевуха тонкого клиента по протоколу PXE запрашивает у DHCP-сервера
сетевые настройки.

DHCP-сервер, помимо основных настроек (IP-адрес, маска подсети,
дефолтный шлюз и т.д.), выдает IP-адрес TFTP-сервера и имя образа для
загрузки.

Клиент подключается к TFTP-серверу и сливает файл загрузчика PXE.

Скачанный PXE-загрузчик исполняется и забирает с TFTP-сервера конфиг,
в котором прописаны имена файлов ядра Linux (vmlinuz) и образа файловой
системы (initrd).

После распаковки и загрузки ядра Linux с подмонтированным образом
файловой системы Thinstation снова обращается к TFTP-серверу для
скачивания конфигурационных файлов (с настройками подключений, адресами
терминальных серверов, к которым нужно подключаться, и т.д.). После чего
запускает нужный терминальный клиент (например, rdesktop) и ожидает от
пользователя ввода его логина с паролем для подключения.

Сетевая загрузка для старых машин

Возможность выбора сетевой загрузки в BIOS появилась относительно
недавно, и старые компьютеры такой возможности не имеют. Чтобы не
использовать сменные носители или хард, лучше перепрошить ПЗУ сетевой карты.
Готовый образ можно взять на сайте
rom-o-matic.net .
Достаточно выбрать в "Choose NIC/ROM type" марку чипа, используемого на
сетевой карте, и в списке "Choose ROM output format" формат файла. Кроме
версий для ПЗУ (.rom), имеются образы для записи на дискету, болванку и
USB-flash, а также для использования с загрузчиками LILO/GRUB/SYSLINUX. Если
с сетевой картой не повезло, и ее прошивку обновить нельзя, то можно
попробовать перепрошить BIOS материнской платы (если он на
Flash-микросхеме), интегрировав в него PXE-код, взятый с сайта
rom-o-matic.net.

Локализация Thinstation

Оригинальный Thinstation локализован лишь частично, и, скорее
всего, возникнет желание устранить эту проблему. Для этого как раз необходим
девелоперский пакет. Первым делом следует пересобрать ядро, активировав в
разделах DOS/FAT/NT Filesystems, Network File Systems и Native Language
Support все модули, в которых фигурируют кодировки CP1251 и 866. Далее ищем
в packages/base/etc/udev/scripts три скрипта floppy.sh, ide.sh, usb.sh,
отвечающие за монтирование файловых систем. Добавляем запись "-o iocharset=cp1251,codepage=866"
к командам внутри sh-файлов. Например, строка для FAT:

mount -t vfat -o iocharset=cp1251,codepage=866 /dev/$devpath /mnt/disc/$name/$name

В поставке есть и другие скрипты и конфигурационные файлы, которые
потребуется поправить в случае необходимости. Для Samba в smb.conf.tpl и
smb.conf также меняем кодировку:

unix charset=cp1251
display charset=cp1251
dos charset=866

Локаль следует указать и в строке запуска rdesktop, например, для
ru_RU.KOI8-R добавляем "-P KOI8-R".

INFO

Тонкие клиенты не требовательны к железу (поскольку все вычисления выполняет
мощный сервер) и заточены для работы в бездисковом режиме (без FDD/CDROM/HDD).

В качестве тонкого клиента под управлением Thinstation может выступать
любой компьютер на базе архитектуры x86 с процессором не ниже Pentium 100 и
объемом оперативной памяти не менее 16 Мб.

Как правило, на терминальных серверах используется общесистемное программное
обеспечение Windows, Linux, xBSD, Solaris, а тонкие клиенты функционируют под
управлением Windows CE, Linux или xBSD.

Thinstation — мини-дистрибутив Linux, позволяющий превратить старые
компы в полноценные бездисковые тонкие клиенты, поддерживающие все основные
протоколы подключения: RDP, VNC, ICA, X11, Telnet, SSH и т.п.

Thinstation можно загружать по сети с помощью Etherboot/PXE или со
стандартного носителя — FDD/CD/HDD/CF/USB-flash.

PXE (Pre-boot eXecution Environment) - среда предзагрузочного выполнения.

О том, как настроить сервер терминалов в Win2k3, можно узнать из статьи " ", опубликованной в

за 2007 год.

WARNING

Службы DHCP и TFTP должны функционировать на одной машине!

При выходе из строя сервера или неполадках в сети тонкие клиенты превращаются
в бесполезные ящики.

С понятием тонких клиентов многие из пользователей сталкиваются чуть ли не каждый день, правда, совершенно не отдавая себе отчета в том, с чем они имеют дело. На самом деле ничего в понимании того, каким образом работают тонкие клиенты, нет. Достаточно посмотреть на свой компьютер и установленное на нем программное обеспечение. Далее предлагается рассмотреть несколько возможных ситуаций, связанных с понятием тонких клиентов в операционной системе. И необязательно это должны быть ОС семейства Windows. Принципы, по которым производится установка и настройка тонкого клиента, для всех систем одинаковы.

Что такое тонкий клиент по своей сути?

Вообще, если посмотреть на некое официальное обоснование, под тонким клиентом подразумевается либо компьютерная система с ограниченными возможностями, либо программное обеспечение, которые взаимодействуют с удаленными серверами.

Чтобы было немного понятно, тонкие клиенты на пользовательских терминалах можно представить даже в виде обычного веб-браузера. Вся компьютерная система является так называемым толстым клиентом, а при формировании и подаче запроса серверу в интернете используется прослойка в виде тонкого клиента (как раз интернет-обозревателя).

С другой стороны, тонкие клиенты можно описать и как компьютерные терминалы с минимальной конфигурацией и отсутствием на них жестких дисков, но подключенные к локальной сети, когда загрузка операционной системы с центрального сервера производится на каждый компьютер при помощи специальных сетевых протоколов. То же самое касается и некоторых типов прикладного программного обеспечения.

Схема «сервер - тонкий клиент»: как это работает?

Собственно, суть вопроса сводится к тому, чтобы при отправке запроса на сервер он идентифицировал запрос, подтверждал его и отправлял ответ на клиентскую машину.

Тут абсолютно неважно, какая используется схема подключения Главное - четкая переадресация. Пояснить это можно на примере загрузки ОС с центрального сервера на клиентские терминалы, не имеющие винчестеров.

Загрузка операционных систем

Но как же операционная система может загружаться на компьютер без жесткого диска? Элементарно! Современные соединений могут использовать протоколы вроде RIS, DHCP, PXE, RDP и другие.

Получается, что фактически операционной системы на удаленной клиентской машине нет, но терминал может работать с ОС, установленной на сервере, при этом частично используя и его вычислительные возможности, и конфигурации компьютеров в окружении. Таким образом, сами тонкие клиенты этого типа получают распределенную по всей сети нагрузку на компьютерные ресурсы, а быстродействие ОС от этого не страдает. Плюс еще и в том, что администрирование клиентских машин в плане физического вмешательства в настройки ОС на каждой из них совершенно необязательно. Сделать это можно с администраторского компьютера или сервера посредством самого обычного удаленного доступа. В данном случае речь идет о том, что используется тонкий клиент на Windows (RDP), который в седьмой версии и выше является встроенным.

Система «тонкий клиент»: требования

Если речь идет именно о компьютерных терминалах, для работы тонкого клиента любого типа обычно достаточно самого простенького процессора и всего-то 1 Мб оперативной памяти.

В случае когда используется какая-то интернет-среда (например, Office 365), в обязательном порядке необходимо наличие хоть какого-то веб-браузера и достаточно высокой скорости подключения. С «Офисом», кстати, ситуация выглядит достаточно интересно. Дело в том, что этот интернет-проект использует возможности, присущие большинству программ этого типа с возможностью одновременного доступа и редактирования отдельно взятых документов, пусть даже сохраненных в облачном хранилище.

Пример установки и настройки приложений 1С

Однако посмотрим, что собой представляет установка тонкого клиента на примере программных продуктов 1С.

Требование тут самое простое: серверная часть находится на центральном терминале, клиенты - на остальных машинах в локальной сети. Только в данном случае использование подключения через обычно применяется на уровне TCP/IP, HTTP или HTTPS, а на терминалах устанавливаются жесткие диски минимального объема для инсталляции клиентской части программы.

Приблизительная схема по настройке может выглядеть следующим образом:

загрузка и инсталляция клиентов 8.2 и 8.3;
публикация базы данных на сервере;
добавление базы в список доступных;
установка подключения типа «веб-сервер».

Кстати, стоит отметить, что клиентские машины могут только получать доступ к центральной программе или выполнять какой-то минимальный набор разрершенных действий.

В формировании отчетности они участия не принимают, а вся нагрузка ложится исключительно на серверный ПК.

Подключение и лицензии

Тонкие клиенты хороши еще и тем, что для них можно устанавливать сертификаты и лицензии, используемые для коммерческого программного обеспечения, несколькими методами, что существенно снижает затраты на их официальное приобретение. В качестве основных правил можно использовать либо установки одной лицензии для отдельно взятой машины, на которой зарегистрировано несколько пользователей, либо приобретение лицензий для определенного количества пользователей, которые имеют доступ к разным компьютерным терминалам, то есть при входе под своей регистрационной записью могут работать с программой-клиентом на любом компьютере в локальной сети.

Выгоды и преимущества

Если посмотреть на преимущества, которые получает организация или предприятие при использовании тонких клиентов, они в основном сводятся к нескольким вещам. Во-первых, наблюдается существенная экономия затратных средств на приобретение необходимого «железного» оборудования или программного обеспечения. Во-вторых, сразу же отпадает проблема администрирования пользовательских терминалов, находящихся в локальной сети. Как уже говорилось выше, сделать это можно просто с центрального сервера. В-третьих, появляется возможность использования на всех сетевых машинах одной операционной системы и одинакового ПО. Правда, на самом сервере должна быть установлена именно серверная версия ОС, хотя некоторые системные администраторы при небольшом количестве дочерних терминалов умудряются пользоваться даже обычными стационарными модификациями.

Но есть и свои проблемы. Например, при выборе топологии подключения не по схеме «звезда», компьютеры, соединенные последовательно или подключенные к одному центральному кабелю, могут стать причиной выхода из строя всей сети, если хотя бы на одном из них появляются проблемы и ошибки. В остальном же использование тонких клиентов оправдано, как говорится, на все сто. Правда, в домашних условиях применять такие технологии смысла нет. А вот на предприятиях и в офисах иногда это становится крайней необходимостью.