Pull to refresh

Comments 23

Это очень кстати. Спасибо за труд и за пояснения!
А как дела с принтерами обстоят и с флешками?

С флешками всё хорошо, есть два варианта:



С принтерами есть такие варианты:


  • проброс принтера с помощью FreeRDP. Сам такое делать не пробовал. Понадобится добавить в образ CUPS с драйверами для нужных принтеров, какой-нибудь скрипт для запихивания принтера в CUPS при загрузке, и возможно некоторое количество магии(а может наоборот сразу заработает).
  • в банке это делалось так: все принтеры были сетевые, они пробрасывались из филиала по VPN на принт-сервер, откуда их забирал сервер терминалов. Было настроено, чтобы пользователь из соответствующего OU видел только свои принтеры. Немного повышает требования к толщине канала, но думаю в 2018 году уже не осталось офисов, сидящих на модемном соединении.
с принтерами вообще все просто,
достаточно открыть порт 9100 например xinetd + скрипт с cat или обычный nc и сделать редирект в /dev/usb/lp0, можно так же предусмотреть файл блокировки и spool

драйвер я ставлю стандартные ps или pcl5, pcl6 в зависимости от модели притера что он понимает

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


Собираемый по-умолчанию образ с LXDE работает на 1 Гб оперативки, сам образ весит 330 Мб(вместе с initrd и ядром). Причём top после загрузки показывает, что занято 400 Мб, а ещё 600 осталось для программ, а с учётом zram там поместится раза в полтора больше.


Если убрать LXDE, оставить только X и какой-нибудь легковесный WM, то возможно получится завестись на 768 Мб.

Я использовал для тонкого клиента slitaz он менее прожорлив.
image

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


Впрочем, сейчас железо меньше чем с гигабайтом памяти просто не найдёшь.

Если бы не кривая реализация BT в андройдах, то планшеты для тонкого клиента сгодились бы.

Вау, я крайне удивлен что ни одного упоминания про LTSP.
Простое и проверенное решение, а главное уже готовое и умеет все тоже самое что описанно в статье.


Я использую несколько модифицированную версию для фермы серверов.
Squashed образ грузится с nbd-сервера и копируется в RAM.


LTSP-сервер вместе с клиентским образом и всеми необходимыми изменениями собирается автоматически из Dockerfile после пуша в корпоративный git-репозиторий.


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

Оно вроде требует монтировать ФС по сети, или нет? Описанный в статье велосипед родился как раз из-за требования так не делать.

Вовсе нет, переменная LTSP_NBD_TO_RAM позволяет скопировать Squashed-образ в RAM при загрузке, все дополнительные фс (например локальные диски) можно настроить через переменные FSTAB, есть целая куча встроенных возможностей.


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

Если бы этот комментарий появился в 2013 году, описанное в статье решение вероятно не было бы создано :)


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


Сейчас уже поздно, завтра добавлю к списку альтернатив помимо Thinstation ещё и LTSP.

Не отчаивайтесь, зато теперь вы знаете как работает initramfs — а это уже половина дела, все что вы описали в статье применимо так же и к LTSP.
LTSP просто предоставляет вам набор скриптов который сильно упрощает жизнь. :)


К примеру:
ltsp-chroot — что бы установить софт или внести другие изменения.
ltsp-update-image — и у вас новый squashed образ.
ltsp-update-kernels — и у вас готовый конфиг с новыми ядрами для pxelinux.

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


Кстати, посмотрел, LTSP_NBD_TO_RAM в LTSP добавили как раз 5 лет назад, возможно на момент создания thinclient этого ещё не было в стабильной версии или оно не упоминалось в документации.

Обновил статью, указал LTSP в списке альтернативных решений.

В 2013-2014 LTSP был достаточно сырым. После нескольких тестов решили от него отказаться.

Ну и еще пара особенностей, которые нужны были:
1. Поддержка вебкамер и вообще любого железа в потенциале (мало ли, что бизнес запросит).
2. Настройка окружения пользователя. Например, браузеров и т. п. Это так и не понадобилось, но, опять же, мысли были.
Так, а в чем проблема то? Все что можно установить в chroot все тоже самое можно сделать и тут.
Поддержка железа такая же как и на десктопной версии Ubuntu.
Касательно настройки окружения — достаточно просто положить необходимые конфиги в домашнюю директорию пользователя.
Да, не спорю. Просто на то время LTSP был весьма нестабилен и глючноват, оказалось проще и быстрее сделать свой проект. Да, звучит странно, но факт.
Насколько я помню, в LTSP ещё отваливалась сессия без возможности восстановления в случае разрыва сетевого соединения с сервером, то есть выдёргивание свича равносильно резету куче машин.

Да, именно та проблема с монтированием ФС по сети, которая и вызвала появление этого решения. Впрочем, kvaps сверху написал комментарий, что LTSP тоже оказывается это умеет.

Такая проблема происходит при использовании stateful-протоколов, NBD — как раз один из них.
При использовании stateless NFSv3 эта проблема отсутсвует, но есть ряд крайне неприятных багов при использовании OverlayFS над NFS.
В сообществе мне еще советовали попробовать AOE, но руки так и не дошли. Squashed образ и правда занимает относительно немного места в памяти, а работает гораздо стабильнее чем по сети.
Sign up to leave a comment.

Articles