Инженеры дата-центров часто сталкиваются с задачей первоначальной настройки серверов. Причем, чаще всего настраивать приходится не одну-две единицы оборудования, а несколько десятков или даже сотен. Каждый раз, когда к нам приезжает новое оборудование мы должны его не только досконально проверить перед сдачей в эксплуатацию, но еще и соответствующим образом настроить для работы с нашими внутренними системами.
Перед тем как приступить к достаточно тривиальной процедуре настройки 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 eth0
static 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 0
MENU TITLE Raspberry Pi PXE Server
MENU BACKGROUND bg.png
LABEL bootlocal
menu label Boot from HDD
kernel chain.c32
append hd0 0
timeout 0
TEXT HELP
Boot from first HDD in your system
ENDTEXT
LABEL grml
menu label GRML Linux
KERNEL grml/boot/grml32full/vmlinuz
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
LABEL reboot
menu label Reboot
kernel reboot.c32
TEXT HELP
Reboot server
ENDTEXT
Здесь наверное стоит немного остановиться и разобраться что делает каждая строка:
- 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 755 /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.
edo1h
всё отлично, только зачем тут raspberry? берём любой сервер, настраиваем на нём dhcp/tftp/…, пробрасываем на этот сервер vlan с сегментом, где у нас эти настраиваемые сервера и… всё.
бонус: после настройки ничего даже переподключать не придётся
Darksa Автор
Правильно. Вот только если коммутаторы пока что еще не настроены — настраивать VLAN бесполезно. Raspberry Pi хороша своей мобильностью и тем, что ее достаточно настроить всего лишь один раз. Образ MicroSD-карты можно сохранить и потом это сэкономит много времени.
Я столкнулся с таким, когда потребовалось настроить несколько десятков серверов в помещении, где еще нет сетевой инфраструктуры, но уже есть электропитание. Чем тянуть временный патчкорд до помещения, гораздо проще было взять предварительно настроенную «малинку», любой неуправлямый свитч на нужное число портов и пачку патчкордов. Настроив вызов перешивальщика и автозагрузку скриптом можно быстро воткнуть все серверы в свитч, подать на них питание, включить туда же малинку и через 10 минут приходить проверять, что все операции выполнены. И точно так же быстро всю эту конструкцию разобрать.
easyman
Если у Вас уже есть серверы воткнутые в свич, зачем Вам маломощная малинка?
Один сервер можно загрузить с флешки и дальше раздавать все сервисы уже с него. Разве это не быстрее?
Можно и KVM и docker и ещё много чего приплести...
edo1h
мне кажется этот аргумент высосанным из пальца.
не лучше ли таки сделать сеть и спокойно всё настраивать, сидя в своем любимом кресле, чем ютиться с ноутбуком в шумной и холодной серверной? вам же потребуются монитор и клавиатура, так что без ноутбука никак.
btw, если у нас есть ноутбук — никто не мешает на нём поднять виртуалку со всем требуемым, если уж так хочется автономности.
Darksa Автор
Окей. А теперь представьте на минуту, что вы системный инженер ЦОД. Ноутбук вы таскаете с собой по разным серверным постоянно. Вы не можете его бросить даже на 10-15 минут, потому что там тикеты, задачи, мониторинг и так далее. Брать еще один ноутбук ради этого? Малинку я воткнул и оставил, пока она там все свои дела автономно не завершит. Сеть сделать и сидеть удаленно все тыкать хорошо, когда у вас уже на всех серверах IPMI настроен, а соответствующий сетевой VLAN завернут куда вам надо. А если это новое железо и новая серверная, то у вас этого не будет и провозитесь вы вместо 20-30 минут в общей сложности несколько часов. Тут основной плюс — скорость и возможность быстро все организовать.
edo1h
увы, нет. задачи как раз интерактивные, помимо rpi вам потребуется ещё какой-то монитор с клавиатурой.
а что мешает настраивать управляющий VLAN и IPMI сидя в уютном кресле?
ИМХО у вас организационные проблемы.
не стоит мешать в одну кучу «голову» и «руки».
если бы я организовывал «настоящий» ЦОД, то я бы поступил так:
инженер на месте («руки») получил задачу: установить сервер в стойку такую-то, юнит такой-то, сетевые кабели подключить в порты такие-то ToR свитча.
установил, скоммутировал, сфотографировал табличку с маком и паролем bmc, отписался в задаче, приложил фотографии — всё.
остальное делает другой инженер («голова») на своём рабочем месте.
Darksa Автор
Сама перепрошивка — это просто запуск BAT-файла, который сам все сделает и выдаст по итогу надпись о том, что питание можно отключать. Никакого интерактива там нет.
Внимательно прочитайте мой предыдущий комментарий. Если сетевой инфраструктуры еще не подключено, то каким образом вы собрались там что-то настраивать?
Это в идеальном мире. А в реальном мире задачи порой ставятся такие, которые надо выполнять используя лишь то, что есть под рукой и с минимальными временными затратами.
elve
Видимо в качестве носимого карманного варианта. Я одно время таскал для похожих целей малинку + mikrotik hap. Оба цепляются с повербанку и можно положить в ящике коммутационном, а самому спуститься и по wi-fi ковырять свитч. И не надо висеть на лестнице с ноутбуком и консольным кабелем.
numb
Насколько помню, у микротиков напряжение питания 12-52 вольта. Как подружили с повербанком?
Или у этой модели 5 вольт?
elve
Там мало того что 5 вольт, но и разъем microUSB
Есть несколько разных таких моделей. Вот пример:
mikrotik.ru/katalog/katalog/hardware/wifi_routers/wireless_soho/RB941-2nD
yuklimov
Вдруг будет полезно. Есть повербанки с USB PD с напряжением до 12 или даже до 20В (надо смотреть спецификацию повербанка на максимальные напряжения и токи). И китайские переходники с USB-C на нужный разъем питания с нужным напряжением.