Thinstation готовые сборки. Загрузка операционных систем. Что у нас должно быть

Итак, что бы сделать тонкий клиент из обычного компьютера много усилий не надо. Для минимального понимания данной статьи нужно иметь хотя бы мутное отдаленное представление о:

Время идет, железо устаревает физически и морально, на покупку новых компов в организации у руководства денег как обычно нет, на этот случай есть возможность "вдохнуть жизнь" в музейный хлам. Для тонкого клиента подойдет любой раритет с частотой одноядерного процессора от 1 ГГц и ОЗУ 128 Мб, и самая важная деталь это материнская плата с сетевокй картой поддерживающие загрузку PXE. Жесткий диск, дисковод нам не понадобятся вообще, мы же будем делать настоящий тонкий клиент, а не жалкую пародию! ;)

Как сделать тонкий клиент из старого компьютера (способ 2)

Подготовка тонкого клиента и дополнительного оборудования.

Конечно сначала соберите более или менее живой агрегат из барахла, как уже говорил выше жесткий диск нам не понадобится вообще, что касается дисковода и другой переферии, тут уже все зависит от поставленной задачи с которой должен справляться наш тонкий клиент, мне на работе из переферии хватило только монитр, клавиатура, мышь, USB устройства руководство посчитало излишним (естественно кроме клавиатуры и мыши), т.к. стремление сделать систему более замкнутой превзашло хотения юзверей (как не странно я с ними в этом согласился, все функции съемных носителей заменяет почта и внутренняя файлопомойка, а тем кому нужно работать с большими файлами и производительность от ПК не переводились на тонкие клиенты вообще). После того как убедились что железка работает необходимо в БИОСе произвести настройку загрузки с сетевой карты и отключить все остальные методы загрузки. Делается это по разному на различных мат. платах, но суть сводится к одному.

Для работы тонкого клиента необходим сервер который будет выступать в роли удаленного рабочего места к которому наш тонкий клиент подключется. Подробно останавливаться на рассмотрении всех типов удаленного рабочего места я не буду, остановимся на самом популярном Сервере терминалов от Microsoft. Будем считать что у вас уже имеется сервер на котором развернут Сервер терминалов , к примеру, на Windows Server 2008 R2 . Если нет надобности подключать пользователей за пределами организации, тогда будем рассматривать настройку подключения только "внутри". Пусть у нашего сервера терминалов внутренний IP 192.168.0.5 .

DHCP

Теперь настроим DCHP для раздачи ip адресов нашим тонким клиентам и дополнительных параметров. Как настроить DHCP на Windows Server 2008 можно прочесть здесь, для Linux Server вот здесь. В этой статье я укажу только то, что необходимо донастроить уже к готовой схеме.

Для настройки в Windows Server 2008 R2 : перейдем в параметры области

Выбираем Настроить параметры и добавляем парметр:

066 Имя узла сервера загрузки и укажем IP адрес нашего TFTP сервера (в нашем случае 192.168.0.4)

067 Имя файла загрузки, впишем pxelinux.0

и не забудьте рестартануть службу DHCP.

Настройка в Ubuntu Server :

будет позже

TFTP сервер

Настройки , в Ubuntu Server 14.04 LTS . Также можно поспользоваться программой tftpd32 для Windows систем

Дистрибутив Thinstation

Ознакомиться с возможностями данного дистрибутива можете на сайте разработчика http://thinstation.github.io/thinstation/ . Для того что бы получить рабочий дистрибутив с возможностью загрузки с сервера TFTP необходимо его собрать, я не буду рассматривать как это делается, а воспользуюсь уже готовым собранным дистрибутивом с возможностью загрузки по сети PXE версия сборки (зеркало) собранная с опцией allmodules (за это отдельная благодарность nik0el). Скачаваем архив и распаковываем, теперь надо раскидать файлы. Я рассмотрю на примере настроеннго TFTP сервера в Windows Server 2008 R2 .

Закинем все файлы и папки как есть в C:\TFTPRoot

Теперь приступим к настройкам основных файлов, которые вы будите править под себя:

thinstation.conf.network - отвечает за дефолтные настройки подключения для всех тонких клиентов

thinstation.conf.sample -

thinstation.hosts - указывает индивидуальные настройки

thinstation.conf.group-... - вместо точек указано название группы (1280@75 - разрешение и частота, user - имя тонкого клиента присвоенного в файле thinstation.hosts и т.д.)

Ниже приведу немного отредактированные параметры которые согласно нашим ip адресам:

thinstation.conf.network

SCREEN=0
WORKSPACE=1SESSION_0_TITLE="Terminal Server"
SESSION_0_TYPE=rdesktop
SESSION_0_SCREEN=1
SESSION_0_RDESKTOP_SERVER=192.168.0.5
SESSION_0_RDESKTOP_OPTIONS="-u "user""
SESSION_0_AUTOSTART=On#SESSION_#_TITLE="Big Bad Server Donald"
#SESSION_#_TYPE=freerdp
#SESSION_#_SCREEN=1
#SESSION_#_SCREEN_POSITION=2
#SESSION_#_FREERDP_SERVER=192.168.1.1
#SESSION_#_FREERDP_OPTIONS="-u username -p password"
#SESSION_#_AUTOSTART=OffRDESKTOP_SOUND=Off
RDESKTOP_FDD=Off
RDESKTOP_CDROM=Off
RDESKTOP_HDD=Off
RDESKTOP_USB=Off
RDESKTOP_1394=Off
RDESKTOP_COM3=Off
RDESKTOP_COM4=Off
RDESKTOP_SLOWLINK=On
RDESKTOP_COMPRESSION=On
RDESKTOP_COLOR_DEPTH="16"
#RDESKTOP_DOMEN=mydomen
RDESKTOP_USB_NO_MOUNT_DIR=OnFREERDP_USB_NO_MOUNT_DIR=On # Mount USB Drive On/Off
FREERDP_USB=Off # Mount USB Drive On/Off
FREERDP_SOUND=On # Audio, On/Off
FREERDP_KEYMAP=419 # Keymap number
FREERDP_CONSOLE=Off # Conect to console, On/Off
FREERDP_SLOWLINK=Off # Slow Network Link, On/Off
FREERDP_COMPRESSION=Off # RDP Compression, On/Off
FREERDP_CDROM=Off # CDROM Drive present, On/Off
FREERDP_CDROM_SATA=Off # SATA CDROM present, On/Off
FREERDP_FDD=Off # Floppy Drive present, On/Off
FREERDP_USBFDD=Off # USB Floppy present, On/Off
FREERDP_HDD=Off # HDD Drive present, On/Off
FREERDP_1394=Off # FireWare HDD present, On/Off
FREERDP_COM3=Off # Redirect COM1, On/Off
FREERDP_COM4=Off # Redirect COM2, On/OffKEYBOARD_MAP=en_us
TIME_ZONE="Europe/Moscow"
AUDIO_LEVEL=67
AUTOPLAYCD=On
DAILY_REBOOT=On
CUSTOM_CONFIG=off
RECONNECT_PROMPT=menu
NET_TELNETD_ENABLED=On
SCREEN_RESOLUTION="1024x768"
SCREEN_HORIZSYNC="30-65"
SCREEN_VERTREFRESH="75"
SCREEN_COLOR_DEPTH="16"
MOUSE_PROTOCOL=IMPS/2
MOUSE_RESOLUTION=100
MOUSE_ACCELERATION="1"
X_DRIVER_OPTION1="swcursor On"
PRINTER_0_NAME=parallel
PRINTER_0_DEVICE=/dev/printers/0
PRINTER_0_TYPE=P
PRINTER_1_NAME=usb
PRINTER_1_DEVICE=/dev/usb/lp0
PRINTER_1_TYPE=U

