И не смотря на то, что в сети есть много примеров образов тонких клиентов, вряд ли всем они смогут подойти. Поэтому в этой статье рассмотрим процедуру сборки образа тонкого клиента. Для этого нам понадобится рабочая станция под управление ОС Linux (я буду использовать CentOS ) и платформу (последнюю версию можно взять ).
Скачанный архив распаковываем в любую папку. Установка платформы проходит автоматически. Для установки необходимо выполнить команду:
./setup-chroot
Сборка тонкого клиента происходит внутри платформы. Т.е. в случае если после установки вы выходили из «chrootsession », необходимо еще раз выполнить команду
./setup-chroot
Конфигурационные файлы, на основе которых будет собираться тонкий клиент, лежат по пути ts/2.5, там же лежит скрипт, который собирает тонкий клиент.
Т.е. выполняем команду:
cdts/2.5
Первый конфигурационный файл, который нужно подправить под наши нужды, будет build.conf. В этом конфигурационном файле можно указать какие именно драйвера необходимо включать в сборку, какие пакеты программного обеспечения установить, базовые параметры тонкого клиента, поменять приветственные картинки, установить необходимый оконный менеджер или запускать необходимые графическое приложение типа rdesktop .
Хочу обратить внимание на параметры:
paramdefaultconfigthinstation . conf . buildtime --- название файла с настройками по умолчанию;
parambasenamethinstation --- название файла; настроек, загружаемых по tftp -серверу.
parambasepathconfig --- название каталога на tftp -сервере, где искать конфигурационные файлы
Конфигурационный файл по умолчанию правится один раз перед сборкой тонкого клиента и содержит настройки, который после сборки уже нельзя изменить. Для того чтобы тонкий клиент подгружал свои настройки после загрузки через tftp сервер, эту функцию необходимо включить в конфигурационном файле по умолчанию и называется он:
NET_FILE_ENABLED=On
Таким образом, у нас появится возможность
переопределять настройки тонкогоклиента в процессе его эксплуатации. Файл
конфигурации должен называться basename.conf
Network – настройки по умолчанию, которые загружаются с tftp-сервера.
User – конфигурационный файл находящийся на локальном хранилище.
-
Group-
-
-
После проведения всех необходимых настроек в конфигурационных файлах необходимо выполнить команду
./build –-buildtimethinstation.conf.buildtime
После выполнения скрипта в папке boot-images появятся необходимые образы. И в зависимости от выбранного варианта загрузки тонкого клиента выбрать свой. В нашем случае мы использовали PXE, и поэтому наш образ лежит в папке pxe.
Далее копируем все файлы, созданные в папке pxe, в нашу папку с tftp и настраиваем рабочую станцию, которая будет использоваться под тонким клиентом, для загрузки по tftp. Если необходимо провести дополнительные настройки, в корне папки tftp создаем папку config (это название мы указали в конфигурационном файле по умолчанию) и складываем туда специфические файлы настройки тонких клиентов, которые будут загружатся по tftp.
Thinstation — мини-дистрибутив Linux, позволяющий превратить стандартные ПК в бездисковые тонкие клиенты. Его можно загружать по сети с помощью Etherboot/PXE или со стандартного носителя — дискеты/CD/жесткого диска/flash-диска и т.п.
Схема Загрузки
Загрузка Linux с HDD (SATA или PATA) или Flash
– Загружается операционная система Linux c диска на котором находятся образ системы и ядро.
Примечание:
Если используется сборка собранная с опциями NET_USE_DHCP=off и NET_FILE_ENABLED=OFF, то запрос к DHCP серверу не происходит и используеться локальный файл конфигурации thinstation.profile/thinstation.conf.user
Запрос DHCP сервера
– при инициализации сетевого интерфейса происходит запрос к DHCP сервера на получение IP-адреса клиента, маски подсети, IP-адреса TFTP сервера для получения конфигурационных файлов.
Ответ DHCP сервера
– При получении ответа, клиенту назначается IP-адрес и передается информация, где необходимо искать конфигурационные файлы. – загрузочные скрипты системы Linux получают c TFTP-сервера конфигурационные файлы, в которых описаны необходимые параметры для соединения клиента с терминальным сервером.
Инициализация терминального клиента
Установка на Диск
Для установки необходимо создать на жестком диске раздел 100 Мб с файловой системой fat. Переписать содержимое архива на диск. Подправить файл конфигурации thinstation.profile/thinstation.conf.user, описание настроек можно посмотреть в статье Синтаксис конфигурационных файлов.
Прописать загрузчик, для чего в командной строке windows (Пуск — Выполнить — cmd) или загрузив DOS, набрать:
F:>syslinux.exe -ma f:
где f — диск с образом
Внесения изменений в файл конфигурации на уже установленной системе:
1.
Загружаем терминального клиента, переходим на вторую консоль Alt+F2 или Alt+Ctrl+F2 (если AUTOSTART=On). Заходим под логином root, пароль secretword. В качестве редактора используем e3. Набираем:
E3 /mnt/disc/sda/part1/thinstation.profile/thinstation.conf.user
где sda
— первый SATA диск, для PATA — hda. Чтобы не вбивать весь путь, используйте кнопку Tab после первых введенных букв. После редактирования нажмите Ctrl+K X — для сохранения.
2.
Редактировать thinstation.conf.user можно удаленно по telnet. Для windows лучше использовать PuTTY
P.S.
Если диск отформатирован в ext2/ext3/ext4, то для загрузки нужен extlinux Скачиваем архив syslinux и взять из него (/syslinux-6.02/bios/extlinux/). Раздел должен быть активным.
Открывем консоль и переходим на монтированный раздел с диском или флэшкой например cd /mnt/flash, копируем туда extlinux и выполняем: ./extlinux –install . точка в конце означает что устанавливаем в текущий каталог.
Файл конфигурации:
extlinux.conf, точная копия syslinux.cfg
Как работает PXE
1.PXE запрос DHCP сервера:
2.Ответ DHCP сервера
– в зависимости от параметров конфигурационного файла запускается RDP или ICA клиент, который устанавливает соединение с терминальным сервером.
Настройка сервера DHCP и TFTP на linux.
Пример настройки на Freebsd.
В Freebsd чтобы inetd слушал запросы TFTP, нужно расcкомментировать строку в файле /etc/inetd.conf:
Tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
И сделать рестарт сервиса inetd:
Dom:~# killall -1 inetd
Потом создать директорию tftpboot и дать права:
Dom:~# mkdir /tftpboot dom:~# chmod -R 777 /tftpboot
Option domain-name "example.com"; option domain-name-servers 192.168.0.1; server-identifier NAME_HOST; authoritative ; allow booting; allow bootp; max-lease-time 172800; ignore client-updates; ddns-domainname "example.com"; ddns-updates on; ddns-update-style interim; default-lease-time 86400; log-facility local7; subnet 192.168.0.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option routers 192.168.0.1; one-lease-per-client on; range 192.168.0.20 192.168.0.30; } group { filename "pxelinux.0"; next-server 192.168.0.1; host 1 { hardware ethernet 00:0E:8F:32:B6:C5; fixed-address 192.168.0.10; } host 2 { hardware ethernet 08:20:07:26:C0:A5; fixed-address 192.168.0.11; } }
Распаковываем образ thinstation с pxe в /tftpboot
PXE-совместимые прошивки используются производителями при изготовлении сетевых карт и BIOS материнских плат с интегрированными сетевыми картами. Поэтому для бездисковой загрузки потребуется сетевая карта укомплектованная прошивкой PXE. Если у вас сетевая карта без прошивки, но Вы желаете сделать бездисковую загрузку, то как единственный выход в использовании прошивок Etherboot. Этот вариант здесь не рассматривается.
Как работает PXE
1.PXE запрос DHCP сервера:
сетевая карта с поддержкой PXE запрашивает DHCP сервер на получение параметров, таких как IP-адрес клиента, маска подсети, IP-адрес TFTP сервера, на котором находится образ, а также — имя образа.
2.Ответ DHCP сервера
– сервер назначает IP-адрес и затем передает его для использования клиенту вместе с другими параметрами. – клиент загружает с указанного DHCP-сервером IP-адреса TFTP сервера сначала PXE загрузчик — pxelinux. 0, с помощью которого загружается уже ядро операционной системы Linux — vmlinuz и образ файловой системы — initrd, включающий все необходимое для работы клиента. – загрузочные скрипты системы Linux получают c TFTP-сервера конфигурационные файлы, в которых описаны необходимые параметры для соединения клиента с терминальным сервером.
5.Инициализация терминального клиента
– в зависимости от параметров конфигурационного файла запускается RDP или ICA клиент, который устанавливает соединение с терминальным сервером.
Настройка сервера Windows 2003
Службы и сервисы, необходимые для работы «тонких» клиентов
Вы можете использовать в качестве терминального сервера:
Microsoft® Windows® Terminal Server
Citrix® MetaFrame®
Если Вы используете в качестве терминального сервера Windows® Terminal Server, выберите следующие службы и сервисы:
Terminal Server
Если Вы используете в качестве терминального сервера Citrix® MetaFrame®, выберите следующие службы и сервисы:
Citrix® MetaFrame®
Пакет файлов для загрузки по PXE
Настройка DHCP Server
Для настройки DHCP Server выполните следующие действия:
2. Нажмите кнопу Add or remove a role.
3. В открывшемся диалоговом окне Preliminary Steps нажмите кнопку Next.
4. В открывшемся диалоговом окне Configuration Options выберите элемент Custom Configuration и нажмите кнопку Next.
5. В списке Server Role выберите DHCP Server и щелкните на кнопке Next дважды.
6. В диалоговом окне Welcome to the new Scope Wizard нажмите кнопку Next.
7. В диалоговом окне Scope Name в полях Name и Description введите имя и описание, после чего нажмите кнопку Next.
8. В диалоговом окне IP Address Range выполните следующие действия для выдачи DHCP сервером IP адресов для тонких клиентов:
Введите Start IP Address (Начальный IP адрес)
Введите End IP Address (Конечный IP адрес)
Нажмите кнопку Next.
9. В открывшемся диалоговом окне Add Exclusions допускается указать диапазон адресов, которые не будут выделяться DHCP сервером. Нажмите кнопку Next.
10. В открывшемся диалоговом окне Lease Duration можете указать время использования IP-адреса тонкими клиентами. Нажмите кнопку Next.
11. В диалоговом окне Configure DHCP Options выберите No, I will configure these options later. Нажмите кнопку Next, затем кнопку Finish.
12. Подтвердите действие очередным нажатием кнопки Finish.
13. Выберите Start→Programs→Administrative Tools→Manage Your Server.
14. В открывшемся диалоговом меню выберите элемент Manage this DHCP server
15. В диалоговом окне выберите элемент Server Options. Нажав правую клавишу мыши, в открывшемся контекстном меню выберите Configure Options.
16. В списке выполните следующие действия:
Выберите пункт 066 Boot Server Host Name и укажите IP адрес TFTP сервера, на который устанавливали DHCP сервер
Выберите пункт 067 Bootfile Name и введите имя pxe-загрузчика, а именно pxelinux.0
17. Нажмите кнопку Apply.
18. В диалоговом окне выберите элемент Scope . Нажав правую клавишу мыши, в открывшемся контекстном меню выберите Activate.
Настройка DHCP сервера завершена.
Настройка TFTP Server
1. Выберите Start→Settings→Control Panel→Add or Remove Programs.
2. Нажмите кнопку Add/Remove Windows Components.
3. В списке Components выберите Remote Installation Services и нажмите кнопку Next.
4. Нажмите кнопку Finish и на запрос о перезагрузке выберите No. Перезагрузку сервера осуществите позднее.
Настройка Terminal Server
1. Выберите Start→Programs→Administrative Tools→Manage Your Server.
2. нажмите кнопку Add or remove a role.
3. В диалоговом окне Preliminary Steps нажмите кнопку Next.
4. В списке Server Role выберите элемент Terminal Server и нажмите кнопку Next дважды.
5. В открывшемся диалоговом окне Configure Your Server Wizard появится предупреждение о перезагрузке сервера. Нажмите кнопку Ok.
6. После перезагрузки нажмите кнопку Finish.
Настройка TFTP Server на автоматический запуск
2. Раскройте список Services and Applications и выберите элемент Services.
3. Справа в появившемся списке нажмите правую клавишу мыши на пункте Trivial FTP Daemon и в контекстном меню выберите Properties.
4. В закладке General в выпадающем меню Startup type выберите Automatic. Нажмите кнопку Apply, затем кнопку Ок.
Создание пользователей терминальных сессий
1. Нажмите правую клавишу мыши на ярлыке My Computer и выберите Manage.
2. В раскрывающемся списке Local Users and Groups выберите папку Users.
3. В появившемся справа списке пользователей нажмите правую клавишу мыши и в открывшемся контекстном меню выберите New User.
4. В диалоговом окне New User введите User name (Имя пользователя) и Password (Пароль). Допустимо отменить выделение User must change password at next logon (Пользователь должен изменить пароль при следующем подключении) и установить необходимые вам пункты: User cannot change password (Пользователь не может изменить пароль), Password never expires (Срок действия пароля никогда не истекает), Account is disabled (Учетная запись отключена). Нажмите кнопку Apply, затем кнопку Ок.
5. В списке выберите папку Groups, и в списке справа нажмите правой клавишей мыши на имени группы Remote Desktop Users, далее выберите Propeties.
6. В появившемся меню выберите General, нажмите кнопку Add и введите имя пользователя, которому Вы хотите разрешить терминальный доступ к серверу. Затем щелкните на кнопке Check Names и подтвердите свой выбор нажатием на кнопку Ок.
7. Нажмите кнопку Apply и кнопку Ок.
Копирование файлов, необходимых для загрузки «тонких» клиентов
1. Создайте папку C:tftpdroot.
2. Скопируйте в нее файлы pxelinux.0, vmlinuz, initrd, thinstation.conf.network.
3. Создайте папку с:tftpdrootpxelinux.cfg.
4. Скопируйте файл default в папку c:tftpdrootpxelinux.cfg
5. Теперь необходимо отредактировать конфигурационные файлы. Подробное опи¬са¬ние действий представлено в части 3. «Изменение параметров конфи¬гура¬ци¬он¬ных файлов».
Настройка сервера для передачи звука тонким клиентам
Внимание!
Для передачи звука «тонким» клиентам необходимо, чтобы на сервере была установлена ОС Microsoft® Windows® 2003, звуковая карта и необходимые драйверы.
1. Выберите Start→Settings→Control Panel
2. Откройте Sounds and Audio Devices и установите выделение в пункте Enable Windows Audio. Нажмите кнопку Ok.
3. На запрос о перезагрузке нажмите кнопку Yes.
4. После перезагрузки вызовите Microsoft® Management Console (Start→Run→mmc).
5. Затем выполните следующие действия: File→Add/Remove Snap-in и нажмите кнопку Add.
6. Выберите Group Policy Object Editor и нажмите кнопку Add, затем последовательно нажимайте на кнопки Finish, Close,Ok.
7. Откройте элемент Local Computer Policy→Computer Configuration→Administrative
Templates→Windows Components→Terminal Services→Client/Server data redirection.
8. В списке справа правой клавишей выберите Properties в пункте Allow audio redirection.
9. Выделите пункт Enabled и нажмите кнопку Apply, затем кнопку Ок.
Требования ПК:
Оперативная память не меньше 256 Mb
Флешка не меньше 128 Mb
Чтобы Флешку сделать загрузочной используйте файл →
Технология NX, разработанная фирмой Nomachine, дает новые возможности для связи и способна оживить старые компьютеры в роли тонких клиентов.
Прежде чем перейти непосредственно к описанию NX, перечислю некоторые тенденции, которые сегодня становятся очевидными для многих крупных компаний нашей страны:
1. Компьютерная техника дешевеет и становится более доступной, чем раньше. При этом её производительность удваивается каждые 1,5-2 года согласно закону Мура. Это приводит к накоплению техники, не выработавшей свой ресурс, но уже устаревшей.
2. Разработанные на предприятиях силами программистов отделов АСУ в перестроечные годы клиент-серверные приложения еще работают на старой технике, но уже не соответствуют требованиям времени.
3. Современные программное обеспечение и операционные системы не заставить работать на компьютерах с процессорами прежних поколений (i386, i486 и т. д.).
4. Не секрет, что во многих организациях нашей страны с давних времен незаконно используются многие программы и ОС, которые сотрудники устанавливали по своей инициативе. Вначале это рассматривалось как само собой разумеющееся обстоятельство, потом оправдывалось финансовым положением. Сейчас, когда наша страна вступает в ВТО, правительство вынуждено такую ситуацию спешно исправлять, в связи с этим усилилось давление на предприятия со стороны внутренних органов с требованием отказаться от незаконно используемых ПО и ОС.
Очевидно противоречие между вторым и третьим пунктами: необходимо или найти способ, позволяющий эффективно задействовать старую технику для выполнения современных задач, или отказаться от этой техники. Если имеется достаточно средств, то выбор понятен. Но что делать, если средств нет или нет возможности списать такую технику, да и просто выкидывать жалко? И как решать не менее острую проблему «лицензионной чистоты» используемых программ, о которой говорится в четвертом пункте?
На помощь приходят терминальные технологии, которые позволяют задействовать старые компьютеры, а также частично снять вопросы «лицензионной чистоты», если применять решения на базе продуктов 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.
Рисунок 1. Взаимосвязь компонентов NX
Для того чтобы добавить в образ пакет 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-протокола.
В основе идеи разностной компрессии лежит проект Differential X Protocol Compressor (DXPC) , созданный в 1995 году, там уже упоминаются термины клиентского и серверного прокси. Nomachine подхватила идею и разработала свой собственный продукт. Заявляется о 10-кратном превосходстве NX над стандартной библиотекой ZLIB.
Nomachine также разработала умный механизм кэширования X-трафика, который использует знакомый по прокси-серверам термин «попаданий в кэш». Этот механизм сокращает сетевой трафик при передаче одних и тех же блоков данных, а при изменении этих блоков данных потока вычисляет и передает только их разницу.
До 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 открыла исходные коды большинства своих наработок и библиотек, их можно скачать всем желающим с . Сборки от самой 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-lfs_hint.diff
NX-lfs_hint.diff
Для сборки понадобятся следующие пакеты (их можно установить из вашего дистрибутива Linux): libjpeg-devel, libpng-devel, openssl-devel, netcat, expect. Описание сборки можно найти также здесь .
# Накладываем NX patch
patch -p0
# Собираем 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
#!/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
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"
Там же можно на первое время включить возможность ведения лога:
Теперь можно установить клиент Nomachine NX на любой компьютер Linux (можно использовать и KNX) или Windows и проверить работу NX-сервера. C сервером можно работать как в режиме приложений, так и в режиме удаленного рабочего стола.
Рисунок 2. NX-сессия KDE в режиме рабочего стола из Windows XP
Настройка и создание образа 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 достаточно хорошо откомментированы, но вот сам процесс настройки и последовательность действий не всегда очевидны, так что некоторые трудности, с которыми мне пришлось столкнуться, и тонкости я все-таки упомяну.
Привет, сегодня мы будем собирать последнюю версию загрузочного образа для тонких клиентов — Thinstation! В данной статье мы соберем загрузочный образ Thinstation, настроим и сервер для загрузки сего образа тонкими клиентами по сети, посредством протокола . Данная статья расчитана на более продвинутых пользователей, у которых есть понимание того, что такое , у кого в парке есть хотя бы одна машина с и базовый багаж знаний работы с nix подобными системами. Для тех, у кого нет таких знаний будет статья о том, как собрать такой образ из готового загрузочного диска .
Что у нас должно быть
- Lunix машина (для сборки образа на ней)
- DHCP сервер
- Укромное местечко для TFTP сервера
- Собственно тонкие клиенты
- Терминальный (или любой другой сервер) для того, что бы эти тонкие клиенты туда подключались.
Оговорюсь относительно последнего пункта. Тонкие клиенты на Thinstation могут работать не только в режиме подключения к терминальному серверу, но и как самостоятельные бездисковые рабочие станции на ОС Linux с полным набором софта. Правда в пределах этой стати, мы рассмотрим только первый и самый распространенный вариант.
Приступаем к сборке. Подключаемся к нашей Linux машине (в данном случае я использую виртуальную машину на Ubuntu 14.04 на VMware Workstation, так очень удобно). Первым делом установим git, для того, что бы забрать последнюю версию Thinstation.
Apt-get install git-core
Далее перейдем в папку, в которой будем разворачивать окружение для сборки образа и начнем его качать (это довольно длительный процесс, около 40 минут. Свободного дискового пространства нам понадобится около 3GB)
Cd /home/verbin/Documents/ git clone --depth 1 git://github.com/Thinstation/thinstation.git
После окончания загрузки переходим в директорию с этим добром и заупскаем chroot скрипт, который соберет в нашу систему недостающие пакеты и подготовит инфраструктуру для последующей сборки.
Cd thinstation ./setup-chroot
По окончанию сего процесса вы увидите примерно такой вывод в консоле. Это означает что все готово для сборки нашего первого и пока что «толстого» образа. Толстого — то есть с полным набором пакетов и драйверов, для первой загрузки станции и последующего определения только необходимых нам составляющих и исключения лишних из образа.
Все работы по сборке образа Thinstation должны проводится в данной виртуальной среде. Для скрытия приветствия (README) нажимем Q и попадаем в командную строку chroot
Переходим в папку ts/5.x/ в которой находятся конфиги и скрипт сборки. Краткий ликбез по требующим внимания файлам.
- build.conf — Корневой конфигурационный файл, в котором указываются необходимые драйвера, параметры и пакеты для сборки образа.
- thinstation.conf.buildtime — Конфигурационный файл уже Thinstation образа, указанные в нем параметры будут «зашиты» в образ. Воздержимся от использования оного, лучше оставим это на потом и будем использовать обычные конфигурационные файлы находящиеся на TFTP сервере вместе с образом. Так — более гибко.
- boot-images/ — Директория в которой после сборки образа появятся папки с образами нашего Thinstation для разных типов загрузки
- boot-images/pxe/ — Собственно директория в которой после окончания сборки образа будут находится необходимые нам файлы образа для загрузки по PXE.
Сборка «толстого» образа
Сразу оговорюсь о том, что можно закоментировать пакет «package chrome» в buid.conf, так как он попросту не нужен и является одним из самых «тяжелых», значительно повышая вероятность того, что у вашего тонкого клиента не хватит оперативной памяти для запуска (так же размер самого образа вырастет мегабайт на 20-30).
Так же опишу несколько важных опций в buid.conf из раздела настроек (param)
- param rootpasswd — Пароль для пользователя root в образе (для доступа к административным функциям)
- param xorgvncpasswd — Пароль для подключения к станциям по VNC (если этот пакет был включен при сборке «package xorg7vnc» )
- param bootresolution — Разрешение экрана при загрузке
- param desktop file: — Стандартный фон (рабочий стол и загрузка системы)
- param httpproxy — Настройка прокси (если загрузка файлов доступна только через proxy. В значении можно указать и авторизацию user:password@proxy:port)
Приступаем к сборке следующей командой.
./build --allmodules
Во время данного процесса могут появится запросы подтверждения загрузки недостающих компонентов, соглашаемся Y. Пока ждем окончания сборки — сконфигурируем TFTP сервер и DHCP для PXE загрузки с него (Cisco DHCP или Windows DHCP).
Сборка завершена, теперь копируем файлы образа из папки boot-images/pxe/ (полный путь: thinstation/ts/5.2/boot-images/pxe/) на наш TFTP сервер. Вполне вероятно что наш образ полностью не запустится. Нам нужно что бы образ загрузился до того состояния, когда на экране будет фоновое изображение и прогрессбар загрузки, в этот момент нужно нажать Ctrl+Alt+F3, попадаем в консоль (в противном случае, если станция не запустится даже до этого шага — это означает что не хватило оперативной памяти (убираем лишние модули в build.conf).
Итак, мы попали в консоль нашего толстого образа и видим приглашение войти (вводим root / pleasechangeme — если не меняли это в buid.conf). Далее выполняем команду
Hwlister.sh
которая сгенерирует нам файлы профиля конкретного железа тонкого клиента (module.list) и графических режимов (vbe_modes.list). Забираем эти файлы на нашу Lunix машину где проводится сборка образа (любым удобным способом, я показываю пример как это сделать через наш TFTP сервер).
Cd / tftp -p -l module.list -r module.list 192.168.1.3 tftp -p -l vbe_modes.list -r vbe_modes.list 192.168.1.3
Создаем папку для профилей нашего тонкого клиента и кладем в нее файлы module.list и vbe_modes.list
Mkdir thinstation/ts/5.2/machine/Thinclient
Финальная конфигурация и сборка
В файле build.conf
- machine Thinclient — Название профиля оборудования по которому будет производится сборка.
- package xorg7-vesa — Стандартный видеодрайвер (рекомендуется включать его в сборку).
- package freerdp или package rdesktop — Выбираем RDP клиент который будем использовать (можно добавить оба).
- package xorg7vnc — VNC сервер для удаленного управления клиентами.
- param fastboot true — Значительно ускоряет загрузку бездисковых систем но могут быть проблемы из-за не совместимости с сетевой картой
В файле thinstation.conf.buildtime
- DONT_VT_SWITCH_STATE=TRUE — Запретит переключение в консоль посредством Ctrl+Alt+F3
- DONT_ZAP_STATE=TRUE — Запрет переинициализации графического режима через Ctrl+Alt+Backspace (тоже лазейка к консоли)
Начинаем финальную сборку находясь в папке thinstation/ts/5.2/ и
./setup-chroot ./build
Полученный образ кладем в корень TFTP сервера и там же создаем стандартный общий конфигурационный файл thinstation.conf.network в который добавим параметры подключения к терминальному серверу (обратите внимание — для freerdp клиента и rdesktop указаны разные команды подключения по RDP).
SESSION_0_TITLE="Terminal Server rdesktop" SESSION_0_TYPE=rdesktop SESSION_0_SCREEN=1 SESSION_0_RDESKTOP_SERVER=192.168.1.10 SESSION_0_RDESKTOP_OPTIONS="-d "DOMAIN" -u "USER"" SESSION_0_AUTOSTART=On SESSION_1_TITLE="Terminal Server freerdp" SESSION_1_TYPE=freerdp SESSION_1_SCREEN=1 SESSION_1_SCREEN_POSITION=2 SESSION_1_FREERDP_SERVER=192.168.1.10 SESSION_1_FREERDP_OPTIONS="-d "DOMAIN" -u "USER"" SESSION_1_AUTOSTART=On
Пример классического thinstation.conf.network можно найти . В следующих статьях рассмотрим более подробную конфирурацию тонких клиентов, индивидуальные конфигурационные файлы для разных станций и прочее.
