Андрей Маркелов
Постановка задачи
Работа сотрудника отдела автоматизации – это постоянная борьба с проблемами
и решение задач, которые попеременно подкидывают пользователи, разработчики
эксплуатируемого программного обеспечения и руководство организации. И если два
первых направления работы – это просто «борьба за живучесть корабля», то
последнее, как правило, – поступательное движение вперед. Как раз в ходе
решения одной из таких задач и появилась на свет данная статья.
Итак, перед отделом автоматизации была поставлена
задача в короткие сроки ввести в строй два новых удаленных офиса, каждый
численностью в пять-десять человек. Оба офиса и «голову» связали посредством
технологий VPN в одну сеть. Минимальная ширина канала между тремя точками
составила 256 Кбит, что вполне удовлетворило наши потребности. В каждом из
офисов был развернут дополнительный контроллер домена Windows 2000, а для
минимизации трафика домен разделили на несколько сайтов. Все вышеописанное
является стандартным решением, и здесь я не ожидал никаких сюрпризов. Главным
вопросом для нас было, как поведет себя основной инструмент работы сотрудников
организации – комплексная система автоматизации, при работе с которой и в
пределах одной площадки хватало проблем. Изначально ориентированная на Novell/BTRIVE
6.15 после миграции сети на Windows, она работала под Windows/Pervasive.SQL 7.
После недели тестирования этого основного
бизнес-приложения организации, оказалось, что разработчик и вовсе не оставил
нам выбора, так как использование встроенного терминального режима
автоматизированной системы по ряду причин нас не устроило. Опять же, из-за
особенностей функционирования в качестве терминального сервера была выбрана
платформа Microsoft Windows Server. Тестирование же решений компании Citrix мы
не проводили, так как работа с «родными» терминальными службами Windows нас
вполне удовлетворила, а использование надстроек только увеличивает стоимость
всей системы.
Когда с серверной частью все определилось, встал
вопрос по клиентской составляющей системы. В первую очередь хотелось бы снизить
необходимость в администрировании пользовательских машин, так как постоянное
присутствие системного администратора на удаленных площадках не планировалось.
Кроме того, желательным представлялось уменьшить стоимость решения, которая
возросла из-за необходимости покупки терминальных лицензий. Также необходимо
было учесть намерение разместить в офисах устаревшие компьютеры класса
Celeron-400 с ОЗУ от 32 до 64 Мб.
Идеальным со всех точек зрения оказалось
использование в качестве рабочих мест бездисковых станций с загрузкой по сети.
При этом единственным компьютером, требующим внимания администратора,
становится дополнительный контроллер домена в каждом офисе, управляемый по VNC.
Само собой, что в рамках данной статьи я оставляю за пределами внимания
оборудование и ПО, обеспечивающее шифрование трафика, доступ в Интернет и т. д.
В роли ОС, которая будет по сети загружаться на
рабочие станции, я выбрал Linux – что обеспечивает лицензионную чистоту решения
(по крайней мере на сегодняшний момент). Доступ к рабочему столу Windows 2003
должен был осуществляться при помощи разработки проекта http://www.rdesktop.org, который стал
стандартом для решения данной задачи. В качестве же необходимых для такой
загрузки серверов DHCP и TFTP логично было бы использовать уже имеющиеся в
каждом сайте дополнительные контроллеры домена Windows 2000. Благо существуют
как бесплатные реализации DHCP/TFTP под эту операционную систему, так и
встроенные сервера. При этом TFTP наличествует в рамках службы Remote Installation
Services (RIS).
Сетевые карты клиентских машин, естественно,
должны поддерживать возможность загрузки по Etherboot/PXE. В отдельных случаях из-за
несовместимости оборудования я допускал использование загрузчика,
расположенного на дискете.
Выбор реализации Linux
При выборе варианта ОС Linux с возможностью загрузки по сети в первую
очередь я обратил внимание на уже готовые дистрибутивы подобной направленности
со встроенным пакетом rdesktop. Наиболее известный из них – NetStation (netstation.sourceforge.net),
который застыл в виде бета-версии с конца 2002 года, и его наследники: PXES (pxes.source forge.net), Thinstation
(thinstation.sourceforge.net),
и DIET-PC (diet-pc.sourceforge.net).
При этом DIET-PC предназначен для пользователей, хорошо знакомых с ОС Linux,
что сразу исключает его из области рассмотрения. Поскольку процедура его
настройки весьма кропотлива, и в DIET-PC присутствует достаточно много
настроек, которые простому смертному, не Linux-гуру, никогда не пригодятся.
PXES является наиболее «продвинутым» с большим числом дополнительных
возможностей, включая собственную графическую среду, что также лишнее в моем
случае. В моей конфигурации клиент, минуя промежуточные меню, должен был сразу
загружать удаленный рабочий стол и выходить на окно ввода пароля Windows 2003 Server.
Таким образом, я обратил внимание на оставшийся дистрибутив – Thinstation.
Кратко рассмотрим его
возможности:
n поддержка протоколов X, RDP, VNC, SSH, Telnet,
ICA и Tarantella;
n возможность использовать браузер Firefox;
n загрузка по сети при помощи Etherboot, PXE (при
помощи Etherboot-загрузчика или PXELinux), HDD, CD или floppy-диска. К
сожалению, отсутствует поддержка USB-flash;
n работа на ПК класса x86-100 МГц c ОЗУ 16 Мб;
n наличие pre-build образа, и возможность
самостоятельной сборки через веб-интерфейс;
n поддержка локальных дисков, USB- и
LPT-принтеров.
Из всех вариантов загрузки наиболее простой – это
PXE при помощи Etherboot-загрузчика. В рамках этой статьи мы пойдем по самому
простому пути будем использовать заранее скомпилированный образ.
Установка и первоначальная
настройка
Начнем с того, что скачаем со странички http://struktur.
kemi.dtu.dk/thinstation/download, доступной по ссылке с официального сайта,
последний из архивов, в моем случае – это был
Thinstation-2.0.2-prebuilt-NetBoot.zip. Архив содержит в себе все, что
необходимо, включая TFTP/DHCP-сервер Tftpd32, который удобен при первоначальной
настройке и конфигурировании. Если вы будете его использовать, то я бы
порекомендовал сразу же обновить его с домашней странички, где имеется более
свежая версия. Кстати, Tftpd32 (http://tftpd32.jounin.net)
– сама по себе отличная программа. Причем настолько, что даже рекомендуется Cisco
для некоторых потребностей клиентов компании.
Развернув архив, мы получаем пять
директорий:
n BootDisk – образ дискеты с
Etherboot-загрузчиком, для ПК, с неподдерживаемыми сетевыми картами;
n BootPXE – загрузчик через PXE для эмуляции Etherboot;
n BuildFiles – примеры конфигурационных файлов;
n TFtp – сервер Tftpd32;
n TftpdRoot – корневая директория TFTP-сервера.
Итак, первым делом запускаем
самораспаковывающийся архив thinstation.nbi (autoextract).exe, содержащий
один-единственный файл thinstation.nbi, архив сделан для того, чтобы у вас была
возможность ознакомиться с «CITRIX(R) LICENSE AGREEMENT».
Теперь копируем TFtp и TftpdRoot на
Windows-сервер в нашем сегменте сети. В качестве такого сервера при
использовании Tftpd32 может выступать любая Windows-машина со статическим
IP-адресом.
Допустим, мы скопировали обе директории на диск
C:\. Запускаем на исполнение C:\TFtp\Tftpd32.exe. Внешний вид окна программы
представлен на рис. 1. Необходимо задать параметры сервера. Нажимаем кнопку «Settings»
и прописываем в качестве «Base directory» значение «C:\TftpdRoot». Далее идем
на вкладку «DHCP server». Там необходимо указать начальный IP-адрес, выделяемый
DHCP-сервером («IP pool starting address»), размер пула адресов («Size of pool»),
маску подсети («Mask»), имя файла с Etherboot-загрузчиком(«Boot file»), в нашем
случае это thinstation. nbi.zpxe. Нажимаем кнопку «Save» для сохранения
настроек и сворачиваем приложение.
Рисунок 1. TFTP/DHCP-сервер
Tftpd32, который удобен при первоначальной настройке
Все готово для работы. Вы можете попробовать
включить одну из машин с сетевой картой, поддерживающей загрузку по протоколу
PXE, не забыв выставить порядок загрузки в BIOS станции. При включении машина
должна получить IP-адрес из выделенного диапазона и загрузить по протоколу TFTP
файл thinstation.nbi.zpxe. Он содержит загрузчик, эмулирующий работу сетевой
карты с поддержкой Etherboot. Затем управление передается загрузчику, который в
свою очередь еще раз запрашивает по DHCP адрес, и загружает файл с именем,
совпадающим с названием файла самого загрузчика минус расширение zpxe, то есть thinstation.nbi.
Данный файл и есть образ Thinstation. Когда образ загружен, Thinstation
пытается загрузить из корневой директории TFTP-сервера конфигурационный файл thinstation.conf-<MAC-адрес
клиента>, затем thin station.conf-<IP-адрес клиента>. Если такие файлы
найдены, то Thinstation объединяет их содержимое с общим конфигурационным
файлом thinstation.conf.network, который в отличие от двух вышеперечисленных
обязан присутствовать на TFTP-сервере.
Постарайтесь избежать конфликтов между главным
файлом настроек и специфическим к группе или конкретной станции. Кроме того,
можно объединять одним конфигурационным файлом целые группы IP- и MAC-адресов.
Это делается при помощи файла thinstation.hosts, имеющего следующий формат:
# HOST MAC GROUPS COMMENTS
ws-oper1 0002B3655065 hi_res #
Операционист №1
ws-oper2 0002B3651075 hi_res #
Операционист №2
ws-oper3 0002B365A021 hi_res
ssh_en # Операционист №3
В данном примере предполагается, что имеются два
файла thinstation.conf.group-hi_res и thinstation.conf.group-ssh_en.
Настройки, прописанные в первом файле,
применяются ко всем трем станциям, а настройки из второго – только к компьютеру
ws-oper3.
То, как отображаются сессии терминальных клиентов
в оснастке диспетчера терминальных служб, вы можете увидеть на рис. 2.
Рисунок 2. Сессии тонких
клиентов в оснастке диспетчера терминальных служб
Клиенты с именами вида ts_<MAC-адрес> – это
как раз клиентские терминалы, работающие под управлением Thinstation. Клиенты с
именами вида P<IP-адрес> работают под управлением дистрибутива PXES,
рассмотрение которого выходит за рамки данной статьи.
Рисунок 3. Меню Thincstation
Далее я приведу простой, но вполне
работоспособный вариант конфигурационного файла с комментариями.
# Опции сессий
#
# Первая сессия должна
обязательно начинаться с номера 0.
# При отсутствии
необходимости выбора сессии, например, когда вы используете только rdesktop,
# можно снять комментарий со
следующего параметра, и исключить меню выбора сессий.
#AUTOSTART=On
SESSION_0_TITLE="Windows
2003 terminal server (16 bit color depth)"
SESSION_0_TYPE=rdesktop
SESSION_0_RDESKTOP_SERVER=192.168.0.1
SESSION_0_RDESKTOP_OPTIONS="-u
Administrator -p password -a 16"
SESSION_1_TITLE="VNC server"
SESSION_1_TYPE=vncviewer
SESSION_1_VNCVIEWER_SERVER=192.168.0.2
SESSION_2_TITLE="Telnet server"
SESSION_2_TYPE=telnet
SESSION_2_TELNET_SERVER=192.168.0.3
SESSION_3_TITLE="SSH server"
SESSION_3_TYPE=ssh
SESSION_3_SSH_SERVER=192.168.0.4
# Общие опции
#
# Раскладка клавиатуры. В
случае работы с rdesktop она роли не играет
KEYBOARD_MAP=en_us
# Опции XServer
#
SCREEN_RESOLUTION="1024x768"
SCREEN_COLOR_DEPTH="16"
SCREEN_HORIZSYNC="30-64"
SCREEN_VERTREFRESH="56-87"
MOUSE_RESOLUTION=100
# Опции печати
#
PRINTER_0_NAME=usb
PRINTER_0_DEVICE=/dev/usb/lp0
PRINTER_2_TYPE=U
В заключение статьи, хочу сказать, что после
отладки работы с терминальными клиентами, лучше всего передать функции TFTP- и
DHCP-серверов программному обеспечению, способному работать в режиме службы на Windows
NT/2000/2003/XP, например, как я уже говорил, «родным» службам Windows, либо
воспользоваться соответствующими сервисами любой другой операционной системы.
Кроме того, на сайте проекта
thinstation.sourceforge.net при помощи веб-интерфейса вы можете самостоятельно
перекомпилировать образ Thinstation без загрузки исходных кодов, включив
какие-либо отсутствующие в prebuild образе функции, например браузер, или
исключив ненужные модули.
Рисунок 4. Самостоятельное
построение образа через веб-интерфейс TS-O-Matic
