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

{{stub}}

= Системные требования =

Возможно использование двух вариантов демонстрационного стенда. Реальный аппаратный — нагляднее для слушателей. Виртуальный стенд удобнее в транспортировке и при демонстрации.
Также для демонстрации нужны хотя бы два .iso образа, основной - дистрибутива Centaurus и ещё один, лучше всего Simply.  

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

== Виртуальный стенд ==
Хост-машина с характеристиками не ниже:

* Процессорных ядер 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 и 2202 на 8080 (alterator) и  22 (ssh) гостя соответственно. Адаптер 2 тип подключения внутренняя сеть `intnet`. Адаптер 3 тип подключения внутренняя сеть `intnet2`. На адаптерах 2 и 3 обязательно включить неразборчивый режим (promiscuous mode), для обеспечения прозрачного проброса пакетов через мост.

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

* Процессор класса 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.

<code>$ ssh admin@localhost -p 2201</code>

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

Набор скриптов для модификации загружаемого образа получается из репозитория. Пакет можно установить при помощи apt-get или распаковать и использовать напрямую.
<code>
 server# apt-get update
 server# apt-get install netinst-overlays
</code>
Имеются три сценария, предназначенные для управления [[Centaurus:_Бездисковый_клиент#Модернизация загружаемого образа|модифицированными]] 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'''

Для удобства пользования целесообразно скопировать все три скрипта в подходящее для них место на сервере:
 
<code>server# cp overlays-* /usr/local/bin/</code>

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

<code>
server# mkdir /srv/public/netinst/overlays-live

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

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

</code>

Проверим, что получилось:
<code>
 server# ls -l /srv/public/netinst/overlays-live -d
 drwxrwxr-x 2 root wheel 4096 апр  4 22:04 /srv/public/netinst/overlays-live
</code>
Для того, чтобы скрипты работали, им необходимо "знать" какой должен быть пользователь и на каком хосте он сидит.

Пока что скрипты не доработаны, поэтому предполагают что находятся в подкаталоге bin профиля пользователя.
<code>
 server ~]$ mkdir bin
 server ~]$ cp /usr/local/bin/overlays-* bin/
</code>
По ходу выполнения скрипт создаёт на сервере подкаталог /srv/public/netinst/overlays-live.pool Как раз в него первоначально выкладываются свежесозданные оверлеи, и уже потом из них можно набрать только действительно нужные. Так сделано, чтобы избегать ненужных, но неизбежных ошибок. Каатлог создаётся автоматически, и для этого надо дать доступ.

<code>
server# chgrp wheel /srv/public/netinst

server# chmod 775 /srv/public/netinst
</code>

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

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

<code>localhost# DST=admin@10.10.10.1 sh overlays-initial</code>

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

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

Скрипт '''overlays-create''' предусматривает создание разных оверлеев, их назначение подробнее рассматривается в уже упоминавшейся [[Centaurus:_Бездисковый_клиент|статье]]. '''overlays-create initial''' предназначен для того, чтобы перебить всё то, что было изменено полностью.
<code>localhost# overlays-create initial</code>
Убедимся, что на сервере создался каталог /srv/public/netinst/overlays-live.pool и в нём  - файл iso. Если мы сейчас перезагрузимся ничего не изменится, потому что /srv/public/netinst/overlays-live всё ещё пустой. Чтобы управлять этим делом на сервере, существует '''overlays-manage'''.
<code>
 server ~]# overlays-manage
 server ~]# overlays-manage info
</code>
'''overlays-manage info''' показывает что в /srv/public/netinst/overlays-live.pool оверлей есть, а /srv/public/netinst/overlays-live пустой. '''overlays-manage relink''' раскладывает всё как надо, оверлей копируется в /overlays-live и будет применён, оверлеи из /overlays-live применяются последовательно в лексикографическом (алфавитном) порядке.
<code>
 server ~]# overlays-manage relink
</code>
Можно посмотреть, что упаковано в получившемся оверлее
<code>
 server ~]# 7z l /srv/public/netinst/overlays-live/00000000000000-initial.iso
</code>
Ничего особенного - файлы, которые были изменены относительно базового образа, разложенные по своим каталогам и подкаталогам.
Бездисковый клиент можно перезагрузить и убедиться, что сделанные изменения сохранились. В процессе загрузки можно заметить сообщение о загрузке и применении оверлея.

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

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

Для начала произведём несколько наглядных изменений на рабочем столе клиента: изменим фон рабочего стола, отменим блокировку экрана, сменим комбинацию раскладок клавиатуры, добавить иконку запуска чего-нибудь. Обязательно завершить сеанс пользователя, чтобы изменения записались.
<code>
 localhost# overlays-create home