thinstation.hosts

# NAME MAC GROUP #COMMENT #thinstation01 0013D409A812 1024@75 cdrom fdd usb #192.168.0.21 user 000A5E1ADCAA 1280@60 cdrom usb #192.168.0.10

здесь мы присваиваем имя для мак адреса тонкого клиента и указываем группы настроек в примере это группа с настройками монитора, привода и usb портов.

Злоключение

Теперь убедитесь, что сервера запущены и работают. Стартуйте тонкий клиент, после загрузки дистрибутива и его полного запуска откроется окно ввода имени пользователя и пароля для входа на наш сервер терминалов. Я в примере использовал для подключения клиент rdesktop , а так их порядка 10 разновидностей которые можно выбрать и настроить под себя.

Есть второй способ описанный в статье

Часть первая: Немного лирики

Нижеследующий текст автора не претендует на истину в последней инстанции и по нему не стоит судить о среднестатистическом уровне IT инфраструктуры в небольших компаниях нашей необъятной страны. Статья написана по мотивам общения с многочисленными знакомыми IT-шниками (в основном уровня «студент» и «только что из института»), начинающих свою карьеру с эникейщика в небольших компаниях.

Давайте представим себе среднестатический офис небольшой торговой фирмы с точки зрения IT:

• несколько десятков слабеньких компьютеров для секретаря, менеджеров, бухгалтерии и, конечно, главного Босса;
• одна-две-три машины, выполняющих роли:
  • домен-контроллера windows (нередки случаи, когда в сети компании отсутствует даже домен, а все компьютеры работают в одно-ранговой сети);
  • файлового сервера;
  • почтового сервера (вместо него иногда используют внешние бесплатные почтовые сервера, начиная от mail.yandex.ru и gmail.com и кончая десятидолларовым хостингом на N почтовых ящиков);
  • http-прокси для фильтрации доступа ко внешним ресурсам и логирования «куда кто ходит» (часто отсутствует)
  • маршрутизатора/файрвола на границе с внешней сетью для ограничения доступа наружу и наоборот (часто в качестве пограничного маршрутизатора используется любой SOHO-роутер начального уровня ценой до 100 долларов, он же выполняет роль DHCP сервера (для динамической раздачи IP адресов рабочим станциям сотрудников);
  • другие вещи, список которых может быть довольно большим;
• несколько принтеров, часто подключенных локально к рабочим станциям сотрудников и расшареных по сети стандартными средствами Windows (как вариант, принтеры могут быть сетевыми изначально или же подключены через аппаратные принт-сервера).
• в продвинутых случаях - один терминальный сервер (под Windows) для бухгалтерии (на нем крутится 1C а там же лежит база данных оной, а бухгалтеры, подключаясь к серверу терминалов через стандартные средства Windows (remote desktop), работают с ней на терминальном сервере (локально), что, во-первых, дает больше удобства, а во-вторых, ускоряет работу самой 1C (обычно же 1С с базой установлена на компьютере одного из бухгалтеров, а остальные подключаются к ней со своих компьютеров, работая с расшареной по сети базой).

Все это хозяйство связано в единую локальную сеть посредством одного/нескольких дешевых коммутаторов на 100Мбит. И работает это в едином домене NT/Active directory (хотя встречаются варианты одноранговых рабочих станций безо всяких доменов).

На всех машинах с Windows обычно установлен (хотя и тут бывают исключения) какой-то антивирус. Часто встречается не сетевые версии этих программ (тот же Avast), хотя, опять таки в более продвинутых (с точки зрения IT) конторах, стоят сетевые версии антивирусов с централизованным управлением и обновлением антивирусных баз.

Приведенные выше ситуации варьируются от случая к случаю, так как на конфигурацию сети, железа и софта влияют как знания/умения/желания (и, что немаловажно, лень) системного администратора(ов), так и понимание начальства (в лице главного Босса) «чем же именно этот наш системный администратор занимается, когда все и так отлично работает» (из последнего вытекает - сколько денег выделяется на оборудование для IT и зарплату будущего специалиста). Если денег выделяется мало (а так обычно и бывает — управленцы торговых компаний от IT обычно далеки и слабо понимают, что же там происходит), то поднабравшийся знаний эникейщик уходит в другую компанию. На место ушедшего приходит очередной студент и все повторяется по новой.

Думаю излишне говорить, что в подобных конторах отдел системного администрирования состоит из одного человека, который совмещает в себе инженера по прокладке/поддержанию офисной сети, системного администратора как такового (т.е. ту самую личность, что отвечает за работоспособность серверного парка на программном и аппаратном уровнях и внедрением нового функционала) и эникейшика - «мальчика на побегушках» — который занимается разрешением проблем у пользователей, протиркой мышек, сменой картриджей у принтеров и подобными вещами.

В результате, в небольших компаниях часто наблюдается довольно разнообразный парк пользовательских машин класса от pentium2/128Mb ram/5Gb hdd до P4 Celeron/1Gb ram/80Gb hdd. На всех машинах, разумеется, Windows (98, 2000 и XP Home/Pro) и разные версии софта (ставили то машины в разное время). Доходит до того, что и антивирусное ПО на машинах тоже от разных производителей.

А на нелегкую долю системного администратора (и эникейщика по совместительству), выпадает денно и нощно поддерживает весь этот зоопарк. А ведь железо иногда ломается:

• вентиляторы начинают противно жужжать (их надо чистить и смазывать или же менять на новые);
• блоки питания выходят из строя;
• винчестеры - сыпятся;
• сетевые карты (как встроенные в материнскую плату, так и внешние - перестают работать и требуют замены);
• остальное железо, обычно, летит сильно реже, но тем не менее летит тоже

При выходе из строя винчестера (или же материнской платы компьютера), операционную систему на восстановленной машине часто приходится переставлять с нуля в такой или очень похожей последовательности:

• ставим Windows;
• ставим необходимые драйвера (весь парк железа разный - не забыли?), предварительно определив модель материнской платы в данной машине и скачав из Интернет последние версии драйверов или найдя нужные у себя на файл-сервере;
• вводим машину в домен (если он настроен);
• ставим необходимый софт (офис, браузер, почтовый клиент, тотал-коммантеры, аськи, джабберы, пунто-свитчеры и подобное) - в случае домена Active Directory часть софта можно поставить автоматически, но не у всех он настроен, да и не все знают его возможности;
• ставим антивирус;
• плюс дополнительные танцы с бубном, индивидуальные для конкретной сети каждой организации вокруг новой рабочей станции;

После успешного выполнения всех пунктов (эта процедура занимает примерно два часа) рапортуем Боссу, что рабочее место сотрудника спасено и он может приступать к работе.

Счастливый обладатель восстановленного компьютера садится за свое рабочее место, после чего выясняется, что (так как доменные профили были не перемещаемые или же домена не было вовсе, ссылка «мои документы» вела на локальный диск C:, а про то, что все важное нужно сохранять на сетевом диске - на сервере, сотрудник забыл):

• у меня тут была папка с важными документами - где она?
• а еще я там фотографии из Турции сохранил, можно их восстановить?
• на рабочем столе было много важных ярлыков и еще сотня документов - куда они пропали?
• в избранном (это про закладки в браузере) моих любимых сайтов больше нет - где их теперь искать? и так далее…

Знакомо? Хорошо, если полетел не жесткий диск, а всего лишь материнская плата. Или же часть информации на осыпавшемся диске поддается восстановлению. Но все эти процедуры занимают рабочее время системного администратора, которое можно было бы потратить с куда большей пользой — поиграть в сетевую стрелялку или же… изучить IPv6 - ведь уже все на него переходят и совсем скоро перейдут, адреса в пространстве Ipv4 уже лет пять как закончились:)

В результате, поддержка IT инфраструктуры небольшой компании для системного администратора превращается, по большей части в поддержку работоспособности пользовательских рабочих станций, а именно:

• переустановить Windows;
• настроить на новой машине весь необходимый софт;
• восстановить все то, что потерялось;
• доустановить нуждающимся новые программы;
• провести профилактику корпуса (пыль пропылесосить в системном блоке);

И в оставшееся время (если системный администратор не сильно ленив) надо пытаться изучить что-то новое, проапгрейдить софт на сервере (серверах) и ввести в строй новый сетевой сервис. Т.е. на основные обязанности (именно то, чем системный администратор и должен заниматься большую часть времени) времени то как раз и не остается.

Как же выйти из этого замкнутого круга?

Одним из вариантов решения вышеописанной проблемы, является отказ от «толстых» рабочих станций (там, где это можно сделать) и переход на .

Под «толстой» рабочей станцией понимается любой компьютер с установленной ОС, который и выполняет обработку большинства пользовательской информации. Т.е. браузер, офис и все остальное выполняется локально именно на рабочей станции пользователя, системный блок которой жужжит у него под столом или где то рядом.

Надо понимать, что требования современных ОС (не обязательно Windows) идут в ногу с современным железом - другими словами, для относительно комфортной работы в Windows XP старой (но полностью работоспособной и относительно мощной) машины класса Celeron 800Mgz/128Mb Ram/ 10Gb HDD может и не хватить. Работать под современной ОС на подобном железе, конечно, можно, но подтормаживать эта операционка и приложения будут довольно часто — хотя бы из-за малого количества набортной памяти и старого (читай — медленного) жесткого диска.

А тонкий клиент, если вкратце, можно определить как бездисковый компьютер, работа которого заключается лишь в подключении к удаленному серверу и отображении полученной с сервера информации на экране. Обычно такой сервер называется сервером терминалов или терминальным сервером. Вся же обработка пользовательской информации происходит именно на нем (одновременно к которому может быть подключено множество — хотя и не бесконечное количество — тонких клиентов).

Обычно тонкие клиенты делают на основе слабого (а, соответственно, и малопотребляющего) железа - часто это единая системная плата, на которой все и интегрировано. Процессор и память так же могут быть намертво припаяны к материнской плате. Некоторые тонкие клиенты имеют flash-диск (вставляемый в IDE разъем материнской платы), на котором прошита специализированная ОС (WinCE или другие).

Сравнение тонкого клиента Clientron U700 со стандартным корпусом для рабочей станции.

В результате, при включении тонкого клиента (их еще называют терминалами), ОС грузится со встроенного flash-диска (обычно на загрузку уходит менее 30 секунд), после чего на экране появляется диалог подключения к терминальному серверу. Некоторые из этих клиентов умеют подключаться только Windows Terminal Server или же Citrix Metaframe, другие - в том числе и к терминальным серверам других ОС. В любом случае, в цену таких решений закладывается и цена лицензии на WindowsCE, прошитую на встроенный flash-диск. Мы рассказывали о подобных решениях ранее:

• Windows-терминал
• Тонкий клиент
• Windows-терминал

Разумеется, подобные решения существуют и у других компаний. В том числе и без встроенной ОС (за которую, в случае Microsoft Windows CE, нужно дополнительно платить, да и flash-диск копейки, но стоит).

Терминальные клиенты без встроенного flash-диска, при включении загружают нужный образ ОС по сети, после чего они тратят на загрузку те же пару десятков секунд. После чего готовы к работе, под чем подразумевается вывод на экран меню со списком терминальных серверов для подключения или же автоматическое подключение к одному из жестко заданных терминальных серверов (в зависимости от настроек) - пользователю останется ввести лишь логин и пароль. После правильного ввода оного, он попадает в свою сессию на сервере терминалов и может приступать к работе.

Несомненные плюсы терминальных решений на специализированных тонких клиентах или правильных самосборных компьютерах:

• отсутствие жесткого диска (которые греются и ломаются);
• отсутствие вентиляторов (на процессоре и блоке питания установлены лишь радиаторы, которых хватает для рассеивания выделяемого при работе тепла);
• низкое энергопотребление;
• теоретическая дешевизна (при самосборе можно подобрать очень дешевые комплектующие — ведь производительности от железа не требуется; а вот производители за специализированные тонкие клиенты попросят раза в два больше)
• минимальные временные затраты на обслуживание (при поломке такой железяки, достаточно отключить поломавшуюся и подключить запасную — работы на пять минут; а это уже минимальный простой для рабочего места сотрудника, а так же минимум затраченного на устранение поломки времени системного администратора)
• весь софт для работы пользователей настраивается централизовано на одном (двух/трех/…) терминальных серверах — это значительно проще, чем поддерживать зоопарк софта на «толстых» рабочих станциях сотрудников

Не стоит забывать и о пользовательских данных — локально терминал ничего не хранит (все данные пользователя находятся на удаленных серверах). В результате легко настроить автоматических бекап всего и вся и, в случае чего, восстановить «случайно удаленный» документ.

В общем, плюсов море, но есть и минусы:

• при отказе сети, рабочие места сотрудников «превращаются в тыкву» (а сотрудники на «толстых» клиентах могут продолжать набивать документ, к примеру, в OpenOffice);
• при отказе терминального сервера рабочие места сотрудников опять «превращаются в тыкву» (но это решается установкой нескольких - например, двух - терминальных серверов; при выходе одного из них из строя, второй его подменит или же сотрудники просто переподключатся ко второму серверу вручную)
• тонкие клиенты подходят не всем: к примеру, людям, постоянно смотрящим видео или работающим активно работающих с графикой (в фотошопе) или занимающимся версткой журнала, лучше делать это на локальном «толстом» клиенте (зато тонкие клиенты отлично подходят большинству остальных сотрудников, которым нужен лишь браузер с Интернет, почта, создание и редактирование документов в Openoffice и работа с 1C).

Последний минус, который мы тут рассматривать не будем — это лицензионная политика (если не сказать обдираловка) со стороны Microsoft. Работа на терминальном сервере под управлением ОС этой известной компании требует большого количества разнообразных лицензий:

• лицензия на Windows Server
• CAL (Client Access License) — лицензии на подключение к Windows-серверу и их кол-во должно быть не меньше количества подключаемых к серверу клиентов (обычно в составе Windows-сервера уже идет некоторое кол-во таких лицензий — от пяти и выше)
• лицензии на работу с сервером терминалов (их количество тоже должно быть равно количеству подключаемых клиентов)

Не забываем про отдельные лицензии на весь используемый софт (например на Microsoft Office) в количестве, равном количеству подключаемых к серверу клиентов. Если клиентские лицензии на Microsoft Office еще можно обойти, отказавшись от данного продукта и поставив ему замену в виде, к примеру, OpenOffice, то от самого терминального сервера в лице Windows 2000/2003 TS избавиться несколько сложнее:) Хотя и это возможно в некоторых случаях.

