Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/devel/spt ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Использование spt в народном хозяйстве


NOTE: spt как инструмент устаревает с каждым днём, поскольку его пользователи мигрируют на mkimage


NB: см. spt.txt в документации текущего пакета

Возможности


spt позволяет (должен позволять):

Базовые действия


  1. Создавать развернутые образы системы ALT Linux и ее частей с использованием hasher, распаковывая пакеты и выполняя из них install scripts.
  2. Запаковать развернутый образ одним из способов, тем самым создав некую файловую систему, ISO-образ и т.п.
  3. Добавить тот или иной загрузчик к образу (?)

«Рецепты» создания более сложных вещей


  1. LiveCD = развернутый образ + скрипты, исправляющие загрузку с readonly root и remount unionfs (механизм remounttab) + загрузчик + сворачивание в ISO.
  2. Инсталляционный диск = развернутый образ мини-системы с инсталлятором + скрипты, исправляющие загрузку этой мини-системы и автоматический запуск инсталлятора + свернуть это все в squashfs + добавление на диск пакетов + загрузчик + сворачивание в ISO.
  3. Инсталляционный диск «как Ubuntu» = LiveCD + внутрь ставится пакет с инсталлятором.
  4. Образ ovz / чего-то подобного = развернутый образ со специальным набором пакетов + скрипты (в основном – всевозможные эмуляции симлинками частей «живой» системы типа proc/ или /etc/mtab). lakostis: я не понимаю, зачем там что-то эмулировать, автор что-то не то имел в виду?
  5. Тонкий клиент для загрузки по сети = развернутый образ + загрузка с remounttab + загрузчик + некоторые части загрузчика подготавливаются для раскладывания в другие места, в частности, ядро и init на tftp-сервер. lakostis: назовем это read-only appliance. mike: см. ltsp-build-client из ltsp5-server

Рабочая директория


Все свои действия spt производит в рабочей директории (далее work_dir)), которая содержит:


Текущий механизм работы spt 


1. Необходимо создать рабочую директорию и создать в ней профиль (=скопировать эталонный). Реализуется запуском “spt -p profilename work_dir”, что приводит к тому, что профиль создается, после чего spt выходит. Кроме profile/ в рабочей директории на этом этапе ничего не создается. Либо можно просто руками скопировать нужный профиль из /usr/share/spt или /etc/spt/profiles в profile


2. Проводится создание образа в out/ и tmp/. Для каждой из компонент выполняется:


2.1. Распаковка пакетов
2.2. Выполнение их install scripts
2.3. Копирование дополнительных файлов, указанных в компоненте (всевозможных README и т.п.). Должна быть предусмотрена возможность отключения этого (--excludedocs).


3. Выполняются post install scripts из профиля:


3.1. Class-скрипты
3.2. Собственно скрипты из профиля


4. Упаковка образа в выбранный fstype + запуск соответствующих class-скриптов после упаковки.


5. Загрузчик (сейчас только syslinux / isolinux):


5.1. Загрузчик
5.2. Ядро + модули
5.3. Memtest (зачем это?)
5.4. Boot logo (зачем это?)
5.5. MAR-архив для propagator (спорно, проще запихать в initramfs ядро с модулями)
5.6. Initramfs


6. Упаковка того, что получилось еще раз в ISO