</code>
На сервере при этом в overlays-live.pool стало два оверлея (в overlays-live пока один)
<code>
 server ~]# overlays-manage relink
</code>
Оверлей типа home добавился в overlays-live. Следует обратить внимание на серийный номер оверлея. Скрипт relink устроен так, что удаляет всё кроме initial, а из однотипных вроде home оставляет только последний. Оверлеи типа static и cumulative полностью перебивают содержимое старых, и старые становятся не нужны. Тогда как оверлеи типа diff нужны все, причём в правильном порядке, чтобы отразить например установку и обновление пакетов. Перезагрузим клиента, отметим как в процессе загружаются уже два оверлея, ('''initial''' и '''home''') и убедимся, что изменения сделанные на рабочем столе клиента и в его параметрах настройки - сохранились.

Изменённые обои и прочие настройки это хорошо, но может понадобиться что-то дополнительно установить. Например, чтобы подготовить учебную систему к определённой теме урока, может понадобиться кастомизировать программное окружение нашего клиента. Для установки пакетов требуется довольно много места в каталоге /var/spool/apt/ Эти кэши не нужны никогда, за исключением ситуации когда мы ставим пакеты. При обычной эксплуатации они не нужны. Но когда мы ставим пакеты, кэши способны сожрать всю оперативную память, поэтому достаточно очевидный ход - на время апдейта смонтировать эти каталоги в какую-то реально существующую файловую систему. Рассматриваемые скрипты работают так: обнаружив на диске линуксовую файловую систему, монтируют её, создают там временный каталог и его используют.
Теперь имеет смысл выключить клиент, добавить к нему (виртуальный) накопитель минимального объёма... 

[[Файл:Masterclass-1-2.png]]

...и запустить клиент снова. 
<code>
 localhost ~]# sfdisk /dev/sda
 localhost ~]# sfdisk -l
 localhost ~]# mkfs.ext3 /dev/sda1
</code>
Повторимся: дополнительное блочное устройство нужно только на время подготовки образа, и только потому, что при этом используется дополнительное количество больше ни для чего не нужных кэшей.
<code>
 localhost ~]# overlays-create diskcache
</code>
Посмотрим, как теперь используется наш диск. Убедимся, что на него смонтировались: /mnt, /var/log/, /var/cache/apt, /tmp, /var/lib/apt 
<code>
 localhost ~]# mount
[[Файл:Masterclass-1-3.png]]
 localhost ~]# ls /mnt
 localhost ~]# ls /mnt/overlays
</code>
Это те каталоги, которые будут расти по мере работы установщика пакетов, и которые совершенно не нужны в LiveCD
<code>
 localhost ~]# apt-get update
 localhost ~]# du -h /mnt/overlays
</code>
И установим какой-нибудь полезный пакет
<code>
 localhost ~]# apt-get install geany-plugins
</code>
Откроем сеанс пользователя и убедимся что пакет стоит (появился в пользовательском меню). Добавим кнопку запуска Geany на рабочий стол. Завершим сеанс пользователя.
Обновим /home
<code>
 localhost# overlays-create home
</code>
Просто полный дамп всего /home, и хорошо что изначально он совершенно пустой. И вторая операция - это составление кумулятивного оверлея, который будет содержать то, что мы дополнительно установили. 
<code>
 localhost# overlays-create system
</code>
Что на сервере?
<code>
 server ~]# overlays-manage info
</code>
В overlays-live.pool теперь один initial, два home и один system-cumulative.
<code>
 server ~]# overlays-manage relink
 server ~]# overlays-manage info
</code>
В overlays-live - один initial, один последний home и system-cumulative. Оверлеи home сразу не удаляют, на случай если что-то в домашнем каталоге было сделано неправильно. Можно вернуться назад, удалив 
последний - неправильный - оверлей и повторив relink. Перезагрузим клиент, обратим внимание на загрузку трёх оверлеев и убедимся, что на рабочем столе кнопка Geany сохранилась - и работает.
[[Файл:Masterclass-1-4.png]]

Это не обязательно показывать, но если сейчас ещё что-то модифицировать, то с '''overlays-create system''' будет создан ещё один оверлей, который будет монтироваться при старте, и так они будут монтироваться пачками. Есть другая команда, '''overlays-create packages'''. Она делает фактически разницу между initial и тем что было доустановлено (или удалено) с тех пор. Её выдача - список команд apt-shell
<code>
 localhost ~]# overlays--create packages | apt-shell
