Как подключить тонкий клиент к серверу windows

Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу 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:RemoteInstallBootx64 на сервере WDS следующие файлы:
  syslinux-6.03bioscorepxelinux.0 (переименовать в pxelinux.com)
  syslinux-6.03bioscom32menuvesamenu.c32
  syslinux-6.03bioscom32elflinkldlinuxldlinux.c32
  syslinux-6.03bioscom32chainchain.c32
  syslinux-6.03biosmemdiskmemdisk
• Скопируем файл D:RemoteInstallBootx64abortpxe.com в файл abortpxe.0.
• Скопируем файл D:RemoteInstallBootx64pxeboot.n12 в файл pxeboot.0.

Повторим действия, проделанные для каталога D:RemoteInstallBootx64 применительно к каталогу D:RemoteInstallBootx86

***

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

Создадим конфигурационный файл PXE «по умолчанию» с именем default в каталоге D:RemoteInstallBootpxelinux.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:RemoteInstallBootx64 и создадим символическую ссылку (junction) на каталог D:RemoteInstallBootpxelinux.cfg:

cd /d D:RemoteInstallBootx64
mklink /J pxelinux.cfg D:RemoteInstallBootpxelinux.cfg

Повторим тоже самое для каталога D:RemoteInstallBootx86:

cd /d D:RemoteInstallBootx86
mklink /J pxelinux.cfg D:RemoteInstallBootpxelinux.cfg

 
***

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

В командной строке с правами Администратора перейдём в каталог D:RemoteInstallBootx64 и создадим символическую ссылку (junction) на каталог D:RemoteInstallImagesLinux:

cd /d D:RemoteInstallBootx64
mklink /J Linux D:RemoteInstallImagesLinux

Повторим тоже самое для каталога D:RemoteInstallBootx86:

cd /d D:RemoteInstallBootx86
mklink /J Linux D:RemoteInstallImagesLinux

***

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

wdsutil /set-server /bootprogram:bootx86pxelinux.com /architecture:x86
wdsutil /set-server /N12bootprogram:bootx86pxelinux.com /architecture:x86
wdsutil /set-server /bootprogram:bootx64pxelinux.com /architecture:x64
wdsutil /set-server /N12bootprogram:bootx64pxelinux.com /architecture:x64

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

wdsutil /set-server /bootprogram:bootx86pxeboot.com /architecture:x86
wdsutil /set-server /N12bootprogram:bootx86pxeboot.n12 /architecture:x86
wdsutil /set-server /bootprogram:bootx64pxeboot.com /architecture:x64
wdsutil /set-server /N12bootprogram:bootx64pxeboot.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:RemoteInstallImagesLinux

Создадим временную сетевую папку на нашем 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:RemoteInstallImagesLinux

Получение файлов профиля оборудования для 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:RemoteInstallImagesLinux (перезаписав возможно ранее размещённые там файлы от служебного образа 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:Inetpubwwwroot). Вспомним, что именно этот подкаталог веб-сервера мы указывали в параметре basepath в файле build.conf перед компиляцией рабочего образа Thinstation.

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

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

Мы помним, что для размещения файлов образа Thinstation initrd и vmlinuz на WDS мы использовали каталог D:RemoteInstallImagesLinux. В процессе загрузки PXE клиенты сначала скачивают файл D:RemoteInstallBootpxelinux.cfgdefault (на него ведут сим.линки из D:RemoteInstallBootx64pxelinux.cfg и D:RemoteInstallBootx86pxelinux.cfg), в котором указан путь к файлам initrd и vmlinuz. Этот файл мы создавали ранее на этапе настройки WDS.

