Thinstation по русски


Разворачиваем сеть тонких клиентов Thinstation с подключением к серверу Windows Server 2012 R2 Remote Desktop Services

Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP.

В качестве аппаратной платформы для тонкого клиента мы будем использовать устройства HP t610, хотя в рамках нашей задачи эти устройства имеют более чем избыточную конфигурацию. По сути минимальные системные требования для тонкого клиента с Thinstation – любой "аппаратный хлам" начиная с уровня Pentium-II с 128MB RAM и выше. Мы будем использовать бездисковую конфигурацию тонких клиентов, то есть загрузка системы будет выполняться по сети с использованием PXE (приоритетно) или с локальных загрузочных USB-накопителей (для клиентов без поддержки PXE и в отдалённых участках со слабым каналом передачи данных).

Когда я изучал доступные в открытых источниках статьи на тему подобного развёртывания, то среди множества материалов выделил для себя статью Пети Хинчли "Use Thinstation to build a network-bootable RDP-enabled thin client image", от наработок которой я и буду отталкиваться. Также в качестве полезного источника информации стоит отметить такие русскоязычные ресурсы, как Thinstation по русски и Thinstation Доработка тонкого клиента.

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

  • Все тонкие клиенты должны быть изолированы в рамках одной сети и должны маршрутизироваться только до своего RDS-сервера.
  • RDS-сервер, помимо предоставления сессий удалённых рабочих столов, по совместительству должен выполнять все функции управления тонкими клиентами (раздача IP адресов, раздача загрузочных образов ОС, раздача настроек каждого конечного клиента и т.д.).
  • Загрузка конечной рабочей среды тонкого клиента должна происходить автоматически без участия пользователя/оператора (авто-логон RDP-сессии и запуск необходимой оболочки – конечного бизнес-приложения)
  • Цикличная работа тонких клиентов должна быть автоматизирована, то есть клиенты должны автоматически включаться по расписанию утром каждого рабочего дня и выключаться в конце рабочего дня.    

Начнём процедуру настройки с выделенного сервера, который в нашем случае является виртуальной машиной Hyper-V с предварительно установленной гостевой ОС Windows Server 2012 R2 Standard. Развернём и настроим на этом сервере службы DHCP и WDS.

 

Настройка сервера DHCP

Для автоматического назначения IP-адресации нашим тонким клиентам установим и настроим службу DHCP на нашем сервере управления.

Устанавливаем роль DHCP Server через оснастку Server Manager или через PowerShell:

Install-WindowsFeature -Name DHCP -IncludeManagementTools

После установки роли откроем оснастку Server Manager и запустим мастер Post-Deployment Configuration, после завершения которого роль сервера DHCP может считаться развёрнутой.

В нашем примере сервер DHCP разворачивается на компьютере, не являющемся членом домена, поэтому с авторизацией (активацией) службы DHCP не возникнет проблем – сразу после развёртывания сервер будет готов к работе. Создадим для тонких клиентов область с пулом выдаваемых IP адресов и активируем её:

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

В оснастке управления правилами Windows Firewall проверяем правила относящиеся к серверу DHCP (как минимум нужно разрешить входящие подключения по протоколу UDP на порты 67/68)

 

Настройка сервера Windows Deployment Services

Роли Windows Deployment Services и Web Server понадобятся нам для возможности раздачи по сети (PXE) загружаемых образов Thinstation тонким клиентам по протоколам TFTP/HTTP. Устанавливаем роли:

Install-WindowsFeature -Name "Web-Server","WDS" -IncludeManagementTools

К настройке веб-сервера IIS мы обратимся позже, а сейчас рассмотрим то, как настроить WDS сервер на поддержку загрузчика SYSLINUX.

Откроем консоль WDS и первым делом вызовем мастер конфигурирования сервера Configure Server

На первом шаге мастер ознакомит нас с требованиями необходимыми для работы WDS.

  • Первым пунктом идёт информация о том, что сервер может быть сконфигурирован как с поддержкой доменной инфраструктуры, так и в изолированном варианте (как раз наш случай).
  • Службу сервера DHCP мы уже развернули. В процессе конфигурации WDS будет включена специальная опция DHCP сервера для поддержки PXE-клиентов.
  • Среди требований присутствует наличие DNS-сервера в сети, хотя в нашем конкретном случае в этом нет реальной необходимости. DNS это конечно хорошо и правильно, но мой практический опыт работы с Thinstation показал, что полностью избавится от применения IP-адресов вместо FQDN-имён не получится, и поэтому я решил вообще не заморачиваться с использованием службы DNS.
  • Отдельный NTFS-раздел для хранения загрузочных образов сделан на нашем WDS-сервере (далее в примерах будет фигурировать как диск D:\)

На шаге выбора типа развёртывания WDS, согласно исходных условий нашего примера, выбираем режим изолированного сервере Standalone server

На шаге размещения каталога для файлов WDS и загрузочных образов по умолчанию предлагается каталог C:\RemoteInstall. В нашем примере путь изменён на диск D:\

На следующем шаге мастер конфигурации, определив наличие на нашем сервере службы DHCP-сервера, предложит настроить параметры взаимодействия с этой службой. А именно, нам потребуется включить запрет прослушивания портов DHCP службой WDS и разрешить конфигурирование опций DHCP-сервера для поддержки PXE-клиентов.

На шаге настроек PXE по условиям нашей задачи разрешаем WDS серверу отвечать на запросы всех PXE-клиентов

По завершению работы мастера служба WDS будет запущена. В консоли WDS откроем свойства сервера и на закладке Boot отключим включенное по умолчанию требование нажатия F12 на стороне PXE-клиента для возможности загрузки по сети, выбрав опцию Always continue the PXE boot.

Заглянем в оснастку управления сервером DHCP и проверим, что в DHCP-опциях на уровне сервера появилась опция PXE

***

Теперь сделаем ряд действий по добавлению нашему WDS серверу поддержи SYSLINUX.

Скачаем архив актуальной версии загрузчика syslinux-6.03 по ссылке:

https://www.kernel.org/pub/linux/utils/boot/syslinux/

Распакуем архив syslinux-6.03.zip и выполним следующие действия:

  • Скопируем в каталог D:\RemoteInstall\Boot\x64 на сервере WDS следующие файлы:\syslinux-6.03\bios\core\pxelinux.0 (переименовать в pxelinux.com)\syslinux-6.03\bios\com32\menu\vesamenu.c32\syslinux-6.03\bios\com32\elflink\ldlinux\ldlinux.c32\syslinux-6.03\bios\com32\chain\chain.c32\syslinux-6.03\bios\memdisk\memdisk
  • Скопируем файл D:\RemoteInstall\Boot\x64\abortpxe.com в файл abortpxe.0.
  • Скопируем файл D:\RemoteInstall\Boot\x64\pxeboot.n12 в файл pxeboot.0.

Повторим действия, проделанные для каталога D:\RemoteInstall\Boot\x64 применительно к каталогу D:\RemoteInstall\Boot\x86

***

Создадим каталог D:\RemoteInstall\Boot\pxelinux.cfg (не файл, а именно каталог). В этом каталоге будут хранится конфигурационный файлы PXE, которые будет отдавать WDS-сервер PXE-клиентам.

Создадим конфигурационный файл PXE "по умолчанию" с именем default в каталоге D:\RemoteInstall\Boot\pxelinux.cfg и добавим в него следующий контент:

DEFAULT RDP PROMPT 0 NOESCAPE 1 ALLOWOPTIONS 0 LABEL RDP MENU DEFAULT KERNEL /Linux/vmlinuz APPEND initrd=/Linux/initrd splash=silent,theme:default load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=3 console=tty1 vt.global_cursor_default=0 LM=3

***

В командной строке с правами Администратора перейдём в каталог D:\RemoteInstall\Boot\x64 и создадим символическую ссылку (junction) на каталог D:\RemoteInstall\Boot\pxelinux.cfg:

cd /d D:\RemoteInstall\Boot\x64 mklink /J pxelinux.cfg D:\RemoteInstall\Boot\pxelinux.cfg

Повторим тоже самое для каталога D:\RemoteInstall\Boot\x86:

cd /d D:\RemoteInstall\Boot\x86 mklink /J pxelinux.cfg D:\RemoteInstall\Boot\pxelinux.cfg

 ***

Создадим каталог D:\RemoteInstall\Images\Linux. В этом каталоге мы будем размещать загружаемые образы ОС тонких клиентов.

В командной строке с правами Администратора перейдём в каталог D:\RemoteInstall\Boot\x64 и создадим символическую ссылку (junction) на каталог D:\RemoteInstall\Images\Linux:

cd /d D:\RemoteInstall\Boot\x64 mklink /J Linux D:\RemoteInstall\Images\Linux

Повторим тоже самое для каталога D:\RemoteInstall\Boot\x86:

cd /d D:\RemoteInstall\Boot\x86 mklink /J Linux D:\RemoteInstall\Images\Linux

***

Для того, чтобы настроить WDS на использование добавленных нами загрузочных программ SYSLINUX (замена стандартного для WDS загрузчика pxeboot на pxelinux), выполним ряд команд с правами Администратора на сервере WDS:

wdsutil /set-server /bootprogram:boot\x86\pxelinux.com /architecture:x86 wdsutil /set-server /N12bootprogram:boot\x86\pxelinux.com /architecture:x86 wdsutil /set-server /bootprogram:boot\x64\pxelinux.com /architecture:x64 wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.com /architecture:x64

Примечание: Если в дальнейшем по какой-то причине потребуется восстановить загрузочные программы (pxeboot), используемые в WDS по умолчанию, сделать это можно командами:

wdsutil /set-server /bootprogram:boot\x86\pxeboot.com /architecture:x86 wdsutil /set-server /N12bootprogram:boot\x86\pxeboot.n12 /architecture:x86 wdsutil /set-server /bootprogram:boot\x64\pxeboot.com /architecture:x64 wdsutil /set-server /N12bootprogram:boot\x64\pxeboot.n12 /architecture:x64