</code>
Сделано так потому, что если количество оверлеев приблизится к десятку,- их последовательное монтирование начнёт представлять собой проблему. В какой-то момент становится правильнее создать один большой кумулятивный оверлей со всеми изменениями, а все остальные потереть. Для этого нужно удалить все оверлеи из /srv/public/netinst/overlays-live, оставив один только initial
<code>
 server ~]# overlays-manage clean
</code>
Загрузиться с одним initial, посмотреть что было изменено с помощью '''overlays--create packages''', проделать необходимые изменения и изготовить один кумулятивный оверлей. Приём позволяет держать под контролем количество кумулятивных оверлеев, используемых для загрузки.

= Влияние параметров сети =
Весьма важно представлять себе влияние ключевого компонента бездисковой системы - сети. С начала загрузки это tftp, потом nfs и всё в очень, очень больших количествах. Для демонстрации влияния качества сети запустим виртуальную машину, которая должна будет играть роль управляемого моста в сети. Установка проводилась в варианте "вручную", из 8 Гб выделенного виртуального накопителя 512 Мб swap, остальное корневой раздел ext2/ext3. Профиль - "минимальная установка". Сетевых адаптеров три, первый - режим NAT, адрес назначается по DHCP с хоста. Второй внутренняя сеть intnet, третий внутренняя сеть intnet2, они будут затем объединены в мост (bridge), их IP адрес не имеет значения. '''Неразборчивый режим: разрешить всё''' для интерфейсов 2 и 3, чтобы обеспечить прозрачный проброс пакетов протокола ARP.  
Запустим bridge, зайдём на него с хоста по ssh.
<code>
 $ ssh admin@localhost -p 2202
 bridge ~]$ su -
 bridge ~]#
</code>
Теперь мы будем настраивать из этой виртуальной машины bridge, причём такой на котором (между адаптерами 2 и 3) пакеты будут ходить или нормально, или медленно, а то и вовсе теряться. Словом, имитируем не очень хорошую сеть и смотрим как это влияет на запуск и работу бездискового клиента. Создаём в /etc/net/ifaces/ каталог bridge и в нём файл options следующего содержания:
<code>
 # cat /etc/net/ifaces/bridge/options 
 TYPE=bri
 HOST="enp0s8 enp0s9"
</code>
[[Файл:Masterclass-1-5.png]]

'''enp0s8''' и '''enp0s9''' - имена виртуальных сетевых интерфейсов 2 и 3, включенных во внутренние сети '''intnet''' и '''intnet2'''.
<code>
 # service network restart
 # tc qdisc list
 qdisc pfifo_fast 0: dev enp0s3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 qdisc pfifo_fast 0: dev enp0s8 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 qdisc pfifo_fast 0: dev enp0s9 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
</code>
<code>
 # cd /etc/net/ifaces/enp0s8
 enp0s8]# mkdir qos/1/ -p
 enp0s8]# cd qos/1
</code>
Специфика управления etcnet состоит в том, что всё это куски опций команды '''tc''' (см. man tc), для удобства разложенные в конфигурационные файлы. Для имитации качества сети используем дисциплину netem (NETwork EMulator)
<code>
 # ls
 qdisc  qdisc#delay  qdisc#loss  qdisc#LOSS  qdisc#rate
</code>
Настало время проверить, как наш бездисковый клиент будет чувствовать себя в условиях не очень хорошей сети. Два сетевых интерфейса машины bridge включены к внутренним сетям intnet и intnet2. Они связаны в мост, в котором мы можем управлять скоростью прередачи данных, задержкой при передаче данных, потерями пакетов и их порчей при передаче. На виртуальном бездисковом клиенте переключим интерфейс с intnet на intnet2 и получим ситуацию, при которой между server и diskless машинами находится bridge. Первоначально он ничему не должен мешать, поэтому запустим diskless и убедимся, что он нормально загружается. Перекладывание пакетов между интерфейсами нагружает CPU, поэтому загрузка может происходить чуть медленнее чем в отсутствии моста, но не сильно.
Посмотрим что будет, если в сети при загруженном клиенте возникнут значительные потери пакетов.
<code>
 [root@bridge 1]# cat qdisc#LOSS
 netem loss 5% 25% corrupt 5%
 [root@bridge 1]# service network restartwith LOSS
 [root@bridge 1]# tc qdisc list
 qdisc pfifo_fast 0: dev enp0s3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 qdisc netem 1: dev enp0s8 root refcnt 2 limit 1000 loss 5% 25% corrupt 5%
 qdisc pfifo_fast 0: dev enp0s9 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 [root@bridge 1]]# cd /etc/net/ifaces/enp0s9/
 bridge enp0s9]# ln -s ../enp0s8/* .
 ln: не удалось создать символьную ссылку «./options»: Файл существует
 bridge enp0s9]# l
 итого 12
 drwxr-xr-x 2 root root 4096 апр 20 17:04 ./
 lrwxrwxrwx 1 root root   13 апр 20 17:04 qos -> ../enp0s8/qos/
 drwxr-xr-x 9 root root 4096 апр 19 18:57 ../
 -rw-r--r-- 1 root root   61 апр 17 21:58 options
 bridge ~]# service network restartwith LOSS
 [root@bridge enp0s9]# tc qdisc list
 qdisc pfifo_fast 0: dev enp0s3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 qdisc netem 1: dev enp0s8 root refcnt 2 limit 1000 loss 5% 25% corrupt 5%
 qdisc netem 1: dev enp0s9 root refcnt 2 limit 1000 loss 5% 25% corrupt 5%