Мы можем заставить отдельно-взятого тонкого клиента Thinstation вместо настроек, указанных в файле default использовать какие-то другие настройки порядка загрузки, например указав путь к другим файлам initrd и vmlinuz. Для этого в каталоге PXE-сервера D:RemoteInstallBootpxelinux.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:RemoteInstallBootpxelinux.cfgdefault. То есть в каталоге, из которого PXE-сервер отдаёт клиентам загрузочные образы мы создали подкаталог /Linux/HP-t610/ (физический путь D:RemoteInstallImagesLinuxHP-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:RemoteInstallImagesLinuxHP-t610vmlinuz
• D:RemoteInstallImagesLinuxHP-t610initrd
• C:inetpubwwwrootThinClientsHP-t610lib.squash
• Файл настроек загрузки PXE-клиента:
• D:RemoteInstallBootpxelinux.cfg1-00-15-5d-00-40-36
• Конфигурационные файлы Thinstation:
• C:inetpubwwwrootThinClientsthinstation.conf.network
• C:inetpubwwwrootThinClientsthinstation.conf-00155D004036

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

…на следующем этапе (опять же согласно настроек pxelinux.cfg1-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, которая будет управлять значениями ключа реестра HKLMSystemCurrentControlSetServicesW32Time

Конфигурируем службу времени на синхронизацию с внешним 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_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer]
"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/

<

p align=»center»>***

Я на практике столкнулся с тем, что в загружаемой системе 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 

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

• Thinstation / maintained by Donald A. Cupp Jr.
• Thinstation Wiki
• Peter Hinchley — Use Thinstation to Build a Network-Bootable RDP-Enabled Thin Client Image
• Блог QUADED — Сборка Thinstation образа
• ITSave — Thinstation 5.x
• Thinstation по русски
• Thinstation Доработка тонкого клиента
• PXE загрузка Thinstation в зависимости от железа тонкого клиента
• Загрузка PXE для разных платформ тонких клиентов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Windows-терминал K-Systems Termin
• Тонкий клиент AK-Systems GP
• Windows-терминал AK-Systems GPN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как из старого Windows ПК сделать тонкий клиент?

Рано или поздно возникает вопрос о необходимости заменить один или несколько ПК по причине медленной работы.

Самый простой способ, нечего не выдумывать и просто заменить ПК.

Не самый простой способ, это начать внедрять «удаленные рабочие столы» в варианте терминальный сервер или виртуальные десктопы.

Стоимость тонкого клиента HP, DELL или других брендов может сравнится с стоимостью полноценного ПК, а использование старого ПК в качестве тонкого клиента позволит продлить срок эксплуатации на достаточно долгий срок.

Как поступить с морально устаревшими ПК:
— оставить на ПК Windows, пользователь будет подключатся к удаленному рабочему столу.
— загружать ПК по сети, один из linux вариантов thinstation.
— установить на ПК локальную версию linux, вариантов море.

Далее буду описывать вариант с Windows, такой тонкий клиент обладает некоторыми преимуществами при сравнении с linux вариантами.

Зачем я все это делал:

— У меня есть удаленные офисы с пользователями которых нужно было перевести работать на терминальные сервера, применение групповых политик в домене позволяют получить необходимый результат без присутствия в офисе и без замены ПК.
— И Windows и linux варианты пользовательских интерфейсов тонких клиентов HP, Wyse/DELL меня не устраивают по разным причинам.

Преимущества Windows варианта:
— Полная поддержка RDP/RemoteFX.
— Полная поддержка сменных носителей.
— Возможность использовать локальный принтер.
— Возможность использовать смарт карты для клиент банка.
— Редирект воспроизведения видео/аудио на тонкий клиент при использовании Windows Media Player, без тормозов и без нагрузки на сервер можно смотреть видео 1080р, но это отдельная история =).

Если начать с результата:

Так будет выглядеть загрузка рабочего стола пользователя, если на ПК установлен Windows XP:

Так будет выглядеть загрузка рабочего стола пользователя, если на ПК установлен Windows 7:

Чтобы получить результат который вы можете видеть на слайдах, необходим домен AD и несколько групповых политик для ПК и пользователей.

На ПК с XP SP3 необходимо установить обновления для rdp клиента KB969084 и Fixit50588, для расширенных групповых политик необходимо установить обновление KB943729.

№1 — Пользователям необходимо разрешить Single sign-on, я распространяю эту политику на весь домен.

№2 — Для ПК делаем отдельный OU и замыкаем групповые политики в этом OU.

№3 — В новом OU создаем политику где меняем шел пользователя на «wscript c:thinPCthinPC.vbs /nologo /b».

