Система централизованного управления linux

Централизованное управление конфигурациями: Puppet + Foreman. Часть І

В этой статье будет рассмотрена установка и настройка связки Puppet + Foreman для централизованного управления конфигурациями.

Для сервера, на котором будет установлена связка Puppet + Foreman, будет использоваться виртуальная машина (1 CPU, 2 Gb RAM, 20Gb HDD), в качестве клиентов будут физические ПК на которых установлена Ubuntu. Конфигурация моего виртуального сервера с указанными выше характеристиками позволяет без проблем обслуживать 500 клиентов (можно и больше).

Установка Puppet довольно простая (все последующие команды выполняются от root):

Этими командами мы скачиваем deb пакет с сайта разработчиков puppet и устанавливаем его. Данный пакет puppetlabs-release-trusty.deb при установке создает файл /etc/apt/sources.list.d/puppetlabs.list в котором прописаны репозитории puppet, а также импортируется gpg ключ которым подписан репозиторий puppet. Сам puppetmaster мы не устанавливаем, он будет установлен автоматически при установке Foreman.

На этом установка Puppet закончена, приступим к установке веб-интерфейса Foreman:

Здесь мы добавили файл /etc/apt/sources.list.d/foreman.list в который вписали репозитории от Foreman, а также добавили ключ от данного репозитория. После добавления репозитория мы обновили список пакетов и установили foreman-installer — это пакет который позволяет установить Foreman.

Далее нам нужно настроить правильное имя компьютера. Прописываем в /etc/hosts и /etc/hostname

Перезагружаем наш сервер.

Запускаем наш установщик коммандой foreman-installer -i.

Нас спрашивают — готовы ли мы к установке, отвечаем «y», далее следует меню в котором можно выбрать дополнительные конфигурации Foreman и дополнительные модули. Мы же устанавливаем стандартную конфигурацию, поэтому выбираем пункт «Save and run» и у нас начинается установка (можно было ставить командой foreman-installer без опции -i, тогда у нас поставится базовая установка, -i подразумевает интерактивный режим).

У меня установка заняла примерно 5 минут, после установки мы видим сообщение об успешно установке, в этом сообщении находятся наши параметры доступа к Foreman.

Переходим по адресу srv.co.com и заходим в веб-интерфейс используя параметры доступа которые мы получили при установке (их желательно сохранить в файлик, а после первого входа в панель управления — поменять пароль). После входа мы видим страницу с множеством текстовой информации на английском языке, можно перейти в настройки аккаунта и сменить язык на русский. Переходим в правый верхний угол, жмем Admin User, My account, вибираем нужный нам язык и сохраняем настройки.

При последующем входе в Foreman мы получим другой интерфейс:

Здесь в списке будут отображаться наши клиенты.

Вот мы и завершили установку связки Puppet + Foreman. Давайте попробуем добавить клиента puppet и посмотреть что поменяется в веб-интерфейсе.

Для установки Puppet агентов на клиентские ПК я использую следующий скрипт:

Этот скрипт устанавливает puppet agent, настраивает автозапуск агента при старте системы, указывает адрес Puppet сервера и запускает агента. Также мы закомментируем в конфиге /etc/puppet/puppet.conf строку templatedir, если не закомеентировать — сыпятся ошибки (как фиксить без комментирования я не разобрался, хотя оно меня не раздражает).

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

Для просмотра сертификатов на сервере можно использовать комманду puppet cert —list —all:

# puppet cert —list —all
«zeppelin» (SHA256) 43:64:08:BF:DB:AF:7C:17:5B:DE:3C:CE:22:8B:40:6A:13:60:B7:F4:2C:38:B6:57:E5:FA:EA:CC:63:FB:87:EB
+ «srv.co.com» (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 (alt names: «DNS:puppet», «DNS:puppet.co.com», «DNS:srv.co.com»)

Здесь мы видим что у нас 2 сертификата, один не подписан с именем zeppelin и другой подписан (+) с именем srv.co.com. Не подписаный сертификат — это сертификат от нашего новоустановленого клиента.

Для подписи сертификата можно использовать комманду puppet cert —sign $client_name. Также для подписи сертификатов мы можем использовать веб-интерфейс от Foreman, для этого нам нужно перейти в меню «Инфраструктура» — «Капсули» — «Сертификаты» и здесь можно подписать или удалить сертификат.

Жмем «Подписать», в результате при просмотре списка сертификатов в консоли у нас будет 2 подписаных сертификата:

# puppet cert —list —all
+ «srv.co.com» (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 (alt names: «DNS:puppet», «DNS:puppet.co.com», «DNS:srv.co.com»)
+ «zeppelin» (SHA256) 03:C6:FF:F9:4D:10:7C:7D:6C:32:A7:E8:0C:9F:DA:FB:DD:43:B6:E5:36:79:DD:E3:04:41:D3:58:9F:6A:C4:8F

Переходим в меню «Узлы» — «Все узлы» — здесь мы видим 2 сервера (новый сервер может появиться не сразу, а через некоторое время, для того чтобы он появился сразу, нужно после подписи сертификата выполнить на клиенте команду puppet agent -t).

Поумолчанию Foreman берет манифесты из папки /etc/puppet/environments далее в записимоти от окружения. Сейчас мы добавим манифест в Foreman и попробуем применить его для одного из наших клиентов. Создаем папку mkdir -p /etc/puppet/environments/production/modules/vsftpd/manifests, в эту папку закидаем файл init.pp:

Теперь для того чтобы наш модуль с манифестом появился в Foreman нужно зайти в меню «Настройки» — «Классы Puppet» и нажать «Импорт из srv.co.com».

Отметить птичкой нужное нам окружение и нажать «Обновить».

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

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

Жмем кнопу «Изменить», попадаем на другую страницу с настройками указанного узла, тут жмем на вторую вкладку «Классы Puppet» и видим наш класс «vsftpd».

Выбираем наш клас (значок +), он перемещается в левую сторону с «Доступных классов» в «Включенные классы», подтверждаем изменения.

Все — наш манифест добавлен для выбраного сервера, остается подождать пока он будет применен на клиенте. Если мы не хотим ждать, можно зайти на клиент и выполнить комманду puppet agent -t, сразу после ее выполнения манифест будет применен к клиенту и на нем будет установлення vsftpd (в нашем случае).

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

Источник

Система централизованного управления авторизацией пользователей на FreeIPA в Docker

На волне популярности Docker на Хабре, после участия в некоторых дискуссиях в комментариях относительно Docker, и в связи с недавней необходимостью настроить централизованную авторизацию для кластера Linux машин, я решил написать небольшую заметку. Здесь будет показан яркий, на мой взгляд, пример применения Docker’a для небольшой частной задачи.

Вот так, кстати, выглядит FreeIPA WebUI (официальное демо) (кликабельно):

Какие задачи я хотел решить при помощи FreeIPA:

1. Иметь возможность создавать/изменять/удалять акаунты пользователей централизовано, а не на каждом отдельном сервере
2. Централизованные плавила для sudo
3. В последствии мы подключим к этой системе ещё и VPN авторизацию, а потом может и другие внутриофисные сервисы

Да, скорее всего FreeIPA в нашем случае это выстрел пушкой по воробьям, но с другой стороны — альтернатив что-то не видно. Я рассматривал такие варианты: NIS (по-моему он уже давно должен отправиться на отдых), OpenLDAP +… +… (не очень дружелюбно, да и FreeIPA в итоге под собой имеет LDAP, только нам не приходится с ним иметь дело напрямую), тут перечень заканчивается, я не нашёл ничего больше.

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

Перечень используемых технологий:

• FreeIPA — открытый проект компании RedHat, который объединяет в себе множество других открытых проектов: 389 Directory Server, MIT Kerberos, NTP, DNS (bind), Dogtag certificate system, SSSD и другие. При этом у данного решения есть Web UI, CLI, XMLRPC, JSONRPC API и Python SDK.
• Dnsmasq — легковесный DNS сервер (позже я объясню зачем мне он нужен был в дополнение к bind, который используется в FreeIPA).
• Docker — open-source платформа, автоматизирующая развертывание приложений в легковесные, переносимые, самодостаточные контейнеры, которые могут без изменений переноситься между серверами. © Используем Docker и не волнуемся о vendor-lock

FreeIPA, в следствие того, что это продукт RedHat, естественно умеет хорошо разворачиваться на CentOS и Fedora и практически никак не разворачивается на других дистрибутивах. (прим. Я не особо задавался целью, поэтому может и есть где-то инструкции, но пакетов в Debian/Ubuntu для FreeIPA сервера нет, зато есть клиентский пакет freeipa-client , но об этом потом.)

Меня этот факт ни разу не расстроил, а, наоборот, воодушевил! Это же идеальная задача для Docker, когда на серверах Debian/Ubuntu/Gentoo/etc. То есть я мог взять базовый образ Fedora, поставить там нужные пакеты, собрать всё в кучу и запустить, НО ещё более приятной новостью для меня стал официальный Docker образ freeipa-server (есть у них и клиент, но меня интересовал вариант с клиентом на Ubuntu, поэтому я запускал ubuntu образ в Docker и таким образом моделировал и быстро начинал с начала для отладки процесса «с нуля»).

Вообще, запуск freeipa-server не вызвал никаких проблем, всё в соответствии с документацией к образу Docker’a:

Создаём директорию, которая будет монтироваться в образ для конфигов FreeIPA, которые нужно оставлять после перезапуска (в документации предлагается использовать /var/lib/ipa-data/ , но я не люблю засорять систему, поэтому /opt/ ):

Добавим файл с опциями, которые будут использоваться при инсталяции freeipa-server:

Всё, запускаем (в доке не хватает проброса портов, хотя это и очевидно, что нужно сделать; стоит также отметить, что в доке написано, что нужно подключать раздел с постфиксом :Z:rw , но если у вас нет SELinux, вам эта опция не нужна (спасибо grossws)):

После недолгой установки вам любезно предоставят bash — на этом установка и настройка FreeIPA Server по большому счёту завершена. Можете добавить freeipa.example.test себе в /etc/hosts, пройти на https://freeipa.example.test/, залогиниться под admin и создать пользователя.

FreeIPA у себя в образе поднял целый зоопарк служб, в том числе и bind (DNS), который настроил по своему усмотрению (магия, которую практически невозможно повторить на других DNS). Для клиентов FreeIPA ожидается, что они будут иметь доступ к этому DNS, который ещё умеет как-то хитро failover обрабатывать, только вот в случае как здесь — всё в одном образе Docker я не очень вижу пользу с такого failover. Однако, я не стал идти на перекор и учёл пожелания разработчиков FreeIPA (кстати, это особенность Kerberos, всё-таки FreeIPA — просто объединяет множество пакетов).

Так вот, к чему я про DNS? Мне нужен был DNS внутри кластера, но мне категорически не хотелось влезать в bind внутри FreeIPA контейнера. Поэтому я решил воспользоваться проверенным решением — Dnsmasq. На Docker Hub есть минималистичный образ Dnsmasq, основанный на Alpine Linux — 6МБ.

Вот как я его подготовил:

Создал директорию для конфигов:

Добавил туда конфиг dnsmasq:

Запускаем (DNS работает на 53/tcp и 53/udp портах, так что пробрасываем их, папку с конфигами):

Проверяем, что работает:

Итого, у нас есть FreeIPA Server в одном контейнере и Dnsmasq в другом. Кстати, Dnsmasq, как можно было заметить, никак с bind DNS сервером FreeIPA ещё не взаимодействует.

Дальше я связал эти два сервиса в один docker-compose.yml :

Можно заметить небольшую магию с дополнительной опцией к команде dnsmasq, эта опция будет перенаправлять запросы к *.example.test на bind DNS, уставновленный в freeipa контейнере.

Удобство Docker Compose в данном конкретном случае в том, что его конфиг всё-таки удобнее читать, чем bash-скрипт с docker run . Да и лучше сразу делать хорошо. Сохраняем docker-compose.yml и запускаем:

C сервером, наконец, закончили.

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

Тут у меня есть решение в 3 команды 🙂

Нужно исправить /etc/hosts таким образом, чтобы первым в списке было полностью определённое имя домена (FQDN):

Настроить DNS (через /etc/network/interfaces или /etc/resolvconf/resolv.conf.d/head ) так, чтобы в /etc/resolv.conf появились следующие строки:

И теперь изменив пароль admin’a к FreeIPA в следующей команде, можете её запустить:

Здесь добавится PAM-модуль для автоматического создания домашних директорий, установится freeipa-client, запустится установка ipa-client, добавится сервис sudo в sssd.conf и перегрузятся sssd и ssh.

Вот и всё, теперь на этом хосте можно делать su/sudo/ssh, где пользователя при самом первом входе заставят сменить пароль, а при первом входе на новом хосте для пользователя будет автоматически создана домашняя директория из /etc/skel .

Выводы

Docker может упростить разворачивание сложных проектов в любой инфраструктуре. У Docker есть масса применений и это только одно из них.

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

Источник

LTSP: Терминальный сервер на Linux

Сейчас я расскажу вам о том, как можно сэкономить немалое количество времени и денег на вашей IT-инфраструктуре.
Как централизованно админить большое количество linux рабочих станций не разводя при этом хаос в вашей экосистеме.
И так, что же такое LTSP?

LTSP — Это терминальное решение на Linux.
Говоря «терминальное», я в первую очередь имею в виду не подключение к удаленному рабочему столу как в Windows. Я подразумеваю гораздо более гибкую и продвинутую систему доставки ПО, конфигов, домашенего каталога, да и самой операционной системы на клиентские рабочие станции с вашего терминального сервера.

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

У LTSP есть несколько режимов работы:

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

Принцип работы

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

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

Теперь о режимах работы:

• тонкий клиент — Приложения выполняются на терминальном сервере и просто выводятся на дисплей терминального клиента.
• толстый клиент — Приложения выполняются непосредственно на терминальном клиенте, а сервер просто предоставляет доступ к пользовательским файлам и программам.

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

Кроме того, режимы можно комбинировать и некоторые приложения можно заставлять работать иначе, чем все остальные. Например запускать «тяжелый» браузер с flash локально на клиентах, а офисные приложения запускать на самом сервере.

Плюсы и минусы

Давайте рассмотрим какие же плюсы мы имеем по сравнению со стандартными принципами построения ит инфраструктуры:

• Централизованное управление — У вас есть одна единая конфигурация, которой вы управляете из одного места.
• Резервирование и бэкапирование — Все пользовательские данные у вас хранятся на одном сервере, а соотвественно настроив резервирование этого сервера, вы никогда не потеряете пользовательские данные.
• Экономия на компьютерах — Бездисковые терминальные станции стоят заметно дешевле, чем полноценные компьютеры.
• Быстрое развертывание — Вам больше не нужно устанавливать ОС. Прикупив очередную пачку терминалов их можно смело втыкать в сеть, они сразу подтянут операционку с сервера и они будут полностью готовы к работе. Точно так же нерабочий терминал можно быстро заменить другим.
• Независимость от рабочего места — Пользователи могут работать под своей учетной записью независимо с любого компьютера в сети, всегда будет подгружаться именно их личный профиль.
• OpenSource — Прежде всего, LTSP — это открытый и свободный проект. Вам не надо покупать лицензии для его использования. Кроме того, вы всегда можете посмотреть исходники, в основе которых лежат обычные bash-скрипты.

• Требуется непрерывное подключение LAN — терминальные станции грузятся и работают по сети, поэтому требуется стабильное проводное подключение к сети.
• Зависимость от сервера — понятное дело, без сервера все терминальные клиенты становятся бесполезными и превращяются в тыкву.

Устройство

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

• DHCP-сервер — используется для выдачи клиентам IP-адресов и информации о tftp-сервере и пути к загрузчику pxelinux. Вы так же можете использовать ваш собственный DHCP-сервер.
• TFTP-сервер — отдает по tftp-протоколу загрузчик, ядро и главный конфиг lts.conf .
• NBD-сервер — используется ядром для загрузки базовой системы по сети. Так же, при желании, может быть заменен на NFS
• SSH-сервер — используется для авторизации пользователей и передачи их домашних каталогов на терминальные станции.

Во вторых разберемся в том как он работает:

Когда вы установите на ваш сервер пакет ltsp-server-standalone , вы, к полностью настроенным сервисам, получите еще несколько ltsp-скриптов:

• ltsp-build-client — собирает для нас образ системы, который мы будем отдавать на клиентские машины.
• ltsp-chroot — chroot’ит нас в клиентскую систему, например для установки дополнительных пакетов и изменения конфигов.
• ltsp-config — генерит дефолтные конфиги для LTSP.
• ltsp-info — выводит информацию о текущей установке.
• ltsp-update-image — обновляет nbd-образ базовой системы.
• ltsp-update-kernels — копирует ядро и загрузчик из клиентского образа, в директорию tftp-сервера
• ltsp-update-sshkeys — добавляет ssh publickey вашего сервера, в known_hosts клиентского образа.

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

Как устроена загрузка по сети?

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

• Рабочая станция включается и опрашивает DHCP-сервер, как ей грузиться дальше:
  А точнее происходит запрос двух опций: next server — адрес TFTP-сервера и boot file — путь к загрузчику.
• DHCP-сервер, выдает ответ с адресом сервера и путем к pxelinux.
• Рабочая станция загружает загрузчик pxelinux по TFTP
• pxelinux загружает ядро.
  В конфиге pxelinux в опциях ядра указанно откуда грузить основную систему по NBD
• Когда ядро запускается, оно маунтит с сервера nbd-образ в корень системы и загружает процесс init, который в свою очередь и загружает все остальное обычным способом.
• Так же в этот момент ltsp-читает главный конфиг lts.conf с сервера и запускает LDM, после чего пользователь видит приглашение к вводу логина и пароля.

LDM — это логон менеджер LXDE, который отвечает за авторизацию пользователей и начальный запуск окружения.

Когда пользователь логинится проиходит следующее:

• В случае тонкого клиента, LDM заходит с введенным логином и паролем на ваш сервер по SSH,, если успешно, загружает окружение с сервера простым пробросом X’ов.
• В случае толстого клиента, LDM пытается подключиться с введенным логином и паролем к вашему серверу, если успешно, то маунтит домашний каталог пользователя с сервера на клиент посредством sshfs, затем запускает окружение.

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

Установка

Я опишу установку LTSP в режиме толстого клиента, как наиболее сложную и интересную.
Настройка в режиме тонкого клиента мало чем будет оличаться, за исключением того, что необходимое ПО вам придется устанавливать не в chroot, а в основную систему, и после этого вам не нужно будет пересобирать nbd-образ.

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

UPD: Проверенно, с последней Ubuntu 16.04 LTS таких проблем не возникает.

Итак, приступим. Сначала устанавливаем ltsp-server-standalone :

Теперь с помощью ltsp-build-client мы установим клиентскую систему. LTSP поддерживает различные DE, но больше всего мне понравилось как работает LXDE. В отличии от Unity он потребляет совсем мало ресурсов и так-как работает на голых иксах, он почти полностью конфигурируется с помощью переменных среды, это очень удобно, так-как их можно указать в главном конфиге lts.conf.

Все эти опции можно указать в конфиге /etc/ltsp/ltsp-build-client.conf , что бы не прописывать их вручную:

В случае если опция не указана, будет использоваться тот же дистрибутив и/или архитектура, что и на серверной системе.

После запуска комманды, у вас в полностью автоматическом режиме, с помощью debootstrap , развернется система в каталог /opt/ltsp/i386 .

Эта же система и будет использоваться в дальнейшем всеми командами LTSP, в нее будет устанавливаться дополнительное ПО, из нее будут генериться загрузчик с ядром и nbd-образ системы. В принципе, ее, так же можно отдавать по nfs при должной настройке загрузчика.
После установки LTSP автоматически сгенерит из нее nbd-образ. Этот образ и будут загружить наши клиенты.

Для того, чтобы внести какие-нибудь изменения в гостевую ОС, например устанавливать дополнительное ПО, используется команда ltsp-chroot .
Если вы хотите что-то поменять или добавить в гостевую систему, выполните ltsp-choot и вы окажетесь внутри нее.
Затем произведите нужные вам действия, и выйдите командой exit.
Чтобы изменения применились, нужно перегенерить nbd-образ командой ltsp-update-image

DHCP-сервер:

Вместе с метапакетом ltsp-server-standalone у нас установился и isc-dhcp-server .
В принципе он уже из коробки работает как надо, но при желании вы можете поправить его конфиг /etc/default/isc-dhcp-server .
Есть классная статья на OpenNet от 2010 года на тему настройки LTSP, там неплохо описана процедура настройки DHCP-сервера.

Но, так как я предполагаю, что у вас уже есть DHCP-сервер, предлагаю настроить его.

Теперь вам нужно добавить к вашему dhcp-серверу 2 опции:

Как это сделать, смотрите инструкции к вашему DHCP-серверу.
Вот, например инструкция как это сделать на оборудовании Mikrotik.

Установка ПО

Давайте же войдем в нашу гостевую систему:

Теперь установим vim:

Поддержку русского языка:

Последнюю версию Remmina:

Браузер Chromium c плагином PepperFlash (свежий flash от google)

Кстати, PepperFlash можно установить и запустить без Chromium, в Firefox:

Еще в Ubuntu 16.04 есть некая проблема, если не настроить xscreensaver, то через определенное время клиент покажет черный экран, из которого никак не выйти. Исправим это:

Установим xscreenasver, если он еще не установлен:

Если вы намерены блокировать экран с вводом пароля, не забудьте добавить следующую строку в ваш конфиг lts.conf:

Не забываем выйти из chroot и обновить наш nbd-образ:

Создание пользователей

Обычных пользователей терминального сервера можно создать стандартным способом:

Или через GUI если он установлен у вас на сервере

Также при желании можно создать локального администратора в клиентском образе:

Конфиг lts.conf

Вот мы и подобрались к самому главному конфигу
Находится он по адресу /var/lib/tftpboot/ltsp/i386/lts.conf и представляет ссобой нечто иное как описание глобальных переменных.

Конфиг поделен на секции, в секции Default описываются настройки общие для всех клиентов:

Также можно добавить секции для отдельных клиентов, на основе hostname, IP или MAC-адреса:

Вообще полный список опций вы можете найти на этой странице, или в

Итоги

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

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

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

UPD: widestream в комментариях отписал, что успешно использует похожую схему для создания рендер-фермы.

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

Источник