</code>
В таких условиях уже загруженный клиент работать будет, но совсем медленно. Зелёный индикатор активности сети (если стенд виртуальный) говорит о том, что происходит интенсивный ретрансмит потерянных и повреждённых пакетов. 5% потерянных пакетов это такое плохое качество сети, которое становится видно явно, то есть можно считать недопустимым. Причём если уже загруженный клиент по NFS с грехом пополам работает, то первоначальная загрузка по TFTP уже не работает никак.

Уменьшим потери пакетов. 
<code>
 [root@bridge 1]# cat qdisc#loss
 netem loss 0.33% 25% corrupt 0.33%
 [root@bridge enp0s9]# service network restartwith loss
 [root@bridge enp0s9]# tc qdisc list
 qdisc pfifo_fast 0: dev enp0s3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 qdisc netem 1: dev enp0s8 root refcnt 2 limit 1000 loss 0.33% 25% corrupt 0.33%
 qdisc netem 1: dev enp0s9 root refcnt 2 limit 1000 loss 0.33% 25% corrupt 0.33%
</code>
Всего примерно один процент потерянных пакетов, плюс ещё один - повреждённых. Загрузка теперь происходит, хотя и очень медленно. Если очень долго ждать, можно дождаться загрузки. Очевидно, что уже загруженный клиент будет работать лучше чем в предыдущем случае. Периодически ретрансмиты возникают, но работает уже довольно прилично.

Теперь как влияет задержка.
<code>
 [root@bridge 1]# cat qdisc#delay
 netem delay 0.5ms loss 0.05% 25% corrupt 0.05%
 [root@bridge enp0s9]# service network restartwith delay
 [root@bridge enp0s9]# tc qdisc list
 qdisc pfifo_fast 0: dev enp0s3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 qdisc netem 1: dev enp0s8 root refcnt 2 limit 1000 delay 499us loss 0.05% 25% corrupt 0.05%
 qdisc netem 1: dev enp0s9 root refcnt 2 limit 1000 delay 499us loss 0.05% 25% corrupt 0.05%
</code>
Задержка небольшая, всего половина миллисекунды. Перезапускаем клиент. Разумеется, загрузка идёт заметно медленнее. Задержка может происходить по причине каскадного подключения коммутаторов, чего при использовании бездисковых клиентов следует избегать. Теоретически, в сети с задержками ещё хуже будет протоколу TCP, который использует подтверждения передачи. Однако прямо сейчас без специального замера проблема не видна ввиду малой величины задержки.
И, наконец, ограничение пропускной способности. 
<code>
 [root@bridge 1]# cat qdisc#rate
 netem loss 0.05% 25% corrupt 0.05% rate 10mbit
 [root@bridge enp0s9]# service network restartwith rate
 [root@bridge enp0s9]# tc qdisc list
 qdisc pfifo_fast 0: dev enp0s3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 qdisc netem 1: dev enp0s8 root refcnt 2 limit 1000 loss 0.05% 25% corrupt 0.05% rate 10000Kbit
 qdisc netem 1: dev enp0s9 root refcnt 2 limit 1000 loss 0.05% 25% corrupt 0.05% rate 10000Kbit
</code>
Необходимо отметить, что сейчас в нашей тестовой сети один потребляющий трафик клиент. Наверняка можно даже померить этот трафик, например '''iftop''' хотя трафик при различных действиях клиента - тоже разный. При активных действиях полоса пропускания занимается полностью, при отсутствии активности освобождается. Интереснее оценить влияние ограничения трафика на глаз, причём результат совершенно предсказуем - чем уже полоса пропускания тем медленнее происходит загрузка. В самом начале загружается в основном read-only информация, которая затем будет локально закеширована, и последующая работа будет проходить уже легче - разумеется при условии что клиенты не начнут что-то делать одновременно. Например, начальную загрузку можно производить заранее, до начала работы (вручную или по расписанию посредством Wake-on-LAN). В нашем случае при ограничении в 10 Мбит работать совершенно некомфортно.
<code>
 [root@bridge 1]# apt-get install iftop
 [root@bridge 1]# iftop -i enp0s9