На целевой ПК необходимо скопировать 3 файла, я использую для этого расширенные групповые политики.
Рекомендую фалы разместить в центральном хранилище групповых политик \имя доменаSYSVOLимя доменаPolicies, это позволит обеспечить отказоустойчивость в случаи недоступности одного из домен контроллеров.
На домен контроллерах этому сетевому ресурсу соответствует папка C:WindowsSYSVOLsysvolимя доменаPolicies

Содержимое файла thinPC.cmd

В процессе работа описанного скрипта пользователь будет наблюдать выполнение команд в окне, и для скрытия окна скрипт запускается средствами VBS.

Содержимое файла thinPC.vbs

Dim oShell
Set oShell = WScript.CreateObject («WSCript.shell»)
oShell.run «C:thinPCthinPC.cmd»,0
Set oShell = Nothing

— Необходимо отключить отображение панели подключения при работе на полном экране.
— Я отключаю проброс локальных дисков, но разрешаю проброс дисков подключенных позже, это позволит пользователям работать с сменными носителями которые подключат после начала удаленного сеанса.
— В случаи ОС windows 7 для использования протокола RemoteFX необходимо установить глубину цвета 32 бита и указать скорость соединения 10 мегабит/локальная сеть.
— В случаи если сертификат сервера самоподписанный необходимо отключить предупреждение в разделе «Проверка подлинности сервера».

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

Основным минусом предложенного скрипта является невозможность пользователю самостоятельно выбрать разрешение экрана, но я честно говоря не понимаю когда выпрашивают монитор 22-24 дюйма, а затем просят увеличить на нем буковки.
В таких случаях я устанавливаю на целевой ПК VNC сервер и меняю разрешение с его помощью.

№4 — Для того чтобы отключить данное сообщение, пользователю достаточно поставить галочку больше не уведомлять.

Для автоматизации процесса административными средствами нужно добавить ключ в реестр.

[HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientLocalDevices]
«адрес сервера»=dword:0000000d

[HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server Client]
«BitmapCacheSize»=dword:0000ffff

№8 — Interactive logon: Message text for users attempting to log on и Interactive logon: Message title for users attempting to log on
Заполняем заголовок и текст который предназначен для пользователей, в самом простом случаи тут нужно указать контакты центра поддержки.

№9 — Для отключения визуальных эффектов на тонком клиенте, необходимо добавить ключ в реестр.

№10 — Power options
Средствами расширенных групповых политик необходимо создать план питания в котором при нажатии на кнопку питания тонкий клиент будет выключатся.

№11 — Software Restriction Policies
Рекомендую настроить контроль запуска ПО, данный механизм работает на WindowsXP и Windows 7 PRO.
AppLocker более гибки но работает только на Windows 7 enterprise и выше.
Считаю что в случаи тонкого клиента гибкость не нужна, преследуется цель исключить возможность запуска вредоносного ПО.

№12 — Turn off Autoplay
Для отключения автоматического запуска сменных носителей необходимо установить параметр Enabled for All drives.

№13 — Allow RDP redirection of other supported RemoteFX USB devices from this computer
Если вы планируете пробрасывать USB устройства, разрешите политику для Adminstrators and Users.

№14 — Delete user profiles older than a specified number of days on system restart
Я устанавливаю параметр в 180 дней, политика работает только на Windows 7.

№15 — User Account Control
UAC мне мешает и по этому отключаю.

№16 — Замена фона рабочего стола, красота требует жертв.

Для Windows XP, этот ключ в реестре отвечает за обои на экране ввода логина и пароля.
Файл с фоном может находится в любом месте, но это должен быть bmp файл.

[HKEY_USERS.DEFAULTControl PanelDesktop]
«Wallpaper»=«C:\thinPC\rd.bmp»
«WallpaperStyle»=«2»

[HKEY_CURRENT_USERControl PanelDesktop]
«Wallpaper»=«C:\thinPC\rd.bmp»
«WallpaperStyle»=«2»

— Подобные тонкие клиенты работают уже больше года
— На нескольких старых ПК успели посыпаться диски, в замен выслали тонкие клиенты HP, ну а все данные пользователей были на серверах 😉
— Несколько бухгалтеров успешно работают с USB токенами BIFIT

Источник

Thinstation — «худеем» с тонкими клиентами до версии 2.5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RDP-клиенты

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

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