***

В оснастке управления правилами Windows Firewall проверяем правила относящиеся к серверу WDS (как минимум нужно разрешить входящие подключения по протоколу UDP к исполняемому файлу службы).

А также включаем правило, разрешающее входящий трафик к веб-серверу IIS

Кстати, к настройке веб-сервера IIS мы ещё вернёмся позже.

 

Развёртывание сборочной среды DevStation

Для сборки собственных загрузочных образов проект Thinstation, в качестве одного из вариантов, предлагает использовать специальную загружаемую среду DevStation. Используя загрузочный дистрибутив DevStation, мы развернём выделенную Linux-систему, с помощью которой в дальнейшем будем собирать загрузочные образы Thinstation для конечных тонких клиентов. Прежде всего в DevStation будет сгенерирован специальный загрузочный образ Thinstation, с которого, в свою очередь, нужно будет загрузиться на всех используемых типах аппаратных конфигураций наших клиентов и сгенерировать профиль оборудования. На базе полученных профилей оборудования на нашем сервере DevStation будут скомпилированы конечные загрузочные сборки Thinstation под каждую аппаратную конфигурацию. Такой подход позволит свести к разумному минимуму размер загружаемого по сети образа Thinstation для каждой конкретной партии "железок".  

Под задачу развёртывания DevStation можно использовать виртуальную машину. В сети можно найти примеры использования для этих целей виртуальных машин на базе VMWare и VirtualBox. В моём случае используются среды виртуализации Microsoft Hyper-V и oVirt. Попытки развернуть DevStation 5.5 на виртуальную машину Hyper-V 2012 R2 результата не дали, так как происходило зависание процесса установки на стадии разметки диска, хотя с определением диска проблемы не возникало. В конечном итоге виртуальная машина была создана в среде виртуализации oVirt с настройками согласно документа DevStation setup.

Созданная виртуальная машина имеет 2vCPU , 3GB ОЗУ, vHD 25GB (при меньшем размере диска, чем 20GB, DevStation может не установиться). В качестве интерфейса диска вместо используемого по умолчанию в oVirt 4.0.6 значения VirtIO я выбрал IDE, так как развёртывание DevStation заработало корректно только на этом интерфейсе.

***

Загружаем последнюю версию DevStation по ссылке: Thinstation Latest Download

В нашем случае это файл TS-5.5.1-Installer-0627.iso размером 212MB

Загружаемся в подготовленную виртуальную машину с ISO-образа и выбираем пункт установки – Installer for DevStation

В память загрузится Live-система, будет выполнен авто-вход в графическую оболочку, где с рабочего стола запустим ярлык Install to HD. В открывшейся форме нам поведают о том, что на самом деле можно прожить и без выделенной инсталляции DevStation, залив git-клон проекта Thinstation на любой другой сборочной Linux-системе.   

Утвердительно "кивнём гривой", после чего будет запущена процедура проверки Интернет-соединения.

В случае, если наша виртуальная машина DevStation не имеет прямого подключения к Интернету, то нам любезно будет предложено настроить параметры прокси-сервера 

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

После того, как Интернет-соединение будет успешно проверено, нам сообщат о том, на какой диск будет установлена система DevStation.

Затем укажем предпочитаемое разрешение экрана. У нас ВМ и выбор здесь небольшой.

Затем из представленных списков выберем свою временную зону и раскладку клавиатуры:

 

 

 

 

 

 

 

 

Перед началом процесса установки DevStation нас предупредят о том, что все данные на диски будут уничтожены (инсталлятор по своему усмотрению выполнит разметку диска)

Будет запущена программа развёртывания DevStation, в ходе которой будет выполнена разметка диска, загрузка и установка всех необходимых пакетов из онлайн-репозитория проекта Thinstation размером примерно около 2GB.

Процедура может занять от 20 минут и более, в зависимости от пропускной способности вашего Интернет-канала и проворности диска виртуальной машины. Когда процесс будет завершён, мы получим несколько уведомительных сообщений о том, как собрать собственный загрузочный образ тонкого клиента…

…о том, что наша система DevStation способна выступать в качестве PXE-сервера…

…и о том, что загрузочный образ ISO, с которого мы выполняли установку теперь нам больше не нужен, как, впрочем, и прямое подключение к Интернет, и после перезагрузки мы уже можем использовать установленную систему…

На это этапе можно извлечь загрузочный ISO образ из привода виртуальной машины и нажать OK

Отправляем виртуальную машину в перезагрузку.

 

Сборка служебного образа Thinstation

Подключаемся к консоли только что развёрнутой сборочной среды DevStation. Учётные данные при этом вводить не требуется, так как в системе настроен авто-вход. Пароль пользователя root на нашей виртуальной машине DevStation - pleasechangeme. По умолчанию в DevStation включен Telnet-сервер и с этими учётными данными без проблем можно удалённо подключиться к системе. И как я понял, простого и вменяемого способа изменить такое поведение нет. Лишь в ветке обсуждения Thinstation Installer Disc Server - ssh access я нашёл пример того, как вместо Telnet можно включить SSH и сменить root-пароль, который подразумевает пересборку самого образа DevStation. Что скорее всего, как следствие, вызовет необходимость его переустановки. Как бы там ни было, включённая система DevStation нам нужна только на этапе сборки конечных образов тонких клиентов, а всё остальное время можно держать её выключенной.

Итак, с рабочего стола графической среды DevStation запускаем ярлык Terminal Chroot

В открывшейся консоли автоматически откроется файл справки README. Нажмём Q чтобы закрыть справочный файл и перейти в консоль.

Сменим текущий каталог на /build. Здесь мы и будем выполнять практически всю работу – настройку конфигурации под наших клиентов и сборку образов для их загрузки. В первую очередь нас интересуют два основных файла build.conf и thinstation.conf.buildtime. Первый файл определяет порядок сборки образов Thinstation, то есть то, какие в образ будут включены драйверы для поддержки оборудования (например поддержка определённых видео-адаптеров), какие будут добавлены пакеты приложений сервисного уровня (например поддержка NFS, NTP и т.п.) и прикладного уровня (например наличие веб-браузера, RDP-клиента и т.д.) и ряд других параметров сборки. Второй файл добавляется в собираемый образ и в основном служит для передачи неких параметров/переменных, которые могут определять тот или иной порядок работы тонкого клиента и включённых в него приложений.

На данном этапе перед нами стоит задача сборки служебного загрузочного образа Thinstation, который будет содержать в себе все драйверы, поддерживаемые средой Thinstation и с минимальными изменениями в файле build.conf. Этот служебный образ потребуется нам для того, чтобы на следующем этапе, загрузившись с него уже на конечных устройствах – тонких клиентах, выполнить процедуру генерации файлов профиля оборудования, которые в свою очередь будут использоваться для сборки конечных результативных образов тонких клиентов.

Удалим имеющуюся символическую ссылку на конфигурационный файл build.conf и создадим новый файл на базе шаблона build.conf.example

# rm build.conf # cp build.conf.example build.conf

Обратите внимание на то, что все команды здесь мы будем выполнять в chroot-окружении, которое ссылается на каталог /thinstation/ относительно корневой системы DevStation.