Есть, правда, еще один «минус» (кроме боязни нового) который часто останавливает от внедрения подобных решений - почему то многие думают, что эти тонкие клиенты надо покупать (а они не очень дешевые - от 200 долларов и выше). Куда же девать весь парк уже существующих компьютеров?

Именно для ответа на последний вопрос написана данная серия статей. В ней будет рассматриваться софт тонкого клиента .

Этот небольшой, но обладающий множеством возможностей и, что немаловажно, OpenSource софт, позволяет превратить практически любые древние компьютеры в тонкие клиенты. Минимальные описанные на его родном сайте к используемому железу - это Pentium 100Mhz и 16Mb оперативной памяти. Ах да, жесткий/flash диск тоже не нужен - компьютеры при включении могут скачивать образ тонкого клиента (это около двадцати! мегабайт) по сети (хотя так же возможна установка Thinstation клиента на жесткий или usb диск). В наш век операционных систем, с радостью сжирающих гигабайты места на диске после установки, это впечатляет, не так ли?

Thinstation базируется на Linux, но для его использования знаний Linux, как таковых не нужно - достаточно в своей сети поднять dhcp и tftp сервера и соответствующим образом их настроить (оба этих сервера есть и в составе продуктов Windows Server). Таким образом, даже в сети, где кроме Windows-а ничего не знают, использование Thinstation клиента затруднений не вызовет.

