LINUX.ORG.RU

Создание загрузочных образов boobstrap v1.0

 


10

4

Хочу представить вашему вниманию фреймворк под названием boobstrap, написаный на POSIX shell, для создания загрузочных образов с дистрибутивами GNU/Linux. Фреймворк позволяет пройти весь пусть в три простых шага: от развёртывания системы в chroot, создания initramfs-образа включающего в себя систему из chroot, и в конечном счёте загрузочного ISO-образа. boobstrap включает в себя три утилиты mkbootstrap, mkinitramfs и mkbootisofs соответсвенно.

mkbootstrap устанавливает систему в отдельную директорию, имеется нативная поддержка CRUX, а в случае Arch Linux / Manjaro и дистрибутивов на основе Debian должны быть использованы сторонние утилиты pacstrap, basestrap и debootstrap соответственно.

mkinitramfs создаёт initramfs-образ, вы можете использовать установленную систему в директории как «оверлей», сжатый при помощи SquashFS, либо загрузившись в систему работать прямиком в tmpfs. Так например, команда mkinitramfs `mktemp -d` --overlay "arch-chroot/" --overlay "/home" --squashfs-xz --output initrd создаст initrd файл, включив в него два оверлея с «arch-chroot/» системой и вашим «/home», сжатых при помощи SquashFS, который далее вы можете загружать через PXE в tmpfs, либо создать загрузочный ISO образ с этим initrd.

mkbootisofs создаёт BIOS / UEFI загрузочный ISO-образ из указанной директории. В директорию достаточно положить /boot/vmlinuz и /boot/initrd.

boobstrap не использует busybox, а для создания рабочего окружения initramfs копируется минимальный набор программ с использованием ldd, необходимых для загрузки и переключения в систему. Список программ для копирования, как и всё остальное, можно настроить через файл конфигурации /etc/boobstrap/boobstrap.conf. Так же, вы можете установить любой минималистичный дистрибутив в отдельный chroot/, из которого далее создать уже полноценное initramfs окружение. В качестве такого минималистичного, но при этом полноценного окружения предлагается использовать шаблон «crux_gnulinux-embedded», который после xz занимает компромиссные 37мб. busybox же, кроме своего размера, 3-5мб против 30-50мб полноценного GNU/Linux окружения, никаких преимуществ более не предлагает, таким образом использование busybox в проекте не видится целесообразным.

Как быстро проверить работоспобность и начать работу? Установите и запустите.

# git clone https://github.com/sp00f1ng/boobstrap.git
# cd boobstrap
# make install
# boobstrap/tests/crux_gnulinux-download-and-build
# qemu-system-x86_64 -enable-kvm -m 1G -cdrom tmp.*/install.iso

Так же вам необходимо доустановить зависимости, а именно: cpio, grub, grub-efi, dosfstools, xorriso. Использование squashfs-tools не обязательно, вы можете работать в tmpfs при соответствующем объёме оперативной памяти. В случае, если в системе чего-то недостаёт, boobstrap об этом сообщит при запуске.

Для упрощения создания конфигураций boobstrap предлагает использовать «шаблоны» и «системы», суть которых заключается в том, чтобы использовать «шаблоны» (bootstrap-templates/) для быстрой установки систем из файла, а непосредственно «системы» (bootstrap-systems/) использовать для настройки конечных конфигураций.

Так например, запуск скрипта boobstrap/bootstrap-templates/crux_gnulinux-embedded.bbuild установит минимальную конфигурацию системы CRUX GNU/Linux и сохранит её в файле crux_gnulinux-embedded.rootfs, далее вы запускаете boobstrap/bootstrap-systems/default/crux_gnulinux.bbuild который загрузит первичную конфигурацию из упомянутого файла, выполнит всю необходимую настройку и подготовит загрузочный ISO. Это удобно, когда например, множество систем используют однотипную конфигурацию: чтобы каждый раз не описывать одинаковый набор пакетов, вы используете один шаблон, на основе которого уже и создаёте загрузочные образы систем с конечной конфигурацией.

Где всё это использовать?

Вы настраиваете систему в файле один раз и запуском оного выполняете её сборку и/или обновление. Система работает в tmpfs, что делает её одноразовой, по-сути. В случае выхода системы из строя, вы одним нажатием кнопки Reset возвращаетесь в исходное состояние. Вы можете спокойно выполнить rm -rf /.