С помощью текстового редактора внесём минимальные корректировки в файл build.conf.В частности, нужно убрать комментарий (#) в строке содержащей запись package extensions-x (этот пакет содержит инструменты создания профилей оборудования, в том числе и скрипт hwlister.sh, который нам потребуется в дальнейшем)

В целом этого достаточно, однако на практике я столкнулся с багом squashfs and firmware.list generation #192, который, как я понимаю, на данный момент не исправлен. Баг приводит к тому, что в процессе генерации профиля оборудования, который мы будем делать на следующем этапе, не создаётся файл firmware.list, что может привести к отсутствию корректной поддержки необходимых аппаратных компонент тонкого клиента. В качестве обходного решения этой проблемы на данный момент является замена параметра initrdcmd (Compression Mode) в файле build.conf c "squashfs"…

… на "gzip -9"

Сохраним отредактированный файл build.conf и выполним команду сборки образа, включающего в себя все драйверы, которые поддерживает Thinstation

# ./build --allmodules

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

Процесс компиляции образа будет завершён созданием файла initrd размером около 175MB. Этот файл и содержит загружаемую ОС c ПО Thinstation для наших тонких клиентов. Напоминаю, что размер образа большой по той причине, что мы на этапе сборки включили в него все модули поддержки оборудования.

В конечном итоге на данный момент нас интересуют 2 файла, появившихся после компиляции - initrd (Initial RAM Disk) и vmlinuz (Linux Kernel). Файл vmlinuz служит для первичной загрузки и инициализации оборудования тонкого клиента, после чего начинается загрузка initrd. 

После завершения процесса компиляции оба эти файла можно найти в каталоге /thinstation/build/boot-images/pxe/boot/ (в консоли "Terminal Chroot" это каталог /build/boot-images/pxe/boot/). Нужно скопировать эти два файла на наш WDS-сервер в каталог D:\RemoteInstall\Images\Linux

Создадим временную сетевую папку на нашем Windows-сервере и предоставим доступ на запись к этой папке для своей учётной записи. На DevStation-машине создадим новый каталог и смонтируем в него сетевую папку с Windows-сервера WDS, после чего скопируем в смонтированную папку все нужные нам файлы:

# mkdir /mnt/WDSTempShare # mount.cifs //KOM-APP20/TempShare /mnt/WDSTempShare -o user=volodya # cp /build/boot-images/pxe/boot/initrd /mnt/WDSTempShare/ # cp /build/boot-images/pxe/boot/vmlinuz /mnt/WDSTempShare/ # umount /mnt/WDSTempShare

На WDS-сервере из папки /TempShare перенесём файлы initrd и vmlinuz в каталог, из которого PXE-сервер будет отдавать PXE-клиентам файлы для загрузки D:\RemoteInstall\Images\Linux

 

Получение файлов профиля оборудования для Thinstation

Задача получения профиля оборудования заключается в том, чтобы загрузить эталонный компьютер (тонкий клиент с типичным для партии набором аппаратных компонент) с образа Thinstation собранного с опцией --allmodules и выполнить в этой системе скрипт /bin/hwlister.sh. Данный скрипт сгенерирует файлы профиля оборудования и попытается передать их на PXE-сервер, встроенный в DevStation.

Обратите внимание на то, что на данном этапе PXE-загрузку эталонного клиента (для генерации файлов профиля оборудования) мы можем произвести как с нашего WDS-сервера (ведь мы уже скопировали на него загрузочные файлы образа initrd и vmlinuz), так и с встроенного в DevStation PXE-сервера. Однако стоит учитывать то, что скрипт hwlister.sh будет пытаться передать получившиеся файлы профиля оборудования именно на тот PXE-сервер, с которого он был загружен. Поэтому для генерации профиля оборудования будет проще всего загружаться именно с PXE-сервера встроенного в DevStation.

При этом на сервере DevStation для загрузки будут использоваться именно те файлы initrd и vmlinuz, которые расположены в каталоге /thinstation/build/boot-images/pxe/boot/, так как этот каталог является корневым для встроенного в DevStation PXE-сервера. Именно поэтому важно, чтобы при попытке загрузки эталонной машины c PXE-сервера DevStation, на этом сервере в каталоге /thinstation/build/boot-images/pxe/boot/ находились файлы образа собранного с опцией --allmodules, который мы собрали в на предыдущем этапе. Это предотвратит потенциальные проблемы с распознаванием оборудования и полноценной загрузкой Thinstation.

***

Теперь на нашем Windows-сервере потребуется на время внести некоторые изменения:

  • В оснастке управления сервером DHCP создадим резервирование IP для эталонной машины
  • В оснастке управления сервером WDS отключим опцию интеграции с DHCP

Чтобы заставить нашу эталонную машину тонкого клиента загружать образ по сети не с WDS сервера, а с машины DevStation, создадим на DHCP-сервере резервирование IP адреса для эталонной машины с опциями 66 и 67:

66 = <IP-адрес DevStation>

67 = boot/pxelinux/pxelinux.0

Кстати, в значении 67 опции по замечанию из статьи Thinstation OS можно указать путь к другому файлу, чтобы изменить загрузку с TFTP на HTTP (это может несколько ускорить процесс загрузки образа). Для этого значение boot/pxelinux/pxelinux.0 нужно заменить на на boot/lpxelinux/lpxelinux.0. Однако, как я понял, загрузка по HTTP поддерживается не всеми сетевыми картами и поэтому в большинстве случаев всё же будет использоваться TFTP.

Так, как мы планируем использовать PXE сервер с DevStation, то в нашей конфигурации потребуется на время отключить PXE сервер, встроенный в WDS, чтобы из опций DHCP-сервера исчезла опция 060 = PXEClient. Если этого не сделать, то WDS может передавать PXE-клиенту не тот адрес PXE-сервера, который нас интересует.

***

Переходим на DevStation и разрешаем запись всем пользователям в корневой каталог встроенного TFTP сервера. Для этого можно либо выполнить консольную команду:

# chmod 777 /thinstation/build/boot-images/pxe

Либо в графической оболочке вызвать через пункт меню Start > DevStation > Toggle PXE Read/Write:

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

***

Включаем эталонный компьютер. При старте клиент получит с DHCP зарезервированный нами IP-адрес с опциями указывающими на PXE-сервер DevStation и начнёт оттуда загружать образ.

На загруженном эталонном клиенте в графической оболочке открываем меню Applications > Utilities и выбираем Terminal Emulator

В окне терминала запускаем генерацию профиля оборудования с передачей на машину DevStation командой:

# /bin/hwlister.sh

Заглянем в каталог /thinstation/build/boot-images/pxe на DevStation машине. Здесь появятся файлы переданные с клиента (в зависимости от "железа" клиента): module.list, package.list, firmware.list

Итак, аппаратный профиль эталонного клиента получен и передан на DevStation. Теперь можем выключить эталонный компьютер. Он нам больше не нужен.

На DevStation создаём новый подкаталог для профиля клиента в каталоге /thinstation/build/machine/ (/build/machine/ в chroot-окружении) и переносим туда только что полученные с эталонного клиента list-файлы

# mkdir /build/machine/HPt610 # cd /build/machine/HPt610 # mv /build/boot-images/pxe/*.list .

Далее созданный профиль под названием HPt610 мы будем использовать при сборке конечного рабочего образа (будем указывать имя этого каталог в build.conf).

Туже самую процедуру создания нового профиля из list-файлов, попавших в каталог /thinstation/build/boot-images/pxe, можно сделать и с помощью графической оболочки DevStation. Для этого будет достаточно вызвать пункт меню  Start > DevStation > Make Machine Profile и указать имя нового профиля

***

Отключаем право на запись в PXE-сервере DevStation через ранее упомянутый пункт меню Start > DevStation > Toggle PXE Read/Write или командой в терминале:

# chmod 755 /thinstation/build/boot-images/pxe

***

Возвращаемся на наш Windows-сервер и в консоли WDS не забываем обратно включить опцию поддержки интеграции PXE с DHCP (вторую галочку)

А в консоли управления DHCP-сервером удаляем созданное ранее резервирование, которое мы делали под эталонного клиента.

 

Сборка рабочего образа Thinstation

На данном этапе можно считать, что у нас всё готово для сборки конечного рабочего образа Thinstation, который будет использоваться для наших тонких клиентов определённой аппаратной конфигурации. Процедура сборки аналогична той, что мы рассмотрели ранее, когда делали служебный образ Thinstation с главным отличием в том, что сборка выполняется без ключа --allmodules. При этом в собираемый образ Thinstation будут добавлены только те модули поддержки оборудования, которые перечислены в незакомментированных строчках перечисляющих профили оборудования (machine …) в файле build.conf.

Базовую информацию о структуре конфигурационного файла build.conf можно получить из документа Thinstation Wiki - build.conf. Логика простая – включаем только те модули и пакеты, которые нужны для работы наших тонких клиентов, всё что не нужно – отключаем (комментируем), так как каждый лишний модуль/пакет увеличивает размер образа который получится в результате компиляции. При этом лучше не отключать те вещи, значение которых вам непонятно, если не хотите потерять время на отладке, которой можно было и не заниматься. 

Далее рассмотрим правки, которые нужно внести в build.conf исходя из условий нашей задачи.

В секции #!Hardware добавим запись о ранее созданном профиле machine HPt610

В секции #!!File System Support оставим модули usb-storage, isofs, udf, vfat. Остальные модули закомментируем. Эти модули нам потребуются на случай необходимости загрузки не по сети а с накопителей, типа USB-флэш диск.

В секции #!!Miscellaneous (я обнаружил в файле 2 таких секции) в списке пакетов закомментируем ранее включённый пакет extentions-x, так как на рабочем образе тонкого клиента в нём нет необходимости. Для возможности нормальной автоматической конфигурации сети в процессе загрузки тонкого клиента включим пакет ts-classic, выключим networkmanager и добавим autonet.

В секции #!!X закомментируем пакеты xorg7-vmware и, при необходимости, раскомментируем прочие (например в нашем случае нужен пакет xorg7-ati). В любом случае рекомендуется оставлять пакет xorg7-vesa, так как он будет использован, если родной пакет драйвера не обнаружен или по какой-то причине не заработал.

В секции #!!Locale закомментируем все языковые пакеты за исключением тех. которые могут нам быть полезны: locale-en_US и locale-ru_RU.

В секции #!Applications закомментируем пакеты все ненужные нам пакеты, например firefox, open-vm-tools и vboxguest. В нашем случае в этой секции остаться только пакет freerdp.

В секции #!!Window Managers комментируем все пакеты оконных менеджеров, так как в нашей ситуации в них нет необходимости.

В секции #!!Other services комментируем пакеты cups (печать в нашем случае не нужна) и samba-client (нам не требуется, чтобы тонкий клиент мог куда-то попасть по SMB).

В секции #!!Basic раскомментируем параметр fastboot, чтобы использовать механизм быстрой загрузки образа (HTTP вместо TFTP). Зададим значение пароля в параметре rootpasswd. Закомментируем параметры xorgvncpasswd, storagepasswd, dualupasswd, sambapasswd, так как в них нет нужды. Так, как мы собрались использовать быструю загрузку HTTP, зададим параметр baseurl, в котором укажем URL-адрес веб-сервера и параметр basepath, в котором укажем имя папки на веб-сервере, в которой нужно искать файлы для загрузки. Параметр initrdcmd вернём в исходное значение "squashfs".

В конечном счёте (без учёта закомментированных строк) конфигурационный файл build.conf в нашем случае примет следующий вид:

#!Hardware machine HP-t610 #!!Filesystem Support module usb-storage module isofs module udf module vfat #!!Miscellaneous package overlayfs package ts-classic package autonet package udisks package ntp package cpufreq #!!X related package xorg7-vesa package xorg7-ati #!!Locale package locale-en_US package locale-ru_RU #!Applications package freerdp #!!Miscellaneous package fonts-TTF-BH package fonts-TTF-vera package fonts-TTF-liberation #!!Basic param fastboot true param rootpasswd Str0nGpWd param bootlogo true param boottheme default param splash silent param fbmtrr 0 param fbnocrtc true param fbsm ywrap param bootresolution 1280x768-32 param desktop file:./backgrounds/Hive_Lite.jpg param defaultconfig thinstation.conf.buildtime param basename thinstation param basepath ThinClients param baseurl http://10.1.4.10 param haltonerror false param hardlinkfs true param sametimestmp true param initrdcmd "squashfs" param bootverbosity 3 #!!Advanced param downloads /downloads param bootimages "iso syslinux pxe" param syslinuxtheme "default" package alltimezone param allres true param allfirmware true param blacklist snd-pcsp.ko

***

Следующим правим конфигурационный файл thinstation.conf.buildtime, предварительно сделав копию оригинального файла на всякий случай:

# cp thinstation.conf.buildtime thinstation.conf.buildtime.original

Базовую информацию об этом файле можно получить в документе Thinstation Wiki - thinstation.conf, а узнать о возможных параметрах и их описании можно в файле thinstation.conf.sample.

Основную массу имеющихся в файле thinstation.conf.buildtime параметров можно оставить без изменений. Изменим и добавим лишь те параметры которые относятся к специфике нашей задачи:

NET_FILE_ENABLED=On NET_FILE_METHOD=wget ... SESSION_0_TYPE=freerdp SESSION_0_TITLE="RDP" SESSION_0_AUTOSTART=on ... NET_USE=LAN NET_USE_DHCP=ON NET_DHCP_DELAY=30 NET_DHCP_TIMEOUT=30 NET_LINKWAIT=30 ...

Добавленными параметрами NET_FILE_* мы укажем на необходимость загрузки конфигурационных файлов Thinstation по сети по протоколу HTTP. Это позволит нам разместить на веб-сервере конфигурационные файлы thinstation.conf-<MAC>, настраивающие конкретных тонких клиентов, не меняя при этом настройки внутри раздаваемого образа. Далее мы рассмотрим пример такого файла.

В параметрах SESSION_0_* вместо используемого по умолчанию графического оконного менеджера xfwm4 мы сразу будем вызывать RDP-клиента freerdp. А общие для всех наших  клиентов параметры подключения RDP-клиента к RDS-серверу (имя сервера, опции RDP-сессии) мы также вынесем в дальнейшем на веб-сервер в файл thinstation.conf.network. Его пример мы также рассмотрим далее.

В перечисленных параметрах NET_* мы зададим те опции тонкого клиента, которые могут повлиять на корректность инициализации сети в загружаемой системе и успешность загрузки по сети, как таковую. Например первая опция NET_USE=LAN задаёт приоритет использования проводных сетевых адаптеров перед беспроводными (может быть полезно, если тонкий клиент имеет и беспроводной и проводной адаптеры и один мешает загрузке другого). Опции задержки и таймаутов нужны для ожидания инициализации драйвера сетевого адаптера. На практике столкнулся с тем, что неуспевающий пройти инициализацию сетевой адаптер ломал загрузку по сети через HTTP.

***

Так как по условиям нашей задачи требуется авто-вход в RDP-сессию, удалим пару файлов, которые предотвращают авто-вход для freerdp

# rm /thinstation/build/packages/freerdp/etc/cmd/freerdp.getuser # rm /thinstation/build/packages/freerdp/etc/cmd/freerdp.getpass

Это позволит нам передавать учётные данные для подключения к RDS-серверу клиенту freerdp в виде параметров. Эти параметры мы будем хранить в файлах thinstation.conf-<MAC>, которые тонкие клиенты будут получать с веб-сервера в процессе загрузки. В целом, с точки зрения безопасности, такое решение может быть неверным, однако учитывая условия нашей задачи (изоляцию сегмента сети тонких клиентов и одинаковый ограниченный набор возможностей конечных пользователей работающих на всех тонких клиентах) такая конфигурация вполне имеет право на жизнь.

***

Теперь на DevStation всё готово для сборки рабочего образа. Запускаем сборку из chroot-окружения:

# ./build

Так, как в конфигурационном файле build.conf мы включили поддержку fastboot, то при сборке вместо одного "тяжёлого" файла initrd мы получим "легковесный" initrd и дополнительный squash-файл, который и будет в себе содержать бОльшую долю загружаемых данных.  

Таким образом, подразумевается что первая часть (файл initrd) будет загружаться на PXE-клиенте по протоколу TFTP (с сервера WDS), а вторая часть (файл lib.squash) по протоколу HTTP (с веб-сервера IIS).

Получившиеся в процессе компиляции файлы initrd и vmlinuz мы скопируем на WDS сервер в ранее созданный нами каталог D:\RemoteInstall\Images\Linux (перезаписав возможно ранее размещённые там файлы от служебного образа Thinstation), а о файле lib.squash мы поговорим чуть позже, после настройки веб-сервера IIS.

 

Настройка веб-сервера IIS для поддержки Fast Boot

Так как на этапе сборки рабочего образа Thinstation мы включили опцию поддержки fastboot в build.conf, а в thinstation.conf.buildtime указали расположение веб-сервера Fast Boot, то теперь нам нужно разместить получившийся ранее Squash-файл на этом веб-сервере, чтобы в процессе загрузки основной "тяжёлой" части образа использовался не протокол TFTP а протокол HTTP. Это позволит ускорить время загрузки ОС тонкого клиента.

В нашем случае в качестве веб-сервера выступает IIS, который мы уже развернули ранее вместе с WDS, поэтому выполним его настройку, например через IIS Manager. Нам нужно сделать две вещи. Включить поддержку нового MIME-типа .squash и убедиться в том, что к сайту разрешён анонимный доступ.

В оснастке IIS Manager выберем сайт, в нашем случае это Default Web Site.

В настройках сайта выберем пункт MIME Types и используя в меню Actions ссылку Add добавим новый MIME-тип: filename extension = .squash , MIME type = application/octet-stream

Если не выполнить данную настройку, то наш веб-сервер IIS приходящим к нему PXE-клиентам попросту не будет отдавать squash-файл, а будет возвращать ошибку доступа.

Перейдём к разделу настроек сайта Authentication и убедимся в том, что включена анонимная аутентификация

Опять же, это нужно для того, чтобы приходящие PXE-клиенты без проблем могли скачать нужные им файлы.

***

Скопируем с DevStation появившийся после компиляции файл /thinstation/build/boot-images/pxe/boot/lib.squash в подкаталог ThinClients каталога, в котором размещена корневая папка сайта IIS (по умолчанию C:\Inetpub\wwwroot). Вспомним, что именно этот подкаталог веб-сервера мы указывали в параметре basepath в файле build.conf перед компиляцией рабочего образа Thinstation.

 

Использование разных сборок и конфигураций Thinstation

Есть разные походы к тому, каким образом можно настроить разный порядок загрузки "разношёрстных" тонких клиентов и выбор того или иного подхода зачастую зависит от исходных условий среды реализации. Исключительно оптимальных подходов, на мой взгляд здесь не существует, так как каждое решение имеет свои преимущества и недостатки. По имеющимся исходным условиям я выбрал вариант с выдачей PXE-клиентам загрузочных образов Thinstation (и конфигурационных файлов) в зависимости от их конкретных MAC-адресов. Поговорим о том, как реализовать подобную схему.

Мы помним, что для размещения файлов образа Thinstation initrd и vmlinuz на WDS мы использовали каталог D:\RemoteInstall\Images\Linux. В процессе загрузки PXE клиенты сначала скачивают файл D:\RemoteInstall\Boot\pxelinux.cfg\default (на него ведут сим.линки из D:\RemoteInstall\Boot\x64\pxelinux.cfg и D:\RemoteInstall\Boot\x86\pxelinux.cfg), в котором указан путь к файлам initrd и vmlinuz. Этот файл мы создавали ранее на этапе настройки WDS.

Мы можем заставить отдельно-взятого тонкого клиента Thinstation вместо настроек, указанных в файле default использовать какие-то другие настройки порядка загрузки, например указав путь к другим файлам initrd и vmlinuz. Для этого в каталоге PXE-сервера D:\RemoteInstall\Boot\pxelinux.cfg\ можно создать файл, с содержанием аналогичным файлу default, но с именем в формате 01-<MAC>. Например, для клиента с MAC-адресом 00-15-5d-00-40-36 файл должен иметь имя 01-00-15-5d-00-40-36.

Содержимое файла может иметь следующие настройки:

DEFAULT RDP PROMPT 0 NOESCAPE 1 ALLOWOPTIONS 0 LABEL RDP MENU DEFAULT KERNEL /Linux/HP-t610/vmlinuz APPEND initrd=/Linux/HP-t610/initrd splash=silent,theme:default load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=3 console=tty1 vt.global_cursor_default=0 LM=3 FASTBOOT_URL=http://10.1.4.10/ThinClients/HP-t610/

Как видно, в качестве пути к файлам initrd и vmlinuz, которые загружаются с нашего PXE-сервера по протоколу TFTP, здесь уже указаны пути отличные от тех, что могут быть указаны в файле D:\RemoteInstall\Boot\pxelinux.cfg\default. То есть в каталоге, из которого PXE-сервер отдаёт клиентам загрузочные образы мы создали подкаталог /Linux/HP-t610/ (физический путь D:\RemoteInstall\Images\Linux\HP-t610\) с файлами определённой сборки образа нашего клиента Thinstation.

Также можно обратить внимание на то, что строку инициализации initrd здесь мы дополняем параметром FASTBOOT_URL, который ссылается на веб-сервер, где у нас расположен squash-файл ассоциированный с initrd-файлом. Нетрудно догадаться, что на веб-сервере в каталоге /ThinClients/ у нас также создан подкаталог под конкретную сборку образа - /ThinClients/HP-t610/. 

Таким образом мы организовали возможность раздачи файлов загружаемого образа Thinstation в зависимости от MAC-адреса PXE-клиента.

***

Теперь вспомним, что по условиям нашей задачи требуется, чтобы каждый загруженный экземпляр Thinstation автоматически создавал RDP-сессию на RDS-сервере, где автоматически должно запускаться определённое бизнес-приложение. А подключение к RDS-серверу подразумевает передачу каких-то учётных данных, используемых на этом сервере. При этом, как мы понимаем, каждый тонкий клиент должен передавать уникальные учётные данные, чтобы иметь выделенную RDP-сессию на сервере. Получается, что у нас добавляется необходимость дополнительной уникальной для каждого клиента настройки ПО freerdp, запускаемого в среде Thinstation.

Реализовать это можно с помощью дополнительно загружаемых с веб-сервера файлов вида thinstation.conf.network и thinstation.conf-<MAC>. И не забываем про то, что в процессе сборки рабочего образа Thinstation мы настаивали файл thinstation.conf.buildtime, который попал в этот образ. Thinstation обрабатывает все эти thinstation.conf* файлы в следующем порядке (процитирую источник):

Первым применяется thinstation.conf.buildtime при начальной загрузке образа, затем происходит получение файла thinstation.conf.network, и далее индивидуальные файлы конфигурации.

Если значение переменной SESSION_0_TYPE=rdesktop в файле thinstation.conf.network, а в thinstation.conf-ИМЯ_КОМЬЮТЕРА уже SESSION_0_TYPE=freerdp, то в результате загрузится freerdp.

Получить общую информацию о том, какими вообще методами могут загружаться конфигурационные файлы Thinstation можно из документа Thinstation Wiki – Configuration. Как я уже сказал, мы будем использовать загрузку дополнительных конфигурационных файлов тонких Thinstation по протоколу HTP с веб-сервера IIS. Поэтому сначала создадим на нашем веб-сервере файл групповых настроек, затем файл персональных настроек тонкого клиента.

***

На веб-сервере (вспомним параметр baseurl из build.conf) в каталоге, где уже размещаются squash-файлы (вспомним параметр basepath из build.conf) создадим общий для всех клиентов конфигурационный файл thinstation.conf.network:

SESSION_0_AUTOSTART=ON SESSION_0_TYPE=freerdp SESSION_0_TITLE="RDP" SESSION_0_FREERDP_SERVER="10.1.4.10" RECONNECT_PROMPT=FORCE NET_TIME_SERVER="10.1.4.10" TIME_ZONE="Europe/Moscow" CRON_JOB1="30 18 * * * /sbin/poweroff"

Этот файл будет содержать общие для всех клиентов параметры работы ОС Thinstation (запуск оболочки в опциях SESSION_0_*) и адрес RDS-сервера (SESSION_0_FREERDP_SERVER). Опция RECONNECT_PROMPT=FORCE, позволит автоматически выполнять переподключение к RDS-серверу в случае попыток завершения сессии и/или проблем с временной недоступностью сервера. Присутствующие здесь опции, связанные со временем и планировщиков задач рассмотрим далее. 

***

Теперь в этом же каталоге веб-сервера создадим файл индивидуальных настроек тонкого клиента с именем формата thinstation.conf-<MAC>. В нашем примере файл получится с именем thinstation.conf-00155D004036. В этом файле будут указаны опции подключения freerdp, касающиеся только этого конкретного тонкого клиента:

SESSION_0_FREERDP_OPTIONS="/u:'thinusr-00155d004036' /p:'rdpClPwd00155d004036' /bpp:32 /cert-ignore /sec:nla +fonts +aero"

Разумеется на RDS-сервере мы параллельно должны создать соответствующую учётную запись пользователя с указанным именем и паролем. Эта учётная запись будет ассоциироваться с данным тонким клиентом.

Кстати, информацию о допустимых опциях freerdp можно найти в документе: FreeRDP Wiki – CommandLineInterface.

В конечном итоге на веб-сервере мы получим примерно следующую картину:

***

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

Образ Thinstation должен быть собран со следующими параметрами:

  • В файле thinstation.conf.buildtime должны присутствовать директивы NET_FILE_ENABLED=Onи NET_FILE_METHOD=wget
  • В файле build.conf должен быть указан пусть каталоге на веб-сервере, где искать файлы конфигурации в параметрах baseurl и basepath

Кроме этого, не стоит забывать про ограничения MIME-типов которые накладывает IIS. То есть нужно решить вопрос возможности загрузки файлов с именами формата thinstation.conf*

Для этого ранее описанным способом на веб-сервере IIS добавим MIME-типы .network и .conf-<MAC-клиента> (для всех допустимых MAC-адресов) с типом text/plain:

После этого убедимся в том, что через браузер мы можем без проблем скачать соответствующие файлы с веб-сервера по ссылкам типа:

  • http://10.1.4.10/ThinClients/thinstation.conf.network
  • http://10.1.4.10/ThinClients/thinstation.conf-00155D004036

Если заниматься настройкой MIME-типов в IIS под каждый MAC-адрес не очень хочется, то можно разрешить загрузку файлов с любым расширением для определённого каталога веб-сервера. Для того, чтобы это сделать воспользуемся рекомендацией из статьи KB326965 - IIS 6.0 does not serve unknown MIME types и добавим для соответствующего каталога IIS универсальную запись: * = application/octet-stream 

***

Теперь можно считать, что наш веб-сервер готов к раздаче PXE-клиентам разных сборок и конфигураций Thinstation.

 

Тестируем запуск тонкого клиента

Перед тем, как выполнять проверочный запуск тонкого клиента, ещё раз вспомним о том, какие файлы мы имеем для его автоматической загрузки и настройки, и где эти файлы расположены на нашем Windows-сервере управления:

  • После компиляции рабочего образа Thinstation мы имеем три файла, которые распределены на сервере следующим образом:
    • D:\RemoteInstall\Images\Linux\HP-t610\vmlinuz
    • D:\RemoteInstall\Images\Linux\HP-t610\initrd
    • C:\inetpub\wwwroot\ThinClients\HP-t610\lib.squash
  • Файл настроек загрузки PXE-клиента:
    • D:\RemoteInstall\Boot\pxelinux.cfg\01-00-15-5d-00-40-36
  • Конфигурационные файлы Thinstation:
    • C:\inetpub\wwwroot\ThinClients\thinstation.conf.network
    • C:\inetpub\wwwroot\ThinClients\thinstation.conf-00155D004036

При запуске клиент с PXE-сервера получит по TFTP файлы vmlinuz и initrd, указанные в \pxelinux.cfg\01-00-15-5d-00-40-36 и загрузит их в память тонкого клиента… 

…на следующем этапе (опять же согласно настроек \pxelinux.cfg\01-00-15-5d-00-40-36) с веб-сервера будет загружен файл lib.squash и произведено применение конфигурационных файлов thinstation.conf.network и thinstation.conf-00155D004036

На последней стадии загрузки, согласно условий нашей задачи, будет запущен RDP-клиент freerdp с автоматическим подключением к серверу RDS.

Если что-то "пошло не так", перепроверим все конфигурационные файлы и заглянем в раздел Поиск решений проблем (далее).

 

Загрузка с USB накопителя

В некоторых случаях может получиться так, что загрузка образа тонкого клиента по сети не самый лучший вариант, например, из-за слабеньких и неустойчивых каналов передачи данных между конечным тонким клиентом и PXE-сервером. В таком случае, в качестве исключения, можно воспользоваться загрузкой Thinstation с локального USB-накопителя, подключённого в порт тонкого клиента.

При каждой процедуре компиляции рабочего образа Thinstation, которую мы рассматривали ранее, помимо уже знакомых нам файлов initrd/vmlinuz/lib.squash, генерируется файл загрузочного ISO-образа:

/build/boot-images/iso/thinstation.iso

Однако, как я понял, если образ Thinstation был скомпилирован с параметром fastboot в build.conf, то он для локальной загрузки не подойдёт. Поэтому, для того, чтобы получить отдельно загружаемый (без проблем) с локального накопителя образ, нам потребуется скомпилировать его с выключенной опцией fastboot.

В некоторых источниках можно встретить рекомендации по специальной настройке thinstation.conf.buildtime в процессе подготовки к компиляции локально загружаемого образа. Однако я таких настроек не выполнял, и у меня загрузка тонкого клиента с локального USB-накопителя успешно прошла из образа по сути аналогичного, тому что я собирал для сетевой загрузки с единственным упомянутым исключением - выключенным fastboot.

Структура расположения файлов внутри получающегося при компиляции ISO-образа такова:

g:\>tree /f Структура папок тома THINSTATION Серийный номер тома: 65F3-6981 G:. │ syslinux.cfg │ └───boot │ image.md5 │ initrd │ vmlinuz │ └───syslinux boot.cat isolinux.bin isolinux.cfg ldlinux.c32 product.txt<\pre>

То есть, мы видим, что нужные для загрузки системы файлы vmlinuz и initrd имеются в каталоге boot (lib.squash при этом не используется, так как образ собирался с выключенным fastboot). При этом конфигурационные файлы thinstation.conf.network и thinstation.conf-00155D004036, как и при сетевой загрузке с веб-сервера, что по прежнему нам даёт преимущества управления некоторыми параметрами конфигурации клиентов в централизованном месте.

Для записи загрузочного ISO-образа на USB-накопитель можно использовать, например, свободно распространяемую утилиту Rufus:

 

Работа тонких клиентов по расписанию

Как мы помним, согласно исходных условий, нам нужно решить вопрос автоматизации цикличной работы тонких клиентов. То есть утром каждого рабочего дня клиентов нужно автоматически включать, а вечером - автоматически выключать. Фактически эту задачу можно разложить на три составляющих момента:

  • Синхронизация времени на тонких клиентах
  • Включение клиентов по расписанию
  • Выключение клиентов по расписанию

***

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

Учитывая изолированность наших тонких клиентов, единственным источником, с которым они могут синхронизировать время, является наш выделенный Windows-сервер. Давайте настроим службу времени на этом сервере.

Так как наш Windows-сервер является виртуальной машиной Hyper-V, то в первую очередь в свойствах этой виртуальной машины отключим функцию синхронизацию времени с хостом:

 

Для настройки службы времени "Windows Time" (w32time) будем использовать входящую в состав Windows Server утилиту w32tm, которая будет управлять значениями ключа реестра HKLM\System\CurrentControlSet\Services\W32Time

Конфигурируем службу времени на синхронизацию с внешним NTP-сервером командой:

net stop w32time w32tm /config /manualpeerlist:"10.10.0.2 10.11.0.3" /syncfromflags:MANUAL net start w32time

Проверяем статус синхронизации командой:

w32tm /query /status

Для того, чтобы служба времени работала, не только как NTP-клиент, но и как NTP-сервер, нужна дополнительная правка реестра:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer] "Enabled"=dword:00000001