Thinstation умеет работать со следующими серверами терминалов:

• Сервера Microsoft Windows по протоколу RDP или через nxclient (Windows NT4TSE, W2k Server, W2k3 Server или же Windows XP в однопользовательском режиме);
• Citrix servers по протоколу ICA (на серверах MS Windows, SUN Solaris и IBM AIX);
• Сервера Tarantella
• *nix-like сервера по протоколу X11;
• подключение к VNC-серверам (tightVNC);
• подключение к SSH и Telnet серверам;

Для того, что бы загрузить Thinstation по сети, от компьютера требуется лишь встроенная или внешняя сетевая карта, поддерживающая стандарт PXE (есть и другие варианты, но, к примеру все встроенные в системную плату сетевые карты работают именно по этому протоколу).

PXE расшифровывается как Pre-boot eXecution Environment — среда предзагрузочного выполнения. Этот стандарт был впервые реализован компанией Intel. Первый признак наличия PXE-биоса на борту встроенной сетевой карты, это пункт «Enable Boot ROM» рядом с пунктом активации сетевой карты в биосе. Если встроенная сетевая карта не поддерживает загрузку по сети (или отсутствует вовсе), можно использовать любую внешнюю сетевую плату с опцией «Boot ROM» (этот вопрос в подробностях будет рассмотрен далее).

А сейчас вкратце рассмотрим процесс загрузки клиента Thinstation по сети.

• Сетевая карта по протоколу PXE запрашивает DHCP сервер следующую информацию: IP адрес, маску подсети, шлюз а так же IP-адрес сервера TFTP (на котором лежат образы, в данном случае, ThinStation) и имя образа, которое она попытается загрузить.
• DHCP сервер возвращает запрашиваемую информацию (помечая у себя, что выданный клиенту IP адрес — занят таким-то клиентом)
• Клиент подключается к TFTP серверу, IP-адрес которого ему только что сообщили и скачивает с него файл загрузчика PXE (имя которого ему опять таки сообщил DHCP-сервер)
• Скаченный PXE загрузчик исполняется и, в свою очередь скачивает с TFTP сервера конфигурационный файл, в котором прописаны имена файлов ядра ОС Linux — vmlinuz и образа файловой системы — initrd. Эти файлы скачиваются и управления передается ядру Linux
• После распаковки и загрузки ядра Linux с подмонтированным образом файловой системы, Thinstation снова обращается к TFTP серверу для скачивания необходимых ему конфигурационных файлов (там, среди прочего, записаны адреса терминальных серверов, к которым нужно подключаться), после чего запускает нужный терминальный клиент (в нашем случае это будет rdesktop) и ожидает от пользователя ввода его логина с паролем для подключения.

На первый взгляд, описанная схема выглядит сложно. Но по факту настройка оной занимает полчаса-час и в дальнейшем она работает полностью автономно. Загрузка тонкого клиента с момента первого запроса в сеть по PXE (этот момент совпадает с моментом начала загрузки ОС с жесткого диска) занимает секунд 20…30.