</code>
Запустим на клиенте LibreOffice и убедимся что стартовать он будет долго, и отведенная полоса пропускания будет при этом занята полностью.
[[Файл:Masterclass-1-6.png]]

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

= Множественные образы и клиентское меню загрузки =
В этом разделе мы затронем моменты, которыми уже нельзя управлять "из коробки", поскольку они превышают возможности доступные штатному Alterator. В настоящее время мы можем выбрать образ и один вариант загрузки - и он будет всем раздаваться. Наше цель - добиться чтобы сам пользователь (не администратор!) мог выбрать вариант загрузки. Прежде всего следует рассмотреть, как вся эта схема работает. Зайдём на сервер с правами root. 

Когда мы вставили CD с загрузочным образом (или указали Alterator *.iso файл образа), этот образ смонтировался с помощью '''loopmount''' в каталог /srv/public/netinst/mnt/ 
<code>
 [root@server ~]# cd /srv/public/netinst/mnt/
 [root@server mnt]# ls
 altinst   docs        license.all.html  live      rescue           syslinux
 ALTLinux  index.html  license.ru.html   Metadata  RPM-GPG-KEY.bz2
</code>
Здесь лежит некоторая документация, пакетная база дистрибутива, а также файлы '''altinst, live''' и '''rescue'''. Это - образы файловых систем squashfs,
<code>
 [root@server mnt]# file /srv/public/netinst/mnt/live 
 /srv/public/netinst/mnt/live: Squashfs filesystem, little endian, version 4.0, 189563681279 bytes, 90042 inodes, blocksize: 44 bytes, created: Wed Aug  7 18:56:00 2002
</code>
в которых, собственно, и содержатся все нужные файлы для того или иного варианта загрузки. Вариантов загрузки, в данном случае три: '''altinst''' для установки, '''live''' для LiveCD и '''rescue''' для аварийного восстановления. Есть ещё загрузка с жёсткого диска и тест памяти, который просто загружается отдельно. Следует иметь в виду, что имеет место двойное монтирование: сначала монтируется .iso, потом внутри выбирается нужный вид загрузки, который ещё раз монтируется через loopmount, на этот раз не как isofs а как squashfs, и вот только теперь его содержимое становится доступно.

В оверлеях, которые монтируются позднее, уже никакого squashfs, они просто монтируются сверху. При старте системы с флэшки работает '''syslinux'''. Это загрузчик, его файлы располагаются в /srv/public/netinst/mnt/syslinux/
<code>
 [root@server mnt]# ls /srv/public/netinst/mnt/syslinux/
 16x16.fnt  drs16b.fnt  fr.tr         it.tr      nl.tr     sv.hlp
 af.tr      drs16.fnt   gfxboot.c32   ja.tr      pa.hlp    sv.tr
 alt0       drs18b.fnt  gfxboot.cfg   ka.tr      pa.tr     ta.tr
 ar.hlp     drs18.fnt   gl.hlp        kk.tr      pl.hlp    timer_a.jpg
 ar.tr      el.hlp      gl.tr         ko.hlp     pl.tr     tr.tr
 back.jpg   el.tr       gu.hlp        ko.tr      pt_BR.tr  tt.hlp
 bg.tr      en.hlp      gu.tr         lang       pt.hlp    tt.tr
 boot.cat   en.tlk      hi.tr         languages  pt.tr     uk.hlp
 bootlogo   en.tr       hr.tr         lt.hlp     ro.hlp    uk.tr
 ca.hlp     es.hlp      hu.hlp        lt.tr      ro.tr     wa.tr
 ca.tr      es.tr       hu.tr         memtest    ru.hlp    xh.tr
 cs.hlp     et.hlp      id.tr         mr.hlp     ru.tr     zh_CN.hlp
 cs.tr      et.tr       init          mr.tr      sk.hlp    zh_CN.tr
 da.hlp     fi.hlp      isolinux.bin  nb.hlp     sk.tr     zh_TW.hlp
 da.tr      fi.tr       isolinux.cfg  nb.tr      sl.tr     zh_TW.tr
 de.tr      fr.hlp      it.hlp        nl.hlp     sr.tr     zu.tr
</code>
здесь и тексты, и картинки, и всё что нужно для красоты при загрузке. А ядро и стартовый виртуальный диск лежат в подкаталоге alt0
<code>
 [root@server mnt]# ls /srv/public/netinst/mnt/syslinux/alt0
 full.cz  vmlinuz