После правки реестра отправляем службе NTP информацию об обновлении конфигурации (последняя команда покажет текущий статус конфигурации):

w32tm /config /update w32tm /query /configuration

Учитывая то обстоятельство, что в в нашем случае Windows-сервер не является членом домена, у нас может возникнуть проблема с автоматическим запуском службы времени в процессе загрузки системы. Проблема эта известна давно и описана в статье KB2385818 - Windows Time service doesn't start automatically on a workgroup computer that's running Windows 7 or Windows Server 2008 R2. Суть проблемы в том, что служба времени имеет триггер, который выполняет запуск службы только в том случае если система является членом домена. Проверить это можно командой:

sc qtriggerinfo w32time

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

sc triggerinfo w32time start/networkon stop/networkoff

После перезапустим сервер и убедимся в том, что служба запускается автоматически без проблем.

Убедимся в том, что в системе висит UDP-прослушиватель на 123 порту:

C:\>netstat -na | findstr 123 UDP 0.0.0.0:123 *:* UDP [::]:123 *:*

Создадим правило в Windows Firewall, разрешающее входящие подключения на порт NTP-сервера:

New-NetFirewallRule -DisplayName "NTP Server (UDP-In)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "123"

***

Теперь посмотрим на протокол NTP с точки зрения нашего тонкого клиента. Первое, о чём стоит заметить, это то, что для поддержки возможности синхронизации времени, образ Thinstation должен быть собран с включённым пакетом package ntp в build.conf (в приведённом ранее примере build.conf этот пакет включен).