Как уже отмечалось выше, Thinstation умеет работать с разными терминальными серверами. Но мы в ближайших статьях, как самое простое в реализации (но еще раз напоминаю о покупке множества клиентских лицензий, необходимых для официальной работы), рассмотрим лишь связку Thinstation с Microsoft Terminal Server.

Для начала нам надо иметь настроенный сервер терминалов от Microsoft. Этот сервер может работать как в составе домена (в этом случае удобнее управлять аккаутами пользователей - они общие — особенно если терминальных серверов в сети несколько), так и в вне домена - в одноранговой сети. Второй случай отличается от первого тем, что необходимых пользователей придется заводить на каждом сервере локально и синхронизировать актуальные списки пользователей и их прав - вручную.

Вторым пунктом нашей программы будет настройка DHCP и TFTP серверов. Первый ведает динамической раздачей IP адресов для рабочих станций, а так же сообщает, с какого IP адреса (с какого сервера tftp) и какое имя файла компьютеру нужно скачать в качестве загрузочного образа тонкого клиента. А второй — tftp сервер — фактически и отдает образы тонкого клиента и конфигурационные файлы для них же. Эти настройки могут быть как глобальными (для всех бездисковых терминалов сети), так и локальные — для определенных групп машин или же одиночных тонких клиентов.

Оба эти сервиса можно поднять как в составе Windows сервера (запуском и настройкой соответствующих служб), так и отдельными демонами в составе *nix-сервера — мы это рассмотрим на примере сервера с установленным Gentoo Linux.

А третьим пунктом идет настройка клиентских машин — перевод их на загрузку по сети и рассмотрение стандартных подводных камней.

Но об этом — в следующих статьях нашего цикла.

Доброго времени суток!

Относительно недавно в свет вышла новая версия популярного тонкого клиента Thinstation , а именно 2.5. И, конечно же, несет в себе как новые плюшки, так и новые грабли плюс минимум документации по новой версии.

В этой статье (а она расчитана на новичков , особенно для тех, кто слабо знаком с Linux) я опишу как быстро собрать тонкого клиента и сделать его использование достаточно безопасным, с использованием смарт-карт , RDP-клиента фирмы и хэппи-эндом. Добро пожаловать!

Постановка задачи

Итак, у нас имеется:

• Несколько железяк, гордо именуемых «тонкими клиентами». Например, пара десятков уже давно не новых машинок HP HSTNC-001L-TC .
• Настроенный терминальный сервер, к которому тонкие клиенты будут цепляться. Пусть будет MS Windows Server 2003 или 2008.

А теперь чего, собственно, хотим:

• Загружать тонкие клиенты по сети (то есть бездисково).
• Поддержку тонкими клиентами MS RDP версий 6+ или даже 7, т.к. это более безопасно.
• И не просто MS RDP, а с поддержкой TLS 1.0 .
• Авторизацию пользователей с помощью смарт-карт (т.е. проброс смарт-карты c тонкого клиента на сервер).

С чего начнем?

Для бездисковой загрузки наших тонких клиентов (а грузиться они будут по протоколу PXE) нам потребуется настроить DHCP-сервер и TFTP-сервер. Что это, для чего, как происходит загрузка по сети (PXE) и как это настроить хорошо и подробно написано . В качестве TFTP-сервера под Windows могу порекоммендовать tftpd32, который можно скачать . Несмотря на название, есть версии и для платформы x64.

Далее, если есть желание, можно немного почитать о Thinstation , и (под списком файлов для загрузки). На русском языке информацию можно найти , хотя она уже несколько устаревает. Там расписывается создание и настройка образов Thinstation версии 2.2.2, многое актуально и для 2.5. Непосредственно версии 2.5 посвящена пока лишь . Итак, начнем.

Первая сборка

Так как Thinstation основан на Linux’е, значит для сборки тонкого клиента нам потребуется компьютер с установленным Linux’ом (спасибо, КО!). Я использовал Ubuntu 11.10. Также нам понадобится установить Git (если его еще нет) и с его помощью склонировать себе репозиторий с генератором образов:

sudo apt-get install git

cd / home/ user/

git clone --depth 1 git :// thinstation.git.sourceforge.net/ gitroot/ thinstation/ thinstation

cd thinstation

После того, как генератор образов скачан, необходимо запустить скрипт:

./ setup-chroot

При первом запуске этот скрипт соберет необходимые пакеты и развернет всю инфраструктуру для дальнейщей генерации наших загрузочных образов.

Пришла пора собрать наш первый, пока что «толстый», образ. Этот большой образ с поддержкой очень широкого списка аппаратки нужен, чтобы сгенерировать затем небольшой профиль для поддержки нашего конкретного железа. Хочу отметить, что в этом и заключается одна из главных плюшек новой версии Thinstation: теперь не надо самому руками составлять список драйверов, которые следует включить в образ - он сгенерируется автоматически скриптом.

Как советуют разработчики, сборку надо производить «inside chroot session», поэтому из скрипта setup-chroot.sh не выходим (нажимаем лишь «Q», чтобы скрыть приветственное сообщение скрипта) и пишем следующие команды в тамошней консоли:

cd ts/ 2.5

nano build.conf

В файле build.conf раскомментируем строчку «package extensions «. Если у вас интернет через прокси, то еще раскомментируем строчку «param httpproxy » и укажем в ней свои настройки прокси-сервера (например, так: «param httpproxy user :password@proxy:port «), сохраним файл и продолжим сборку:

./ build --allmodules

Смотрим на длинную портянку лога скрипта сборки, соглашаемся на скачивание дополнительных пакетов, если он попросит, и дожидаемся окончания процесса. Теперь копируем содержимое директории «/home/user/thinstation/ts/2.5/boot-images/pxe » (а это и есть наш собранный загрузочный образ) в корень TFTP-сервера и пробуем первый раз загрузить тонкого клиента по сети.

И вот тут мы можем встретить первые долгожданные грабли. Если оперативной памяти у вашего тонкого клиента мало, то мы возвращаемся к редактированию файла build.conf и закомментируем какой-нибудь тяжелый пакет, например «#package chrome «, повторяем сборку и видим уменьшение обзаза почти в 2 раза. Теперь загрузка должна пойти.

Даже после этого с вероятностью, близкой к 100%, полной загрузки тонкого клиента не произойдет. Но нам этого и не надо. Ждем, когда загрузчик покажет нам картинку с надписью «Thinstation» и прогрессбаром. После этого нажимаем Ctrl+Alt+F3 и видим консоль с приглашением войти. Вводим следующую пару логин-пароль «root - pleasechangeme » и запускаем скрипт:

Этот скрипт сгенерирует нам файлы профиля для конкретного железа нашего тонкого клиента. Обычно их два: «module.list » (список драйверов для нашего железа) и «vbe_modes.list » (графические режимы). Теперь их нужно скопировать на Linux-машину. Сделать это можно, например, через TFTP-сервер (он должен позволять запись). В консоли тонкого клиента вводим:

cd /

tftp -p -l module.list -r module.list 192.168.0.1

tftp -p -l vbe_modes.list -r vbe_modes.list 192.168.0.1

Где 192.168.0.1 - адрес нашего TFTP-сервера. Вернемся к Linux-машине, создадим там папку «/home/user/thinstation/ts/2.5/machine/my_machine » и скопируем в нее из корня TFTP-сервера наши два полученных файла.

Страшный зверь - смарт-карта

• Собственно, сами смарт-карты. Например, такие .
• Устройства для чтения смарт-карт (картридеры). Например, такие .
• И, конечно же, наш терминальный сервер должен быть соответствующим образом настроен, чтобы использовать смарт-карты для аутентификации. Данная настройка сервера - тема большая. Про нее отдельно можно и почитать . Кроме того, для поддержки конкретных смарт-карт необходимо установить на терминальный сервер ПО производителя. Для выбранных мною в качестве примера карт фирмы Aladdin оно находится . На данном этапе будем считать, что мы уже справились с настройкой терминального сервера и он позволяет пользователям логиниться, используя смарт-карты.

Теперь нам необходимо найти и собрать драйвера для картридера под Linux. На сайте производителя находим драйвера , качаем и распаковываем:

cd / home/ user/

wget http:// www.athena-scs.com/ downloads/ asedriveiiie-usb-3.7 .tar.bz2

tar -xjf asedriveiiie-usb-3.7 .tar.bz2

cd asedriveiiie-usb-3.7

Читаем README и видим, что для сборки нам понадобится установить пакет PCSC Lite (есть , я ставил последнюю на тот момент версию ccid-1.4.5 ), а также нам понадобятся исходники (с более старшими версиями не собирается ).

Ставим PCSC Lite, в папку с исходниками драйверов для картридера копируем файл usb.h из исходников libusb . Теперь запускаем обычное:

./ configure

make

make install

Так как Thinstation уже содержит в себе пакет PCSC Lite, мы можем просто скопировать наши драйвера в сборщик Thinstation, вот так:

cp -LR / usr/ lib/ pcsc/ drivers/ ifd-ASEDriveIIIe-USB.bundle / home/ user/ thinstation/ ts/ 2.5 / packages/ ccidreader/ lib/ pcsc/ drivers cp / etc/ udev/ rules.d/ 50 -pcscd-asedriveiiie.rules / home/ user/ thinstation/ ts/ 2.5 / packages/ ccidreader/ etc/ udev/ rules.d

Все, готово! Теперь картридер при загрузке тонкого клиента будет определяться и работать нормально. В версии 2.5 такие извращения для работы со смарт-картами, как для 2.2.2, больше не нужны.

RDP-клиенты

Теперь немного о том, каким клиентом мы будем подключаться к терминальному серверу.

На данный момент самыми известными клиентами для Microsoft RDP для Linux-систем являются rdesktop и его форк - FreeRDP . Но! rdesktop не поддерживает TLS 1.0, а FreeRDP не умеет работать со смарт-картами. И это вызывает откровенную печаль!

После продолжительных поисков был обнаружен еще один RDP-клиент фирмы 2X. Скачать его можно . Оказалось, что он умеет все вышеперечисленное, бесплатен и к тому же еще поддерживает MS RDP версии 7.0 и активно развивается. Каково же было мое счатье, когда я узнал, что этот клиент входит в Thinstation!

Финишная прямая: конфигурируем и собираем

Тщательная конфигурация - тема большая, поэтому читаем в разделе «Конфигурационные файлы » для чего нужен каждый файл и где он должен лежать. В той статье описана конфигурация Thinstation версии 2.2.2. Здесь я расскажу про то, что изменилось в новой версии и приведу примеры своих конфигурационных файлов: build.conf , thinstation.conf.buildtime и thinstation.conf.network .

Итак, комментирую параметры из конфигураций в примерах:

build.conf:

• machine my_machine - помните, мы сгенерировали профиль для железа и сложили его в папку «my_machine «? Это она и есть!
• package xorg7-vesa - выбираем Xorg-драйвер. Вот тут возникли проблемы, потому что родной драйвер для моего чипсета SIS не подошел и пришлось на практике выяснять, какой из оставшихся подойдет. Vesa работает с моим чипсетом хорошо. Возможно тут придется параметр подбирать на практике.
• package ccidreader - пакет PCSC Lite, который позволит нам работать со смарт-картами.
• package 2x, package alsa-lib - это и есть наш замечательный RDP-клиент. Правда на практике было выявлено, что ему для работы нужен пакет Alsa, поэтому включаем и его.
• param fastboot false - если этот параметр выставлен в true , то наш загрузочный образ будет разбит на основной и подгружаемую часть. К сожалению моя сетевая карта нецелый образ грузить отказалась, поэтому генерируем образ целым.
• param basepath config - указывает, в какой папке на TFTP-сервере будут находиться конфигурационные файлы для клиентов (thinstation.conf.network , например).
• #param rootpasswd и т.д. - комментируем параметры, которые задают какие-либо пароли. Если пароль рута закомментирован, то никто, даже если он читерски получит доступ к консоли Thinstation, не сможет залогиниться под рутом. И это хорошо)
• param 2xurl - задает откуда будет скачан клиент 2X. Он будет скачан только один раз при первом запуске скрипта сборки.

thinstation.conf.buildtime:

• DONT_VT_SWITCH_STATE=TRUE - не позволит пользователю через Ctrl+Alt+F3 переключиться в консоль.
• DONT_ZAP_STATE=TRUE - не позволит пользователю через Ctrl+Alt+Backspace переинициализировать графический режим и опять же попасть в консоль.

И, наконец, пример описания запуска сессии для клиента 2X (thinstation.conf.network ):

SESSION_0_TITLE ="2X"

SESSION_0_TYPE =2X

SESSION_0_2X_OPTIONS ="-m MX -C -u user -p password -s ssl://myTerminalServerIp"

SESSION_0_AUTOSTART =ON

• -m MX - режим клиента, MS RDP, полноэкранный.
• -C - редирект смарт-карты.
• -u user -p password - логично, юзер-пароль. Но! Мы ведь хотим авторизоваться по смарт-карте, а не по паролю! Все просто: дело в том, что текущий 2X клиент не запустится без параметров юзера и пароля, а выплюнет вас Segmentation fault. И это полный бред. Однако после длительных разговоров со службой поддержки они эту проблему в следующем релизе обещали решить. Пока же просто пишем несуществующего пользователя и пароль наобум и спокойно авторизуемся по смарт-карте, как будто так и надо.
• -s ssl://myTerminalServerIp - адрес сервера, к которомы будем подключаться. ssl указывает на то, что будет использован TLS 1.0.