Источник

Windows Server 2019 — терминальный сервер без домена

Установим роли терминального сервера на Windows Server 2019 и лицензируем. Маленькая тонкость — сервер не в домене.

Подготовка Windows Server 2019

Для начала установим сам сервер. Всё необходимое вынесено в отдельную статью:

Не забываем про настройку:

Итак, операционная система установлена и настроена. Сервер в рабочей группе WORKGROUP.

Установка роли терминального сервера

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

Роль Remote Desktop Licensing

Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.

Попадаем в раздел Before You Begin.

Это начальная страница, пропускаем. Next.

Попадаем в раздел Installation Type. Для установки сервиса удаленных рабочих столов предусмотрен специальный мастер Remote Desktop Services installation, но нам не удастся его использовать, поскольку сервер не в домене. Выбираем Role-based or feature-based installation. Next.

Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.

Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Services. Next.

Попадаем в раздел Features. Здесь ничего дополнительно не выбираем. Next.

Попадаем в раздел Remote Desktop Services. Ненужное нам окошко. Next.

Попадаем в раздел Role Services. Первая роль, которую нам нужно установить, это Remote Desktop Licensing. Выделяем галкой.

Нам предлагают установить дополнительные фичи, которые требуются для данной роли. Соглашаемся, Add Features.

Remote Desktop Licensing выделено галкой, Next.

Попадаем в раздел Confirmation. Install.

Начинается установка роли.

Роль Remote Desktop Licensing успешно установлена. Примечательно, что перезагрузка не требуется.

Открываем Windows Administrative Tools.

Переходим в папку Remote Desktop Services.

Запускаем оснастку Remote Desktop Licensing Manager.

Выбираем наш сервер, правой кнопкой — активировать.

Открывается окно активации. Next.

Выбираем метод соединения Web Browser. Next.

Получаем код продукта который нам понадобится для активации (Product ID). Копируем.

Выбираем «Activate a license server». Next.

Вводим Product ID полученный ранее, организацию и любую страну или регион. Next. Next.

Если все сделано правильно, то мы получим необходимый код сервера лицензирования. Копируем его. На вопрос «Do you wish to install client access licenses now on the license server with this product ID?» отвечаем «Yes» и пока возвращаемся к терминальному серверу, к текущему окну ещё вернёмся.

Вводим код в открытом мастере, жмём Next.

Устанавливаем галку «Start Install Licenses Wizard now». Next.

Открывается мастер установки лицензий. Next.

Нас просят ввести license key pack ID. Возвращаемся к браузеру.

Вставляем License Server ID, в качестве программы лицензирования, по идее он уже должен сюда переместиться из предыдущего окна. License Program выбираем Enterprise agreement. Указываем компанию и страну. Next.

Выбираем тип продукта: Windows Server 2019 Remote Desktop Services Per Device client access license. Указываем количество лицензий. Обязательно соглашение Enterprise agreement, или ищем в интернете который подойдет…

Не стоит выбирать лицензии Per User, иначе потом вы получите такую ошибку:

Ну вот мы и получили нужные нам клиентские лицензии. Копируем.

Вводим ключ в мастер. Next.

Возвращаемся к Remote Desktop Licensing Manager. Сервер активирован. Лицензии получены. Кстати, они начнут тратиться после окончания триального периода.

Роль Remote Desktop Session Host

Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.

Попадаем в раздел Before You Begin.

Это начальная страница, пропускаем. Next.

Попадаем в раздел Installation Type. Выбираем Role-based or feature-based installation. Next.

Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.

Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Session Host.

Нам предлагают установить дополнительные фичи, соглашаемся. Add Features.

Роль Remote Desktop Session Host выделена. Next.

Попадаем в раздел Features, ничего не выделяем. Next.

Попадаем в раздел Confirmation. Ставим галку Restart the destination server automatically if required. Отображается предупреждение, что сервер может быть перезагружен. Yes.

Начинается процесс установки роли.

В процессе устанавливаются компоненты.

После перезагрузки автоматически продолжается установка роли. Триальный период работы терминального сервера — 119 дней.

Роль Remote Desktop Session Host успешно установлена. Close.

