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

Евгений Бушков

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

Часть 2

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

Доработка функционального окна 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-сервер. В первой части статьи (см. №12 за 2006 г.) на рисунке 3 показаны файлы настроек сессий NX и TUX1C. В итоге там, где нужен Firefox, я использую VNC-сессии в NX, во всех остальных случаях – обычный режим NX.

Основным недостатком использования VNC является необходимость дважды вводить пароль: в окошке приглашения NX-клиента, а потом при авторизации с помощью оконного менеджера, например KDE, при соединении с VNC-сервером. Но на скорости работы это почти не отражается, так что все сказанное об NX справедливо и для сессий VNC под NX.

Настройки VNC-сессии NX-клиента вы можете посмотреть на  рис. 1.

Рисунок 1. Настройки VNC-сессии NX-клиента

Проблема с кириллицей

Встретилась еще одна проблема с кириллицей: при работе в обычном режиме 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).

Тогда всё должно наладиться.

Рисунок 2. Обычная работа на тонком клиенте

Использование дисковых устройств тонких клиентов

Еще одна тонкость. Если пользователям необходимо обращаться к дискетам или локальному диску с разделом FAT16 (32) на своих тонких клиентах, то придется разобраться с Samba. Для этого добавляем в файл build.conf (см. №12 за 2006 г.) модули floppy, fvat, supermount и пакет samba-server.

В первой части статьи (см. №12 за 2006 г.) на рисунке 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, но не хватает на поддержку Samba, желательно ставить немного больше памяти, хотя бы 40 Мб, этого хватит на всё.

Примеры использования 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, работающий в режиме приложений, при этом используется память сервера, которой, как правило, много больше, чем у клиента. Примеры можно продолжать.

Рисунок 3. NX-сессия Wmaker в режиме приложения

Несколько слов о производительности 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» (за лучшее интеграционное решение) [21].

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

И удачи!

P.S. Некоторые из описанных проблем, возможно, будут уже решены на момент выхода журнала, присоединяйтесь к обсуждению статьи на форуме журнала http://www.samag.ru/forum.

1. Дистрибутив Thinstation – http://sourceforge.net/project/showfiles.php?group_id=80408&package_id=82039.
2. Сайт Nomachine – http://www.nomachine.com.
3. http://www.ssc.com/node/20.
4. Бушков Е. Подробное руководство по настройке тонких клиентов на основе дистрибутива Thinstation и протокола NX. //Системный администратор, №12, 2006 г. – C. 16-23.