С конфигурированием закончили. Теперь собираем клиента: запускаем скрипт setup-chroot.sh и вводим:

cd ts/ 2.5

./ build

Полученный образ складываем в корень TFTP-сервера. Также в корне TFTP-сервера создаем папку «config » (та, которую мы указали в build.conf ) и копируем в нее файл thinstation.conf.network .

Все готово! Запускаем, проверяем, видим окошко логина терминального сервера и радуемся!

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

Сборка тонкого клиента, ориетнированного на определенные клиенты, сводится к следующим этапам:

• Скачиваем полный репозиторий ThinStation
• Собираем "толстый" (полный) образ
• Загружаем тонкий клиент на толстом образе
• Получаем список необходимых для этого клиента модулей ядра и пакетов
• Исправляем конфиги сборки, оставив только самое необходимое (в том числе полученное на предыдущем этапе)
• Собираем "тонкий" (облегченный) образ

Подготовка кухни

Сразу скажу, что есть и другой путь сборки - скачивание подготовленного.iso образа. Но мне это кажется не таким удобным, поэтому я буду описывать "правильный" вариант.

Скачивание репозитория

Вообще, для работы с ThinStation рекомендуется иметь базовые знания работы с Git. Просто потому, что ваши изменения нужно будет куда-то сохранять, а заблудиться в иерархии файлов, когда кухня уже распакована (не зная Git) - очень легко. Скачивание сводится к выполнению одной команды.

Всё остальное сейчас не важно - настраивать тонко будем потом.

Отдельно остановлюсь на том, зачем нужно поменять систему сжатия со squashfs на gzip . Скрипт hwlister.sh , о котором пойдет речь ниже, использует очень интересную методику поиска загруженного firmware - он просто смотрит время доступа к файлам в /lib/firmware и на основе этого делает выводы, какие файлы были загружены. Но squashfs монтируется с параметром relatime , что приводит к тому, что время доступа к файлам не меняется и список firmware (чёрт, не знаю, как перевести это слово, не потеряв смысл) всегда пуст. Изменение режима сжатия на gzip - самый простой и быстрый способ вернуть скрипт к жизни не залезая в кишки. Я написал об этом разработчикам, но ответа пока не было.

Сборка

Сборка любого образа выполняется в chroot - так что не забываем в него зайти. Для сборки толстого образа существует также специальный параметр --allmodules , который включает в образ все доступные модули ядра, что также пригодится на неизвестном железе.

После того, как процесс завершится, в директории boot-images можно будет найти варианты образа - iso, pxe и syslinux. Можно использовать любой и загружать клиент любым удобным способом.

Сбор информации

Когда подопытное железо успешно загрузилось, необходимо зайти в консоль любым удобным способом и написать:

Это обычный bash-скрипт, после выполнения которого вы обнаружите несколько файлов:

• /firmware.list - список необходимых firmware
• /module.list - список необходимых модулей ядра
• /package.list - список необходимых пакетов, учитывая архитектуру будет содержать только xorg7-* пакеты
• /vbe_modes.list - если используется uvesafb , этот файл будет содержать список поддерживаемых режимов

Некоторые файлы могут отсутствовать, если ничего подходящего не найдено

Этот же скрипт попытается загрузить файлы на ваш tftp-сервер, указанный в конфиге, однако, надеюсь, у вас запись на tftp, как и у меня, запрещена. Поэтому забираем файлы с тестируемой системы любым способом и кладем в директорию ts/build/machine/MACHINENAME , где MACHINENAME - кодовое имя, которое вы дадите своему железу.

Тонкий образ

Сборка тонкого образа - это всегда балансирование на границе между функциональностью и объемом. Меньше объем - быстрее загрузка бездисковых рабочих станций по сети, быстрее старт системы, меньше оперативной памяти требуется клиентам. Лично у меня стояла задача сделать образ минимального объёма всего под одну задачу - терминальный RDP-клиент. Об этом я и буду рассказывать.

Итак, у нас есть офис, набор тонких клиентов, подключенных проводами, получающих адрес по DHCP, загружающихся по PXE и стартующих одно единственное приложение - RDP-клиент.

Конфигурация сборки - build.conf

Как я уже писал выше, первый этап в конфигурации сборки - это правка файла build.conf . Он определяет какие пакеты будут включены в образ и некоторые другие параметры сборщика.

• Все строки начинающиеся с machine - комментируем. Должно остаться только то, что используется у вас. Нужно отметить, что в конфигурации можно держать активными сразу несколько профилей - тогда получится образ, запускающийся на любом из них (в теории, если нет конфликтов).
• Скорее всего вам не понадобятся файловые системы кроме vfat и ntfs - поэтому в блоке файловых систем можно смело комментировать строки isofs , udf , ext* .
• Так как мы создали профиль для своего железа, содержащий необходимые пакеты xorg7 , то все строки содержащие package xorg7-* - можно смело комментировать.
• Смело комментируем все пакеты локалей package locale-* кроме, конечно ru_RU , и, по желанию, en_US - нужна она или нет вопрос спорный.
• Если вам нужен удаленный доступ к рабочим станциям - включите package sshd
• Если вам нужны смарт-карты и USB-токены - включите package ccidreader
• Если вы собираетесь вырезать оконный менеджер, рабочий стол и показывать пользователю только одно приложение (например FreeRDP) - включите пакет package automount для автоматического монтирования любых USB-устройств. При этом package udisks можно смело выключить.
• Если вам не нужен интерфейс для Wi-Fi соединений и другие рюшечки - закомментируйте package networkmanager и включите package autonet . Но будьте готовы к тому, что придется покопаться в его внутренностях - это скриптовая обвязка для системных утилит и в некоторых сетях может работать не совсем так, как ожидается.
• Чтобы максимально облегчить образ, включаем package openbox и выключаем package gtk-* , package icons-* , package fonts-* .

Что касается пакетов в разделе Applications - здесь выбор полностью за вами. Всё описанное выше применимо к тонким клиентам, где пользователь не будет видеть своего рабочего стола (RDP, VNC, etc) и для использования, например, локального браузера - многое из перечисленного выше придется оставить.

Остается не забыть вернуть param initrdcmd "squashfs" и убрать 3 строки в самом конце: package alltimezone , param allres true и param allfirmware true - в тонком образе это нам не пригодится.

Runtime-конфигурация - thinstation.conf.buildtime

Файл thinstation.conf.buildtime является по своей сути bash-скриптом, предоставляющим переменные окружения для всех скриптов запуска. Перед тем, как начать его редактировать, стоит заглянуть в директорию ts/build/conf (github) - здесь собраны кусочки конфигураций для каждого пакета, включающие в себя пояснения и все доступные переменные.

