Инженеры дата-центров часто сталкиваются с задачей первоначальной настройки серверов. Причем, чаще всего настраивать приходится не одну-две единицы оборудования, а несколько десятков или даже сотен. Каждый раз, когда к нам приезжает новое оборудование мы должны его не только досконально проверить перед сдачей в эксплуатацию, но еще и соответствующим образом настроить для работы с нашими внутренними системами.
Перед тем как приступить к достаточно тривиальной процедуре настройки BIOS и IPMI, мы должны убедиться в том, что каждый компонент сервера имеет требуемую версию прошивки. В большинстве случаев, за редким исключением, необходима актуальная версия, доступная на сайте производителя конкретных комплектующих. Сегодня мы расскажем, как мы придумали для ускорения процесса задействовать популярную нынче малинку.
В чем сложность
Казалось бы задачка весьма проста. Ну давайте возьмем какой-нибудь live-дистрибутив Linux, раскатаем его на флешку и будем с него загружаться и выполнять требуемые процедуры. Но не тут-то было.
Проблема в том, что у каждого вендора свои собственные методы и собственные утилиты для обновления прошивок. Причем, не все они способны корректно работать под Linux. Какие-то компоненты, например, BIOS у серверов SuperMicro желательно шить из-под MS-DOS. Для каких-то компонентов, например, сетевых карт Mellanox в некоторых случаях нужно использовать Windows, а некоторые поддерживают прошивку непосредственно из Linux.
Таким образом нам нужно будет либо собирать мультизагрузочный образ и записать его на несколько десятков флешек, затем долго и упорно загружаться с них, либо придумать нечто более интересное и быстрое. И вот здесь приходит на ум использование сетевых карт серверов с поддержкой загрузки по PXE (Preboot eXecution Environment, произносится как пикси).
Берем малинку, разворачиваем там DHCP- и TFTP-сервер, готовим требуемые образы для загрузки. Чтобы массово загрузить несколько десятков серверов просто временно задействуем неуправляемый гигабитный свитч на 48 портов и вуаля. По-умолчанию большинство серверов возможность загрузки с PXE предусматривают без дополнительной настройки, поэтому такой вариант идеален.
За основу я взял прекрасную статью от Romanenko_Eugene, но с поправками на особенности Raspberry Pi и решаемые задачи. Приступаем!
Малиновое варенье
Когда я первый раз проделывал такое самой продвинутой версией Raspberry Pi была третья с сетевой картой на 100 Мбит/с. Этого откровенно говоря мало для массовой раздачи тяжелых образов, так что настоятельно рекомендую использовать доступную ныне Raspberry Pi 4 с портом на 1 Гбит/с. Еще одна рекомендация по возможности использовать быструю и емкую карту памяти.
Теперь о первоначальной настройке. Графический интерфейс для такой штуки абсолютно не требуется, поэтому можно скачать самую простую Lite-версию операционной системы Raspberry Pi OS. Распаковываем образ и заливаем образ на MicroSD-карту любым удобным способом, например с помощью dd:
sudo dd if=<имя_образа> of=/dev/mmcblk0 bs=1M
В процессе настройки можно либо настраивать традиционным способом, подключив клавиатуру и монитор, либо через SSH. Чтобы при запуске SSH-сервис заработал, создаем пустой файл с именем ssh в разделе /boot.
Поскольку сетевой порт будет задействован для работы DHCP, то для доступа в интернет можно либо использовать подключение к Wi-Fi, либо подключить к малинке еще одну сетевую карту по USB. Вот такую, например:
Теперь запускаем Raspberry Pi, подключаем ее к интернету и обновляем репозитории и пакеты ПО:
sudo apt update
sudo apt upgrade
Поскольку я задействую еще одну сетевую карту, то встроенной надо задать статический IP-адрес. Открываем конфиг:
sudo nano /etc/dhcpcd.conf
Добавляем следующие строчки:
interface eth0static ip_address=192.168.50.1/24
Здесь eth0 встроенная сетевая карта Raspberry Pi. Именно с помощью нее будет осуществляться и раздача IP-адресов, и сетевая загрузка. Теперь устанавливаем tftp-сервер:
sudo apt install tftpd-hpa
После установки открываем конфигурационный файл:
sudo nano /etc/default/tftpd-hpa
Приводим строку к следующему виду:
TFTP_OPTIONS="--secure -l -v -r blksize"
В целом можно было бы и оставить все как есть, но тестировать каждый раз на отдельной машине иногда не слишком удобно. Опции -l -v -r blksize позволяют без проблем тестировать все это на виртуальной машине VirtualBox, исправляя некоторую проблему совместимости. Теперь устанавливаем DHCP-сервер для раздачи IP-адресов:
sudo apt install isc-dhcp-server
Открываем первый конфигурационный файл isc-dhcp-server:
sudo nano /etc/default/isc-dhcp-server
Явным образом указываем интерфейс, на котором предполагается работа DHCP-сервера:
INTERFACESv4="eth0"
Теперь открываем второй конфиг dhcpd.conf:
sudo nano /etc/dhcp/dhcpd.conf
Задаем необходимые параметры сервера, раздаваемую подсеть, а также передаем имя файла загрузчика:
default-lease-time 600;max-lease-time 7200;ddns-update-style none;authoritative;subnet 192.168.50.0 netmask 255.255.255.0 { range 192.168.50.2 192.168.50.250; option broadcast-address 192.168.50.255; option routers 192.168.50.1; filename "pxelinux.0";}
Сохраняем файл и теперь нам предстоит собственно скачать загрузчик, нужные модули и сформировать меню PXE. Начнем со скачивания набора загрузчиков Syslinux, в моем случае наиболее удобна версия 5.01:
wget https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/syslinux-5.01.zip
Распаковываем:
unzip syslinux-5.01.zip
Теперь нам надо найти и извлечь модуль memdisk, умеющий подгружать в ОЗУ ISO-образы целиком, загрузчик pxelinux.0 и остальные модули comboot. Последовательно выполняем команды, которые отыщут и скопируют все найденное в директорию /srv/tftp:
find ./ -name "memdisk" -type f|xargs -I {} sudo cp '{}' /srv/tftp/
find ./ -name "pxelinux.0"|xargs -I {} sudo cp '{}' /srv/tftp/
find ./ -name "*.c32"|xargs -I {} sudo cp '{}' /srv/tftp/
После этой операции нам нужно создать конфигурационный файл непосредственно для меню, отображаемого на экране PXE. Переходим в нашу директорию:
cd /srv/tftp
Создаем директорию с именем pxelinux.cfg и переходим в нее:
sudo mkdir pxelinux.cfg
cd pxelinux.cfg
Создаем конфигурационный файл:
sudo nano default
В качестве примера давайте возьмем отличный live-дистрибутив GRML и загрузим его через PXE. Ниже готовый пример конфигурации:
UI vesamenu.c32 PROMPT 0MENU TITLE Raspberry Pi PXE ServerMENU BACKGROUND bg.pngLABEL bootlocal menu label Boot from HDD kernel chain.c32 append hd0 0 timeout 0TEXT HELPBoot from first HDD in your systemENDTEXTLABEL grml menu label GRML LinuxKERNEL grml/boot/grml32full/vmlinuzAPPEND root=/dev/nfs rw nfsroot=192.168.50.1:/srv/tftp/grml/ live-media-path=/live/grml32-full boot=live lang=us nomce apm=power-off noprompt noeject initrd=grml/boot/grml32full/initrd.img vga=791LABEL reboot menu label Reboot kernel reboot.c32TEXT HELPReboot serverENDTEXT
Здесь наверное стоит немного остановиться и разобраться что делает каждая строка:
- UI vesamenu.c32 используем модуль vesamenu.c32 для вывода меню;
- PROMPT 0 подсвечиваем нулевой пункт меню;
- MENU TITLE Raspberry Pi PXE Server задаем общее название меню;
- MENU BACKGROUND bg.png элемент оформления, используем bg.png в качестве фонового изображения.
Фоновое изображение можно изготовить заранее. По-умолчанию подойдет картинка 640x480 с глубиной цвета не более 24 бит, в формате PNG или JPG. Ее надо заранее скопировать в /srv/tftp. Теперь разберем каждую секцию. Первая секция введена для удобства. Если надо загрузится с первого жесткого диска, то прописываем:
- LABEL bootlocal внутреннее имя секции;
- menu label Boot from HDD то, как будет отображено меню у пользователя;
- kernel chain.c32 используем модуль chain.c32, умеющий выполнять загрузку с различных носителей;
- append hd0 0 явным образом указываем, что загрузка должна быть с первого раздела первого жесткого диска;
- timeout 0 тут можно либо задать таймаут в секундах, по истечении которого будет автоматически запущена загрузка, либо указав 0 убрать таймер.
- TEXT HELP указываем начало текста подсказки для пользователя;
- Boot from first HDD in your system текст подсказки;
- ENDTEXT указываем конец текста подсказки.
Приблизительно таким же образом формируем и секцию для перезагрузки. Единственным отличием будет вызов модуля reboot.c32, который собственно и отправляет машину в ребут. Ну, а перед тем как разобрать что делает третья секция, загружающая дистрибутив GRML, поговорим о том, что собственно будет загружаться и каким образом.
Everything is a file
Сам ISO-образ доступен на сайте этого live-дистрибутива. Скачиваем его и переименовываем для удобства, в примере возьмем 32-битную версию:
wget https://download.grml.org/grml32-full_2020.06.iso
mv grml32-full_2020.06.iso grml.iso
Теперь надо этот образ каким-то образом заставить загружаться. С одной стороны можно применить модуль memdisk и заставить его вначале загрузить все сырое содержимое образа непосредственно в ОЗУ и потом передать управление загрузкой. Но этот метод хорош только для очень маленьких образов, например, так удобно загружать MS-DOS. Большие же образы долго загружаются в память и не всегда работают адекватно.
Поэтому следует все-таки распотрошить образ и на загрузку передать только ядро и livefs. А вот дальнейшие файлы с диска можно предоставлять системе по запросу с помощью NFS-сервера. Такой подход работает значительно быстрее и адекватнее, но требует дополнительных телодвижений, таких как установка NFS-сервера.
Выполняется элементарно:
sudo apt install nfs-kernel-server
Чтобы не устраивать кашу из файлов создаем отдельную директорию для grml:
sudo mkdir /srv/tftp/grml
Нам потребуется примонтировать ISO-образ, поэтому позаботимся о временной точке монтирования:
sudo mkdir /tmp/iso
Монтируем образ. Система предупредит, что образ смонтирован в Read-Only режиме:
sudo mount -o loop grml.iso /tmp/iso
Рекурсивно копируем содержимое образа в нашу отдельную директорию:
sudo cp -R /tmp/iso/* /srv/tftp/grml
Чтобы не возникало проблем с правами доступа, меняем владельца и рекурсивно присваиваем этой директории права из серии Дом свободный, живите кто хотите:
sudo chown -R nobody:nogroup /srv/tftp/grml/
sudo chmod -R 777 /srv/tftp/grml/
Теперь дело за малым указать NFS-серверу, что ему следует предоставлять директорию /srv/tftp/grml любому IP-адресу из нашей подсети:
sudo nano /etc/exports
Прописываем строчку:
/srv/tftp/grml 192.168.50.0/24(rw,sync,no_subtree_check)
Обновляем список и рестартуем NFS-сервер:
sudo exportfs -a
sudo systemctl restart nfs-kernel-server
Теперь у нас наконец-то появляется возможность корректно разделить процесс загрузки на два условных этапа. Первый этап загрузка ядра и live-filesystem. Второй этап подтягивание всех остальных файлов через NFS. Пришла пора посмотреть на оставшуюся секцию:
- LABEL grml имя секции;
- menu label GRML Linux отображение в меню;
- KERNEL grml/boot/grml32full/vmlinuz указываем путь до ядра, относительно корня /srv/tftp;
- APPEND root=/dev/nfs rw nfsroot=192.168.50.1:/srv/tftp/grml/ live-media-path=/live/grml32-full boot=live lang=us nomce apm=power-off noprompt noeject initrd=grml/boot/grml32full/initrd.img vga=791 тут мы говорим, что используем NFS, прописываем пути к условному корню, задаем некоторые дополнительные параметры, рекомендуемые в документации и указываем относительный путь до initrd.
Теперь остается только последовательно запустить TFTP и DHCP-сервер и можно пробовать выполнять загрузку в PXE. Если все сделано правильно, то вы увидите созданное меню:
Выбрав пункт GRML Linux нажимаем Enter и видим, что у нас происходит успешный процесс загрузки образа:
Таким образом мы получили возможность сетевой загрузки популярного среди системных администраторов дистрибутива GRML. Но что насчет того же самого MS-DOS и как можно самостоятельно подготовить образ для перепрошивки BIOS. Об этом поговорим дальше.
In DOS We Trust
Неужели в 21 веке все еще используется операционная система из 80-х годов прошлого тысячелетия. Каким бы странным это не казалось но для некоторых специфичных задач MS-DOS по прежнему актуальна и вполне себе находит применение. Одной из таких задач является обновления прошивки BIOS на серверах.
Возьмем для примера какую-нибудь материнскую плату, например, Supemicro X11SSL-F и скачаем обновление BIOS с официального сайта. Внутри видим приблизительно подобный набор файлов:
user@linux:~/Загрузки/X11SSLF0_B26> ls -lитого 16592-rw-r--r-- 1 user users 169120 фев 1 2015 AFUDOSU.SMC-rw-r--r-- 1 user users 5219 сен 20 2003 CHOICE.SMC-rw-r--r-- 1 user users 22092 апр 27 2014 FDT.smc-rw-r--r-- 1 user users 3799 дек 15 2016 FLASH.BAT-rw-r--r-- 1 user users 3739 мая 22 2019 Readme for UP X11 AMI BIOS.txt-rw-r--r-- 1 user users 16777216 ноя 25 23:48 X11SSLF0.B26
Видим, что у нас уже есть готовый BAT-файл, позволяющий прошить BIOS. Но для того, чтобы это сделать надо иметь уже загруженный в MS-DOS сервер. Сейчас покажем как именно это сделать.
Прежде всего нам надо подготовить небольшой raw-образ жесткого диска с операционной системой. Создаем новую виртуальную машину через Oracle VM VirtualBox с небольшим диском на 32 мегабайта. Формат выбираем QCOW, после всех манипуляций его можно будет легко сконвертировать в raw.
Наверняка вы все знаете где можно достать образы дискет с MS-DOS, так что монтируем их внутрь виртуальной машины и запускаем установку:
Дважды меняем образы дискет в виртуальном приводе и спустя буквально 20 секунд у нас есть qcow-образ со свеженькой ОС MS-DOS 6.22:
Самым простым способом теперь скопировать файлы на данный диск будет примонтировать его к любой другой виртуальной машине с Windows или Linux. После этой операции повторно монтируем диск к виртуальной машине с MS-DOS и проверяем, что файлы видны:
При желании можно даже настроить автозагрузку на выполнение BAT-файла, чтобы перепрошивка BIOS производилась автоматически. Но помните, что это потенциально опасная операция и делаете вы ее на свой страх и риск. Теперь выключаем виртуальную машину и переконвертируем ее в raw-образ с помощью qemu-img.
qemu-img convert -f qcow -O raw DOS.qcow dos.img
Полученный IMG-образ копируем в отдельную директорию нашего TFTP-сервера:
sudo mkdir /srv/tftp/dos
sudo cp dos.img /srv/tftp/dos
Теперь открываем конфигурацию /srv/tftp/pxelinux.cfg/default на редактирование и добавляем в меню еще один пункт:
LABEL DOS kernel memdisk initrd dos/dos.img append raw
Сохраняем конфигурацию и теперь у нас в PXE-меню появился новый пункт меню, выбрав который мы загружаем созданный образ:
Точно так же можно создавать образы, содержащие как служебные утилиты, так и забавы ради со старыми играми под DOS.
In Windows Veritas
Давайте теперь попробуем загрузить Live-образ c WinPE (Windows Preinstallation Environment). Загружать полноценный вариант часто просто не требуется, достаточно лишь ограниченного количества функций. Реальное применение эта штука находит при перепрошивке некоторых устройств.
Та же самая Mellanox, год назад поглощенная Nvidia, выпускает утилиту Mellanox Firmware Tools для перепрошивки своих сетевых карт в вариантах для WinPE различных версий. Разумеется сейчас доступны уже различные варианты MFT, но пару раз мы сталкивались именно с необходимостью шить через WinPE-версию.
Создание своего собственного образа WinPE и интеграция нужного ПО туда задача не слишком сложная, но ее объяснение выходит за рамки данной статьи. Чтобы детально освоить этот процесс можно посетить отличный ресурс winpe.ru. Мы же для примера возьмем какую-либо готовую сборку для демонстрации процесса запуска.
Часто такие сборки представляют собой либо iso-образы, либо rar-архивы с iso-образами. Перед тем как расковыривать такой образ нам нужно раздобыть соответствующий загрузчик.
wimboot достаточно простой загрузчик, умеющий выполнять загрузку образов в формате wim (Windows Imaging Format). Его можно использовать либо в связке с syslinux, либо с более продвинутым собратом, iPXE. Создаем отдельную директорию в /srv/tftp:
sudo mkdir wimboot
cd wimboot
Cкачиваем сам загрузчик:
wget https://github.com/ipxe/wimboot/releases/latest/download/wimboot
Теперь пришло время подмонтировать образ. Создадим временную директорию в /tmp:
sudo mkdir winpe
Переходим в каталог со скачанным ISO-образом сборки и выполняем:
sudo mount -o loop <имя_образа> /tmp/winpe
Создаем директорию в /srv/tftp, куда положим нужные нам файлы:
sudo mkdir /srv/tftp/winpe
Теперь ищем в сборке и копируем 4 файла:
sudo cp BOOTMGR /srv/tftp/winpe
sudo cp bcd /srv/tftp/winpe
sudo cp boot.sdi /srv/tftp/winpe
sudo cp boot.wim /srv/tftp/winpe
Дело за малым в конфигурационный файл /srv/tftp/pxelinux.cfg/default дописываем следующую секцию:
LABEL WinPE menu label WinPE com32 linux.c32 wimboot/wimboot append initrdfile=winpe/BOOTMGR,winpe/bcd,winpe/boot.sdi,winpe/boot.wim
Фактически мы при помощи модуля linux.c32 выполняем загрузку загрузчика
Важно учитывать, что подгрузка файлов происходит по TFTP, что не слишком быстро и удобно. В целом можно немного видоизменить конфигурацию и вытянуть их другим способом. Но для простых утилитарных задач и этого вполне достаточно.
Вместо заключения
В этой статье нет какого-либо ноу-хау, но когда возникла необходимость Raspberry Pi отлично справилась. Ей не потребовалось искать дополнительную розетку питания, прекрасно подошел USB-порт ближайшего свободного сервера. Нет дополнительных заморочек с поиском места в забитой под завязку железом стойке. Работает именно так как надо, а малые габариты позволяют всегда иметь ее под рукой.
В сети на самом деле есть множество мануалов по настройке сетевой загрузки. Проблема лишь в том, что для разных образов используются разные средства и различные подходы. Выбор правильного подхода иногда требует массы времени и я очень надеюсь, что этот материал поможет многим сэкономить время при решении различных задач, связанных с необходимостью быстрого развертывания PXE на одноплатном компьютере Raspberry Pi.
