Тонкие клиенты: установка и настройка. Как сделать тонкий клиент из старого компьютера

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

Подробное руководство по настройке
тонких клиентов на основе дистрибутива 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
Собираем "толстый" (полный) образ
Загружаем тонкий клиент на толстом образе
Получаем список необходимых для этого клиента модулей ядра и пакетов
Исправляем конфиги сборки, оставив только самое необходимое (в том числе полученное на предыдущем этапе)
Собираем "тонкий" (облегченный) образ

Подготовка кухни

Сразу скажу, что есть и другой путь сборки - скачивание подготовленного.iso образа. Но мне это кажется не таким удобным, поэтому я буду описывать "правильный" вариант.

Скачивание репозитория

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

Всё остальное сейчас не важно - настраивать тонко будем потом.

Отдельно остановлюсь на том, зачем нужно поменять систему сжатия со squashfs на gzip . Скрипт hwlister.sh , о котором пойдет речь ниже, использует очень интересную методику поиска загруженного firmware - он просто смотрит время доступа к файлам в /lib/firmware и на основе этого делает выводы, какие файлы были загружены. Но squashfs монтируется с параметром relatime , что приводит к тому, что время доступа к файлам не меняется и список firmware (чёрт, не знаю, как перевести это слово, не потеряв смысл) всегда пуст. Изменение режима сжатия на gzip - самый простой и быстрый способ вернуть скрипт к жизни не залезая в кишки. Я написал об этом разработчикам, но ответа пока не было.

Сборка

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

После того, как процесс завершится, в директории boot-images можно будет найти варианты образа - iso, pxe и syslinux. Можно использовать любой и загружать клиент любым удобным способом.

Сбор информации

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

Это обычный bash-скрипт, после выполнения которого вы обнаружите несколько файлов:

/firmware.list - список необходимых firmware
/module.list - список необходимых модулей ядра
/package.list - список необходимых пакетов, учитывая архитектуру будет содержать только xorg7-* пакеты
/vbe_modes.list - если используется uvesafb , этот файл будет содержать список поддерживаемых режимов

Некоторые файлы могут отсутствовать, если ничего подходящего не найдено

Этот же скрипт попытается загрузить файлы на ваш tftp-сервер, указанный в конфиге, однако, надеюсь, у вас запись на tftp, как и у меня, запрещена. Поэтому забираем файлы с тестируемой системы любым способом и кладем в директорию ts/build/machine/MACHINENAME , где MACHINENAME - кодовое имя, которое вы дадите своему железу.

Тонкий образ

Сборка тонкого образа - это всегда балансирование на границе между функциональностью и объемом. Меньше объем - быстрее загрузка бездисковых рабочих станций по сети, быстрее старт системы, меньше оперативной памяти требуется клиентам. Лично у меня стояла задача сделать образ минимального объёма всего под одну задачу - терминальный RDP-клиент. Об этом я и буду рассказывать.

Итак, у нас есть офис, набор тонких клиентов, подключенных проводами, получающих адрес по DHCP, загружающихся по PXE и стартующих одно единственное приложение - RDP-клиент.

Конфигурация сборки - build.conf

Как я уже писал выше, первый этап в конфигурации сборки - это правка файла build.conf . Он определяет какие пакеты будут включены в образ и некоторые другие параметры сборщика.

