Мой опыт работы с NX (часть 1).

Статья была опубликована в "Системном администраторе" № 12(2006) и № 1(2007) под названием "Подробное руководство по настройке тонких клиентов".

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

Хотя с момента написания статьи прошло уже несколько лет, статья в целом по-прежнему мне кажется актуальной. Большинство linux - дистрибутивов сегодня уже содержат готовые сборки NX, и часть статьи "Сборка и запуск NX" теперь кажется ненужной. Те нерешённые проблемы, что описаны в конце статьи были так или иначе решены. К сожалению, не удалось продолжить дальнейшее описание моей системы и публикацию новых статей. С одной стороны у меня начальство отнеслось весьма неоднозначно к публикации, с другой - я поменял работу, поэтому часть заготовленных материалов осталась лежать мёртвым грузом, возможно, я когда-нибудь и сделаю на её основе что-то вроде заметки.

Статью пришлось разбить на несколько частей из-за ограничений на размер постов lj. Список литературы и ссылки пришлось тоже разместить во второй части.

Тонкие клиенты Thinstation и протокол NX.

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

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

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

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

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

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

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

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

В первую очередь обратил внимание на VNC, как наиболее распространенный и имеющийся в любом дистрибутиве Linux, а также являющийся легким в настройке продуктом. Когда необходимо подключиться к удаленному рабочему столу Linux сервера с рабочей станции Windows или того же Linux, то первое, что приходит в голову, это VNC. Итак, скачайте последнюю версию дистрибутива Thinstation [3], затем распакуйте полученный архивный файл в домашнем каталоге. Будем считать , что путь к дистрибутиву выглядит так: ~/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» и на рисунке(см. рис.3).

Для того, чтобы добавить в образ пакет 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

После сборки образа получаем нормальное переключение раскладок по CTRL-SHIFT. Вот только работает VNC-клиент недопустимо медленно. На компьютерах с процессором ниже P-200 начинается этакое «слайд-шоу», когда любое действие на удаленном рабочем столе сопровождается неторопливой прорисовкой этих изменений на экране монитора тонкого клиента. Существует множество VNC решений, использующих схожие методы кодирования данных при передаче, все используют протокол Remote FrameBuffer (RFB). Различаются они количеством функций, параметрами кодирования данных, а также числом поддерживаемых платформ. Например, RealVNC[4] поддерживает сервер и клиент для Windows, Unix, Microsoft PocketPC и Mac OS X, TightVNC[5] включает сервер и клиент для Windows и Unix, VNC for DOS[6] – клиент для DOS, UltraVNC[7] – сервер и клиент для Windows, OSXvnc[8] – сервер и клиент для 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 серверу терминала[9].

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

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

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

1. В основе идеи разностной компрессии лежит проект Differential X Protocol Compressor (DXPC)[10], созданный в 1995 году, там уже упоминаются термины клиентского и серверного прокси. Nomachine подхватила идею и разработала свой собственный продукт. Заявляется о 10-кратном превосходстве NX над стандартной библиотекой ZLIB;
2. Nomachine также разработала умный механизм кэширования X трафика, который использует знакомый по прокси-серверам термин «попаданий в кэш». Этот механизм сокращает сетевой трафик при передаче одних и тех же блоков данных, а при изменении этих блоков данных потока вычисляет и передает только их разницу;
3. До NX не было надежного способа подавления избыточного трафика X протокола на дальних линиях связи. NX может это делать, транслируя X трафик на удаленном конце(от приложения к nxagent-у) в трафик протокола NX.

Все три метода совокупно позволяют достичь 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 открыла исходные коды большинства своих наработок и библиотек, их можно скачать всем желающим с [11]. Сборки от самой Nomachine для всех клиентов доступны бесплатно, также есть различные варианты сборок NX серверов, поставляемые за определенную плату: годовая подписка на NX Enterprise Server с неограниченным количеством пользователей и числом процессоров 1-2 стоит 1494$, наиболее полное решение с балансировкой нагрузки и управлением узлов на базе NX Advanced Server обойдется в 3494$. Кроме того имеется вариант NX Free Edition, который можно скачать бесплатно, но имеет ограничение на количество одновременных соединений и пользователей, равное двум, так что если есть желание администрировать Linux сервер из дома с помощью обычного аналогового модема, то лучше, безопаснее и проще этого решения не найти. Отмечу также наличие клиентских версий NX Client Desktop Edition для PlayStation2 (при использовании Linux Kit), а также NX Client Embedded Edition для Sharp Zaurus 5xxx и HP/Compaq iPAQ. Их можно также скачать бесплатно[12]. Так что, если Вы в командировке, а с собой только КПК, ничего не мешает подключиться и работать удаленно на своем 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 там же имеется специальная ссылка. Итак, качаем последние версии следующих тарболов со странички [11]: nx-X11, nxagent, nxcomp,nxcompext, nxdesktop(если нужна поддержка RDP), nxproxy, nxscripts, nxviewer(если нужна поддержка VNC). nx-X11– это версия 4.3 Xfree86, которая имеет модифицированные Nomachine X библиотеки. Часть исходников будет распаковываться прямо в дерево nx-X11, поэтому развернем его в первую очередь, очередность распаковки остальных тарболов неважна, главное, чтобы они все распаковывались в одном каталоге. Туда же качаем и распаковываем скрипты FreeNX с адреса[13]. Еще понадобятся два патча, качаем их здесь [14] и здесь[15]. Каталог нашей сборки примет следующий вид:

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. Описание сборки можно найти также здесь[16].

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

# далее важный момент, прежде чем запускать, ознакомьтесь

# с параметрами запуска

# команды: /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 сервером можно работать как в режиме приложений, так и в режиме удаленного рабочего стола.

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

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

От серверной части NX теперь перейдем к созданию образа Thinstation. Сам дистрибутив можно скачать здесь[3]. При сборке образа будем стараться максимально уменьшить количество модулей и пакетов, все лишнее выкидываем. Поскольку у многих компьютеров, выбранных в качестве тонких клиентов, железо и периферия будут отличаться, то отдельные пакеты хотелось бы вынести за рамки общего для всех образа. Такая возможность у 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 не заработал, в таком случае по адресу [17] можно скачать файл BootPXE535.zip, в этом архиве есть универсальный загрузчик loader-native.zpxe, с ним все должно работать.

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

Рисунок 3. Файлы настроек тонких клиентов 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 указана строчка 'filename "thinstation.nbi.zpxe";', то будет использован образ thinstation.nbi, в моем случае образов несколько, соответственно и записи в dhcpd.conf для каждого терминала разные.

Вторая часть статьи