Информацию о NTP-сервере, как источнике синхронизации времени можно указать в любом из thinstation.conf* файлов. Мне показалось более удобным указать эти опции в файле thinstation.conf.network, который лежит на веб-сервере и централизовано раздаётся всем тонким клиентам. Как минимум можно указать параметры (в приведённом ранее примере thinstation.conf.network эти параметры имеются):

NET_TIME_SERVER="10.1.4.10" TIME_ZONE="Europe/Moscow"

Если эти условия соблюдены, то можно попробовать с загруженного тонкого клиента (а мы помним про то, что у нас есть возможность подключения к консоли клиента через Telnet) выполнить команду получения времени с нашего сервера времени:

ts_00155D004036:~# ntpdate 10.1.4.10 9 Feb 16:52:23 ntpdate[4762]: step time server 10.1.4.10 offset 1.681994 sec

Как видим, ответ от NTP-сервера получен. В конфигурации по умолчанию NTP-клиент, встроенный в Thinstation, будет выполнять синхронизацию времени в начале каждого очередного часа.

***

Теперь поговорим об автоматизации выключения тонких клиентов по расписанию. Thinstation, как Linux-система, имеет на борту работающий планировщик cron. Конфигурационные файлы thinstation.conf* позволяют нам добавлять до 9 заданий в этот планировщик с помощью параметров CRON_JOB[1-9]. Пример добавления задачи на отключение тонкого клиента по расписанию - каждый день в 19:30:

CRON_JOB1 = "30 19 * * * /sbin/poweroff"

Опять же отмечу, что в приведённом ранее примере thinstation.conf.network эта задача cron была упомянута. В случае необходимости мы можем разным тонким клиентам аналогичным образом задавать уникальные параметры отключения, например, через файлы thinstation.conf-<MAC>.

Добавленное через конфигурационные файлы Thinstation задание cron в загруженном клиенте попадёт в файл /tmp/crontab

Кстати, здесь же можем увидеть и задания синхронизации времени (первое и второе задание). 

***

Задача автоматизации включения тонких клиентов по расписанию, как и прочие задачи, может иметь разные варианты реализации. Учитывая то, что в нашем случае все клиенты находятся в рамках одного физического сегмента сети, мы можем использовать функционал пробуждения клиентов по сети (Wake On Lan) по MAC-адресам.

Для этой цели я воспользовался ещё одной бесплатной утилитой командной строки для Windows: Wake On Lan Command Line

Синтаксис использования утилиты прост:

wolcmd [MAC-адрес] 255.255.255.255 255.255.255.255 7

То есть с помощью этой утилиты мы посылаем в сеть широковещательный запрос с указанием MAC-адреса интересующего нас клиента.

При этом замечено, что клиент будет реагировать на WoL-запрос, только в том случае, если в прошлый раз система была выключена штатно. Если же выключение произведено жёстко (например нажата кнопка питания с удержанием), то для последующего успешного запуска потребуется обесточить клиента (извлечь/вставить шнур питания).

В общем всё, что здесь остаётся сделать, это создать на нашем Windows-сервере управления командный файл с вызовом wolcmd и добавить его в планировщик заданий Windows на выполнение в нужное время, например, в 07:50 утра каждого рабочего дня недели. 

 

Поиск решений проблем

Если в процессе загрузки по сети возникают проблемы, например, когда останавливается и "замерзает" индикатор загрузки на сплэш-заставке, то может потребоваться получить доступ к расширенной информации о ходе загрузки. Для этого нужно изменить параметры вызова initrd в конфигурационном файле PXE-сервера. Например так выглядит ранее приведённый пример вызова initrd в штатной ситуации:

... APPEND initrd=/Linux/HP-t610/initrd splash=silent,theme:default load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=3 console=tty1 vt.global_cursor_default=0 LM=3 FASTBOOT_URL=http://10.1.4.10/ThinClients/HP-t610/

Чтобы отключить отображение сплэш-заставки, уберём параметр splash=silent,theme:default. Чтобы перенаправить вывод процесса загрузки на основную консоль, заменим console=tty1 на tty0. Дополнительно можно увеличить уровень логирования, например loglevel=32. В тоге получится примерно так: 

... APPEND initrd=/Linux/HP-t610/initrd load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=32 console=tty0 vt.global_cursor_default=0 LM=3 FASTBOOT_URL=http://10.1.4.10/ThinClients/HP-t610/

***

Я на практике столкнулся с тем, что в загружаемой системе Thinstation сеть не успевает пройти полную инициализацию до того момента, как система пытается получить по HTTP squash-файл или файлы конфигурации. В итоге возникают ошибки типа "No lease, forking to background", "Network is unreachable"  и т.п.

В таких случаях на этапе сборки образа можно покрутить параметры в thinstation.conf.buildtime, связанные с сетью (NET_*). А получить по ним информацию можно из файла thinstation.conf.sample. Например можно для начала задать увеличенные значения интервалов ожидания и таймаутов, как было показано на выше.

NET_DHCP_DELAY=60 NET_DHCP_TIMEOUT=60 NET_LINKWAIT=60

Можно попробовать использовать эти параметры как по отдельности так и комбинировать их вместе.

***

Если сразу строить описанный стенд от начала и до конца, то допустив где-нибудь по пути ошибку, можно потратить немало времени на излишний "разбор полётов". Поэтому лучше действовать поступательно, то есть, например, сначала добиться загрузки по сети без использования fastboot, а потом уже, если всё работает как следует, переходить к усложнению конфигурации. Дополнительно в поиске решений проблем может оказаться полезной статья Thinstation Wiki - Debugging 

 

Дополнительные источники информации:

Поделиться ссылкой на эту запись:

Похожее

blog.it-kb.ru

Готовим ThinStation :: [soar.name]

Введение

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

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

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

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

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

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

git clone --depth 1 git://github.com/Thinstation/thinstation.git -b 5.5-Stable

где 5.5-Stable - актуальная на данный момент ветка. К сожалению размер репозитория за последние годы очень сильно вырос - в 2014-ом году он занимал чуть более 2 ГБ, а сейчас скачать придется целых 8 ГБ. Поэтому во всех мануалах предлагают скачивать его с ключом --depth 1 - на вкус и цвет.

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

Подготовка chroot

В корневой директории скачанного репозитория лежит bash-скрипт setup-chroot, который сделает всю работу за вас. О нем нужно знать лишь то, что запускать его нужно от рута (т.к. он, например, монтирует в новое дерево служебные файловые системы), а во-вторых он имеет набор ключей, самым нужным из которых на первом этапе является ключ -a - не задавать вопросы, а скачивать всё что нужно автоматически.

К слову, всё остальное выполняется уже внутри этого чрута. В первый раз операция подготовки может занять до часу времени (на медленном диске), но потом вход осуществляется практически мгновенно до следующей полной очистки.

Толстый образ

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

Безусловно, есть вероятность, что для вашего железа это кто-то уже сделал. Вы можете зайти в директорию ts/build/machine и поискать там название вашей платформы. Если найдете - смело пропускайте этот пункт.

Настройка сборки

Первое, что вам понадобится, отредактировать файл ts/build/build.conf (изначально это симлинк на build.conf.example - сделайте копию) следующим образом (раскомментируйте строки):

... # Пригодится, чтобы больше узнать о железе package lshw ... # Набор xorg-пакетов для практически любого видео package xorg7-v4l package xorg7-vesa package xorg7-vmware package xorg7-ati package xorg7-nouveau package xorg7-openchrome package xorg7-intel package xorg7-sis ... # Системные утилиты, в том числе - hwlister, о нем ниже package extensions package extensions-x ... # Изменение системы сжатия param initrdcmd "gzip" ... # Включает полный набор firmware - иногда не работает, но рекомендую раскоментировать param allres true param allfirmware true ...

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

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

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

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

Этот же скрипт попытается загрузить файлы на ваш 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="rw,nosuid,nodev,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro" 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 - и этого будет более чем достаточно. Если же вам нужно собирать бинарные файлы - то вам понадобится сделать свой порт.

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

Первое, что я рекомендую сделать, это создать для своих поделок отдельную директорию. Для этого нужно в файл ts/etc/prt-get.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 упаковывается в архив. Это и будет наш порт, готовый для установки.

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