Открываем Windows Administrative Tools.

Переходим в папку Remote Desktop Services.

Запускаем оснастку Remote Desktop Licensing Diagnoser.

The licensing mode for Remote Desktop Session Host server is not configured.

Откроется Local Group Policy Editor.

Раскрываем Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing.

Редактируем Use the specified Remote Desktop license servers.

Включаем — Enabled. В поле «License server to use» прописываем сервер, с которого получать лицензии, в моём случае «localhost». OK.

Редактируем Set the Remote Desktop licensing mode.

Включаем — Enabled. В поле «Specify the licensing mode for the RD Session Host server» устанавливаем значение Per Device. OK.

Снова запускаем оснастку Remote Desktop Licensing Diagnoser. Теперь всё зелёное, ошибок нет.

Практические испытания

Поскольку мы с вами системные администраторы 99 уровня, то нам нужно провести практические испытания терминального сервера.

На терминальном сервере создаём трёх локальных пользователей: user1, user2, user3.

Включаем их в группу Remote Desktop Users.

Коннектимся под этими пользователями к терминальному серверу по RDP.

Есть три активных сеанса.

Заключение

Мы с вами успешно создали терминальный сервер Windows Server 2019 в рабочей группе WORKGROUP без домена. 120 дней терминальный сервер будет работать в триальном режиме, затем начнёт использовать лицензии Per Device. Для подключения к терминальному серверу требуется создать локальную учётную запись и включить её в группу Remote Desktop Users.

Источник

Добро пожаловать на блог системного администратора.

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

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

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

Для успешной работы тонкого клиента не нужен жесткий диск, достаточно 1 мегабайта оперативной памяти, простейшей видеокарты и слабого процессора. Основная работа происходит в другом месте и терминалу нужно лишь отобразить на конкретном месте эту работу. Монитор показывает, а мышка и клавиатура управляют процессом.

Теперь технические нюансы. Для того, чтобы тонкий клиент начал функционировать, используются специальные программы, которые производят первоначальную загрузку и подключение к серверу терминалов. Большинство таких программ — бесплатные. Из моего опыта могу порекомендовать решение от ООО «ИТ Консультант», просто, адаптировано и есть форум поддержки. Легко настраивается и управляется.

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

Устанавливаем на сервере, через установку компонентов windows  Remote Installation Service, при этом конфигурирование оставляем на потом. Дальше редактируем реестр, нужный нам путь — HKLMSystemCurrentControlSetServicesTftpdParametersDirectory, тип ключа REG_SZ, значение «C:tftpboot«. Это наша папка с загрузкой тонкого клиента. После этого открываем службы, находим Trivial FTP Daemon, ставим тип запуска АВТО и запускаем службу.

Настройки DHCP совсем простые.

003	Router	192.168.1.2
006	DNS Servers	192.168.1.1, 192.168.5.1
066	Boot Server Host Name	192.168.1.5
067	Bootfile Name	pxelinux.0

Используются 4 пункта, думаю, что нет смысла пояснять, что есть что. Адреса серверов указываете свои.

• Предыдущая запись: Мечтаю познакомиться с женщиной сисадмином, бывают ли такие.
• Следующая запись: Установка и настройка сервера HP ProLiant ML150 G6.

Для начала, скачайте само приложение Тонкий клиент по ссылке:1С:Предприятие. Тонкий клиент, платформа 8.3. Обратите внимание! Получить доступ через тонкий клиент можно только для баз, которые поддерживают работу в режиме управляемых форм на платформе 1С 8.2 и 8.3.

Примеры конфигураций, поддерживающих работу в режиме управляемых форм:

Бухгалтерия предприятия, редакция 3.0 и выше

Зарплата и управление персоналом, редакция 3.0 и выше

Управление торговлей 11.1 и выше

Управление небольшой фирмой, редакция 1.4 и выше

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

Этап 1. Публикация базы.

Для подключения к базе в режиме тонкого клиента нужно выполнить публикацию базы

После того, как база была опубликована, достаточно будет скопировать ссылку доступа в буфер обмена (клик правой кнопкой мыши на ссылке — Копировать адрес ссылки) и вставить ее при добавлении базы в приложение Тонкий клиент.

