Сетевая загрузка и бездисковые клиенты в ALT Linux

Материал из ALT Linux Wiki
Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.


Требования к оборудованию

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

Реальный стенд

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

Виртуальный стенд

Хост-машина с характеристиками не ниже:

  • Процессорных ядер 2, лучше 4;
  • Оперативная память не менее 4 Гб, лучше 8;
  • Свободное дисковое пространство от 100 Гб.

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

Ресурсы виртуального сервера:

  • Процессор класса i686 — один;
  • Оперативная память 1Гб;
  • Виртуальный диск 40 Гб;
  • Виртуальные сетевые интерфейсы — два. Адаптер 1 тип подключения NAT, с пробросом портов хоста 8081 и 2201 на 8080 (alterator) и 22 (ssh) гостя соответственно. Адаптер 2 тип подключения внутренняя сеть `intnet`.

Masterclass-1-1.png

На второй виртуальной машине - сетевого моста - предварительно установлена минимальная система.

Ресурсы сетевого моста:

  • Процессор класса i686 — один;
  • Оперативная память 512Мб;
  • Виртуальный диск 8 Гб;
  • Сетевые интерфейсы — три. Адаптер 1 тип подключения NAT, с пробросом портов хоста 8082 и 2023 на 8080 (alterator) и 22 (ssh) гостя соответственно. Адаптер 2 тип подключения внутренняя сеть `intnet`. Адаптер 3 тип подключения внутренняя сеть `intnet2`.

И третья виртуальная машина - Клиент

  • Процессор класса i686 — один;
  • Оперативная память 1Гб;
  • Видеопамяти чуть добавить - для скорости;
  • Сетевой интерфейс один, тип подключения внутренняя сеть `intnet`;
  • Очередность загрузки - сразу с сети, прочие виды загрузки можно отключить.

Клиент не имеет собственного накопителя.

При установке виртуальных машин для пользователя root и для системного пользователя admin используется пароль master.

Важно: по окончании подготовки образов виртуальных машин обязательно удалить образ дистрибутива из виртуального CD-ROM, иначе перенос на другой хост заранее подготовленного образа (при необходимости такового) будет осложнён - VirtualBox потребует образ для CD-ROM. Однако если если перенос образа не планируется, дистрибутив в CD-ROM Сервера можно оставить, он пригодится в следующем разделе.

Сетевая загрузка из коробки

Запустим виртуальную машину Сервер и дождёмся её полной загрузки. Если всё сделано правильно, интерфейс Alterator виртуального сервера можно вызвать из браузера хоста по адресу https://localhost:8081 Проделаем это. Предупреждение безопасности игнорируем, с использованием сертификата соглашаемся, вносим сайт в список исключений. Используем имя пользователя root и пароль master для входа в интерфейс Alterator, язык интерфейса - русский.

Чтобы бездисковый клиент мог получить параметры сети надо настроить DHCP, а для DHCP требуется статически сконфигурированный интерфейс. Меню Сеть - Ethernet-интерфейсы, второй адаптер, конфигурация Вручную. Устанавливаем статический IP 10.10.10.1 маска /24 (255.255.255.0). "Добавить". "Применить".

Далее DHCP. Раздел Серверы, DHCP. "Включить службу DHCP", "Начальный IP адрес" - 10.10.10.10, "Конечный IP адрес" - 10.10.10.100. "DNS сервер" - 10.10.10.1. "Домен поиска", например - class.altlinux.org "Шлюз по умолчанию" - тоже 10.10.10.1. "Применить".

И в меню Брандмауэры меню Внешние сети выбрать первый адаптер как принадлежащий внешней сети, то есть глядящий в сторону интернета. Открыты порты по умолчанию: Центр управления, OpenVPN, Удаленное управление, Служебные пакеты.

Подключить в виртуальный CD-ROM образ дистрибутива Centaurus. В разделе Серверы, Сервер сетевых установок - "Новый образ" - "Загрузить с CD-ROM". "Добавить" - пройдёт прогресс добавления образа. Для загрузки можно использовать любые дистрибутивы ALT Linux, не только Centaurus, но и KDesktop и Regular. Указать загруженный образ. "Выбрать" Указать вариант загрузки - бездисковый клиент (соответствует варианту дистрибутива LiveCD). "Применить"

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

Модификация загружаемого образа