Вы можете настраивать конфигурации всех ваших систем локально, создавать образы, тестировать их в виртуальной машине или отдельном «железе», далее загружать их на удалённый сервер и запуском всего двух команд kexec -l /vmlinuz --initrd=/initrd && kexec -e обновлять всю систему целиком, перезагружая её в tmpfs.

Аналогичным образом вы можете перевести все системы, например на VDS, на работу в tmpfs, а диск /dev/vda зашифровать и использовать только под данные, без необходимости держать операционную систему на ней. Единственной «точкой утечки информации» в таком случае станет только «холодный дамп» памяти вашей виртуальной машины, а в случае компрометации системы (например, подбором пароля ssh или уязвимости в exim), вы можете загрузить новый ISO через «панель управления» вашего провайдера, чтобы вновь вернуть VDS в строй, не забыв при этом, отредактировать конфигурацию системы закрыв все уязвимости. Это быстрее, чем переустановка, последующая настройка и/или восстановление из бэкапа, ведь по-сути, загружаемый ISO с вашей системой это и есть ваш бэкап. «Семь бед — один Reset.»

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

Ваши пожелания, предложения и замечания приветствуются.

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

>>> Получить исходный код

★★★★★

Проверено: Pinkbyte ()

Ответ на: комментарий от ValdikSS

теперь могу ответить на вопрос чем оно лучше.

mkbootstrap: ничем. «за уши» можно притянуть поддержку CRUX, ко всем этим остальным бутстраперам. всё остальное тоже самое, мульти-архитектурность это заслуга бутстраперов и самих дистрибутивов. не mkosi.

mkinitramfs: большая гибкость в выборе того, что будет загружено. это может быть initrd сам по себе маленький, может быть отдельная система как initrd, может быть initrd с системой внутри который подгружает систему отдельными «слоями» (директориями) которые вы укажете при создании образа, пожатые squashfs или ещё как-то («как-то» надо ещё сделать :)).

initrd это cpio-архив маленький by-design, а если его ещё пожать xz... я не пробовал через PXE загружать целую файловую систему gpt_ext4, но думаю это плохая мысль. в данном случае ответ очевиден, только голый initrd можно грузить через PXE, и чем меньше, тем лучше. и уже загрузившись в initrd, с нормальными драйверами сетевой карточки, с нормальным TCP/IP условно говоря, — ДОгружать полноценную ОС по сети. а не всё одним файлом. короче невероятно огромный простор для творчества предлагаю я. в отличии от dracut.

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

mkbootisofs: как вы сами ответили, умеет в ISO, в отличии от.

и ещё плюсик сверху поставьте: написано на POSIX shell, а значит не требует лишних движений для запуска.

а ещё отдельным плюсиком поставьте, поддержка от меня :D

Spoofing ★★★★★ ()

Пусть я не интересуюсь другими дистрибутивами и настройками системы. Т.е. пусть у меня одна система и 2 компа: локалхост (который для пользования и девелопмента), и сервер (ну или ещё, бывает беру флэшку и загружаюсь где-то ещё, но редко). Есть плюсы по сравнению с fsprotect?

mkbootstrap : ну это очень индивидуально. Я вот всё заскриптовал: добавление юзеров, установка пакетов, доустановка само-пред-откомпиленного софта, копирование/редактирование тучи всяких мелких конфиг-файликов повсюду (это главное, пожалуй — море ручной работы), и т.д, и т.п.

mkinitramfs : с fsprotect не надо ничего знать про initrd, всё делается автоматом.

mkbootisofs : это ж разовые действия, скопи-пастить при создании образа системы (=при мажорных обновлениях системы). Пара груб-команд на 10 секунд «1 раз в жизни».

«7 бед 1 ресет» есть, с rm -rf /.

Админю локалхост, серверов нет (выше — я на перспективу писал), но вроде «а диск /dev/vda зашифровать» — тоже без проблем.

kexec ... я не пользуюсь, но как я понял, оно ведь универсально, не зависит от ваших скриптов?

Виртуалки гоняю, очень удобно — именно из-за read-only root, они все грузятся с одной флэшки, и все одинаковые (только в rc.local по-разному кое-что настраивается на виртуалках и реальном железе)

Обновления образа флэшки — из чрута, как обычную систему.

Есть плюсы по сравнению с fsprotect?

PS. Отдельно-лежащие изменённые файлы тоже конечно есть (в /fsprotect/tmp/). Так сохраняюсь по davfs «в облака» (для этого тоже скриптики есть).

the1 ()
Последнее исправление: the1 (всего исправлений: 1)
Ответ на: комментарий от the1