Этап 2. Установка и настройка приложения 1С:Предприятие 8. Тонкий клиент.

После скачивания приложения Тонкий клиент по ссылке, произведите его установку:

По окончанию установки на Рабочем столе появится ярлык “1C Предприятие” для запуска приложения.

При первом запуске появится окно для добавления базы в список для запуска, в дальнейшем базы можно добавлять через кнопку “Добавить”

При добавлении базы используется ссылка, взятая с Личного кабинета по описанию в Этап 1.

В списке появилась база, готовая к запуску.

При запуске базы, в окне Доступ к веб-серверу необходимо будет указать Ваш логин и пароль от сервиса 42 Облака (как в Личный кабинет).

Затем появится окно Доступ к информационной базе — необходимо выбрать Вашего пользователя в базе 1С.Примечание: по умолчанию в базах создан пользователь Администратор, без пароля.

При первом запуске базы вам будет задан вопрос: «Запуск системы выполнен без использования аппаратной лицензии (ключа защиты). … Отключить использование аппаратной лицензии (ключа защиты)?» (т.к. нет непосредственного доступа с Вашего локального ПК к аппаратному ключу защиты — ключ находиться на сервере 42 Облака). Нажмите Да для ускорения запуска базы.

Дополнительно в Тонком клиенте, в настройках выбранной базы можно прописать ключи с сохранением авторизационных данных:

/WSN adlogin и /WSP pass — для сохранения логина и пароля от сервиса 42Облака, где

login — ваш облачный логин, pass — ваш облачный пароль

/N Пользователь и /P Пароль — для сохранения пользователя и пароля от самой базы

Данные ключи можно использовать как все, так и по отдельности, пример:

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

Комфортной Вам работы!

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

WTware – это оптимизированный дистрибутив на базе Linux, включающий в себя все необходимые драйверы и клиенты для подключения к терминальным серверам Windows (rdesktop), Linux (xrdp), Hyper-V VDI, Mac Terminal Server.

Основные преимущества WTware:

• Низкие требования к аппаратной части. WTware можно запустить практически на любом компьютере с как минимум 48 Мб RAM (для оптимальной работы потребуется 64 Мб). Для Raspberry Pi 2 существует бесплатная версия WTware (http://winterminal.com/ru/)
• Для запуска клиента не обязательно требуется жесткий диск. Поддерживается как сетевая загрузка, так и загрузка с любого носителя
• Простота установки и настройки клиентской части, не требует от администратора знаний по администрированию Linux
• Централизованное управление конфигурацией терминалов
• Поддержка широкого спектра оборудования. Возможность проброса в терминальную сессию локальных принтеров, сканеров штрих-кодов и другой периферии
• Поддержка удаленного подключения к консоли терминала службами техподдержки (через VNC)
• WTware – российский продукт, а это значит, что вся документация и техподдержка также осуществляется на русском языке.
• Возможность одновременного подключения к 4 терминальным серверам (переключение между сеансами с помощью сочетаний Win+1 – Win+ 4 )

Рассмотрим процедуру «быстрого» старта по использованию решения WTware для организации рабочего места с тонким терминальным клиентом в типовой офисной сети.

Варианты загрузки клиента WTware

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

• Жесткий диск
• CD-Rom
• Флешка
• Дискета
• Сетевая карта с BootROM

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

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

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

Процесс загрузки WTware

Чтобы запустить клиент WTware на компьютере пользователя, нужно:

• Загрузить бинарные файлы дистрибутива с сервера (по TFTP) или локального носителя
• Получить сетевые настройки с DHCP сервера или из локальных конфигурационных файлов
• Получить конфигурационный файл с сервера (по TFTP) или загрузить его с диска

Установка серверной части WTware

Начнем с установки серверной части системы WTware. В нашем случае было принято решение установить ее на DHCP сервере, работающего под управлением ОС Windows Server 2012 R2.

Качаем дистрибутив с сайта разработчика – на момент написания статьи версия wtware.5.4.8.ru.exe (226 Мб) и запускаем установку.

Указываем путь для установки конфигурационных файлов (по-умолчанию, C:ProgramDataWTware) и самой программы (C:Program Files (x86)WTware).

Далее предлагается выбрать устанавливаемые службы WTware:

• Служба WTFTP – необходима для загрузки по сети, ведет протокол обращений и позволяет диагностировать проблемы
• Служба WTUSBIP – служба WTware USBIP Initiator используется для автоматического подключения USB устройств терминала
• Службы WTDHCP – назначает терминалам IP адреса, необходима для загрузки по сети

Т.к. мы будем использовать уже имеющийся собственный DHCP сервер, поэтому службу WTDHCP устанавливать не будем. Настройка MS DHCP сервера описана в этом разделе.

Совет. В том случае, если в вашей сети еще не развернут DHCP-сервер, имеет смысл воспользоваться встроенным DHCP серверов WTware (WTDHCP). Использование WTDHCP позволяет быстро развернуть и запустить DHCP сервис для небольшой сети. Настройка службы WTDHCP выполняется при инсталляции и в дальнейшем с помощью графической утилиты – конфигуратора WTware (win32.exe), возможности которого рассмотрены в разделе ниже.

Примечание. В том случае, если ваша сеть разбита на сегменты, в каждом из которых будут присутствовать тонкие клиенты, нет необходимости поднимать в каждом собственный DHCP сервер. Один сервер может обслуживать большое количество зон (подсетей). Пересылка DHCP пакетов между сегментами возможна через DHCP relay.

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

Запускаем установку.

После установки WTWare в системе появятся две дополнительные службы:

• WTware TFTP – исполняемый файл C:Program Files (x86)WTwareBinwtftp.exe – использует локальный порт UDP/69
• WTware USBIP Initiator — C:Program Files (x86)WTwareBinwtusbip.exe – порт TCP/780

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

Предполагается, что в нашей сети уже развернут и используется DHCP сервер на любой серверной редакции Windows. Запускаем консоль управления DHCP (dhcpmgmt.msc) и находим интересующую нас DHCP зону (в нашем случае имя зоны – Managers). Нам нужно прописать дополнительные настройки зоны, необходимые для сетевой загрузки бездисковых терминалов.

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

• 066 (Boot Server Host Name) – здесь указывается ip адрес сервера, на котором будет работать TFTP сервер WTware (у нас он совпадает с адресом DHCP сервера)
• 067 (Bootfile Name) – здесь указывается файл, с которого должна начаться загрузка терминала. Для загрузки с помощью PXE (если BootROM встроен в вашу сетевую карту или материнскую плату производителем) значение параметра задаем 5.4.8/wtware.pxe . Файл wtware.pxe находится в подкаталоге 5.4.8 корня tftp сервера (по умолчанию корень tftp расположен в каталоге C:Program Files (x86)WTwareTFTPDROOT)

Примечание. Для загрузчика Etherboot (при использовании эмулятора BootROM) в качестве значения опции 067 нужно указать другой файл — 5.4.8/wtshell.nbi

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

Примечание. В том случае, если терминал WTWare будет устанавливаться на флешку или локальный диск, можно запретить пользователям менять конфигурацию своей станции. Для этого нужно защитить паролем меню настройки WTware Setup. Для этого можно воспользоваться еще одной опцией DHCP зоны — 018 (Extensions Path). В этом поле указывается хэш пароля, полученный с помощью специальной утилиты. Цель указания хэша – запрет передачи пароля в открытом виде в DHCP ответе.

Настройка параметров терминалов WTWare

Настройка терминальных клиентов WTWare, использующих сетевую загрузку выполняется с помощью конфигурационных файлов. Конфигурация клиентов формируется из трех файлов:

• Общесистемного конфигурационного файла all.wtc (C:Program Files (x86)WTwareTFTPDROOTEveryone)
• Персонального конфигурационного файла config.wtc (хранится в персональном каталоге каждого клиента, идентифицируемого по MAC адресу, к примеру (C:Program Files (x86)WTwareTFTPDROOTTerminals0.50.56.BB.AD.80)
• Подключаемых файлов, определенных в файле list.wtc

В файле all.wtc нужно указать параметры, одинаковые для всех терминалов.

К примеру, можно задать адреса терминальных серверов, доступных для подключения, указав их IP адрес

server=10.24.181.44

или DNS имя сервера (при условии, что клиенты через DHCP получают адрес сервера имен в сети)

server= msk-term-1c.winitpro.ru

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

server=--new—

Чтобы на терминальном сервере вместо рабочего стола сразу было открыто определенное приложение, нужно в конфигурационном файле указать параметр shell:

К примеру, для запуска клиента Directum нужно указать:

shell = C:Program Files (x86)DIRECTUM CompanyDIRECTUM 5.1SBRte.exe -S=msk-drc01 -D=DIRECTUMDB

Индивидуальные конфигурационные файлы каждого клиента хранятся в каталоге C:Program Files (x86)WTwareTFTPDROOTTerminals. Для каждого клиента создается персональный каталог с его MAC адресом. Именно в этом каталоге клиент будет искать файл config.wtc со своей конфигурацией.

На сайте разработчика представлены более чем подробные инструкции по этим и другим параметрами конфигурационных файлов.

Настройка и работа с клиентом WTWare

Итак, настройка серверной части закончена, перейдем к настройке клиента. В BIOS/ UEFI компьютера, который будет использоваться в качестве тонкого клиента в разделе, в котором настраивается порядок перебора загрузочных устройств, указываем высший приоритет сетевой загрузке с PXE (Network boot, LAN boot).

Сохраняем изменения и перезагружаем систему. Если на стороне сервера WTware и DHCP все настроено правильно, клиент должен получить IP адрес от DHCP сервера и по настроенным нами параметрам выполнить сетевую загрузка с указанного tftp сервера.

При первом запуске можно выполнить настройку терминала (F10 – мастер настройки терминала).

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

Для этого на TFTP сервере в каталоге C:Program Files (x86)WTwareTFTPDROOTTerminals0.50.56.BB.AD.80 (каталог с именем, содержащим MAC адрес клиента) создадим файл config.wtc, в котором будут указаны настройки клиента:

video= VESA(F)
bpp= 16
display = 800x600

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

В том случае, если адрес терминального сервера указан в конфигурационном файле, клиент WTWare автоматически инициирует RDP соединение. Осталось авторизоваться на сервере и перед нами откроется его рабочий стол.

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

Для диагностики работы клиентов, на каждом терминале функционирует маленький веб-сервер. Чтобы открыть диагностическую страничку, достаточно набрать ip адрес клиента в браузере. На открывшейся веб странице можно посмотреть текущие настройки клиента, состояние его компонентов, логи, кнопки выключения/перезагрузки клиента и т.д.

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

httpd = 10.10.1.55, 10.10.1.56

Графический конфигуратор WTware

Помимо управления через текстовые конфигурационные файлы, есть возможность управления настройками системы и терминалов клиентов из отдельного графического приложения – конфигуратора WTware (C:Program Files (x86)WTwareBin win32.exe), позволяющего более удобно работать с текстовыми конфиг файлами.

Для чего можно использовать данную утилиту:

• Управление общими настройками клиентами (файл all.wtc)
• Управление персональными настройками клиентов. Так например, утилита может сохранить в конфигурационный файл config.wtc текущие настройки видеорежима на клиенте (не требуется вручную править файл).
• Возможность удобного просмотра, добавления, удаления всех возможных параметров конфигурационных файлов.
• Просмотр логов клиентов и подключение к их консоли
• Ведение шаблонов с типовыми параметрами терминалов
• Создания экранов и соединений к терминальным серверам
• Управление лицензиями
• Управление настройками встроенного DHCP сервера
• Создание загрузочных CD/ USB носителей для клиентских станций
• Создание загрузочной CD карты для Raspberry Pi

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

Лицензирование WTWare и цены

Лицензии WTWare привязываются к MAC адресу сетевой платы компьютера. Все лицензии нужно записать на сервер в файл wtware.lic.

Стоимость лицензии WTWare на одно рабочее место зависит от количества клиентов и начинается с 1000 рублей (при количестве клиентов от 1 до 9) и заканчиваются 350 рублями (при приобретении более 100 лицензий).

Выводы

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

Из бесплатных аналогов WTWare для организации тонкого клиента, можно вспомнить Thinstation, но последний существенно проигрывает в управляемости и развернуть его гораздо сложнее.