</code>
Меню с вариантами загрузки, которые мы видим при старте, находится в файле isolinux.cfg 
<code>
 [root@server mnt]# cat /srv/public/netinst/mnt/syslinux/isolinux.cfg 
 default harddisk
 prompt 1
 timeout 200
 ui gfxboot bootlogo message
 implicit 1
 label harddisk
  localboot 0x80 
 label linux
  kernel alt0/vmlinuz
    append initrd=alt0/full.cz changedisk ramdisk_size=171500 lang=ru_RU splash noeject quiet=1 showopts
 label failsafe
  kernel alt0/vmlinuz
    append initrd=alt0/full.cz changedisk ramdisk_size=171500 lang=ru_RU  showopts noapic pci=nomsi noeject acpi=off noload=ahci nomodeset
 label rescue
  kernel alt0/vmlinuz
  append initrd=alt0/full.cz live ramdisk_size=100942 fastboot stagename=rescue showopts
 label live
  kernel alt0/vmlinuz
  append initrd=alt0/full.cz live lowmem fastboot splash stagename=live quiet=1 showopts
 label memtest
  kernel memtest
</code>
Пункты меню, перечисленные в параметрах label, мы и видим при загрузке, остальное - соответствующие параметры ядра. Следует обратить внимание на соответствие этих пунктов тому перечню, который мы видим при выборе "Вариант загрузки" в Alterator, потому что они делаются один из другого.

Вернёмся к тому, как вообще происходит сетевая загрузка. Во-первых, нужно настроить DHCP, чтобы он раздавал IP адрес '''и''' адрес сервера, с которого происходит загрузка.
<code>
 [root@server ~]# cat /etc/dhcp/dhcpd.conf
</code>
В этой настройке есть подсеть, диапазон адресов, доменное имя, и всё что положено.
Три параметра отвечают за сетевую загрузку:
<code>
	next-server 10.10.10.1;
	filename "pxelinux.0";
	option root-path "/srv/public/netinst/current";
</code>
При загрузке по протоколу PXE (если сервер указанный параметром '''next-server''' умеет раздавать по PXE) параметр '''filename''' укажет файл который будет загружаться. Программа, заключённая в файле, начнёт выполняться. Этой программе будут переданы два параметра: сетевой адрес сервера '''next-server''', с которого следует монтировать по протоколу NFS корневую файловую систему и путь '''root-path''' с которого она должна монтироваться.
<code>
 # file -L /srv/public/netinst/current
 /srv/public/netinst/current: ISO 9660 CD-ROM filesystem data 'ALT Linux 7.0.4 Centaurus  (Ph ' (bootable)
</code>
По этому пути находится файл current, собственно тот самый .iso образ, который мы закачали на сервер. То, что дальше будет происходить с образом, определяется настройкой программы pxelinux.0, которая находится в файле /var/lib/tftpboot/pxelinux.cfg/default
<code>
 # cat /var/lib/tftpboot/pxelinux.cfg/default 
 default live
 prompt 1
 timeout 100
 implicit 1
 label harddisk
  localboot 0x80 
 label linux
  kernel syslinux/alt0/vmlinuz
    append initrd=syslinux/alt0/full.cz changedisk ramdisk_size=171500 lang=ru_RU splash noeject quiet=1 showopts automatic=method:nfs,network:dhcp tz=Europe/Moscow  lang=ru_RU  
 label failsafe
  kernel syslinux/alt0/vmlinuz
    append initrd=syslinux/alt0/full.cz changedisk ramdisk_size=171500 lang=ru_RU  showopts noapic pci=nomsi noeject acpi=off noload=ahci nomodeset automatic=method:nfs,network:dhcp tz=Europe/Moscow  lang=ru_RU  
 label rescue
  kernel syslinux/alt0/vmlinuz
  append initrd=syslinux/alt0/full.cz live ramdisk_size=100942 fastboot stagename=rescue showopts automatic=method:nfs,network:dhcp tz=Europe/Moscow  lang=ru_RU  
 label live
  kernel syslinux/alt0/vmlinuz
  append initrd=syslinux/alt0/full.cz live lowmem fastboot splash stagename=live quiet=1 showopts automatic=method:nfs,network:dhcp tz=Europe/Moscow  lang=ru_RU  
 label memtest
  kernel syslinux/memtest