Все строки начинающиеся с machine - комментируем. Должно остаться только то, что используется у вас. Нужно отметить, что в конфигурации можно держать активными сразу несколько профилей - тогда получится образ, запускающийся на любом из них (в теории, если нет конфликтов).
Скорее всего вам не понадобятся файловые системы кроме vfat и ntfs - поэтому в блоке файловых систем можно смело комментировать строки isofs , udf , ext* .
Так как мы создали профиль для своего железа, содержащий необходимые пакеты xorg7 , то все строки содержащие package xorg7-* - можно смело комментировать.
Смело комментируем все пакеты локалей package locale-* кроме, конечно ru_RU , и, по желанию, en_US - нужна она или нет вопрос спорный.
Если вам нужен удаленный доступ к рабочим станциям - включите package sshd
Если вам нужны смарт-карты и USB-токены - включите package ccidreader
Если вы собираетесь вырезать оконный менеджер, рабочий стол и показывать пользователю только одно приложение (например FreeRDP) - включите пакет package automount для автоматического монтирования любых USB-устройств. При этом package udisks можно смело выключить.
Если вам не нужен интерфейс для Wi-Fi соединений и другие рюшечки - закомментируйте package networkmanager и включите package autonet . Но будьте готовы к тому, что придется покопаться в его внутренностях - это скриптовая обвязка для системных утилит и в некоторых сетях может работать не совсем так, как ожидается.
Чтобы максимально облегчить образ, включаем package openbox и выключаем package gtk-* , package icons-* , package fonts-* .

Что касается пакетов в разделе Applications - здесь выбор полностью за вами. Всё описанное выше применимо к тонким клиентам, где пользователь не будет видеть своего рабочего стола (RDP, VNC, etc) и для использования, например, локального браузера - многое из перечисленного выше придется оставить.

Остается не забыть вернуть param initrdcmd "squashfs" и убрать 3 строки в самом конце: package alltimezone , param allres true и param allfirmware true - в тонком образе это нам не пригодится.

Runtime-конфигурация - thinstation.conf.buildtime

Файл thinstation.conf.buildtime является по своей сути bash-скриптом, предоставляющим переменные окружения для всех скриптов запуска. Перед тем, как начать его редактировать, стоит заглянуть в директорию ts/build/conf (github) - здесь собраны кусочки конфигураций для каждого пакета, включающие в себя пояснения и все доступные переменные.

Давать какие-то универсальные советы - сложно. Настройка будет зависеть от вашего окружения и используемых пакетов. Приведу лишь пример для RDP-сессии.

# У пользователя не будет локального UI, так что локально выкручиваем громкость на максимум AUDIO_LEVEL = 100 MIC_LEVEL = 100 # Для бездисковых станций резонно собирать логи в одном месте SYSLOG_SERVER = syslog.example.com # Локаль и таймзона LOCALE = ru_RU.UTF8 TIME_ZONE = Europe/Moscow # Кнопки "Безопасного извлечения устройства" также не будет - поэтому включаем обязательно USB_STORAGE_SYNC = ON DISK_STORAGE_SYNC = ON # Монтировать устройства нужно в директорию, которую мы потом пробросим в удаленную сессию USB_MOUNT_DIR = /mnt/usb # Для поддержки кириллицы на съемных накопителях, я для себя вывел вот такой набор параметров. Он точно подходит для FAT32/NTFS разделов и FreeRDP USB_MOUNT_OPTIONS = DISK_MOUNT_OPTIONS = "rw,nosuid,nodev,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro" # Если выключили NetworkManager и включили autonet - обязательно настройте сеть NET_USE_DHCP = ON # Нулевая сессия должна быть оконным менеджером # Можно попробовать обойтись без него и даже вообще без Иксов # но это тема для отдельной статьи SESSION_0_TITLE = Desktop SESSION_0_TYPE = openbox SESSION_0_AUTOSTART = ON # Главная рабочая сессия # Список параметров FreeRDP - пожалуй также повод для отдельной статьи SESSION_1_TITLE = RemoteDesktop SESSION_1_TYPE = freerdp SESSION_1_AUTOSTART = ON SESSION_1_FREERDP_SERVER = rdp.example.com SESSION_1_FREERDP_OPTIONS = "+decorations +fonts +aero ..."

Сборка тонкого образа

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

И это всё. В зависимости от того, что вы указали в build.conf , вы получите готовые образы для загрузки по PXE, с CD-ROM, жесткого диска или флешки. При описанной конфигурации можно добиться образа размером ~90 MB и времени загрузки по PXE (от включения питания до рабочего стола) около 1 минуты. С локального диска и того быстрее.

