Настройка тонких клиентов linux

Тонкий клиент или создаем PXE Boot из LTSP

ПОЭТАПНОЕ РУКОВОДСТВО ПО УСТАНОВКЕ И НАСТРОЙКЕ ТОНКОГО КЛИЕНТА НА ПЛАТФОРМЕ Linux Debian Squeeze

• И так, собрав в кучу все имеющееся руководство по настройке «тонкого» клиента и перебрав всевозможные

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

• Применительно к ситуации, создадим «тонкого» клиента, с возможностью обслуживания разделов жесткого диска,

в частности с возможностью сохранения или восстановления образов партиций NTFS по сети.

1. Устанавливаем необходимые пакеты:

• рекомендуется после установки запустить программу aptitude и до установить требуемые пакеты, если есть такой запрос.
• при установке сервера tftpd-hpa он будет просить вас указать каталог где будет «платформа», согласитесь по умолчанию /srv/tftp или /opt/ltsp, все равно потом это будем менять..

2. Теперь настраиваем сервер DHCP:

• предположим что наша сеть такая:

• Исходя из этих данных настраиваем наш dhcp сервер:

• теперь прописываем какой интерфейс будет слушать сервер dhcp

• в данном случае как видно это интерфейс — eth0
• теперь перезапускаем сервер dhcp и на этом настройка первого этапа закончена.

3. Настройка сервера TFTP — HPA

• создаем каталог, где будет наша будущая система клиента в окружении chroot

• прописываем для сервера tftp-hpa где будет наша «платформа»

• перезапускаем сервер tftp-hpa

4. Настройка сервера LTSP

• Корневая файловая система, которую будут использовать клиенты, находится в каталоге /ltsp. Она должна быть доступна через NFS. Настраивается все это через конфиг /etc/exports
• прописываем настройки для сервера nfs-kernel, nfs-common

• теперь создаем корневую систему для пользователя:

• заходим в режиме chroot в каталог /ltsp

• сразу добавляем пользователя который будет работать..

• до устанавливаем необходимые пакеты для работы клиентов..

• выходим из режима chroot

• прописываем права пользователя user в sudo и group в каталоге среды /ltsp/etc
• теперь нам необходимо настроить загрузку нашего тонкого клиента, чтоб он мог по умолчанию через 15 секунд загружать систему с жесткого диска или выбрав нижнее меню, загрузить уже нашу среду и провести восстановление системы у себя с помощью ntfsclon

• для корректной работы загрузчика скопируем необходимую библиотеку..

• перезапускаем сервер tftp-hpa

• пробуем загрузится «тонким» клиентом

• полезное.

• Загрузочный сервер — как загрузочная флешка, только сервер и по сети

Источник

БАЗА ЗНАНИЙ

Инструменты пользователя

Инструменты сайта

Тонкий клиент (RDP-клиент) под управлением Linux

В этой статье пойдет речь о подключении терминальных устройств под управлением операционных систем Linux к службе удаленных рабочих столов Windows по протоколу Remote Desktop Protocol (RDP). Статья рассчитана на читателя с начальными навыками настройки Linux.

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

Остается вопрос какими терминалами оснастить рабочие места сотрудников. Есть несколько вариантов решения этого вопроса со своими плюсами и минусами:

Итак, все очень просто. Нужно установить FreeRDP — свободный клиент для протокола RDP. Он доступен практически для всех платформ и присутствует в репозиториях всех популярных дистрибутивов Linux.

DEB-based дострибутивы Linux:

RPM-based дострибутивы Linux:

Разберемся с нужными нам параметрами консольной команды. Откроем справку:

и познакомимся с опциями:

/v [:port]	указывает адрес:порт сервера службы удаленны рабочих столов. Адрес можно задавать как в виде IP адреса, так и в виде доменного имени
/f	полноэкранный режим, как раз то, что нужно для тонкого клиента
/u [ \]	указывает имя пользователя на сервере службы удаленных рабочих столов
/p

и его пароль /compression использовать сжатие протокола RDP, используйте эту опцию при медленной скорости соединения с сервером /sound перенаправлять вывод звука с сервера на клиент /microphone перенаправлять звук микрофона с клиента на сервер /multimedia перенаправлять поток вывода видео с сервера на клиент +clipboard перенаправлять в обе стороны буфер обмена /printer перенаправлять на сервер принтеры, подключенные к клиенту /usb перенаправлять на сервер USB устройства, подключенные к клиенту +fonts сглаживать экранные шрифты +aero отображать визуальные эффекты Windows в RDP клиенте /rfx использовать расширение протокола RemoteFX /gdi: использование программного или аппаратного ускорения графики на клиенте

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