[[email protected]_chroot]/# cd ts/ports/yourproject/portname/ [[email protected]_chroot]/ts/ports/yourproject/portname# pkgmk -kw =======> Building '/ts/ports/yourproject/portname/portname#0.5.2.3-1.pkg.tar.xz'. ... =======> WARNING: Footprint not found, creating new. =======> Building '/ts/ports/yourproject/portname/portname#0.5.2.3-1.pkg.tar.xz' succeeded.

Конечный файл portname#0.5.2.3-1.pkg.tar.xz (имя файла формируется с учетом переменных заданных в начале скрипта) представляет из себя готовый к установке порт и содержит в себе дерево файловой системы. Остается включить его в образ - о том, как это сделать, смотрите ниже.

Нужно также отметить, что если у вас в директории с портом присутствуют файлы .footprint или .md5sum - сборка может "провалиться" с ошибкой из-за несоответствия дерева файлов или md5-сумм. Можно эти файлы удалить перед сборкой и они сгенерируются автоматически, а можно выполнить следующую последовательность действий:

Порт собран - самое время установить его в систему. На данном этапе речь идет о системе рабочей, той, где вы собираете ThinStation.

[[email protected]_chroot] # prt-get install portname prt-get: installing /ts/ports/yourproject/portname =======> Package '/ts/ports/yourproject/portname/portname#0.5.2.3-1.pkg.tar.xz' is up to date. prt-get: installing portname 0.5.2.3-1 -- Packages installed portname prt-get: installed successfully

Теперь архив распакован в систему и все файлы доступны для использования. Однако эти файлы не появятся в собранном вами образе - для этого вам кроме порта, понадобится еще и пакет.

Создание пакета

Минимальный пакет может выглядеть так:

[email protected]$ tree ts/build/packages/mypackage/ ts/build/packages/mypackage/ ├── dependencies ├── etc │   └── somefile-placed-in-etc

Где в файле dependencies достаточно указать одну строку - base. Считается хорошим тоном, чтобы все пакеты зависели хотя бы от пакета base, но вы можете добавить больше правил. Этого уже достаточно, чтобы при включении строки package mypackage в ваш build.conf - файл somefile-placed-in-etc попал в директорию /etc вашего готового образа.

Что же делать, если мы хотим, чтобы наш пакет, кроме обычных файлов, включал в сборку наш порт? Для этого нам понадобятся всего два скрипта. Скрипт установки ts/build/packages/mypackage/build/install:

#!/bin/sh # mypackage - имя нашего порта export PACKAGE=mypackage export PORTS=$PACKAGE repackage -e returnval=$? exit $returnval

И скрипт удаления ts/build/packages/mypackage/build/remove:

#!/bin/sh # mypackage - имя нашего порта export PACKAGE=mypackage repackage -c

Теперь, при запуске магического ./build наш порт будет добавлен в дерево файлов образа и появится в сборке. Конечно, если вы не забыли добавить этот пакет в build.conf.

Обновления

Нужно отметить, что все манипуляции описанные выше возможны благодаря магии системы портов CRUX. Порт устанавливается и удаляется из системы на основе данных из .footprint и важно следить, чтобы этот файл всегда был актуален. Есть и другие подводные камни - прерванный процесс установки, ошибка во время установки и еще множество различных непредусмотренных действий могут легко привести к тому, что в вашей системе (и как следствие - образе) будут файлы, которые вы совсем не ожидаете увидеть. Я периодически делаю полную очистку кухни, чтобы быть уверенным в том, что система будет вести себя as-expected. Однако, иногда на это времени не хватает. Поэтому, если какой-то пакет и/или порт стал неконсистентным, я для себя вывел следующую последовательность команд, которая в 99% случаев очистит все лишние файлы и всё-таки приведет дерево в порядок:

# Обновляем порт, футпринт и мд5 prt-get update mypackage prt-get update -uf mypackage prt-get update -um mypackage # Очищаем билд (выполняет содержимое файла remove, описанного выше) ./build --removeall # Удаляем порт prt-get remove mypackage # Обновляем пакет (при наличии .dna файла) update mypackage # Устанавливаем порт prt-get install mypackage # Запускаем сборщик ./build --license ACCEPT --autodl

Что еще почитать

Вот пара достаточно интересных статей, которые когда-то мне очень помогли:

Ну и на всякий случай, моя ветка ThinStation на GitHub, где можно найти некоторые дополнительные профили и изменения, может быть пригодится:

soar.name

Thinstation по русски

Если достаточно пробросить одно устройство с тонкого клиента на сервер, то можно попробовать софтину из этого поста на форуме.Ну а если чем то она не устраивает, то поехали дальше.

Итак, начнём с самого главного. Серверная часть этого пакета лежит в ядре в виде модулей. Скажу больше, вам не нужно перекомпилировать ядро в thinstation, потому как они уже включены по-умолчанию, это три модуля usbip-core.ko, usbip-host.ko и vhci-hcd.ko. Для того, чтобы эти модули были собраны в ваш образ вам необходимо добавить эти модули в build.conf вручную тремя строчками, потому что эти модули вспомогательные и не учтутся скриптом hwlister.sh:

( HTML ломает некоторые знаки. Для точного копирования команд справа от листинга есть кнопка <>)

module usbip-core module usbip-host module vhci-hcd

Теперь нам необходима клиентская часть, несмотря на то, что наш ТК выступает в роли сервера. Клиентская часть находится всё в том же ядре, только в userspace части. Для этого нам понадобятся исходники нашего ядра. Итак, скачиваем их:

cd thinstation su ./setup-chroot cd /ts/ports/kernel-modules/kernel-TS pkgmk -d -kw

После применения патчей прерываем компиляцию, нажав Ctrl+C

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

 Итак, перейдём в каталог с исходниками клиентской части (обратите внимание на версию ядра, она скорее всего уже будет иная):

cd /ts/ports/kernel-modules/kernel-TS/work/src/linux-4.6.3/tools/usb/usbip

Находим файл configure.ac и меняем в строке указания версии значение 0x00000111 на 0x00000106

AC_DEFINE([USBIP_VERSION], [0x00000106], [binary-coded decimal version number])

Теперь перейдём в каталог src

и добавим в шапку файла usbip_network.h следующие директивы

#define USBIP_CMD_SUBMIT 0x0001 #define USBIP_CMD_UNLINK 0x0002 #define USBIP_RET_SUBMIT 0x0003 #define USBIP_RET_UNLINK 0x0004 #define USBIP_DIR_OUT 0x00 #define USBIP_DIR_IN 0x01

Редактировать не обязательно в chroot-окружении, пользуйтесь любым удобным редактором (mc, vi ...), а вот команды выполнять в chroot.Все манипуляции проведены, теперь приступим к сборке пакета. Выйдем на ступень вверх из каталога src и выполним все необходимые процедуры:

cd .. ./autogen.sh ./configure --exec-prefix=/ts/build/packages/usbip --with-usbids-dir=/lib make install

Параметром exec-prefix я указал установщику положить библиотеки и бинарники в каталог, где лежат все пакеты, которые могут быть добавлены через параметр package файла build.conf. Перейдём в этот каталог и посмотрим содержимое:

cd /ts/build/packages/usbip ls -l total 8 drwxr-xr-x 2 root root 4096 Nov 22 09:51 sbin drwxr-xr-x 2 root root 4096 Nov 22 09:51 lib

Переименуем каталог sbin в bin(точнее переместим):

Создадим в корне нашего пакета файл dependencies и добавим туда слово ids и base, чтобы наш пакет зависел от базовых утилит(они нам понадобятся в дальнейшем) и :

cat > dependencies base <Enter> ids CTRL+d

CTRL+d - это сочетание клавиш, которое необходимо нажать после набора слова ids.

И добавим в файл build.conf параметр:

Теперь нам осталось совсем немного до того момента, как мы сможем закинуть наш пакет в образ и заставить его работать.Перед нами стоит задача довести процедуру связывания устройств с сервисом usbip до автоматизма, иными словами, при подключении нового устройства или смена порта подключения наше устройство автоматически "мапилось" через usbip, без выковыривания нужных параметров usbip и дополнительной пересборки образа. В этом нам поможет udev - менеджер устройств. У нас возникает только один нюанс - средствами udev невозможно различить устройства по типам - принтеры, сканеры, накопители, hid-устройства и т.д., а это важно, потому что нам не нужно "прокидывать" мышку на сервер через usbip, тем более что устройство становится полностью недоступным для ТК после подключения к нему клиентом usbip. Выход в данной ситуации может быть следующим - перечислить в правилах производителя устройства(т.н. вендор) и, соответственно, таким образом различать устройства. Ну что ж, воплотим слова в жизнь.В каталоге /ts/build/packages/usbip/lib/udev/rules.d мы создадим своё проавило 99-usbip.rules (всё должно быть в одной строке!):

ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_VENDOR}=="Samsung", RUN+="/bin/usbip_bind %E{ID_VENDOR_ID} %E{ID_MODEL_ID}"

Немного расшифрую смысл написанного. Первые три параметра(ACTION и два ENV) действуют по принципу логического И, т.е. при добавлении устройства (ACTION=="add") usb (ENV{ID_BUS}=="usb") производителя Samsung (ENV{ID_VENDOR}=="Samsung") должна выполнятся команда (RUN+="usbip_bind %E{ID_VENDOR_ID} %E{ID_MODEL_ID}"). Таким образом, если вам нужны ещё устройства, например, Canon, Hewlett-Packard, Epson и др., то вам нужно в этом же файле создать точно такие строки, только в ENV{ID_VENDOR} указать нужного вам производителя. Следует заметить, что название производителя не может быть взято "с потолка", его можно посмотреть, например, выполнив команду udevadm monitor --env | grep ID_VENDOR, подключившись к ТК по telnet или ssh, и подключив ваше устройство(после выполнения команды).Как вы могли заметить, в параметре RUN присутствует usbip_bind. Это скрипт, который автоматически подвязывает наше устройство на usbip, при этом нам не нужно будет заботится об особых параметрах, которые передаются команде usbip - это всё за нас будет делать наш скрипт. Этот скрипт мы положем в /ts/5.1/packages/usbip/bin. Итак, создадим скрипт, дадим права на выполнение и заполним его:

cd /ts/5.1/packages/base/lib/udev touch usbip_bind chmod 0755 usbip_bind

#! /bin/sh . /etc/thinstation.env . $TS_GLOBAL BUSID=`/bin/usbip list -l | /bin/grep $1:$2 | /bin/awk '{print $3}' | grep -` USB_IP=`/bin/ps | /bin/grep -v grep | /bin/grep "usbipd -D"` if [ -n "$USB_IP" ]; then /bin/usbip bind -b $BUSID /bin/usbip attach --remote=localhost --busid=$BUSID sleep 3 /bin/usbip port /bin/usbip detach --port=00 else modprobe usbip-core modprobe usbip-host modprobe vhci-hcd /bin/usbipd -D /bin/usbip bind -b $BUSID /bin/usbip attach --remote=localhost --busid=$BUSID sleep 3 /bin/usbip port /bin/usbip detach --port=00 fi

Рассмотрим этот скрипт подробнее. Параметр BUSID - это необходимый параметр команды usbip, его мы вычисляем автоматически с помощью параметров ID_VENDOR_ID и ID_MODEL_ID(они передаются параметрами в скрипт из нашего правила udev). Далее, как вы видите, идет условный оператор if. Всё дело в том, что если ваше устройство уже подключено на момент включения ТК, то при включении ТК вам нужно запустить службу usbipd, а если вы будете подключать устройство уже во время работы ТК, то вам нет необходимоти этого делать. Поэтому здесь мы и воспользовались условным оператором if, а условие "-n $USB_IP" определяет запущен ли процесс usbipd.

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

видим:usbip_host 12943 0usbip_core 5618 1 usbip_hostusbcore 124913 4 usbip_host,usbhid,uhci_hcd,ehci_hcdts_test_1:~# usbip list -lLocal USB devices=================- busid 2-1 (046d:c018)2-1:1.0 -> usbhid- busid 2-2 (04a9:2220)2-2:1.0 -> usbip-host

Как видите строка "2-2:1.0 -> usbip-host" показывает, что наше устройство уже готово со стороны сервера, но подключится с винды получится если устройство было запущено или перезапущено после загрузки клиента.

Теперь остался последний штрих в нашем нелегком деле - настроить клиента. Клиентом в данном случае будет Windows 2008 R2, на других версиях Windows возможно не заведётся, но если такая уж необходимость, то надо пробовать.Итак, идём вот сюда и скачиваем usbip_windows_v0.2.0.0_signed.zip. Распакуем это "добро" в каталог C:\ (желательно, чтобы название каталога было usbip, а не usbip_win..., это просто для дальнейшего удобства). Теперь добавим новое "старое устройство". Всё это описано в файле USAGE скачанного нами клиента. Итак, по шагам:

1. Открываем "Панель управления" - "Диспетчер устройств"2. Правой кнопкой мыши на имени компьютера - "Установить старое устройство"3. Откроется мастер, жмёте "Далее"4. В следующем окне выбираете "Установка оборудования, выбранного из списка вручную" и жмёте "Далее"5. Выбираете "Системные устройства" - "Далее"6. "Установить с диска" указываете путь, куда распаковали клиента, и снова "Далее"7. Выберите "USB/IP Enumerator", нажмите "ОК", "Далее" и "Готово"

Теперь необходимо подключить наше устройство, присоединенное к ТК. Открываем командную строку и пишем:

C:\Users\Administrator>cd c:\usbip usbip -l 10.10.10.10 - 10.10.10.10 2-2: Canon, Inc. : CanoScan LIDE 25 (04a9:2220) : /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-2 : Vendor Specific Class / unknown subclass / unknown protocol (ff/00/ff) : 0 - Vendor Specific Class / unknown subclass / unknown protocol (ff/00/ff) usbip -a 10.10.10.10 2-2 new usb device attached to usbvbus port 1 Receive sequence: 3900

Командой "usbip -l 10.10.10.10" мы вывели список всех устройств с нашего ТК, "расшаренных" через usbip (10.10.10.10 - ip нашего ТК).Командой "usbip -a 10.10.10.10 2-2" мы примапили это устройство к себе на наш терминальный сервер (2-2 это тот самый busid, необходимый для присоединения устройства).Теперь в диспетчере устройств у вас есть новое неопознанное устройство. Ставите на него драйвера и оно должно заработать как ему и положено.Коммандую строку закрывать нельзя, иначе связь обрывается. Есть проще решение - написать скрипт и выполнять в фоне. Самый простой вариант выглядит так:

On Error Resume Next Set wshshell = CreateObject("wscript.shell") WshShell.Run "cmd /c cd c:\usbip & usbip -a 10.10.10.10 2-2", 0, FALSE

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

Статья переработана 10.02.2017 года, в свете последних изменений в исходниках ядра.

Готовый пакет на ядре 4.6.3 можно забрать ЗДЕСЬ

Оригинал статьи здесь

Обсудить на форуме (комментариев 32).

it-advisor.ru

Thinstation по русски

В больших организациях часто встречается зоопарк различных аппаратных платформ тонких клиентов. Даже у одного производителя система может базироваться и на VIA чипсете и на Geode и на NVidia, а собрать универсальный образ загрузки не всегда получается - либо очень большой, либо модули или пакеты несовместимы.

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

  • Правильный, и работающий на Windiws и Linux DHCP серверах -  выбрать самый многочисленный класс одинаковых клиентов и отдать им дефолтную загрузку PXE, а остальные прописать по MAC-адресам в DHCP и назначить каждой опцию 67 равную папка/pxelinux.0 (filename "папка/pxelinux.0";), разместив эти файлы по разным папкам на TFTP сервере, в зависимости от железа или софта.Но это затратное по времени мероприятие - собрать маки и забить их в DHCP.
  •  Второй способ - через конфигурацию загрузки pxelinux.cfg, находящуюся на сервере TFTP.При получении файла конфигурации от TFTP сервера клиент ищет подходящую для себя в следующем порядке:

    pxelinux.cfg/01-88-99-aa-bb-cc-ddpxelinux.cfg/C0A800FEpxelinux.cfg/C0A800Fpxelinux.cfg/C0A800pxelinux.cfg/C0A80pxelinux.cfg/C0A8pxelinux.cfg/C0Apxelinux.cfg/C0pxelinux.cfg/СИ если ничего подходящего нет - pxelinux.cfg/defaultpxelinux.cfg - сама папка с файлами конфигурации, 01-88-99-aa-bb-cc-dd - файл с названием МАС-адрес клиента, в нижнем регистре, разделенный тире, с префиксом 01-.А дальше - это IP-адрес, который клиент получил, в шестнадцатеричном формате. Т.е. C0A800FE = 192.168.0.254. Получается, что для привязки машины к образу нам нужен MAC-адрес или IP клиента и файлы (содержание посмотреть в файле pxelinux.cfg/default, только в пути до vmlinuz и initrd дописать свою папку или переименовать их, например в  vmlinuz-depo и initrd-depo и прописать в конфиг) с именем "01-мак-ад-рес" или с именем "IPклиента" переведённом в HEX формат (здесь онлайн) или в консоли linux: echo $(printf '%02X' 192 168 0 254), и находиться они должны в папке pxelinux.cfg. В общем телодвижений ещё больше, чем в первом варианте.

  • Третий способ  - выбор образа загрузки через меню.Делаем меню загрузки для разных конфигураций. Для начала нужно привести файл pxelinux.cfg/default примерно к следующему виду:

default vesamenu.c32prompt 0menu title Меню выбора образа PXEtimeout 300font 866_8x16.psflabel depomenu label PXE для ДЕПОmenu defaultkernel depo/vmlinuzappend initrd=depo/initrd  video=uvesafb:1024x768-32,mtrr:0,ywrap splash=silent,theme:default console=tty1 loglevel=3 LM=3label tonkmenu label PXE для ТОНКkernel tonk/vmlinuzappend initrd=tonk/initrd  video=uvesafb:1024x768-32,mtrr:0,ywrap splash=silent,theme:default console=tty1 loglevel=3 LM=3

Если нужны ещё пункты - добавляем их по образу и подобию.Сразу после загрузки клиента получим вот такое меню:

Для отображения меню по русски нам нужно сохранить файл в кодировке CP-866 и положить в папку файл шрифта font 866_8x16.psf. (архив в конце статьи)А если немного настроить меню под себя - то можно получить вот такую красоту:

Недостаток такого метода в том, что придётся объяснить пользователям в какой пункт меню заходить, в зависимости от начинки клиента.

  • И наконец самый лёгкий путь, к сожалению я не знаю как его реализовать в Windows сервере, это прописать условие в конфигурационном файле Linux сервера dhcpd.conf  в описание subnet следующие настроики:

if (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:26:73") { filename "/depo/pxelinux.0"; } elsif (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:1e:90") { filename "/tonk/pxelinux.0"; } else { filename "pxelinux.0"; }

Здесь прописываются начальные, одинаковые для определённого производителя, значения MAC-адреса и если условие совпадает с началом мака клиента - то ему назначается определённый в условии файл начальной загрузки из соответствующей папки на TFTP сервера.Важно отметить, что в «переменной» hardware для сетевых карт идет лидирующий блок: «01:», так что приходится его учитывать. Также важно, что, если часть MAC-адреса начинается с нуля, то он при переводе отбрасывается. Таким образом, MAC-адрес с началом «00:03:EF» преобразуется в «1:0:3:ef».

Ещё проще в dnsmasq

dhcp-mac=depo,00:26:73:*:*:* dhcp-boot=net:depo,depo/pxelinux.0,boothost,192.168.111.254 dhcp-mac=tonk,00:1E:29:*:*:* dhcp-boot=net:tonk,tonk/pxelinux.0,boothost,192.168.111.254 dhcp-boot=pxelinux.0,boothost,192.168.111.254

 Выбор способа за Вами.

Обсудить на форуме (комментариев 2).

it-advisor.ru


Смотрите также