</code>
Этот конфиг повторяет isolinux.cfg постольку, поскольку именно из него и создаётся специальным скриптом при нажатии кнопки '''Выбрать''' в Alterator. Те же самые метки, те же параметры, плюс дополнительные типа 
'''ramdisk_size''' и '''stagename'''. Параметр '''stagename''' определяет тот конкретный squashfs, который собственно и будет загружен. Поддержку всего этого процесса обеспечивает софт из initrd=syslinux/alt0/full.cz Разумеется, что ядро kernel syslinux/alt0/vmlinuz и стартовый виртуальный диск syslinux/alt0/full.cz тоже должны где-то располагаться. И это место - /var/lib/tftpboot/syslinux/
<code>
 [root@server ~]# l /var/lib/tftpboot/syslinux/
 итого 2304
 drwxr-xr-x 4 root root   4096 апр  4 21:54 ../
 dr-xr-xr-x 3 root root   4096 апр  4 21:54 ./
 .
 dr-xr-xr-x 2 root root   4096 апр  4 21:54 alt0/
 .
</code>
Alterator, не мудрствуя, копирует сюда весь каталог syslinux как он есть один в один. Если подать в Alterator новый образ (загрузить и выбрать) - всё что было в pxelinux.cfg и syslinux удаляется, так оно сейчас устроено, и генерируется заново. Это означает, что в действующей на сейчас конфигурации мы не можем поддерживать множество различных загружаемых образов и разных дастрибутивов, потому что при загрузке каждого нового он попросту заменяет прежний.

