Для многих задач наиболее актуальным, а зачасту и единственным, является решение терминальной работы приложения, которое разработано по принципу клиент-серверной архитектуры. Если речь идет о nix-сервере, то резонным встает вопрос о терминальном сервере. В принципе удаленный доступ можно организовать с помощью разным протоколов: ssh, vnc, rdp, nx... У каждого есть свои преимущества и недостатки, а также соотвествующая область применения. Далее будет рассмотрена установка и базовая настройка FreeNX сервера с наработками от компании Etersoft - RX@Etersoft, на базе дистрибутива Debian 4.0_r0. Цепляться к нему будем удаленно из openSuSE10.3 с помощью NX-клиента от компании NoMachine.
Почему решение от Etersoft'a? Уж не знаю что они допилили по сравнению с авторской реализацией, однако обещается (разработчиком естественно) корректная работа с рендерингом кириллических шрифтов. При использовании обычного freenx'а шрифты (замечено на многих win-приложениях - WinRAR, 1С, etc) накладываются друг на друга и получается каша. Если отключить рендеринг на стороне клиента (винды то бишь), то резко возрастает обмен трафиком и тормозится работа - вследсвие того что все фонты начинают передаваться bitmap'ами, что нехило по размеру. Решением спецы с Etersoft'a предлагают свой пакет NX'a. С ним и будем работать.
Почему решение от Etersoft'a? Уж не знаю что они допилили по сравнению с авторской реализацией, однако обещается (разработчиком естественно) корректная работа с рендерингом кириллических шрифтов. При использовании обычного freenx'а шрифты (замечено на многих win-приложениях - WinRAR, 1С, etc) накладываются друг на друга и получается каша. Если отключить рендеринг на стороне клиента (винды то бишь), то резко возрастает обмен трафиком и тормозится работа - вследсвие того что все фонты начинают передаваться bitmap'ами, что нехило по размеру. Решением спецы с Etersoft'a предлагают свой пакет NX'a. С ним и будем работать.
Качаем отсель собранные для нашего дистриба пакеты (freenx_0.7.2-1_i386.deb и nx_3.1.0-1_i386.deb). Затем устанавливаем их, перейдя в соответствующий каталог.
interra:/home/delayer/# cd .\!/rxТак же уже должен стоять пакет openssh-server. Если нет, то следует установить и его.
dpkg -i *.deb
apt-get install openssh-serverВ принципе все - далее займемся конфигурацией.
Для успешной авторизации клиентов нам нужны ключи. Их созданием занимается утилита nxkeygen
interra:/home/delayer/!/rx# nxkeygen
Unique key generated; your users must install
/var/lib/nxserver/home/.ssh/client.id_dsa.key
on their computers.
Далее этот файлик нам пригодится для пользовательских машин, сей ключ мы импортируем nx-клинентам для успешной авторизации на сервере.
Создаем пользователя (или пользователей =)) в системе любым удобным методом, например с помощью adduser.
Запускаем собственный инсталлер сервера, который произведет его настройку и запуск. На "выхлопе" получим примерно следующее:
interra:/home/delayer/!/rx# nxsetup
------> You did select no action.
FreeNX guesses that you want to _install_ the server.
Type "y" to abort the installation at this point in time.
"N" is the default and continues installation.
Use "/usr/bin/nxsetup --help" to get more detailed help hints.
Do you want to abort now? [y/N] n
------> It is recommended that you use the NoMachine key for
easier setup. If you answer "y", FreeNX creates a custom
KeyPair and expects you to setup your clients manually.
"N" is default and uses the NoMachine key for installation.
Do you want to use your own custom KeyPair? [y/N] nSetting up /etc/nxserver ...done
Generating public/private dsa key pair.
Your identification has been saved in /etc/nxserver/users.id_dsa.
Your public key has been saved in /etc/nxserver/users.id_dsa.pub.
The key fingerprint is:
81:a9:42:ea:97:59:51:41:c3:e4:f0:63:29:cc:d8:10 root@interra
Setting up /var/lib/nxserver/db ...done
Setting up /var/log/nxserver.log ...done
Setting up known_hosts and authorized_keys ...done
Setting up permissions ...done
Setting up cups nxipp backend ...done
----> Testing your nxserver configuration ...
Warning: Could not find nxdesktop in /usr/bin. RDP sessions won't work.
Warning: Could not find nxviewer in /usr/bin. VNC sessions won't work.
Warning: "/usr/lib/cups/backend/smb" is not executable.
Users will not be able to enable printing.
Warning: Invalid value "DEFAULT_X_SESSION=/etc/X11/xdm/Xsession"
Users might not be able to request a default X session.
Warning: Invalid value "COMMAND_START_KDE=startkde"
Users will not be able to request a KDE session.
Warning: Invalid value "COMMAND_START_CDE=cdwm"
Users will not be able to request a CDE session.
Warning: Invalid value "COMMAND_SMBMOUNT=smbmount". You'll not be able to use SAMBA.
Warning: Invalid value "COMMAND_SMBUMOUNT=smbumount". You'll not be able to use SAMBA.
Error: expect necessary for /usr/bin/nxnode-login could not be found in '/usr/bin/expect'. Please install it or change nxnode-login accordingly.
Errors occured during config check.
Please correct the configuration file.
На сообщения об опасности особого внимания обращать не стоит, часть из них, что ругается на Invalid value, есть следствие того, что указанные переменные не определены ввиду отсутствия установленных компонентов (CUPS, samba), остальные уведомляют, что не могут найти некоторые компоненты nx-пакета. Однако ни RDP, ни VNC протокол мы использовать не будем, поэтому нам это не вредит ничуть %).
По поводу второго вопроса (с первым я думаю все ясно), связанного с KeyPair, выбираем вариант использования ключей специально для NoMachine, который и будет использоваться в качестве клиента. Хотя по сути, если мы создаем ключ заново nxkeygen'ом, а затем его импортируем клиентам, то смысл ответа n в принципе то теряется. Но подумал я об этом только сейчас, когда уже все работает ;). Так что по уму стоит поставить y, если мы хотим использовать свои ключи, сгенеренные на этой системе, и n, если планируется работать с NoMachine nx-клиентом и его дефолтными ключами. Тогда этап отработки nxkeygen'a выпадает.
По поводу второго вопроса (с первым я думаю все ясно), связанного с KeyPair, выбираем вариант использования ключей специально для NoMachine, который и будет использоваться в качестве клиента. Хотя по сути, если мы создаем ключ заново nxkeygen'ом, а затем его импортируем клиентам, то смысл ответа n в принципе то теряется. Но подумал я об этом только сейчас, когда уже все работает ;). Так что по уму стоит поставить y, если мы хотим использовать свои ключи, сгенеренные на этой системе, и n, если планируется работать с NoMachine nx-клиентом и его дефолтными ключами. Тогда этап отработки nxkeygen'a выпадает.
Теперь зарегистриуем пользователя для nx-соединения через nxserver. Это делается через примерно следующий диалог:
interra:/# nxserver --adduser delayer
NX> 100 NXSERVER - Version 2.1.0-72-SVN OS (GPL)
NX> 1000 NXNODE - Version 2.1.0-72-SVN OS (GPL)
NX> 716 Public key added to: /home/delayer/.ssh/authorized_keys
NX> 1001 Bye.
NX> 999 Bye
interra:/var/lib/nxserver/home/.ssh# nxserver --passwd delayer
NX> 100 NXSERVER - Version 2.1.0-72-SVN OS (GPL)
New password:
Password changed.
NX> 999 Bye
Для надежности перезапустим nxserver
interra:/home/delayer/!/rx# nxserver --restart
Eсли пользователя нет в ОС, то nxserver вернет ошибку, так как при регистрации используется домашний каталог пользователя.
После этого на стороне клиента настраиваем NX-клиент, в данном примере от NoMachine - http://www.nomachine.com/download-client-linux.php, доступны сборки как для deb-, так и для rpm-орентированных дистрибутивов, ну и tarball тоже имеется. Поддерживаются linux, BSD, MacOS, Win системы.Создав подключение (пояснение не привожу, так как считаю что ничег осложного в этом нет, все исключительно user friendly), импортируем сохраненный ранее ключ. Вот так: Configure -
General -> Key... -> Import -> /path/to/dsa-key -> SaveВсе, проверяем подключение.
Если для секурности есть желание изменить ssh порт, то это делается в /etc/ssh/sshd_config, меняя значение Port. Аналогично изменяется директива SHHD_PORT на желаемое значение в /etc/nxserver/node.conf. Там же стоит изменить уровень логирования с дефолтного 0 на 2 или 4 ( опция NX_LOG_LEVEL). Подробности прямо в конфигурационном файле. Это полезно при начальной настройке и обкатке. Впоследствии несложно отключить и рестартнуть nxserver
interra:/# nxserver --restart
После перезагрузки самой системы freenx поднимается сам, благодаря init-скриптам.
Вы как-нть решили проблему с переключением раскладок?
ОтветитьУдалитьЯ использовал http://adeptofacultubuntu.blogspot.com/2007/12/freenx.html - но описанные там методы - не совсем подходят
вообще с недавнего времени на фтп-шнике Etersoft'a, там же, где выклажываются сборки NX-сервера, присутствует и пиленая ими же сборочка nx-клиента, в которой правятся многие болячки нативного "немашинного" клиента, это и проброс шар/принтеров, и прорисовка окон с seamless-режиме, и работа буфера обмена, и, если мне память не изменяет, проблема с раскладками. Так что стоит попробовать ее. Если речь идет о вин-клиентах, то патченую версию можно взять вот поэтой ссылке: http://linuxforum.ru/index.php?s=04dfc60fc60238b8390b24b1f14d3222&showtopic=64076&start=200&p=740593&#entry740593
ОтветитьУдалитьЗаодним и тред почитать, там много интересного, и etersoft имхо этой веткй и вдхнвился в свое время =).
Однако списывать со счетов setxkbmap все-таки не стоит...
я пробовал и оригинальный клиент и клиент от etersoft - картина одинаковая :(
ОтветитьУдалитьпричем в версии 3.3.0-6(etersoft) параметры выбора кодировок доступны только через правку .nx/config/ИМЯ.nxs
хм.. не наю...
ОтветитьУдалитья в работе использую во-первых, Gnome-сессии на терминальном сервере, с соотвествтующей настройкой апплета смены раскладок клавы, во-вторых, при запуске нужного приложения, 1С в данном случае, запуск происходит с ярлычка, который ссылкается вот на такой скрипт:
root@interro:~# more /usr/bin/1Cv77.sh
#!/bin/sh
setxkbmap -model pc104 -layout us,ru - variant ,winkeys -option grp:ctrl_shift_toggle
wine "C:\\Program Files\\1Cv77\\BIN\\1CV7.exe"
проблем вроде как не знаем... больше десятка клиентов
Выходит если использовать данную статью, коммерческий _терминал_ от Etersoft не нужен? Я так понял, FreeNX ставился на Дебиан, необременённый коммерческим терминалом от Etersoft. Подключения к FreeNX не ограничены. Клиент NX бесплатен и открыт. Покупаем нужное количество сетевых клиентов wine@Etersoft Network, ставим сабж, и собсно всё?
ОтветитьУдалитьВсё лишь упирается в количество одновремменных терминальных сессий.
Ну и ещё, насколько легально пользование патчей с фтпшика Этерсофт?
Решение RX@Etersoft основано на коде freenx, а также NX-клиента от nomachine.
ОтветитьУдалитьИ то и другое GPL-ное. Отсюда вытекает, что изменения в коде RX/NX также должны выпускаться под соответствующей лицензией. Что, собственно, и делается. Так что RX@etersoft (и серверная, и клиентская части) доступны для свободного доступа на ftp.etersoft.ru и распространяются под GPL. А лицензия на терминальный сервер, предлагаемая на сайте Этерсофта, несет в себе две цели: 1) получение "бумажки", которую можно предъявить кому следует, и счета-фактуры, с помощью которого можно без проблем занести купленный софт на баланс предприятия. 2) Техническую поддержку в течение определенного времени.
Если ни первое, ни второе не актуальны - пожалуйста, качаем as is и пользуемся.