Допустим, сервер служб удаленных рабочих столов под управлением Windows Server 2008 R2 SP1 или выше находится в локальной сети по адресу 10.0.0.4 , порт используется по умолчанию 3389 , пользователя зовут user , его пароль parol , на клиенте имеется аппаратный ускоритель графики. Запускаем:

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

Источник

Тонкий бездисковый клиент на базе Ubuntu, не требующий монтирования ФС по сети

UPDATE 2020-11-06 Теперь проект поддерживает Ubuntu 20.04 Focal Fossa (LTS) и появился готовый вариант для сборки с использованием VMWare Horizon, наряду с FreeRDP.

Изображение с сайта getwallpapers.com

История

В далёком 2013 году в одном банке использовались тонкие клиенты на основе DisklessUbuntu. С ними были некоторые проблемы, по-моему монтирование корневой ФС по сети в больших филиалах со слабой сетью работало не очень. Тогда мой хороший друг @deadroot сделал первую версию тонкого клиента, который грузился целиком в память, не требуя что-то монтировать по сети для работы.

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

Недавно у меня дошли руки сделать из этой кучи страшных ненадёжных скриптов достаточно удобное для использования решение:

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

Что умеет

В банке для удалённого подключения к тонкому клиенту пользователя использовался VNC ( x11vnc для подключения к уже запущенной сессии Xorg). Это далеко не всем требуется (обычно хватает возможности подключения к сеансу RDP на сервере терминалов), и тут всё очень индивидуально в плане требований удобства/безопасности. Поэтому эту часть я выкладывать не стал.

Аналоги

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

Но версии софта в нём достаточно древние и его там мало. Если нужно что-то дополнительное, помимо клиентов RDP/Citrix/… — потребуется собирать это руками, и так при каждом обновлении.

kvaps указал в комментарии, что LTSP может скопировать образ squashfs в память и работать без монтирования ФС по сети: это настраивается переменной LTSP_NBD_TO_RAM. Для настройки используется chroot, что может быть менее удобно, особенно для настройки графического окружения и приложений. Также хороший зрелый проект, можно рассматривать как альтернативу.

Vagrant vs chroot

Прошлые версии использовали chroot, как собственно и большинство похожих проектов, тот же Thinstation к примеру. Это несложно, но всё-таки запущенная в chroot отдельная программа не соответствует происходящему на реальной машине: нету взаимодействия с системным init, с другими программами и службами. Плюс Vagrant позволил сделать процесс создания клиента максимально простым: виртуалка настраивается как обычная машина.

Конечно, использование Vagrant приносит и некоторые сложности.

На машине должна работать служба virtualbox-guest-utils , для работы общих папок. Кроме того, нужен менеджер загрузки ( grub ), обязательный для машины с диском и бесполезный для загружаемого по сети клиента. Эти проблемы я решил, исключая из сборки все файлы этих пакетов. Поэтому на размер получившегося образа они не влияют.

Кроме того, для Vagrant обязателен работающий на машине ssh, пускающий пользователя со сгенерированным ключом. Я исключаю из сборки домашний каталог пользователя vagrant, используемого для настройки, вместе с его ssh ключами. Ключи для используемого при работе пользователя ubuntu можно положить в его домашний каталог.

Ну и для работы Vagrant генерирует настройки сетевых интерфейсов, которые будут ошибочными для реальной машины. Пришлось на время сборки подменять файл interfaces , и написать скрипт, который на реальной машине генерирует конфиг для настройки всех доступных интерфейсов по DHCP.

Provisioning делается с помощью Ansible. Это очень удобный инструмент для конфигурации всяческого софта и железа. Но включать в итоговый образ Ansible и требующийся ему второй python с нужными библиотеками не хотелось бы: бесполезный балласт. Ставить Ansible на машину, где запукается виртуальное окружение, тоже не хочется: это усложнит работу.

Vagrant позволяет сделать хитрость: поставить Ansible на одну машину (тестовый PXE сервер), и с неё делать разворачивание других машин, в рамках той же playbook. Для этого машины должны иметь статический IP, чтобы прописать его в ansible inventory. Ну а проблему с конфигурацией интерфейсов мы решили в прошлом пункте.

Непослушный кабачок

Squashfs — сжимающая read-only файловая система. Лежит в основе большинства существующих Linux LiveCD. Именно она позволяет создать достаточно компактный образ системы, помещающийся в оперативную память тонкого клиента.

Из итогового образа надо много чего вырезать: /tmp , /run , /proc , /sys , /usr/share/doc и так далее.