Для продолжения демонстрации требуется загрузить на сервер ещё один дистрибутив. Воспользуемся установочным .iso образом дистрибутива Simply Linux LiveCD, указав его для виртуального CD сервера. (https://localhost:8081/netinst) Теперь достаточно указать в интерфейсе Alterator '''Загрузить с CD/DVD''', '''Добавить''', далее '''Выбрать'''. В результате действия '''Выбрать''' оба ключевых места, а именно
<code>
 [root@server ~]# l /var/lib/tftpboot/syslinux/
</code>
и 
<code>
 [root@server ~]# l /var/lib/tftpboot/pxelinux.cfg/
</code>
будут полностью переписаны. Обратите также внимание на то, как изменился список параметров '''Вариант загрузки'''. Попробуем загрузить Клиента и посмотреть, что получится. (Не забыть переключить сетевой адаптер обратно на внутреннюю сет intnet.) Очевидно, что загрузится Simply Linux в режиме LiveCD. Ещё раз обратим внимание на процесс загрузки. На самом деле, при появлении приглашения '''boot:''' пользователь может вмешаться и изменить установку, заданную в Alterator, введя другой label из 
pxelinux.cfg/default - например, rescue. Тогда вместо рабочего стола получится консоль root, вдобавок по умолчанию (то есть без пароля).

[[Файл:Masterclass-1-7.png]]

Идея состоит в том, чтобы изменить меню по умолчанию тем, что нам нужно. Для этого надо порыться в пакете syslinux, частью которого являются и isolinux и pxelinux и много чего ещё. Тут мы довольно быстро найдём 
<code>
 [root@server ~]# rpm -ql syslinux | grep menu
 /usr/lib/syslinux/menu.c32
 /usr/lib/syslinux/vesamenu.c32
 /usr/share/doc/syslinux-4.04/menu.txt
</code>
Где menu.c32 собственно меню и документация к нему - в файле menu.txt.
<code>
 [root@server ~]# less /usr/share/doc/syslinux-4.04/menu.txt
</code>
Здесь находится описание того, каким образом можно подгрузить вместо ядра - меню, при помощи которого пользователь сможет управлять загрузкой.
<code>
 # The file graphics.conf contains common color and layout commands for
 # all menus.
 LABEL othermenu
        MENU LABEL Another Menu
        KERNEL vesamenu.c32
        APPEND graphics.conf othermenu.conf
 # Return to the main menu
 LABEL mainmenu
        MENU LABEL Return to Main Menu
        KERNEL vesamenu.c32
        APPEND graphics.conf ~
</code>

Фактически, мы берём всё тот же pxelinux.cfg и добавляем в него дополнительные настройки, такие как MENU LABEL, MENU DEFAULT и так далее. На сайте uneex.ru уже есть [http://uneex.ru/FrBrGeorge/BookP5/NetworkInstall статья], в которой описано как всё это организуется. 
<code>
 [root@server ~]# vim /var/lib/tftpboot/pxelinux.cfg/default 
</code>
Добавляем в начале файла инструкцию 
<code>
ui menu.c32
</code>
После такой модификации pxelinux загрузит сначала меню, в этом меню, в соответствии с его конфигом, позволит пользователю стрелочками выбирать опции. Затем скопируем получившееся 
<code>
 [root@server syslinux]#  cp /usr/lib/syslinux/menu.c32 /var/lib/tftpboot/
</code>
и перезапустим Клиент

[[Файл:Masterclass-1-8.png]]

Если мы хотим вместо текстового меню какую-нибудь красивую картинку, то вместо menu.c32 можно использовать vesamenu.c32. Нужно найти подходящую картинку и преобразовать ей к размеру 680 на 480, это стандартный размер для vesamenu. Например, 
<code>
 [root@server ~]# convert /var/lib/tftpboot/syslinux/back.jpg -resize 640x480 /var/lib/tftpboot/back.jpg
</code>
А также дописать в /var/lib/tftpboot/pxelinux.cfg/default указание на картинку и заголоовк, что-то вроде 
<code>
 menu background back.jpg
 menu title BOOT
</code>
Ещё раз перезапустим Клиент
 

[[Файл:Masterclass-1-9.png]]

Попробуем модифицировать меню. Например доведём  /var/lib/tftpboot/pxelinux.cfg/default до такого вида: ^ означает выделение буквы особым цветом, она же "горячая клавиша", загрузка с жесткого диска защищена паролем ''P@sswd'' :
<code>
 ui vesamenu.c32
 default live
 prompt 1
 timeout 100
 menu background back.jpg
 menu title BOOT
 implicit 1
 label harddisk
  menu label ^Boot from harddisk
  menu passwd P@sswd
  localboot 0x80
 label live
  menu label ^Diskless client
  menu default
  kernel syslinux/alt0/vmlinuz
  append initrd=syslinux/alt0/full.cz live lowmem fastboot splash stagename=live quiet=1 showopts automatic=method:nfs,network:dhcp tz=Europe/Moscow  lang=ru_RU
 label memtest
  menu label ^Memory test
  kernel syslinux/memtest
</code>

[[Файл:Masterclass-1-10.png]]

С меню можно проделывать множество различных манипуляций. Меню можно двигать, по-разному раскрашивать, задавать пароль текстом или пароль md5sum (чтобы нельзя было подглядеть), но всё это пока не даёт возможности работать с '''несколькими''' кастомизированными загрузками. Вот мы выбираем для загрузки совсем другой образ - Simply вместо Centaurus

[[Файл:Masterclass-1-11.png]]

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

= Кастомизация множественных образов =
Идея состоит в том, что если  руками - пока что только руками - передать машине при загрузке профайл, то оверлеи будут искаться уже не в одном-единственнолм каталоге а в разных для каждого профайла. Тогда можно будет создавать множество вариантов загрузки, и каждый из них будет хранить свои оверлеи отдельно один от другого. Поддержка такой "разводки" в образах дистрибутивов на основе ALT Linux присутствует начиная с версии 7.0.1 и управляется параметром ядра '''profile='''

Подготовим к загрузке систему с профилем. Сейчас у нас загружается образ дистрибутива Simlpy: удалим все оверлеи, которые были созданы ранее
<code>
 [root@server ~]# rm -rf /srv/public/netinst/overlays-live*/*
</code>
и снова загрузим бездисковый клиент, который на этот раз должен загрузиться с беспарольным root и без всех наложенных нами ранее оверлеев. Убедившись, что клиент успешно загружается в первозданном виде, модифицируем vi /var/lib/tftpboot/pxelinux.cfg/default  с тем, чтобы на этот раз передать параметр загрузки, например '''profile=simply'''
<code>
 default live
 prompt 1
 timeout 100
 menu background back.jpg
 menu title BOOT
 implicit 1
 label harddisk
  menu label ^Boot from harddisk
  menu passwd P@sswd
  localboot 0x80
 label live
  menu label ^Diskless client
  menu default
  kernel syslinux/alt0/vmlinuz
  append initrd=syslinux/alt0/full.cz live profile=simply lowmem fastboot splash stagename=live quiet=1 showopts automatic=method:nfs,network:dhcp tz=Europe/Moscow  lang=ru_RU
 label memtest
  menu label ^Memory test
</code>
... и презагрузиться. И убедиться, что параметр ядра, который самому ядру не нужен (но нужен нам), действительно передаётся.

[[Файл:Masterclass-1-12.png]]

Заходим на Клиента с правами root, и берём с Сервера файл overlays-initial
 # scp admin@10.10.10.1:bin/ove*al .
 # DST=admin@10.10.10.1 sh overlays-initial

[[Файл:Masterclass-1-13.png]]

 # overlays-create initial

 server ~]# l /srv/public/netinst/overlays-live
 drwxrwxrwt 2 admin admin 4096 май 21 23:21 simply.pool/
 drwxrwxr-x 4 root  wheel 4096 май 21 23:21 ./
 drwxr-xr-x 2 admin admin 4096 май 21 23:21 simply/
 drwxrwxr-x 6 root  wheel 4096 май 14 20:40 ../
И проверим что получилось.

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

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

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

[[Категория:Мастер-классы]]
[[Категория:Centaurus]]