Другие возможности

Нужно отметить, что всё, о чем я писал выше - советы по сборке универсального образа. Я добился того, чтобы с одного образа можно было загрузить любой ПК из присутствующих в зоопарке компании. Но может получиться так, что вам понадобится сделать несколько вариантов клиентов, с разными настройками или, например, разными адресами серверов. В таком случае обратите внимание, что ThinStation умеет как скачивать дополнительные конфигурационные файлы во время загрузки, так и докачивать дополнительные модули. Это очень хорошо описано в документации, и я на этом останавливаться не буду.

Полезные заметки

Очистка кухни

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

Не забыть выйти из chroot
Убедиться, что сохранили все свои изменения в Git
Отмонтировать все системные ФС внутри кухни: umount -R thinstation/*
Запустить скрипт очистки: sudo ./setup-chroot -a
Удалить всё, что осталось: git clean -dx - это удалит все несохраненные файлы

Добавление своих пакетов

Если вы собираетесь привносить в проект что-то свое, нужно знать о том, что в терминологии ThinStation, а вернее в терминологии CRUX Linux, на котором базируется TS, существует два базовых понятия:

package (далее "пакет") - некая абстракция, указывающая на то, что необходимо установить в будущий образ. Пакет может содержать кусок дерева файловой системы, отдельные файлы, или даже просто один конфигурационный файл, указывающий, например на зависимости.
port (далее "порт") - подобие *.deb иди *.rpm пакета, с одним важным отличием: архив со скомпилированными файлами не содержит правил установки, а представляет из себя просто кусок дерева файловой системы. Любые правила (скрипт компиляции, скрипты пост-установки, и т.д.) лежат рядом с архивом и легко редактируются.

Когда вы хотите дополнить образ чем-то своим, первое, о чем стоит задуматься, а что именно вам нужно? Если вы хотите добавить в образ пару текстовых конфигов - просто создайте свой пакет, включите его build.conf - и этого будет более чем достаточно. Если же вам нужно собирать бинарные файлы - то вам понадобится сделать свой порт.

Создание своего порта

Prtdir /ts/ports/yourproject

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

Теперь вам понадобится создать один единственный bash-скрипт, который будет отвечать за сборку порта: /ts/ports/yourproject/portname/Pkgfile . Образец можно посмотреть , а можно подсмотреть в любом другом порте. Базовый вариант выглядит так:

Name = mdetect-TS version = 0 .5.2.3 release = 1 source =(http://ftp.de.debian.org/debian/pool/main/m/$name /$name -$version .tar.bz2) build() { cd $name -$version ./configure --prefix= /usr \ --exec-prefix= / \ --sysconfdir= /etc \ --mandir= /usr/man \ --disable-extras make make DESTDIR = $PKG install }

Давайте разберемся, что он делает (на самом деле делает не он, он лишь определяет стадию сборки):

Скачивает файлы, заданные в source (в данном случае - http://ftp.de.debian.org/debian/pool/main/m/mdetect-TS/mdetect-TS-0.5.2.3.tar.bz2), их может быть несколько
Распаковывает все скачанные файлы в рабочую директорию
Выполняет configure + make
Делает make install из директории /ts/ports/yourproject/portname/work/src в /ts/ports/yourproject/portname/work/pkg
Полученное содержимое директории pkg упаковывается в архив. Это и будет наш порт, готовый для установки.

Проверим наши предположения. Чтобы выполнить первую сборку, необходимо сделать следующее:

[ _chroot]/# cd ts/ports/yourproject/portname/ [ _chroot]/ts/ports/yourproject/portname# pkgmk -kw =======> Building "/ts/ports/yourproject/portname/portname#0.5.2.3-1.pkg.tar.xz".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часть первая: Немного лирики

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

Давайте представим себе среднестатический офис небольшой торговой фирмы с точки зрения IT:

несколько десятков слабеньких компьютеров для секретаря, менеджеров, бухгалтерии и, конечно, главного Босса;
одна-две-три машины, выполняющих роли:
- домен-контроллера windows (нередки случаи, когда в сети компании отсутствует даже домен, а все компьютеры работают в одно-ранговой сети);
- файлового сервера;
- почтового сервера (вместо него иногда используют внешние бесплатные почтовые сервера, начиная от mail.yandex.ru и gmail.com и кончая десятидолларовым хостингом на N почтовых ящиков);
- http-прокси для фильтрации доступа ко внешним ресурсам и логирования «куда кто ходит» (часто отсутствует)
- маршрутизатора/файрвола на границе с внешней сетью для ограничения доступа наружу и наоборот (часто в качестве пограничного маршрутизатора используется любой SOHO-роутер начального уровня ценой до 100 долларов, он же выполняет роль DHCP сервера (для динамической раздачи IP адресов рабочим станциям сотрудников);
- другие вещи, список которых может быть довольно большим;
несколько принтеров, часто подключенных локально к рабочим станциям сотрудников и расшареных по сети стандартными средствами Windows (как вариант, принтеры могут быть сетевыми изначально или же подключены через аппаратные принт-сервера).
в продвинутых случаях - один терминальный сервер (под Windows) для бухгалтерии (на нем крутится 1C а там же лежит база данных оной, а бухгалтеры, подключаясь к серверу терминалов через стандартные средства Windows (remote desktop), работают с ней на терминальном сервере (локально), что, во-первых, дает больше удобства, а во-вторых, ускоряет работу самой 1C (обычно же 1С с базой установлена на компьютере одного из бухгалтеров, а остальные подключаются к ней со своих компьютеров, работая с расшареной по сети базой).

Все это хозяйство связано в единую локальную сеть посредством одного/нескольких дешевых коммутаторов на 100Мбит. И работает это в едином домене NT/Active directory (хотя встречаются варианты одноранговых рабочих станций безо всяких доменов).

На всех машинах с Windows обычно установлен (хотя и тут бывают исключения) какой-то антивирус. Часто встречается не сетевые версии этих программ (тот же Avast), хотя, опять таки в более продвинутых (с точки зрения IT) конторах, стоят сетевые версии антивирусов с централизованным управлением и обновлением антивирусных баз.

Приведенные выше ситуации варьируются от случая к случаю, так как на конфигурацию сети, железа и софта влияют как знания/умения/желания (и, что немаловажно, лень) системного администратора(ов), так и понимание начальства (в лице главного Босса) «чем же именно этот наш системный администратор занимается, когда все и так отлично работает» (из последнего вытекает - сколько денег выделяется на оборудование для IT и зарплату будущего специалиста). Если денег выделяется мало (а так обычно и бывает управленцы торговых компаний от IT обычно далеки и слабо понимают, что же там происходит), то поднабравшийся знаний эникейщик уходит в другую компанию. На место ушедшего приходит очередной студент и все повторяется по новой.

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

В результате, в небольших компаниях часто наблюдается довольно разнообразный парк пользовательских машин класса от pentium2/128Mb ram/5Gb hdd до P4 Celeron/1Gb ram/80Gb hdd. На всех машинах, разумеется, Windows (98, 2000 и XP Home/Pro) и разные версии софта (ставили то машины в разное время). Доходит до того, что и антивирусное ПО на машинах тоже от разных производителей.

А на нелегкую долю системного администратора (и эникейщика по совместительству), выпадает денно и нощно поддерживает весь этот зоопарк. А ведь железо иногда ломается:

вентиляторы начинают противно жужжать (их надо чистить и смазывать или же менять на новые);
блоки питания выходят из строя;
винчестеры - сыпятся;
сетевые карты (как встроенные в материнскую плату, так и внешние - перестают работать и требуют замены);
остальное железо, обычно, летит сильно реже, но тем не менее летит тоже

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

ставим Windows;
ставим необходимые драйвера (весь парк железа разный - не забыли?), предварительно определив модель материнской платы в данной машине и скачав из Интернет последние версии драйверов или найдя нужные у себя на файл-сервере;
вводим машину в домен (если он настроен);
ставим необходимый софт (офис, браузер, почтовый клиент, тотал-коммантеры, аськи, джабберы, пунто-свитчеры и подобное) - в случае домена Active Directory часть софта можно поставить автоматически, но не у всех он настроен, да и не все знают его возможности;
ставим антивирус;
плюс дополнительные танцы с бубном, индивидуальные для конкретной сети каждой организации вокруг новой рабочей станции;

После успешного выполнения всех пунктов (эта процедура занимает примерно два часа) рапортуем Боссу, что рабочее место сотрудника спасено и он может приступать к работе.

Счастливый обладатель восстановленного компьютера садится за свое рабочее место, после чего выясняется, что (так как доменные профили были не перемещаемые или же домена не было вовсе, ссылка «мои документы» вела на локальный диск C:, а про то, что все важное нужно сохранять на сетевом диске - на сервере, сотрудник забыл):

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

Знакомо? Хорошо, если полетел не жесткий диск, а всего лишь материнская плата. Или же часть информации на осыпавшемся диске поддается восстановлению. Но все эти процедуры занимают рабочее время системного администратора, которое можно было бы потратить с куда большей пользой поиграть в сетевую стрелялку или же… изучить IPv6 - ведь уже все на него переходят и совсем скоро перейдут, адреса в пространстве Ipv4 уже лет пять как закончились:)

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

переустановить Windows;
настроить на новой машине весь необходимый софт;
восстановить все то, что потерялось;
доустановить нуждающимся новые программы;
провести профилактику корпуса (пыль пропылесосить в системном блоке);

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

Как же выйти из этого замкнутого круга?

Одним из вариантов решения вышеописанной проблемы, является отказ от «толстых» рабочих станций (там, где это можно сделать) и переход на .

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

Надо понимать, что требования современных ОС (не обязательно Windows) идут в ногу с современным железом - другими словами, для относительно комфортной работы в Windows XP старой (но полностью работоспособной и относительно мощной) машины класса Celeron 800Mgz/128Mb Ram/ 10Gb HDD может и не хватить. Работать под современной ОС на подобном железе, конечно, можно, но подтормаживать эта операционка и приложения будут довольно часто хотя бы из-за малого количества набортной памяти и старого (читай медленного) жесткого диска.

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

Обычно тонкие клиенты делают на основе слабого (а, соответственно, и малопотребляющего) железа - часто это единая системная плата, на которой все и интегрировано. Процессор и память так же могут быть намертво припаяны к материнской плате. Некоторые тонкие клиенты имеют flash-диск (вставляемый в IDE разъем материнской платы), на котором прошита специализированная ОС (WinCE или другие).

Сравнение тонкого клиента Clientron U700 со стандартным корпусом для рабочей станции.

В результате, при включении тонкого клиента (их еще называют терминалами), ОС грузится со встроенного flash-диска (обычно на загрузку уходит менее 30 секунд), после чего на экране появляется диалог подключения к терминальному серверу. Некоторые из этих клиентов умеют подключаться только Windows Terminal Server или же Citrix Metaframe, другие - в том числе и к терминальным серверам других ОС. В любом случае, в цену таких решений закладывается и цена лицензии на WindowsCE, прошитую на встроенный flash-диск. Мы рассказывали о подобных решениях ранее:

Windows-терминал
Тонкий клиент
Windows-терминал

Разумеется, подобные решения существуют и у других компаний. В том числе и без встроенной ОС (за которую, в случае Microsoft Windows CE, нужно дополнительно платить, да и flash-диск копейки, но стоит).

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

Несомненные плюсы терминальных решений на специализированных тонких клиентах или правильных самосборных компьютерах:

отсутствие жесткого диска (которые греются и ломаются);
отсутствие вентиляторов (на процессоре и блоке питания установлены лишь радиаторы, которых хватает для рассеивания выделяемого при работе тепла);
низкое энергопотребление;
теоретическая дешевизна (при самосборе можно подобрать очень дешевые комплектующие ведь производительности от железа не требуется; а вот производители за специализированные тонкие клиенты попросят раза в два больше)
минимальные временные затраты на обслуживание (при поломке такой железяки, достаточно отключить поломавшуюся и подключить запасную работы на пять минут; а это уже минимальный простой для рабочего места сотрудника, а так же минимум затраченного на устранение поломки времени системного администратора)
весь софт для работы пользователей настраивается централизовано на одном (двух/трех/…) терминальных серверах это значительно проще, чем поддерживать зоопарк софта на «толстых» рабочих станциях сотрудников

Не стоит забывать и о пользовательских данных локально терминал ничего не хранит (все данные пользователя находятся на удаленных серверах). В результате легко настроить автоматических бекап всего и вся и, в случае чего, восстановить «случайно удаленный» документ.

В общем, плюсов море, но есть и минусы:

при отказе сети, рабочие места сотрудников «превращаются в тыкву» (а сотрудники на «толстых» клиентах могут продолжать набивать документ, к примеру, в OpenOffice);
при отказе терминального сервера рабочие места сотрудников опять «превращаются в тыкву» (но это решается установкой нескольких - например, двух - терминальных серверов; при выходе одного из них из строя, второй его подменит или же сотрудники просто переподключатся ко второму серверу вручную)
тонкие клиенты подходят не всем: к примеру, людям, постоянно смотрящим видео или работающим активно работающих с графикой (в фотошопе) или занимающимся версткой журнала, лучше делать это на локальном «толстом» клиенте (зато тонкие клиенты отлично подходят большинству остальных сотрудников, которым нужен лишь браузер с Интернет, почта, создание и редактирование документов в Openoffice и работа с 1C).

Последний минус, который мы тут рассматривать не будем это лицензионная политика (если не сказать обдираловка) со стороны Microsoft. Работа на терминальном сервере под управлением ОС этой известной компании требует большого количества разнообразных лицензий:

лицензия на Windows Server
CAL (Client Access License) лицензии на подключение к Windows-серверу и их кол-во должно быть не меньше количества подключаемых к серверу клиентов (обычно в составе Windows-сервера уже идет некоторое кол-во таких лицензий от пяти и выше)
лицензии на работу с сервером терминалов (их количество тоже должно быть равно количеству подключаемых клиентов)

Не забываем про отдельные лицензии на весь используемый софт (например на Microsoft Office) в количестве, равном количеству подключаемых к серверу клиентов. Если клиентские лицензии на Microsoft Office еще можно обойти, отказавшись от данного продукта и поставив ему замену в виде, к примеру, OpenOffice, то от самого терминального сервера в лице Windows 2000/2003 TS избавиться несколько сложнее:) Хотя и это возможно в некоторых случаях.

Есть, правда, еще один «минус» (кроме боязни нового) который часто останавливает от внедрения подобных решений - почему то многие думают, что эти тонкие клиенты надо покупать (а они не очень дешевые - от 200 долларов и выше). Куда же девать весь парк уже существующих компьютеров?

Именно для ответа на последний вопрос написана данная серия статей. В ней будет рассматриваться софт тонкого клиента .

Этот небольшой, но обладающий множеством возможностей и, что немаловажно, OpenSource софт, позволяет превратить практически любые древние компьютеры в тонкие клиенты. Минимальные описанные на его родном сайте к используемому железу - это Pentium 100Mhz и 16Mb оперативной памяти. Ах да, жесткий/flash диск тоже не нужен - компьютеры при включении могут скачивать образ тонкого клиента (это около двадцати! мегабайт) по сети (хотя так же возможна установка Thinstation клиента на жесткий или usb диск). В наш век операционных систем, с радостью сжирающих гигабайты места на диске после установки, это впечатляет, не так ли?

Thinstation базируется на Linux, но для его использования знаний Linux, как таковых не нужно - достаточно в своей сети поднять dhcp и tftp сервера и соответствующим образом их настроить (оба этих сервера есть и в составе продуктов Windows Server). Таким образом, даже в сети, где кроме Windows-а ничего не знают, использование Thinstation клиента затруднений не вызовет.

Thinstation умеет работать со следующими серверами терминалов:

Сервера Microsoft Windows по протоколу RDP или через nxclient (Windows NT4TSE, W2k Server, W2k3 Server или же Windows XP в однопользовательском режиме);
Citrix servers по протоколу ICA (на серверах MS Windows, SUN Solaris и IBM AIX);
Сервера Tarantella
*nix-like сервера по протоколу X11;
подключение к VNC-серверам (tightVNC);
подключение к SSH и Telnet серверам;

Для того, что бы загрузить Thinstation по сети, от компьютера требуется лишь встроенная или внешняя сетевая карта, поддерживающая стандарт PXE (есть и другие варианты, но, к примеру все встроенные в системную плату сетевые карты работают именно по этому протоколу).

PXE расшифровывается как Pre-boot eXecution Environment среда предзагрузочного выполнения. Этот стандарт был впервые реализован компанией Intel. Первый признак наличия PXE-биоса на борту встроенной сетевой карты, это пункт «Enable Boot ROM» рядом с пунктом активации сетевой карты в биосе. Если встроенная сетевая карта не поддерживает загрузку по сети (или отсутствует вовсе), можно использовать любую внешнюю сетевую плату с опцией «Boot ROM» (этот вопрос в подробностях будет рассмотрен далее).

А сейчас вкратце рассмотрим процесс загрузки клиента Thinstation по сети.

Сетевая карта по протоколу PXE запрашивает DHCP сервер следующую информацию: IP адрес, маску подсети, шлюз а так же IP-адрес сервера TFTP (на котором лежат образы, в данном случае, ThinStation) и имя образа, которое она попытается загрузить.
DHCP сервер возвращает запрашиваемую информацию (помечая у себя, что выданный клиенту IP адрес занят таким-то клиентом)
Клиент подключается к TFTP серверу, IP-адрес которого ему только что сообщили и скачивает с него файл загрузчика PXE (имя которого ему опять таки сообщил DHCP-сервер)
Скаченный PXE загрузчик исполняется и, в свою очередь скачивает с TFTP сервера конфигурационный файл, в котором прописаны имена файлов ядра ОС Linux vmlinuz и образа файловой системы initrd. Эти файлы скачиваются и управления передается ядру Linux
После распаковки и загрузки ядра Linux с подмонтированным образом файловой системы, Thinstation снова обращается к TFTP серверу для скачивания необходимых ему конфигурационных файлов (там, среди прочего, записаны адреса терминальных серверов, к которым нужно подключаться), после чего запускает нужный терминальный клиент (в нашем случае это будет rdesktop) и ожидает от пользователя ввода его логина с паролем для подключения.

На первый взгляд, описанная схема выглядит сложно. Но по факту настройка оной занимает полчаса-час и в дальнейшем она работает полностью автономно. Загрузка тонкого клиента с момента первого запроса в сеть по PXE (этот момент совпадает с моментом начала загрузки ОС с жесткого диска) занимает секунд 20…30.

Как уже отмечалось выше, Thinstation умеет работать с разными терминальными серверами. Но мы в ближайших статьях, как самое простое в реализации (но еще раз напоминаю о покупке множества клиентских лицензий, необходимых для официальной работы), рассмотрим лишь связку Thinstation с Microsoft Terminal Server.

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

Вторым пунктом нашей программы будет настройка DHCP и TFTP серверов. Первый ведает динамической раздачей IP адресов для рабочих станций, а так же сообщает, с какого IP адреса (с какого сервера tftp) и какое имя файла компьютеру нужно скачать в качестве загрузочного образа тонкого клиента. А второй tftp сервер фактически и отдает образы тонкого клиента и конфигурационные файлы для них же. Эти настройки могут быть как глобальными (для всех бездисковых терминалов сети), так и локальные для определенных групп машин или же одиночных тонких клиентов.

Оба эти сервиса можно поднять как в составе Windows сервера (запуском и настройкой соответствующих служб), так и отдельными демонами в составе *nix-сервера мы это рассмотрим на примере сервера с установленным Gentoo Linux.

А третьим пунктом идет настройка клиентских машин перевод их на загрузку по сети и рассмотрение стандартных подводных камней.

Но об этом в следующих статьях нашего цикла.

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

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

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

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

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

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

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

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

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

Рисунок 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

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

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

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

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

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

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

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

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

n 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 с адреса . Еще понадобятся два патча, качаем их отсюда . Каталог нашей сборки примет следующий вид:

n freenx-0.4.4

n nx-X11

n nxcomp

n nxcompext

n nxdesktop

n nxproxy

n nxscripts

n nxviewer

n freenx-lfs_hint.diff

n NX-lfs_hint.diff

# Накладываем 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

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

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 < ../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

# Если хотите использовать аутентификацию пользователей с помощью ключей, уберите параметр –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

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

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

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

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;

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

Рисунок 3. Файлы настроек тонких клиентов Thinstation

otd146_57158 00e04d08d710 smb_flop_hard TUX1C monitor #very important PC

thinstation.nbi.zpxe";

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

make World BOOTSTRAPCFLAGS="-m32"

--- 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_LIBRARY_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 надо отредактировать до выполнения команды /srv/NX/bin/nxsetup. В конфигурационном файле /srv/NX/etc/node.conf раскомментируйте строчку:

ENABLE_2_0_0_BACKEND="1"

Теперь посмотрим, что надо изменить в дистрибутиве Thinstation (последняя версия сейчас 2.2) для поддержки NX 2.0 со стороны клиента. На момент написания статьи поддерживался только клиент версии 1.5. Забираем с адреса NX client, не требующий поддержки библиотек XFT, в виде tar.gz-архива (на данный момент это nxclient-2.1.0-9.i386.tar.gz), распаковываем его в домашнем каталоге, копируем файлы и создаём недостающие ссылки.

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

После этих действий пакет NX считается установленным в дереве пакетов Thinstation, теперь собираем образ, выполнив build, и копируем на tftp-сервер. Ну вот, образ готов и помещен в каталог tftp-сервера, но это еще не все. Оказывается NX-клиент новой версии на тонком клиенте по-другому интерпретирует настройки из файлов thinstation.conf.group-TUX1C(NX). После некоторого выяснения оказалось, что файл с настройками NX-сессии должен создаться в корне файловой системы тонкого клиента. Пришлось сделать небольшой патч для Thinstation, идею я подсмотрел на одном форуме:

# Патч просто копирует файл(ы) настроек NX-клиента из стандартного места в корень

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

Данный кусок кода надо вставить в конец файла ~/thinstation/packages/nx/etc/init.d/nx.init перед последней командой «exit 0». После этого надо пересобрать образ Thinstation. Вот, теперь NX-сессия на тонком клиенте запускается так, как и задумано. В целом новая версия работает более стабильно, управление сессиями происходит более корректно плюс в свежих исходниках обновлены алгоритмы компрессии, исправлены некоторые ошибки. Ранее для очистки и закрытия незавершенных сессий и процессов приходилось обращаться к помощи cron:

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

Удобно и то, что клиент NX 2.1 работает с серверами обеих версий.

Рисунок 4. NX-сессия в режиме приложения (1С)

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

1. Борисов А. Тонкий клиент – шаг к мэйнфреймам? //Системный администратор, №11, ноябрь 2005 г. – С. 32-38.

2. Маркелов А. Использование бездисковых Linux-станций с загрузкой по сети. //Системный администратор, № 11, ноябрь 2004 г. – С. 12-14.