Давать какие-то универсальные советы - сложно. Настройка будет зависеть от вашего окружения и используемых пакетов. Приведу лишь пример для RDP-сессии.

# У пользователя не будет локального UI, так что локально выкручиваем громкость на максимум AUDIO_LEVEL = 100 MIC_LEVEL = 100 # Для бездисковых станций резонно собирать логи в одном месте SYSLOG_SERVER = syslog.example.com # Локаль и таймзона LOCALE = ru_RU.UTF8 TIME_ZONE = Europe/Moscow # Кнопки "Безопасного извлечения устройства" также не будет - поэтому включаем обязательно USB_STORAGE_SYNC = ON DISK_STORAGE_SYNC = ON # Монтировать устройства нужно в директорию, которую мы потом пробросим в удаленную сессию USB_MOUNT_DIR = /mnt/usb # Для поддержки кириллицы на съемных накопителях, я для себя вывел вот такой набор параметров. Он точно подходит для FAT32/NTFS разделов и FreeRDP USB_MOUNT_OPTIONS = DISK_MOUNT_OPTIONS = "rw,nosuid,nodev,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro" # Если выключили NetworkManager и включили autonet - обязательно настройте сеть NET_USE_DHCP = ON # Нулевая сессия должна быть оконным менеджером # Можно попробовать обойтись без него и даже вообще без Иксов # но это тема для отдельной статьи SESSION_0_TITLE = Desktop SESSION_0_TYPE = openbox SESSION_0_AUTOSTART = ON # Главная рабочая сессия # Список параметров FreeRDP - пожалуй также повод для отдельной статьи SESSION_1_TITLE = RemoteDesktop SESSION_1_TYPE = freerdp SESSION_1_AUTOSTART = ON SESSION_1_FREERDP_SERVER = rdp.example.com SESSION_1_FREERDP_OPTIONS = "+decorations +fonts +aero ..."

Сборка тонкого образа

Теперь, когда конфигурация готова, остается лишь собрать легковесный образ. Всё те же команды, что и для полного образа, за исключением одного параметра:

И это всё. В зависимости от того, что вы указали в build.conf , вы получите готовые образы для загрузки по PXE, с CD-ROM, жесткого диска или флешки. При описанной конфигурации можно добиться образа размером ~90 MB и времени загрузки по PXE (от включения питания до рабочего стола) около 1 минуты. С локального диска и того быстрее.

Другие возможности

Нужно отметить, что всё, о чем я писал выше - советы по сборке универсального образа. Я добился того, чтобы с одного образа можно было загрузить любой ПК из присутствующих в зоопарке компании. Но может получиться так, что вам понадобится сделать несколько вариантов клиентов, с разными настройками или, например, разными адресами серверов. В таком случае обратите внимание, что ThinStation умеет как скачивать дополнительные конфигурационные файлы во время загрузки, так и докачивать дополнительные модули. Это очень хорошо описано в документации, и я на этом останавливаться не буду.

Полезные заметки

Очистка кухни

Периодически, особенно если вы активно экспериментируете с версиями пакетов, сборкой, пересборкой, перекомпилированием бинарников и т.д., рано или поздно вам придется начать очищать рабочую директорию от накопившегося мусора.

1. Не забыть выйти из chroot
2. Убедиться, что сохранили все свои изменения в Git
3. Отмонтировать все системные ФС внутри кухни: umount -R thinstation/*
4. Запустить скрипт очистки: sudo ./setup-chroot -a
5. Удалить всё, что осталось: git clean -dx - это удалит все несохраненные файлы

Добавление своих пакетов

Если вы собираетесь привносить в проект что-то свое, нужно знать о том, что в терминологии ThinStation, а вернее в терминологии CRUX Linux, на котором базируется TS, существует два базовых понятия:

• package (далее "пакет") - некая абстракция, указывающая на то, что необходимо установить в будущий образ. Пакет может содержать кусок дерева файловой системы, отдельные файлы, или даже просто один конфигурационный файл, указывающий, например на зависимости.
• port (далее "порт") - подобие *.deb иди *.rpm пакета, с одним важным отличием: архив со скомпилированными файлами не содержит правил установки, а представляет из себя просто кусок дерева файловой системы. Любые правила (скрипт компиляции, скрипты пост-установки, и т.д.) лежат рядом с архивом и легко редактируются.

Когда вы хотите дополнить образ чем-то своим, первое, о чем стоит задуматься, а что именно вам нужно? Если вы хотите добавить в образ пару текстовых конфигов - просто создайте свой пакет, включите его build.conf - и этого будет более чем достаточно. Если же вам нужно собирать бинарные файлы - то вам понадобится сделать свой порт.

Создание своего порта

Prtdir /ts/ports/yourproject

Хранить в отдельной директории будет гораздо проще и безопаснее. После редактирования файла нужно не забыть перезайти в chroot. Стоит отметить, что в этом файле уже присутствуют директории с портами, разложенными по коллекциям. Сборщик будет искать порт по имени во всех директориях по-порядку, поэтому, если боитесь коллизии имен - располагайте вашу директорию выше остальных.

Теперь вам понадобится создать один единственный bash-скрипт, который будет отвечать за сборку порта: /ts/ports/yourproject/portname/Pkgfile . Образец можно посмотреть , а можно подсмотреть в любом другом порте. Базовый вариант выглядит так:

Name = mdetect-TS version = 0 .5.2.3 release = 1 source =(http://ftp.de.debian.org/debian/pool/main/m/$name /$name -$version .tar.bz2) build() { cd $name -$version ./configure --prefix= /usr \ --exec-prefix= / \ --sysconfdir= /etc \ --mandir= /usr/man \ --disable-extras make make DESTDIR = $PKG install }

Давайте разберемся, что он делает (на самом деле делает не он, он лишь определяет стадию сборки):

1. Скачивает файлы, заданные в source (в данном случае - http://ftp.de.debian.org/debian/pool/main/m/mdetect-TS/mdetect-TS-0.5.2.3.tar.bz2), их может быть несколько
2. Распаковывает все скачанные файлы в рабочую директорию
3. Выполняет configure + make
4. Делает make install из директории /ts/ports/yourproject/portname/work/src в /ts/ports/yourproject/portname/work/pkg
5. Полученное содержимое директории pkg упаковывается в архив. Это и будет наш порт, готовый для установки.

Проверим наши предположения. Чтобы выполнить первую сборку, необходимо сделать следующее:

[ _chroot]/# cd ts/ports/yourproject/portname/ [ _chroot]/ts/ports/yourproject/portname# pkgmk -kw =======> Building "/ts/ports/yourproject/portname/portname#0.5.2.3-1.pkg.tar.xz".