Идея, предложения и пожелания к spt


  1. Убрать понятие CLASS, зафиксировать те понятия, что нам нужны и терминологию
  2. Дописать необходимые способы упаковки образа (ext2, другие fs) – уже есть tar.bz/tar.bz2, в процессе cramfs.
  3. Выстроить систему базовых модулей-действий и «рецептов», которые являлись бы последовательностью вызовов этих модулей-действий, как описано в рецептах в п. «Возможности». Все это должно быть либо на виду и гибко поддаваться настройке (для разработчиков), либо совершенно скрыто от пользователя, т.е. работа по принципу – одна команда и готовый результат (1 директория или 1 файл) – максимум умолчаний, полное сокрытие наличие вообще такого понятия как рабочая директория с кучей поддиректорий (repo, tmp, profile...) в ней и т.п. (для обычных пользователей, собирающих что-то spt по одному из эталонных «рецептов»).
  4. Все возможные опции собрать в одном месте, сделать возможность передачи их в ровно таком же синтаксисе (как временный override) через командную строку.
  5. Сильно разбить на составные части установку загрузчика: добавить возможность установки LILO или сетевого загрузчика (что это такое?), настройка всех шагов п. 5.
  6. (?) Сделать установку по возможности как можно более кроссовой: сделать возможным сборку x86_64 образа на системе с 32-битным ядром: побороть apt/hasher в части распаковки пакетов (п. 2.1), сделать возможность кроссового запуска init scripts. Объявить курс на кросс-платформенность init scripts, со временем добавить соответствующие проверки в incoming (для initscripts должно быть не важно, с помощью утилит какой платформы они выполняются).
    • *Потенциальные проблемы:** ldconfig => не принципиально, можно сделать либо отложенный ldconfig, выполняющийся уже в target-системе, либо кроссовый ldconfig(?); перезапуск сервисов => не должен выполняться при инсталляции.
  7. Возможность разбиения и раскладки файлов по дискам (зачем это в spt?).
  8. Usability. Убрать нелогичность в работе системы. Убрать п. 1 – пользователь либо сам в состоянии создать/скопировать/изменить профиль, который ему нужен, либо он просто выбирает один из эталонных в /usr/share, он копируется и тут же начинается делопроизводство (это уже есть в текущем spt).
  9. (?) Глобальный рефакторинг профилей как таковых.

Специфика работы spt, существующие проблемы


Из переписки

<gvy> привет!
<gvy> можно вопросов по spt-profiles-desktop? (пытаюсь сварганить spt-profiles-ltsp5)
<boyarsh> Привет!
можно
<gvy> ура!
<gvy> есть скрипт, который делает ряд подготовительных действий (включая прописывание репозитория в конфиг) и запускает ltsp-build-client, который собирает мелкий чрут для отдачи терминалам по NFS в качестве корня
<gvy> вот думаю — имеет ли смысл пытаться втулить его на этапе установки и куда/как — install3?
<gvy> плюс малопонятно, что в каком порядке запускается — воткнул в install2/packages пакет ltsp5-server-light и в install2/hooks.d/0чегототам-ltsp — этот скриптик, он взорвался по причине отсутствия конфига, который идёт в том пакете
<gvy> почитал spt.txt — там про хуки и порядок ни слова
<gvy> => дай, думаю, спрошу тех, кто уже понял, и лучше на wiki оформлю :)
<boyarsh> я правильно понимаю, что ты хочешь чтоб при установке установщиком были выполнены те или иные дополнительные действия?
<boyarsh> если да, то стоит посмотреть на «распиленный» модульный установщик. Он уже используется Стасом в проекте HPC
<boyarsh> там есть кое-какие инфраструктурные нововведения
<boyarsh> но можно сделать и на основе десктопного
<boyarsh> скрипт savesettings.in выполняется после установки базовой системы
<gvy> мгм. хорошо, попробую (я просто надеялся обойтись хуками, чтоб ничего на первом этапе не клонить/патчить/потом_мержить_если_чего_исправит_апстрим)
<boyarsh> ну, сделай хук, который патчит этот скрипт
<gvy> собственно, мне надо поставить «обычный десктоп», только поднять некоторые сервисы и сгенерить чрут (что может занять минуту-две и на быстрой машинке, бишь хорошо бы как-то в продолжении общей инсталяции, чтоб уж всё сразу)
<gvy> спасибо!
<gvy> пойду заваривать зелёный чай покрепче и погружаться :-)
<boyarsh> в инфрасктруктурно новой версии, насколько я понял, сделано как раз так что можно добавлять свои «хуки установки» и прочее не делая своего бранча
<boyarsh> и ещё там есть progress bar в процессе выполнения savesettings

Ссылки по теме, литература



Страницы, ссылающиеся на данную: ALTLinux/Sisyphus/devel/mkimage
AltLinux/Features
AltLinux/Sisyphus/devel/ImageGeneratorsHistory
AltLinux/Sisyphus/devel/mkimage


 
Файлы [Скрыть файлы/форму]
Один комментарий. [Показать комментарии/форму]