Это продолжение первой части статьи о NX (часть 1).
Отличия сборки 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 я нашел заметку[18], в которой сказано, что исходные тексты 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, её можно забрать здесь [19], в-третьих, файл 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)"
# 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 alsochange 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 "^[0|1]$") ] && \
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 neededfor this version of FreeNX."
+# [ -z "$(strings $PATH_BIN/nxagent |grep 'NXAGENT - Version 1.5.0')" ] && \
+# ERROR="yes" && echo "Error: Could not find1.5.0 version string in nxagent. NX 1.5.0 backend is neededfor this version of FreeNX."
[ -z $(echo "$ENABLE_USESSION" |egrep "^[0|1]$") ] && \
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. Забираем с адреса [20] 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
fi
done
fi
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 работает с серверами обоих версий.
Дополнительные настройки и особенности эксплуатации.
До этого момента я описывал сборку серверной части NX , а также настройку дистрибутива Thinstation для работы с ней. Далее расскажу о некоторых проблемах, с которыми мне пришлось столкнуться, и о их решении, а также об особенностях эксплуатации NX.
Доработка функционального окна VNC.
При использовании VNC управление сеансом по умолчанию осуществляется клавишей F8. У нас пользователи используют dosemu c Dos Navigator, в нем активно используется эта клавиша. Чтоб избежать конфликта, я подправил в исходниках файл /nx_build_dir/nxviewer/nxviewer/argsresources.c. Чтобы не тратить много места в статье, укажу лишь какие строчки я отредактировал:
<Key>F8: ShowPopup()\\n\ -> <Key>F12: ShowPopup()\\n\
"*popupButtonCount: 6", -> "*popupButtonCount: 2",
"*popup*button1.label: Dismiss popup", -> "*popup*button1.label: Close",
"*popup*button2.label: Quit viewer", -> "*popup*button2.label: Send F12",
<Btn1Down>,<Btn1Up>: Quit()", ->
<Btn1Down>,<Btn1Up>: SendRFBEvent(key,F12) HidePopup()",
Таким образом, функция вызова меню VNC переназначается c F8 на F12, вместо 6 доступных в меню строк осталось только 2: закрыть меню при случайном нажатии «Close» и послать код F12, если вдруг встретилась такая функциональная клавиша. Если не используете VNC агента nxviewer, то вам это не пригодится.
Проблема связки NX, Thinstation, Firefox.
Почему я стал использовать nxviewer? Сам по себе NX работает замечательно и в режиме приложений, и в режиме работы с удаленным рабочим столом. Но вот что выяснилось: при работе в Firefox на нашем внутреннем сайте встречаются страницы, необходимые для работы, размером от 400 кБ и больше. Вот во время вывода таких страничек на экран изображение останавливается, и тонкий клиент перестает отвечать на запросы («вешается»). Что я только не делал: менял сочетания версий Firefox, Thinstation, NX, менял настройки Firefox в строке «about:config», задавал вопросы в форумах. Ничего не помогло, небольшие странички открываются без проблем, большие от 400 кБ вызывают проблему. Причем эти же страницы нормально отображаются в Opera, но это противоречит нашей ориентации на открытый Firefox. Создалось ощущение, что это связано с особенностями движка данного браузера. Тогда пришлось перейти к использованию RVB/VNC сессий в NX: на NX сервере в настройках сервиса xinetd включается VNC сервер. На рисунке 3 (см. рис. 3 первой части статьи) показаны файлы настроек сессий NX и TUX1C. В итоге, там, где нужен Firefox, я использую VNC сессии в NX, во всех остальных случаях – обычный режим NX. Основным недостатком использования VNC является необходимость дважды вводить пароль: вначале в красном окошке приглашения NX клиента, а потом при авторизации с помощью оконного менеждера, например KDE, при соединении с VNC сервером. Но на скорости работы это почти не отражается, так что все сказанное об NX справедливо и для сессий VNC под NX. Настройки VNC-сессии NX клиента можно посмотреть на рисунке (см. рис. 2).
Еще одна проблема с кириллицей.
Встретилась еще одна проблема с кириллицей: при работе в обычном режиме NX не правильно переключаются раскладки (VNC это не касается, там все работает): в зависимости от указанной кодировки отображаются либо только русские клавиши, либо только английские. Если у вас встретилась такая проблема, то включите в скрипт запуска приложения следующую строчку:
xterm -e setxkbmap -rules xorg -model pc105 -layout "us,ru" -variant ",winkeys" -option "grp:ctrl_shift_toggle,grp_led:scroll".
Например, у меня для запуска программы 1С под эмулятором WINE используется sh скрипт /usr/bin/1c, в котором используются некоторые проверки, подключается нужный шрифт, вносится изменения в реестр с помощью reg файла (для указания названий и путей баз 1С) и перед запуском самого 1С выполняется указанная выше строчка. При запуске сессии удаленного стола можно также выполнить эту строчку в стартовых скриптах домашнего каталога (~/.profile или ~/.bashrc) или системы (/etc/bash.bashrc.local).
Тогда всё должно наладиться.
Использование дисковых устройств тонких клиентов.
Еще одна тонкость. Если пользователям необходимо обращаться к дискетам и(или) локальному диску с разделом fat16(32) на своих тонких клиентах, то придется разобраться с Samba. Для этого добавляем в файл build.conf (как показано в моем листинге) модули floppy, fvat, supermount и пакет samba-server. На рисунке (см. рис. 3 в первой части статьи) показано содержимое файла thinstation.conf.group-smb_hard, в нем два последних параметра указывают: нет поддержки жесткого диска, но есть поддержка флоппи диска. Таких групп у меня несколько с различными сочетаниями значений параметров – в зависимости от необходимости в нужных устройствах. На рисунке также показано содержимое файла thinstation.conf-MAC, в нем видно, что добавлена подгрузка пакетов samba-base и samba-server. Теперь нужно создать ярлычки на рабочем столе пользователей в KDE. При этом если на тонком клиенте устройства нет, то и ярлычка этого устройства быть не должно. Проверка осуществляется командой smbclient, а IP-адрес клиента выясняется с помощью nxserver (я не настаиваю, что это единственный способ). Для возможности запуска nxserver в файл /etc/sudoers добавляем строку:
ALL ALL = NOPASSWD: /srv/NX/bin/nxserver --list*, !/srv/NX/bin/nxserver [!-]*
То есть пользователям разрешается только пролистать текущие NX сессии. Далее, пришлось написать на shell небольшой код, который нужно добавить в файл /etc/bash.bashrc.local:
#We test floppy and HD existing by requesting samba server
# on thin client
name=`whoami`
if [ "$name" != nx ] && [ "$name" != "root" ]
then
ip=$(/usr/bin/sudo /srv/NX/bin/nxserver --list $name|\
grep 10\\.|tail -n 1|awk '{print $3}')
if [ "$ip" != "" ]
then
# testing for harddisk existence
harddisk=`smbclient -NL $ip 2>/dev/null|grep harddisk`
if [ "$harddisk" != "" ]
then
echo "[Desktop Entry]" > ~/Desktop/Harddisk.desktop
echo "Encoding=UTF-8" >> ~/Desktop/Harddisk.desktop
echo "Icon=HD" >> ~/Desktop/Harddisk.desktop
echo "Name=Harddisk" >> ~/Desktop/Harddisk.desktop
echo "Name[ru]=Harddisk" >> ~/Desktop/Harddisk.desktop
echo "OnlyShowIn=KDE;" >> ~/Desktop/Harddisk.desktop
echo "Open=false" >> ~/Desktop/Harddisk.desktop
echo "Type=Link" >> ~/Desktop/Harddisk.desktop
echo "URL=smb://$ip/harddisk" >> ~/Desktop/Harddisk.desktop
echo "X-KDE-KonqSidebarModule=konqsidebar_tree" >> ~/Desktop/Harddisk.desktop
echo "X-KDE-TreeModule=Directory" >> ~/Desktop/Harddisk.desktop
echo "X-SuSE-translate=true" >> ~/Desktop/Harddisk.desktop
else
rm -f ~/Desktop/Harddisk.desktop
fi
# testing for floppy existence
floppy=`smbclient -NL $ip 2>/dev/null|grep floppy`
if [ "$floppy" != "" ]
then
echo "[Desktop Entry]" > ~/Desktop/"Floppy Disk";
echo "Encoding=UTF-8" >> ~/Desktop/"Floppy Disk";
echo "Icon=3floppy_mount" >> ~/Desktop/"Floppy Disk";
echo "Name=Floppy Disk" >> ~/Desktop/"Floppy Disk";
echo "Name[ru]=Floppy Disk" >> ~/Desktop/"Floppy Disk";
echo "OnlyShowIn=KDE;" >> ~/Desktop/"Floppy Disk";
echo "Open=false" >> ~/Desktop/"Floppy Disk";
echo "Type=Link" >> ~/Desktop/"Floppy Disk";
echo "URL=smb://$ip/floppy" >> ~/Desktop/"Floppy Disk";
echo "X-KDE-KonqSidebarModule=konqsidebar_tree" >> ~/Desktop/"Floppy Disk";
echo "X-KDE-TreeModule=Directory" >> ~/Desktop/"Floppy Disk";
echo "X-SuSE-translate=true" >> ~/Desktop/"Floppy Disk";
else
rm -f ~/Desktop/"Floppy Disk";
fi
fi
fi
Единственное, что вы захотите здесь поменять – это в строчке с sudo изменить «grep 10\\.» в соответствии с настройками вашей сети. То есть, если сеть 192.168.10.0/255, то это будет «grep 192\\.», у меня используется сеть 10/8. Я думаю, мысль вы поняли. Теперь ярлычки на рабочем столе будут появляться только тогда, когда на тонком клиенте имеются соответствующие ярлыкам устройства.
И еще здесь добавлю по поводу памяти: 32 Мб на тонком клиенте хватает на то, чтобы кроме ядра Thinstation (в котором уже имеется NX клиент) работали пакеты sshd и lprng, но не хватает на поддержку Самбы: желательно ставить немного больше памяти, хотя бы 40 Mb, этого хватит на всё.
Примеры использования NX в режиме приложений.
В нашей системе производится перевод системы 1С на терминальный сервер с Linux и эмулятором WINE. Одна база уже переведена, и с ней реально работают люди. Вот, что выяснилось. При работе на тонком клиенте у каждого пользователя имеется ярлычок на уже упомянутый скрипт /usr/bin/1c, его можно запускать столько раз, сколько нужно открыть копий приложения 1С(для работы с разными базами). Из Windows получается запустить только одну NX-сессию приложения 1С. При повторном запуске текущая сессия прерывается и восстанавливается в новом окне, то есть используется режим FreeNX «session resume» – возобновление прерванной сессии. Пришлось использовать запуск в режиме приложения NX удаленного рабочего стола Wmaker (он занимает гораздо меньше памяти, чем KDE), а в нем уже можно работать с 1С как на тонких клиентах (можно открыть несколько копий 1С).
И еще один момент. Мы принимали попытку перевести другую базу 1С (ее используют более 200 человек) на тот же терминальный сервер. Сервер Proliant DL-385 c двумя Opteron-ами был полностью загружен: при пиковой нагрузке в системе насчитывалось 150 процессов 1CV7.exe, далее пользователи уже не могли зайти на сервер: на NX клиенте при соединении с сервером секунд через 45 срабатывал таймаут, хотя спустя секунды пользовательские процессы на сервере нормально запускались. Я оставил сообщение на сайте Nomachine с предложением добавить возможность настройки таймаута на клиенте NX, там зарегистрировали Feature Request, но мне это уже было не нужно: пришлось придумывать другой вариант перехода, в рамках заданной темы об этом рассказывать не буду.
Еще один пример. На компьютере с памятью 64 Мб проблемно использовать OpenOffice 2.0: слишком много памяти он потребляет. На помощь приходит клиент NX, работающий в режиме приложений: при этом используется память сервера, которой как правило много больше, чем у клиента. Примеры можно продолжать.
Несколько слов о производительности NX.
Скажу немного о производительности системы с NX. Я упоминал в статье о двух nx-серверах для описания отличий в работе двух версий NX, хотя на самом деле их в нашей сети три. В настоящий момент в нашей системе используется около 50 тонких клиентов Thinstation, число которых постоянно растет. Кроме того часть работников запускают NX клиент из Windows для работы с приложениями, в частности с 1С. Хорошо проявил себя протокол NX. Например, при временном пропадании связи соединение не сбрасывается, а осуществляется попытка его восстановления. Когда на тонком клиенте возрастает нагрузка процессора, вывод на экран немного замедляется. Забавно наблюдать, как во время загрузки рабочего стола KDE анимированная эмблема системы SUSE временно «замирает» , а спустя мгновения возобновляет его отображение с удвоенной скоростью. Я писал ранее о корректной работе в NX компьютера c процессором P-120, но, конечно, чем больше частота процессора, тем более плавно происходит отображение информации (особенно графические эффекты KDE) на экране тонкого клиента. При использовании тонких клиентов в локальной сети достаточно пропускной способности 10 Мбит, однако начальная загрузка образа Thinstation (у меня образ чуть меньше 9 Мб) ускорится, если использовать 100 Мбит сеть. Если тонкие клиенты в филиале связаны с терминальным сервером xDSL-модемами (или иными низкоскоростными соединениями), то лучше предусмотреть наличие tftp сервера на территории самого филиала: это позволит не прокачивать каждый раз образ через узкий канал связи, а брать его с локального сервера.
Могу лишь добавить, что процессы NX на сервере занимают немного памяти и оказывают незначительную нагрузку на процессор(ы) относительно других приложений. Мне кажется, что протокол NX уже корректно сравнивать не с протоколом RFB, используемым VNC, а с протоколом ICA от Citrix (хотя они и используются в разных системах): протоколы примерно схожи по производительности и эффективности, вот только NX обойдется гораздо дешевле, если не бесплатно. Кроме того, если говорить о надежности, вспомните, что бывает, когда виснет один из основных сервисов Citrix на сервере Windows? Это сразу «ощутят» все пользователи Citrix. В Linux с NX для каждого пользователя запускаются отдельные процессы NX, и падение любого из них никак не отразится на работе других пользователей.
В заключение скажу, что в августе 2006 года на прошедшей в Сан-Франциско выставке «LinuxWorld» фирма Nomachine получила награду журнала «LinuxJournal» за свой продукт NX Server 2.0 «BEST INTEGRATION SOLUTION» (за лучшее интеграционное решение)[23].
В целом у NX видятся неплохие перспективы, сообщество Open Source тоже не дремлет. Так что если решитесь использовать его у себя, то не пожалеете. И удачи!
Литература и ссылки:
- Борисов А. «Тонкий клиент – шаг к мэйнфреймам?» - Системный администратор, №11, ноябрь 2005.
- Маркелов А. «Использование бездисковых Linux-станций с загрузкой по сети», № 11, ноябрь 2004.
- http://sourceforge.net/project/showfiles.php?group_id=80408&package_id=82039
- http://www.realvnc.com/
- http://www.tightvnc.com/
- http://www.complang.tuwien.ac.at/nino/dosvnc.html
- http://ultravnc.sourceforge.net/
- http://www.redstonesoftware.com/products/vine/server/vineosx/index.html
- http://en.wikipedia.org/wiki/X_Window_System
- http://www.vigor.nu/dxpc/
- http://www.nomachine.com/sources.php
- http://www.nomachine.com/experimental-products.php
- http://debian.tu-bs.de/knoppix/nx/freenx-0.4.4.tar.gz
- http://www.linuxfromscratch.org/hints/downloads/attachments/freenx/NX-lfs_hint.diff
- http://www.linuxfromscratch.org/hints/downloads/attachments/freenx/freenx-lfs_hint.diff
- http://www.novell.com/coolsolutions/feature/16247.html
- http://sourceforge.net/project/showfiles.php?group_id=80408&package_id=97496&release_id=200769
- http://www.nomachine.com/ar/view.php?ar_id=AR02C00154
- http://prdownload.berlios.de/freenx/freenx-0.5.0.tar.gz
- http://www.nomachine.com/download-package.php?Prod_Id=26
- Дистрибутив Thinstation: http://sourceforge.net/project/showfiles.php?group_id=80408&package_id=82039
- Сайт Nomachine: http://www.nomachine.com
- http://www.ssc.com/node/20
Комментариев нет:
Отправить комментарий