Следует заметить, что (в отсутствии домена, об этом речь будет в завершении) дистрибутивы в режиме LiveCD, что называается, root-unsafe - предоставляют вход системного пользователя altlinux и суперпользователя root без пароля вообще, а также автоматически монтируют для пользователя все локальные носители по умолчанию на чтение и запись. Также у дистрибутива Centaurus, запущенном как LiveCD присутствует характерный ярлычок "Установить на жесткий диск". Попробуем, для примера, это исправить. Дальнейшие действия удобнее демонстрировать, соединившись с Сервером по ssh: именно с этой целью tcp порт 2201 хоста проброшен в гостя Сервер на порт 22.

$ ssh admin@localhost -p 2201

Если это первая попытка входа - подтверждение ключа, пароль master, вход. Мы на сервере.

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

$ git clone http://git.altlinux.org/people/george/packages/netinst-overlays.git

Cloning into 'netinst-overlays'...

$ cd netinst-overlays

Имеются три сценария, предназначенные для управления модифицированными LiveCD, но сначала немного теории.

Фактически загрузка LiveCD по сети состоит в том что по сети монтируется каталог NFS, в котором лежит .iso образ. Образ монтируется через loopmount, и на самом деле там лежит squashfs которая ещё раз монтируется через loopmount. Ничто не мешает, воспользовавшись AuFS (аналог nullfs во FreeBSD, т.н. Union File System), смонтировать "стопкой" несколько файловых систем, из которых все нижние будут read-only, а верхняя read-write. У нас есть несколько файловых систем. Мы видим все файлы которые в них есть, те которые выше закрывают тех которые ниже. Самая верхняя может быть доступна на запись. Когда мы пишем, мы просто записываем в самую верхнюю. Такая методика активно используется в ALT Linux, потому что позволяет например при загрузке того же LiveCD смонтировать его на read-only (а как ещё можно смонтировать CD?), поверх него смонтировать на read-write обычную tmpfs - и смело туда писать, пока хватает памяти. Собственно, именно так и происходит. И ровно в эту технологию монтирования AuFS, которая всё равно происходит (ro iso, и поверх неё rw tmpfs) можно вставить ещё много таких iso. Базовая, поверх неё ещё что-то что изменяет содержимое базовой системы, поверх неё ещё что-то и так далее, а поверх всего wead-write tmpfs чтобы можно было работать.

Далее - о том, как создавать такие iso-шки и где их раскладывать. В дистрибутивах ALT Linux это место фиксировано - /srv/public/netinst/overlays-live, если его нет - каталог следует создать. Если туда складывать iso образы, какие угодно, все они будут складываться поверх того базового, который у нас лежит рядом в /srv/public/netinst/

Комплект скриптов для манипуляции образами состоит из трёх частей:

  • управление заплатками-оверлеями .iso на сервере overlays-manage
  • создание заплаток на клиенте overlays-create
  • первоначальный скрипт для настройки overlays-initial

Для удобства пользования целесообразно скопировать все три скрипта в подходящее для них место на сервере:

server# cp overlays-* /usr/local/bin/

При создании оверлеев .iso будет создаваться собственно на клиенте, и тут же переноситься на сервер. С той стороны должен быть пользователь, который принимает подключения по ssh (очевидно, не root) и имеет право писать файлы оверлеев в соответствующий каталог. Создаём на сервере каталог и ставим на него права группе wheel, к которой принадлежит системный пользователь admin.

server# mkdir /srv/public/netinst/overlays-live

server# chgrp wheel /srv/public/netinst/overlays-live

server# chmod 775 /srv/public/netinst/overlays-live

Проверим, что получилось:

server# ls -l /srv/public/netinst/overlays-live -d drwxrwxr-x 2 root wheel 4096 апр 4 22:04 /srv/public/netinst/overlays-live

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

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

server ~]$ mkdir bin

server ~]$ cp /usr/local/bin/overlays-* bin/

По ходу выполнения скрипт создаёт на сервере подкаталог /srv/public/netinst/overlays-live.pool Как раз в него первоначально выкладываются свежесозданные оверлеи, и уже потом из них можно набрать только действительно нужные. Так сделано, чтобы избегать ненужных, но неизбежных ошибок. Каатлог создаётся автоматически, и для этого надо дать доступ.

server# chgrp wheel /srv/public/netinst

server# chmod 775 /srv/public/netinst

Теперь на клиенте (в консоли root):

localhost# scp admin@10.10.10.1:/usr/local/bin/overlays-initial .

