Использование spt в народном хозяйстве
Возможности
spt позволяет (должен позволять):
Базовые действия
- Создавать развернутые образы системы ALT Linux и ее частей с использованием hasher / separator, распаковывая пакеты и выполняя из них install scripts.
- Запаковать развернутый образ одним из способов, тем самым создав некую файловую систему, ISO-образ и т.п.
- Добавить тот или иной загрузчик к образу
«Рецепты» создания более сложных вещей
- Live CD? = развернутый образ + скрипты, исправляющие загрузку с readonly root и remount unionfs (механизм remounttab) + загрузчик + сворачивание в ISO.
- Инсталляционный диск = развернутый образ мини-системы с инсталлятором + скрипты, исправляющие загрузку этой мини-системы и автоматический запуск инсталлятора + свернуть это все в squashfs + добавление на диск пакетов + загрузчик + сворачивание в ISO.
- Инсталляционный диск «как Ubuntu» = Live CD? + внутрь ставится пакет с инсталлятором.
- Образ ovz / чего-то подобного = развернутый образ со специальным набором пакетов + скрипты (в основном – всевозможные эмуляции симлинками частей «живой» системы типа proc/ или /etc/mtab).
- Тонкий клиент для загрузки по сети = развернутый образ + загрузка с remounttab + загрузчик + некоторые части загрузчика подготавливаются для раскладывания в другие места, в частности, ядро и init на tftp-сервер.
Рабочая директория
Все свои действия spt производит в рабочей директории (далее work_dir)), которая содержит:
- profile – директория с профилем?, более-менее совместимая с профилем Separator.
- aptbox – aptbox hasher, место, в котором работает apt, куда копируется его конфигурация из сборочной системы и в дальнейшем apt использует /etc и /var из этого aptbox.
- cache – кэш инсталлированных / скаченных пакетов hasher; по большому счету – здесь не нужен.
- repo – дополнительные репозитарии hasher, подключаются автоматически, туда можно положить какие-то пакеты, которые нужно будет инсталлировать в систему, но их нет в основных репозитариях, на которые настроены apt sources list.
- chroot – место, где будет строиться реальный root распаковываемой системы.
- out – место, куда будет положен результирующий продукт(ы) – как правило, это сжатые образы.
- tmp – временная директория.
Текущий механизм работы spt
1. Необходимо создать рабочую директорию и создать в ней профиль (=скопировать эталонный). Реализуется запуском “spt -P profilename work_dir”, что приводит к тому, что профиль создается, после чего spt выходит. Кроме profile/ в рабочей директории на этом этапе ничего не создается.
2. Проводится создание образа в out/ и tmp/. Для каждой из компонент выполняется:
2.1. Распаковка пакетов
2.2. Выполнение их install scripts
2.3. Копирование дополнительных файлов, указанных в компоненте (всевозможных README и т.п.)
3. Выполняются post install scripts из профиля:
3.1. Class-скрипты
3.2. Собственно скрипты из профиля
4. Упаковка образа в squashfs + запуск соответствующих class-скриптов после упаковки.
5. Загрузчик (сейчас только syslinux / isolinux):
5.1. Загрузчик
5.2. Ядро + модули
5.3. Memtest
5.4. Boot logo
5.5. MAR-архив для propagator
5.6. Initramfs
6. Упаковка того, что получилось еще раз в ISO
Идея, предложения и пожелания к spt
- Убрать понятие CLASS, зафиксировать те понятия, что нам нужны и терминологию
- Дописать необходимые способы упаковки образа (ext2, другие fs)
- Выстроить систему базовых модулей-действий и «рецептов», которые являлись бы последовательностью вызовов этих модулей-действий, как описано в рецептах в п. «Возможности». Все это должно быть либо на виду и гибко поддаваться настройке (для разработчиков), либо совершенно скрыто от пользователя, т.е. работа по принципу – одна команда и готовый результат (1 директория или 1 файл) – максимум умолчаний, полное сокрытие наличие вообще такого понятия как рабочая директория с кучей поддиректорий (repo, tmp, profile...) в ней и т.п. (для обычных пользователей, собирающих что-то spt по одному из эталонных «рецептов»).
- Все возможные опции собрать в одном месте, сделать возможность передачи их в ровно таком же синтаксисе (как временный override) через командную строку.
- Сильно разбить на составные части установку загрузчика: добавить возможность установки LILO или сетевого загрузчика, настройка всех шагов п. 5.
- (?) Сделать установку по возможности как можно более кроссовой: сделать возможным сборку x86_64 образа на системе с 32-битным ядром: побороть apt/hasher в части распаковки пакетов (п. 2.1), сделать возможность кроссового запуска init scripts. Объявить курс на кросс-платформенность init scripts, со временем добавить соответствующие проверки в incoming (для initscripts должно быть не важно, с помощью утилит какой платформы они выполняются).
- *Потенциальные проблемы:** ldconfig => не принципиально, можно сделать либо отложенный ldconfig, выполняющийся уже в target-системе, либо кроссовый ldconfig(?); depmod => не выполняется DURING_INSTALL; перезапуск сервисов => не должен выполняться при инсталляции.
- Возможность разбиения и раскладки файлов по дискам.
- Usability. Убрать нелогичность в работе системы. Убрать п. 1 – пользователь либо сам в состоянии создать/скопировать/изменить профиль, который ему нужен, либо он просто выбирает один из эталонных в /usr/share, он копируется и тут же начинается делопроизводство.
- (?) Глобальный рефакторинг профилей как таковых.
Специфика работы spt, существующие проблемы
- spt на данный момент не работает внутри vserver, т.к. где-то(?) выполняются вызовы mknod.
- Невозможно собрать i586 образ на x86_64-системе, т.к. используется mksquashfs, скопированный из хост-системы.
Ссылки по теме, литература