Утилита mksquashfs поддерживает аж 3 типа списков для исключения файлов: по полному пути, по маскам и по регулярным выражениям. Казалось бы, всё прекрасно. Но последние два варианта не поддерживают пути, начинающиеся с / . У меня не получилось исключить все файлы внутри некоторой структуры папок, не исключая последнюю папку.

Мне быстро надоело с ней бороться, я просто нашёл find -ом все файлы и папки, которые надо исключить, и запихнул в один большой файл с исключениями по полному пути. Костыли.jpg. Но работает. Единственным артефактом этого подхода в итоговом образе остаётся одинокая папка /proc/NNN , соответствующая номеру процесса mksquashfs, которого при создании списка исключений ещё не было. Сверху всё равно монтируется procfs.

Магия initrd

Чтобы не тянуть в составе ядра все необходимые драйвера и логику монтирования корневой ФС, Linux использует initial ramdisk. Раньше использовался формат initrd, в котором этот диск представлял собой настоящий образ файловой системы. В ядре 2.6 появился новый формат — initramfs, представляющий собой извлекаемый в tmpfs cpio-архив. Как initrd, так и initramfs могут быть сжаты для экономии времени загрузки. Многие названия утилит и имена файлов по-прежнему упоминают initrd, хотя он уже не используется.

В Debian/Ubuntu для создания initramfs используется пакет initramfs-tools. Он даёт следующие возможности для кастомизации:

• хуки — скрипты специального формата, которые позволяют добавлять в образ модули ядра и исполняемые файлы со всеми необходимыми им библиотеками
• скрипты в каталогах init-bottom , init-premount , init-top , local-block , local-bottom , local-premount , local-top , выполняемые в соответствующий момент загрузки. См. man initramfs-tools(8)
• самое интересное — добавлять собственные скрипты загрузки, отвечающие за монтирование корневой ФС. Они должны определять shell функцию mountroot() , которая будет использована главным скриптом /init . В составе уже есть local для монтирования корня на локальном диске и nfs для монтирования корня по сети. Используемый скрипт выбирается параметром загрузки boot .

Итого, чтобы примонтировать корневую ФС каким-то сильно хитрым образом, надо создать свой скрипт загрузки, определить в нём функцию mountroot() , передать имя этого скрипта в параметре загрузки boot и не забыть написать хуки, подтягивающие в initramfs все нужные скрипту программы и модули ядра.

Борьба за оверлеи

Для создания единой корневой файловой системы из нескольких используется OverlayFS. В первых версиях использовалась AUFS (она используется большинством линуксовых LiveCD). Но её не приняли в ядро, и сейчас всем рекомендуют переходить на OverlayFS.

После монтирования настоящей корневой ФС в каталог внутри initramfs, будет запущена программа run_init из состава klibc-utils . Она проверит, что корневая ФС смонтирована внутри initramfs, отчистит initramfs (зачем зря терять память?) и переместит точку монтирования корневой ФС в / , и запустит системный init. Подробности. Эта программа собрана в виде отдельного исполняемого файла, потому что скрипт, использующий любые внешние утилиты, сломается после отчистки initramfs.

Если корневая ФС собирается из нескольких оверлеев, смонтированных внутри initramfs, при работе run_init эти точки монтирования пропадают, и она ломается. Эту проблему можно решить, переместив точки монтирования оверлеев внутрь корневой ФС, где они уже не пропадут. Рекурсия 🙂 Делается так: mount —move olddir newdir .

AppArmor пришлось отключить: её профили рассчитаны на прямое монтирование корневой ФС с одного устройства. При использовании OverlayFS она видит, что /sbin/dhclient это на самом деле /AUFS/root/sbin/dhclient , и профиль ломается. Единственный вариант её использовать — переписать все профили для всех приложений, и обновлять при необходимости.

Где нужна возможность записи

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

• /tmp , /var/tmp — понятно, нужны очень многим
• /var/log — пишем логи
• /run — без него не запустятся почти все сервисы
• /media — монтированиие подключенных носителей
• /var/lib/system — используется многими программами из systemd, в частности systemd-timesyncd
• /var/lib/dhclient — сюда dhclient записывает информацию о leases
• /etc/apparmor.d/cache — если вы всё-таки поборете AppArmor, то ему надо будет писать файлы в /etc . ИМХО отвратительно, для таких вещей есть /var .

Итого

Если вы хотите собрать загружаемую по сети и работающую только из памяти сборку Ubuntu — вот тут есть готовый удобный конструктор: thinclient. Если потребуется помощь — пишите в ЛС или в тикеты на гитхабе, подскажу.

Источник