localhost# DST=admin@10.10.10.1 sh overlays-initial

Происходит запрос пароль для root обновлённого бездискового клиента. Для примера введём простейший пароль - 123

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

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

localhost# overlays-create initial

Убедимся, что на сервере создался каталог /srv/public/netinst/overlays-live.pool и в нём - файл iso. Если мы сейчас перезагрузимся ничего не изменится, потому что /srv/public/netinst/overlays-live всё ещё пустой. Чтобы управлять этим делом на сервере, существует overlays-manage.

server ~]# overlays-manage
Usage: /usr/local/bin/overlays-manage <command>
setup)	# display some setup variables for overlays-create
info)	# list all overlays and show additional info
list)	# list actual overlays
diff)	# show packages intalled since initial image
nosys)	# unlink all cumulative system overlays (for packages reinstall)
clean)	# clean all overlays except initial and manual ones
link)	# link actual overlays
relink)	# clean and then link
start)	# create an initial persistent overlay
create)	# create an overlay $2=name $3=cumulative?
erase)	# remove all managed overlays
*)	# print help

overlays-manage info показывает что в /srv/public/netinst/overlays-live.pool оверлей есть, а /srv/public/netinst/overlays-live пустой. overlays-manage relink раскладывает всё как надо, оверлей копируется в /overlays-live и будет применён, оверлеи из /overlays-live применяются последовательно в лексикографическом (алфавитном) порядке.

server ~]# overlays-manage relink

Можно посмотреть, что упаковано в получившемся оверлее

server ~]# 7z l /srv/public/netinst/overlays-live/00000000000000-initial.iso

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

Главный бонус от использования "толстого" бездискового клиента в сравнении с терминальным - нормальная работа с устройствами. Флэшки, звук, видео -всё это работает локально, без участия сети.

В консоли root перезагруженного клиента можно mount|more видеть, как одна за другой смонтированы образы файловых систем. Что дальше? overlays-initial это полный diff между всем, что есть при загрузке read-only и тем что изменилось, когда мы что-то делали. Проблема состоит в том, что если сейчас снова что-то изменить, то новый diff будет не между исходным образом и тем что есть, а между всей стопкой образов read-only и тем что стало. diff возможно снять только у того, что read-write. Поэтому при помощи overlays-initial есть смысл делать только минимальные начальные изменения, а всё остальное делается несколько иначе. Когда изменения касаются например только домашнего каталога пользователя, невыгодно делать их в несколько итераций - слишком часто файлы в нём накладываются, переписываются. То же самое относится к /usr/local, /opt, /root, которые изначально (почти) пусты. По таким каталогам нет смысла делать diff, а правильнее затолкать в iso целиком, и целиком же сложить на сервер. Посмотрим, как это делается.

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

localhost# overlays-create home

На сервере при этом в overlays-live.pool стало два оверлея (в overlays-live пока один)

server ~]# overlays-manage relink

Оверлей типа home добавился в overlays-live. Следует обратить внимание на серийный номер оверлея. Скрипт relink устроен так, что удаляет всё кроме initial, а из однотипных вроде home оставляет только последний. Оверлеи типа static и cumulative полностью перебивают содержимое старых, и старые становятся не нужны. Тогда как оверлеи типа diff нужны все, причём в правильном порядке, чтобы отразить например установку и обновление пакетов. Перезагрузим клиента, отметим как в процессе загружаются уже два оверлея, (initial и home) и убедимся, что изменения сделанные на рабочем столе клиента и в его параметрах настройки - сохранились.

Влияние параметров сети

Множественные образы и клиентское меню загрузки

Кастомизация множественных образов

Аутентификация пользователей домена

Настройка DNS. Потребуется переключить интерфейс Alterator в режим эксперта. В разделе Серверы появляется "DNS-сервер". "Новый домен" тот же, что и в настройках DHCP, в нашем случае class.altlinux.org "Создать".

Теперь можно проделать завершающее действие - включить поддержку домена Kerberos на ВМ Сервер. Делается это в меню Домен веб-интерфейса Альтератор. До сих пор мы не пользовались этим меню: дело в том, что дистрибутив Centaurus в режиме LiveCD определяет присутствие домена и при запуске автоматически включается запрос пароля. До сих пор это было нам не нужно.

Включим поддержку домена Kerberos и удостоверимся, что все необходимые сетевые службы перешли в состояние OK.