Есть плюсы по сравнению с fsprotect?

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

А вот другие, например, [Как перенести сервер на CentOS 7 с Virtuozzo VPS в Kronos Cloud?] ещё не подозревают: «что? так можно было?»

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

Spoofing ★★★★★ ()
Ответ на: комментарий от Pinkbyte

сервак … в squashfs в составе initrd.

Я немного не в теме серверов. По поводу squashfs: эту идею, read-only root, можно рассматривать как «рекомендации лучших собаководов»? Т.е. можно ли резонно предполагать что read-only-root не даст (сильно затруднит) взломщику измененить сам read-only образ?

the1 ()
Ответ на: комментарий от Spoofing

Тут выше два товарища тоже отписались, каждый нахваливает своё. Ну удачи вам. =)

Ну только не своё наверно, а выбранное из имеющеегося? И не нахваливает, а спрашивает вроде.

Ок, понятно, спасибо. Не, я бы посмотрел конечно. Просто правда не увидел для себя плюсов. Дай думаю спрошу.

А у вас главный плюс — это много дистров и настроек. Может кому это и надо. Я просто не увлекаюсь этим. Стар, ленив.

the1 ()
Последнее исправление: the1 (всего исправлений: 2)
Ответ на: комментарий от the1

не даст (сильно затруднит) взломщику измененить

нет, не даст. ты находишься в initramfs, в котором лежит squashfs, монтируешь squashfs в /newroot, делаешь switch_root и назад дороги в initramfs у тебя нет, более того, switch_root удаляет всё, что находилось в initramfs и ты, как и взломщик, остался 1 на 1 с read-only squashfs примонтированным образом.

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

…и ты, как и взломщик, остался 1 на 1 с read-only squashfs примонтированным образом

Не понял, не пользовался squashfs… Но на всякий случай: пусть я взломал сервер, получил рута, вижу девайсы всякие, типа /dev/sda. Я что, не смогу никак подмонтировать read-write этот «read-only» образ? (ну ясно, что получится хрень, file system - memory cache inconsistency, надо будет как-то быстро ребутить этот горящий танк, но не об этом речь). Или тупо командой dd, никак не смогу ничего записать в /dev/sda?

the1 ()
Ответ на: комментарий от the1

ну собственно у меня там read only root - не самоцель, самоцелью было грузиться с флешки сразу в оперативку не насилуя последнюю логами и временными файлами

А в целом - если использовать правильные политики(например GrSecurity позволял по окончании загрузки системы запретить монтирование и загрузку сторонних модулей ядра) - то да. Можно ли проделать подобное на мэйнстримном SELinux(ибо GrSecurity теперь только за деньги) - без понятия, но скорее да, чем нет.

Просто read only root без запрещения доступа к устройству, откуда он собственно читается повышает безопасность примерно никак, если тебя уже рутанули.

Pinkbyte ★★★★★ ()

BUMP 1.1-rc2

Программа обновилась! Пока это только релиз-кандидат.

Добавлена поддержка busybox.

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

Разницы никакой, но мне был нужен легковесный udev, который есть в busybox: mdev. Тащить целый udev через lddtree я посчитал, что даже для меня это будет слишком. Поэтому busybox.

Теперь система может работать из ISO образа!

Благодаря тому, что появился busybox mdev и теперь создаются /dev-устройства, стало возможным найти системные образы (далее «оверлеи») на других накопителях и работать с ними.

Таким образом, если вы планируете загружаться через PXE, то упаковывайте все оверлеи в initrd образ. Здесь ничего не изменилось.

Если вы планируете использовать ISO, то соответственно указывайте оверлеи при создании ISO. В таком случае для загрузки системы с ISO образа наличие busybox является обязательным.

Благодаря этому мероприятию initrd больше не будет съедать всю оперативную память при использовании системы.

Пример использования нового mkbootisofs, который теперь мало чем отличается от mkinitramfs.

# mkbootisofs ./iso/ --overlay filesystem/ --overlay config/ --squashfs-xz > bootable.iso

Все созданные оверлеи складываются в директорию ./iso/system.

Добавлена утилита mkoverlayfs

Все оверлеи теперь создаются через утилиту mkoverlayfs, формат следующий

mkoverlayfs directory/ --format <format> --output <image>

Где <image> имя файла, куда будет сохранён созданный оверлей.

Где <format> может быть directory, cpio, squashfs и squashfs xz.

