Глава 6. Персональные сборки с PXE загрузкой

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

Вам понадобится предустановленными с предпочитаемым вами дистрибутивом Linux один сервер (или виртуальная машина) - в своих примерах мы будем применять Ubuntu Server 18.04 LTS. Другой сервер (или виртуальная машина) должен быть чистым, либо готовым к повторной установке.

Все примеры обсуждаемого в данной главе кода доступны в GitHub

Ещё до широкого внедрения виртуализации и облачных платформ требовалось создание стандартизованной сборки операционных систем на физических серверах без необходимости посещения центров обработки данных и вставки носителей установки в том или ином виде. Загрузка PXE была создана как одно из распространённых решений данного требования, а её название происходит от Pre-eXecution Environment (среды предварительного исполнения, представляйте себе её как минимальную операционную систему), которая загружается для того чтобы могла пройти установка операционной системы. {Прим. пер.: существует и иной метод, применяющий встраиваемый в материнские платы контроллер BMC (Baseboard Management Controller) посредством интерфейса IPMI (Intelligent Platform Management Interface) подробнее: Установка ОС через iBMC, а также RESTful API RedFish.}

Когда мы обсуждаем PXE сборку некого определённого сервера на самом верхнем уровне, происходит следующий процесс:

Хотя всё это звучит достаточно сложно, на практике это достаточно просто при разбивке далее на некий пошаговый процесс. По мере того как мы продолжим данную главу, мы пройдём весь этот процесс построения некого загрузочного сервера PXE, который способен выполнять загрузку без сопровождения (unattended) как для сервера CentOS 7, так и для сервера Ubuntu 18.04. Это послужит в качестве хорошего практического примера, а также покажет как мы можем составлять свои сценарии процессов сборки даже для физического оборудования, для которого тот процесс имеющихся шаблонов ВМ, который мы обсуждали в своей последней главе не является легко доступным.

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

Как и в случае практически любой установки Linux, её точный способ определяется от того дистрибутива Linux, для которого вы осуществляете данную установку, а также от тех пакетов программного обеспечения, которые вы намерены применять. Здесь мы собираемся воспользоваться сервером DHCP ISC, почтенным демоном TFTP и nginx. Тем не менее, вы также можете применять dnsmasq и Apache.

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

Для данной настройки мы намерены предполагать что у нас имеется некая изолированная сетевая среда. Наш сервер PXE будет иметь IP адрес 192.168.201.1, а его сетевой маской будет 255.255.255.0. Эти детали будут важны при установке нашего сервера DHCP. Давайте пройдём процесс установки вашего сервера для поддержки загрузки PXE:

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

Хотя они и доступны для большинства дистрибутивов Linux (и Ubuntu 18.04 не является исключением), обычно эти пакеты достаточно старые (самый последний стабильный выпуск PXELINUX произведён в 2014) и я столкнулся с известными ошибками, особенно при работе с оборудованием UEFI. Хотя и приветствуются попытки с более новыми моментальными снимками, автор этих строк получил наибольший успех с выпуском, помечаемым как 6.04-pre2, а потому мы поясним как собирать именно его и копируем эти файлы в правильное место своего сервера TFTP следующим образом:

Когда данная сборка завершена, наш окончательный этап состоит в копировании полученных файлов в их правильные расположения. Возвращаясь к нашей более ранней конфигурации сервера DHCP, мы помним что нам требуется отделять те файлы, которые относятся к загрузкам Наследуемого BIOS от выпусков для более новых загрузок UEFI. Здесь мы по шагам пройдём необходимый процесс установки вашего сервера как для сетевых загрузок BIOS, так и для загрузок UEFI:

По завершению этих шагов мы теперь имеем законченный сервер PXE в рабочем виде. Пока ещё мы не выгрузили никаких образов операционных систем, поэтому наш процесс загрузки не продвинулся слишком далеко, однако если вы бы исполнили некую проверку в данный момент, встроенное ПО вашего сервера должно выдать сообщение что оно получило некий IP адрес от DHCP сервера и должно представить вам некие связанные с загрузкой сообщения. Тем не менее, мы сделаем это слегка дальше, прежде чем углубляться в какие- то детальные проверки в данной книге, а в своём следующем разделе мы рассмотрим как получить образы для правильной сетевой установки для избранного дистрибутива Linux.