directory — формат, при котором директория будет полностью скопирована на носитель. Не рекомендуется для ISO и использовать с осторожностью для INITRD. В случае использования директории потребуется много памяти для загрузки оверлея, умножайте расход памяти на два.

cpio — формат, при котором директория будет сохранена одним архивом. Можно использовать и для ISO, и для INITRD, однако следует учитывать, что при распаковке архива может потребоваться очень много памяти, умножайте расход памяти на два.

Добавлена поддержка новых форматов оверлеев

Теперь оверлей это не только архив из директории, вы так же можете самостоятельно положить настоящую файловую систему в виде файла-образа (дампа) и загрузиться в неё!

Перед тем, как создавать ISO образ, вы можете самостоятельно положить образ файловой системы в директорию system/ будущего образа, и если mount сможет её смонтировать, то такая файловая система будет использована как оверлей!

Рассмотрим простой пример: сделать уже имеющуюся систему загрузочной с диска.

Другой вариант: загрузить систему или перенести систему с хостинга А на хостинг Б и хостинг Ц, а ещё развернуть в своей виртуалке, пожалуйста.

Я предлагаю самое «тупое» решение напролом: снять дамп файловой системы, используя утилиту dd. После чего вы кладёте образ в будущий ISO и затем создаёте его.

# mkinitramfs `mktemp -d` > initrd
# mkdir -p ./iso/boot
# mkdir -p ./iso/system
# mv initrd ./iso/boot/initrd
# mv vmlinuz ./iso/boot/vmlinuz

Далее мы копируем файловую систему с использованием dd if=/dev/sda1 of=filesystem.raw.ext4 и сохряем её в виде файла.

И копируем образ с файловой системой в будущий ISO.

# cp filesystem.raw.ext4 ./iso/system

После чего создаём ISO.

# mkbootisofs ./iso/ > bootable.iso

Теперь загрузившись с bootable.iso на любом устройстве вы загрузитесь прямиком в дамп файловой системы, которую вы сделали!

Вы можете самостоятельно складывать в директорию system/ любые форматы «оверлеев», на текущий момент поддерживаются: директории, cpio архивы, squashfs образы, и образы файловых систем, о которых знает mount. Все они будут смонтированы и загружены как одна цельная система!

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

... преимущество, boobstrap создаёт initrd используя окружение хост-системы...

... отдать initrd через PXE для загрузки...

Это не будет работать, если архитектура бездисковых рабочих станций будет отличаться от архитектуры «хост-системы».

qwe ★★ ()
Ответ на: комментарий от qwe

а такое часто бывает? а какие архитектуры могут использоваться на серверах? а когда серверов, условных «нод», много?

куда мне копать? в сторону кросс-компиляции?

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

а такое часто бывает?..

Не знаю насколько часто. Рынок завален дешёвыми тонкими клиентами на arm. Там, как правило, уже прошита операционка и RDP клиент, могут грузиться с SD карт, иногда с USB flash. Но PXE загузка - тоже интересный вариант. PXE -> BOOTC/DHCP -> TFTP -> kernel+initrd -> mount NFS root -> и т.д.

куда мне копать? в сторону кросс-компиляции?

Насколько я понял, Ваша цель просто собрать минимальный загрузочный образ. Естественно, уже должно быть что-то, что можно грузить и где-то валяться, допустим в виде каталога с копией rootfs для нужной архитектуры (допустим, какой-нибудь armbian), но chroot туда сделать не получится и хостовый ldd работать не будет. Будет работать objdump -p app. В выхлопе в «Dynamic Section» покажет все нужные библиотеки. Библиотеки тоже могут линковаться с другими библиотеками... Ну, как-то так.

Нужность всего этого сомнительна. Всё это так, чисто умозрительно.

qwe ★★ ()
Последнее исправление: qwe (всего исправлений: 1)
Ответ на: комментарий от anonymous

Да, помнится, был случай, когда одну прогу из репозитария популярного дистрибутива вычистили из-за того, что кому-то в её названии сиськи померещились, или я что-то путаю?

hobbit ★★★★★ ()

Спасибо проекту FOSSHOST.ORG

Чуваки выделили мне сервер чтобы я там развивал свой проект! 4 ядра, 4 гига, 200гб своп.

http://dl.voglea.com/thank_you_fosshost.png

Ну, на самом деле своп это жёсткий диск, но зачем он мне? Используя свой же бубстрап развернул там систему в tmpfs, загрузившись в initrd через ipxe на системе Proxmox. ;)

Ништяк. Вот, как надо поддерживать проекты. =)

Spoofing ★★★★★ ()