Следующим этапом нашего процесса установки загрузки PXE является сборка необходимого нам образа. К счастью, получение необходимых загружаемых образов достаточно простое - само ядро и пакеты обычно содержатся в DVD ISO образах выбранного вами дистрибутива Linux. Очевидно, они могут меняться от одного дистрибутива к другому, поэтому вам необходимо проверять их. В данной главе мы покажем примеры для серверов Ubuntu и CentOS 7 - эти же принципы можно применять для многих производных Debian, Fedora и Red Hat Enterprise Linux.

Давайте начнём со своего образа CentOS 7 следующим образом:

Это всё что требовалось сделать! После завершения данных шагов мы повторим данный процесс для своего загрузочного образа сервера Ubuntu 18.04, вот они:

$ wget http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.2-server-amd64.iso

$ mount -o loop ubuntu-18.04.2-server-amd64.iso /mnt

$ mkdir /var/lib/tftpboot/EFIx64/ubuntu1804

$ cp /mnt/install/netboot/ubuntu-installer/amd64/{linux,initrd.gz} /var/lib/tftpboot/EFIx64/ubuntu1804/

$ mkdir /var/www/html/ubuntu1804

$ cp -r /mnt/* /var/www/html/ubuntu1804/

$ umount /mnt
		

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

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

На данный момент мы настроили свой сервер с тем чтобы он выдавал нашим клиентам некие IP адреса при загрузке и даже собрали два дерева установки, так что мы способны устанавливать либо CentOS 7, либо сервер Ubuntu 18.04, причём без необходимости в каком- бы то ни было физическом носителе. Тем не менее, когда нашей целью является загружаемая через сеть машина, как ей дать понять что загружать?

Соответствующий ответ даёт установленная настройка PXELINUX. Она крайне схожа по природе с конфигурацией GRUB (GRand Unified Bootloader, {Прим. пер.: подробнее в нашем переводе Главы 16, Загрузка и запуск Linux из 1 тома Применения и Администрирования Linux Дэйвида Боза}), которую применяет большинство установок Linux чтобы определить их варианты и параметры при загрузке с диска. Применяя ту установку, которую мы собирали до сих пор, эти файлы настроек ожидается обнаружить в /var/lib/tftpboot/EFIx64/pxelinux.cfg (или в /var/lib/tftpboot/BIOS/pxelinux.cfg для машин с наследуемым BIOS).

Теперь пара слов по именованию файлов. Вы можете пожелать чтобы все загружаемые через сетевой интерфейс устройства выполняли сетевую загрузку. Тем не менее, рассмотрим некий сервер, в котором на его локальном диске имеется некая допустимая установка Linux, но по причине некой ошибки (возможно, неправильная настройка порядка загрузки в его встроенном ПО или отсутствие загрузчика), он загружается через свой сетевой интерфейс вместо своего локального диска. Когда у вас имеется полная, установка без сопровождения, настроенная для вашего сервера PXE, это может затереть ваши локальные диски с потенциально катастрофическими последствиями.

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

Тем не менее, если вы желаете быть более адресным, вместо этого вы можете создать некий файл настроек с соответствующим названием на основании требуемого MAC адреса. Допустим, у вас имеется некий сервер со значением MAC адреса DE:AD:BE:EF:01:23, а ваш DHCP сервер намерен назначит ему конкретный IP адрес 192.168.10.101/24 (скорее всего это будет выполняться через статическое соответствие DHCP с тем чтобы мы были способны обеспечивать постоянное получение этим сервером данного IP адреса). Когда данный сервер загружается сетевым образом через UEFI, он изначально будет искать /var/lib/tftpboot/EFIx64/pxelinux.cfg/01-de-ad-be-ef-01-23.

Если данный файл не представлен, он будет искать файл с названием в виде соответствующего шестнадцатерично кодированного IP адреса. Когда и он отсутствует, он будет отнимать за раз по одной цифре от шестнадцатеричного IP адреса пока не обнаружит соответствующий файл. Таким образом, наш сервер будет искать /var/lib/tftpboot/EFIx64/pxelinux.cfg/C0A80A65 {Прим. пер.: dec 192 = CO hex, dec 168 = A8 hex, dec 10 = OA hex, dec 101 = 65 hex}. Если он его не обнаруживает, он циклически повторяет поиск со всё более укороченными представлениями IP адресов пока у него не иссякнут варианты. Когда никакое подходящее название не будет найдено, он в конечном итоге вернётся в своему файлу default, а когда отсутствует и этот файл, соответствующему клиенту будет выдан отказ в загрузке.

Следовательно, полная последовательность поиска файлов настройки такова:

Основная идея сокращения имени файла по IP адресу состоит в том, чтобы сделать возможным создание некой настройки для подчинённой сети целиком - например, когда все машины в соответствующей подсети 192.168.10.0/24 требуют одной и той же конфигурации загрузки, вы можете создать некий единственный файл с названием /var/lib/tftpboot/EFIx64/pxelinux.cfg/C0A80A. Особое внимание обратите на вариант написания букв в названии файла - значение имени файла на основании MAC адреса требует букв в нижнем регистре, в то время как соответствующий IP адрес требует букв в верхнем регистре.

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

default isolinux/menu.c32
prompt 0
timeout 120

menu title --------- Enterprise Automation Boot Menu ---------
 	   

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

label 1
menu label ^1. Install CentOS 7.6 from local repo
kernel centos7/vmlinuz
append initrd=centos7/initrd.img method=http://192.168.201.1/centos7 devfs=nomount ip=dhcp inst.vnc inst.vncpassword=password

label 2
menu label ^2. Install Ubuntu Server 18.04 from local repo
kernel ubuntu1804/linux
append initrd=ubuntu1804/initrd.gz vga=normal locale=en_US.UTF-8 mirror/country=manual mirror/http/hostname=192.168.201.1 mirror/http/directory=/ubuntu1804 mirror/http/proxy="" live-installer/net-image=http://192.168.201.1/ubuntu1804/install/filesystem.squashfs
 	   

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

На самом деле это очень простой пример - здесь мы определили меню в простом текстовом режиме с двумя записями, по одной для каждой из своих операционных систем. Всякая запись меню обладает некой label (меткой), неким появляющимся в этом меню заголовком, а затем строками kernel и append. Значение строки kernel сообщает своему клиенту из какого источника берётся данное ядро в нашем сервере TFTP, а строка append применяется для задания значения пути к необходимому образу RAMDick и всем дополнительным параметрам загрузки.

Эти параметры загрузки, как вы можете видеть, значительно разнятся для различных дистрибутивов Linux, поскольку являются соответствующими возможностями их установщиков. К примеру, установщик CentOS 7 является графическим (хотя доступен и вариант текстового режима) и поддерживает некий сервер VNC, который мы настраиваем в своём первом элементе меню, позволяя некую удалённую установку при помощи консоли VNC с применением параметров inst.vnc и inst.vncpassword=password. Прочие применяемые параметры таковы:

Наш установщик Ubuntu, в противоположность этому, обычно запускается в текстовом режиме и потому не поддерживает какой- то сервер VNC, а потому для выполнения некой интерактивной установки будет требоваться иная технология удалённого доступа, такая как SOL (Serial-Over-LAN, последовательный доступ поверх локальной сети). Тем не менее, этот файл меню будет достаточным для нас чтобы выполнить интерактивную установку той из ОС, которую мы выберем и он преставлен в качестве некого шаблона для читателя чтобы тот мог собрать и разработать то что ему требуется. Применяемые параметры таковы:

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

Давайте взглянем на это в действии. После успешной сетевой загрузки тестовой машины нам должно быть представлено следующее заданное ранее меню:

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

Итак, в своём следующем разделе мы рассмотрим выполнение автоматизированной установки при помощи концепции сборок без сопровождения (Italic) - то есть построения там, где нет потребности вмешательства персонала в саму установку.

Окончательной целью данного процесса является наличие самостоятельных загрузки сервера через сеть и его окончательной настройки вместо того чтобы кому- то приходилось взаимодействовать с ним. Хотя он и не является процессом, контролируемым Ansible, это всё же ещё жизненно важный компонент в нашей архитектуре SOE (Standard Operating Environment, Стандартной среды обработки) для обеспечения согласованности сборок и того чтобы стандарты построения могли бы быть хорошо документированы, а версии подлежали контролю.

К счастью, и установщики CentOS (на основе Red Hat) и Ubuntu (на основе Debian) предоставляют имеющиеся возможности для установки без сопровождения, осуществляемые неким программируемым образом. Достойно сожаления что не существует общего стандарта для данного процесса и, как вы увидите в этом разделе, тот язык, который используется для этих процессов, целиком разнится для тех двух типов Linux, которые мы здесь обсуждаем. Тем не менее, выравнивая эти две технологии, мы предоставляем хорошую основу, которая позволит вам выполнять удалённую установку без сопровождения в широком разнообразии систем Linux.

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

Давайте начнём с рассмотрения в своём следующем разделе как выполнять сборки без сопровождения в основанных на Red Hat платформах, подобных CentOS при помощи файлов kickstart (запуска пинком).

Установщик Red Hat, Anaconda, применяет некий язык сценариев с названием kickstart (запуска пинком, ножным стартёром) для определения сборок без вмешательства персонала. Он хорошо документирован и существует множество доступных через Интернет примеров для вашей работы с ними - на самом деле, когда вы вручную устанавливаете такие производные Red Hat как CentOS, вы можете найти в /root/anaconda-ks.cfg некий файл kickstart, который можно применять для автоматизации ваших последующих сборок! далее мы создадим свой собственный образец файла kickstart на основании некой минимальной установки CentOS 7 из такого интерактивного установщика.

Обратите внимание, что clearpart --none на самом деле не чистит значения таблицы разделов - и когда вы исполните этот пример при помощи определённого тут файла kickstart, данная установка завершится успешно лишь если на её целевом диске достаточно пространства для установки CentOS 7. Чтобы заставить ваш файл kickstart очищать свой целевой диск и выполнять свежую установку CentOS 7 (что может быть желательным чтобы избежать необходимости вручную очищать старые машины перед повторным применением), внесите в свой файл kickstart следующие изменения:

Затем мы определяем свои пакеты для установки по умолчанию. Здесь мы устанавливаем группу пакетов core, набор системных пакетов minimal и необходимый пакет chrony. Для своего тестового сервера мы также отключаем kdump, как это отображается в приводимом далее блоке кода:

%packages
@^minimal
@core
chrony

%end

%addon com_redhat_kdump --disable --reserve-mb='auto'

%end
 	   

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

%anaconda
pwpolicy root --minlen=6 --minquality=1 --notstrict --nochanges --notempty
pwpolicy user --minlen=6 --minquality=1 --notstrict --nochanges --emptyok
pwpolicy luks --minlen=6 --minquality=1 --notstrict --nochanges --notempty
%end
 	   

Когда вам приходится собирать свой собственный законченный файл kickstart, это именно тот момент чтобы проверить полученный процесс загрузки. Помните ту настройку загрузки PXELINUX, которую мы применяли в самом последнем разделе? итак, настало время повторно воспользоваться ею почти целиком, за исключением того, что на этот раз нам требуется сообщить где обнаружить необходимый файл kickstart. Я сохранил только что созданный нами файл в /var/www/html/centos7-config/centos7unattended.cfg - таким образом он может быть выгружен с нашего сервера HTTP, в точности также как это было с пакетами для установки. На этот раз наша конфигурация PXELINUX выглядит так:

default isolinux/menu.c32
prompt 0
timeout 120

menu title --------- Enterprise Automation Boot Menu ---------

label 1
menu label ^1. Install CentOS 7.6 from local repo
kernel centos7/vmlinuz
append initrd=centos7/initrd.img method=http://192.168.201.1/centos7 devfs=nomount ip=dhcp inst.vnc inst.vncpassword=password inst.ks=http://192.168.201.1/centos7-config/centos7unattended.cfg
 	   

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

Действительно, когда вы подключитесь к соответствующей VNC консоли своей собираемой машины, изначально вещи кажутся теми же самыми - загружается графический установщик для CentOS 7, как это показано на снимке экрана внизу:

До сих пор всё выглядело как некая обычная интерактивная установка. Однако, раз наш установщик закончил с различными перечисленными задачами (например, Saving storage configuration... - Запоминание настроек хранения), вы заметите что вам будет представлен некий экран, который выглядит как завершённый, за исключением того, что кнопка Begin Installation (начать установку) недоступна (как это и показано на следующем снимке):

Обратите внимание на ещё одно отличие- источник установки теперь был установлен на тот сервер HTTP, который мы настроили для нашего процесса установки. Все прочие элементы обычно выполняются вручную, такие как выбор диска, были осуществлены автоматически при помощи настроек нашего сценария kickstart. На самом деле, если мы подождём чуть больше, в обнаружите что установка начинается автоматически без необходимости нажать на кнопку Begin Installation, как это показано на снимке экрана ниже:

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

Существует лишь два момента когда ожидается взаимодействие пользователя с установкой kickstart:

В последнем случае данная установка будет завершена, однако установщик будет ожидать нажатия на кнопку Reboot, как это отражено на снимке экрана внизу:

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

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

Проверьте это и посмотрите как данная сборка выполняется для вас. В случае каких бы то ни было проблем, установщик запускает несколько консолей в своём физическом сервере - вы можете переключаться между ними, применяя Alt + Tab или Alt + F>n>, где F>n> это одна из функциональных клавиш - каждая из первых шести соответствует отличающейся консоли, которые будут содержать полезные сведения о регистрации. Они могут применяться для запросов при отладке любых способных возникнуть проблем. необходимые инструкции на самом деле отображены в самом низу данной консоли текстового режима - в качестве примера рассмотрите следующий снимок экрана:

На нашем предыдущем снимке экрана вы можете видеть, что мы находимся в консоли 1, имеющей название main. Консоль 2 обладает shell для целей отладки, а консоли 3 и 5 отображают файлы log для данного конкретного процесса установки.

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

Это завершает наш процесс сборки некого сервера CentOS 7 через сеть при помощи файла kickstart. Аналогичный процесс высокого уровня может быть применён для Ubuntu и прочих производных Debian пр помощи файлов pre-seed (предварительного посева), которые мы изучим в своём следующем разделе.

В широком смысле, сборки сервера Ubuntu (и в конечном счёте прочих производных операционных систем Debian) функционирует в точности таким же образом. Мы определяем некий файл сценария, сообщающий своему установщику какие действия предпринимать вместо того чтобы вырианты выбирал оператор. Для сервера Ubuntu они носят названия файлов pre- seed (предварительного посева). Теперь давайте пройдёмся по одному из них и выполним сборку.

Файлы pre- seed очень мощны и кругом имеется очень много документации - тем не менее, они могут порой казаться более сложными для невооружённого взгляда. Начнём со следующих строк кода, которыми мы настраиваем надлежащие схемы локализации и клавиатуры для своего сервера:

d-i debian-installer/locale string en_GB
d-i console-setup/ask_detect boolean false
d-i keyboard-configuration/xkb-keymap select gb
 	   

Затем мы настраиваем следующие сетевые параметры:

d-i netcfg/choose_interface select auto
d-i netcfg/get_hostname string unassigned-hostname
d-i netcfg/get_domain string unassigned-domain
d-i netcfg/hostname string automatedubuntu
d-i netcfg/wireless_wep string
 	   

Здесь вы можете отметить что нам на самом деле не требуется знать значения названия интерфейса наперёд - вместо этого мы можем дать возможность Ubuntu догадаться о нём при помощи его алгоритма автоматического обнаружения. Мы устанавливаем значение имени хоста в automatedubuntu; тем не менее, обратите внимание что прочие параметры данной установки не являются истинно не сопровождаемыми. Затем мы добавляем некие подробности относительно того откуда наш установшик должен выгружать свои пакеты, что отображено в следующем блоке кода:

d-i mirror/country string manual
d-i mirror/http/hostname string 192.168.201.1
d-i mirror/http/directory string /ubuntu1804
d-i mirror/http/proxy string
 	   

Его следует отрегулировать под требования вашей сетевой среды, настройки сервера HTTP в вашем сервере PXE и тому подобному.

После этого мы устанавливаем пароль учётной записи root и некоторых дополнительных учётных записей пользователей следующим образом:

d-i passwd/root-password password password
d-i passwd/root-password-again password password
d-i passwd/user-fullname string Automation User
d-i passwd/username string automation
d-i passwd/user-password password insecure
d-i passwd/user-password-again password insecure
d-i user-setup/allow-password-weak boolean true
d-i user-setup/encrypt-home boolean false
 	   

Обратите внимание на то, что здесь я определил значения паролей открытым текстом чтобы выделить саму возможность осуществления этого прямо здесь - существуют альтернативные параметры, которыми вы способны то как будет приниматься хэш пароля, что намного более безопасно при создании файлов настройки. В данном случае значение пароля root устанавливается равным password, а также устанавливается учётная запись пользователя с именем automation со значением пароля insecure. Как и ранее, наша политика паролей достаточно слабая и может быть усилена здесь, либо позднее с применением Ansible. После этого мы настраиваем значение надлежащей временной зоны и включаем синхронизацию NTP следующим образом:

d-i clock-setup/utc boolean true
d-i time/zone string Etc/UTC
d-i clock-setup/ntp boolean true
 	   

Более сложный блок кода в нашем в противном случае слишком примитивном примере приводится ниже и он применяется для разбиения диска на разделы и его настройки:

d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto-lvm/guided_size string max
d-i partman-auto/choose_recipe select atomic
d-i partman/default_filesystem string ext4
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i partman-md/confirm boolean true
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
 	   

Хотя он и многословен, данный раздел нашего файла в основном сообщает об автоматическом разбиении устанавливаемого диска /dev/sda на разделы, настройки LVM, применения автоматических вычислений для определения разметки устанавливаемой файловой системы, а затем создания файловых систем ext4. Как вы можете видеть, существует множество мер безопасности и предупреждающих предложений на подтверждение, которые мы пометили фагом true, поскольку в противном случае нашему установщику приходилось бы останавливаться и дожидаться ввода пользователя для продолжения процесса. Если бы это произошло, наш установщик вновь бы был не истинным установщиком без сопровождения. В данном месте мы определяем тот набор пакетов, которые мы желаем установить:

tasksel tasksel/first multiselect standard
d-i pkgsel/include string openssh-server build-essential
d-i pkgsel/update-policy select none
 	   

Наши предыдущие строки кода в конечном счёте установят минимальную сборку сервера с пакетом openssh-server и пакетами build-essential поверх него. Автоматизация политики обновления настраивается на отсутствие автоматического обновления. Наконец, для завершения данного файла мы сообщаем ему куда устанавливать его начальный загрузчик и о необходимости выполнения перезагрузки после успешного завершения:

d-i grub-installer/only_debian boolean true
d-i grub-installer/with_other_os boolean true
d-i finish-install/reboot_in_progress note
 	   

Как и в случае нашего примера centOS, мы будем представлять для обслуживания данный файл из своего веб сервера, а следовательно, требуется отрегулировать настройки нашей загрузки PXELINUX чтобы обеспечить то, что мы присоединили данный файл - некий подходящий пример выглядит так:

default isolinux/menu.c32
prompt 0
timeout 120

menu title --------- Enterprise Automation Boot Menu ---------

label 1
menu label ^1. Install Ubuntu Server 18.04 from local repo
kernel ubuntu1804/linux
append initrd=ubuntu1804/initrd.gz url=http://192.168.201.1/ubuntu-config/ubuntu-unattended.txt vga=normal locale=en_US.UTF-8 console-setup/ask_detect=false console-setup/layoutcode=gb keyboard-configuration/layoutcode=gb mirror/country=manual mirror/http/hostname=192.168.201.1 mirror/http/directory=/ubuntu1804 mirror/http/proxy="" live-installer/net-image=http://192.168.201.1/ubuntu1804/install/filesystem.squashfs netcfg/get_hostname=unassigned-hostname
 	   

Обратим на следующие используемые тут новые возможности:

И снова, если вы проверите эту загрузку сервера из сети при помощи приводимой конфигурации, вы должны обнаружить, что необходимая сборка сервера выполнится полностью. В отличии от установки CentOS 7 вы не обнаружите никаких вариантов меню - они будут представлены лишь если ваш файл настройки pre- seed неверен или пропущены важные моменты. Вместо этого вы просто обнаружите некую мерцающую последовательность полос прохода по мере завершения различных стадий данной установки. например, приводимый ниже снимок экрана показывает как устанавливается ваша базовая операционная системка после настройки необходимых разделов и логических томов:

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

После того как эта завершающая полоса прохода окончит своё выполнение, ваш сервер перезагрузится и вам будет представлено приглашение регистрации из которого вы сможете войти в систему с теми учётными записями, которые определены в наших предыдущих параметрах файла pre-seed d-i passwd, показанных ранее. Обратите внимание, что если вы применяете в своей сборке иные учётные записи, вы должны применять именно их, а не те которые определены ранее.

На данном этапе вы должны быть способны выполнять сборку без сопровождения как в CentOS 7, так и для сервера Ubuntu через свою сетевую среду и осуществлять онсовные изменения, такие как выбор необходимых пакетов и настройку учётных записей. В своём следующем разделе мы рассмотрим методы дополнительной выполняемой на заказ индивидуализации помимо самой первоначальной ОС.

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

Тем не менее, что если ваше предприятие имеет некую задачу (или задачи), которые совершенно точно требуется выполнять на момент сборки - например, возможно для соответствия требованиям безопасности (которые мы изучим в Главе 13, Применение эталонного тестирования CIS)? К счастью обе рассмотренные нами здесь технологии предоставляют для этого некий вариант. Давайте вначале рассмотри как вы можете выполнять индивидуальные команды в установке без сопровождения kickstart.

Как уже обсуждалось ранее, для большинства выполняемых вами задач рекомендуется выполнять настройку после сборки при помощи Ansible. Тем не менее, давайте рассмотрим некий гипотетический пример - допустим, что по причинам безопасности вам требуется отключать регистрацию SSH root сразу после сборки данного сервера. В kickstart отсутствует какая бы то ни было директива, которая способна решать эту задачу и оставление данного сервера с такой включённой возможностью пока он не дождётся выполнения этого через Ansible может быть неприемлемым для команды безопасности предприятия, поскольку существует окно возможностей для потенциальной атаки. К счастью, в самом низу нашего файла kickstart мы можем поместить некий блок %post, в котором запускается любой помещённый в нём код оболочки. Тем самым мы имеем возможность запустить свою утилиту sed изнутри приводимого ниже блока кода:

%post --log=/root/ks.log

/bin/sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config

%end
 	   

Это очень простой блок кода, запускаемый после завершения выполнения процесса установки (но до перезагрузки) и регистрирующий свой вывод в файле в /root/ks.log вы можете настроить его индивидуально под свои потребности - тем не менее, здесь для простоты нашего примера мы выполняем действия поиска и замены установленной по умолчанию настройки демона SSH чтобы убедиться что даже при самой первой загрузки регистрация root через SSH будет отключена.

В своём следующем разделе мы рассмотрим как те же моменты достигаются в неком файле pre- seed Ubuntu.

Допустим, мы желаем выполнить точно такую же индивидуализацию в Ubuntu. Файлы pre- seed Ubuntu запускают команды отдельных строк вместо применяемых в kickstart блоков; тем самым, они лучше поддаются либо простым задачам, либо запуску сценария для более сложных действий. Мы могли бы встроить команду sed в свой файл pre- seed, добавив в самые его низ следующую строку:

d-i preseed/late_command string in-target /bin/sed -i 's/#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
 	   

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

d-i preseed/late_command string in-target wget -P /tmp/ http://192.168.201.1/ubuntu-config/run.sh; in-target chmod +x /tmp/run.sh; in-target sh -x /tmp/run.sh
 	   

Обратите внимание но та, что здесь мы применяем wget (который был установлен ранее в процессе сборки) для вгрузки файла с названием run.sh из пути /ubuntu-config/ в нашем веб сервере. Затем мы превращаем его в исполняемый и запускаем его. Таким образом способны запускаться намного более сложные последовательности команд в самом конце нашего процесса сборки, причём сразу до самой первой перезагрузки.

Таким образом, невероятно сложные, выполняемые на заказ сборки операционной системы могут устанавливаться удалённо через сеть, причём без какого бы то ни было вмешательства персонала. Применение файлов kickstart и pre- seed также означает данный процесс поддаётся записи в сценарии и повторному исполнению, что является именно тем важным принципом, которому мы и обязаны следовать.

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

В частности, вы получили опыт выполнения интерактивной среды установки Linux при помощи сетевой загрузки PXE. Далее вы изучили как полностью автоматизировать такой процесс сборки при помощи сценариев kickstart и pre- seed чтобы обеспечить что сборка полностью выполняется без вмешательства персонала (а следовательно автоматическая). Наконец, вы изучили как дальше персонализировать свою сборку, добавляя персональные сценарии для определения такой сборки.

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

Чтобы увидеть все доступные параметры файла pre- seed, пожалуйста, посетите https://help.ubuntu.com/lts/installation-guide/example-preseed.txt.

Для дополнительного изучения файлов kickstart (и работы с CentOS), пожалуйста, посетите https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-howto.

Чтобы просмотреть справочные сведения по синтаксису команд файла kickstart, пожалуйста, посетите https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-syntax#sect-kickstart-commands.