Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein <klark.devel@gmail.com>]

On 10/8/24 16:43, Антон Мидюков wrote:
> Доброго времени суток
>
> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.
>
> По результатам обсуждения я сформулировал следующие тезисы:
>
> 1. Графический интерфейс инсталлятора представляет собой конфигуратор, который создаёт сценарий автоустановки (kickstart-файл)

Типа такого: 
http://www.rhd.ru/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/ch-redhat-config-kickstart.html 
?

Видимо когда-то у нас почти так и задумывалось, но получилось совсем не 
так. Нужна ли совместимость с форматом kickstart? RedHat и на ней 
основанным -- понятно, почему нужна. Формат устаревший, они его тянут по 
нужде, а не от хорошей жизни. Он не подходит как универсальный формат 
для конфигураций при повторных развёртываниях. Достаточно глянуть схему 
описания сложного разбиения дисков. Сейчас для целей массового 
серверного деплоя чаще используют Yaml, реже Toml.

При этом kickstart уже известен и хорошо понятен рынку, только в этом 
его плюс при полной совместимости, которая, скорее всего, недостижима. 
Чтобы не быть голословным, сравните покрытое этой фичей: 
https://github.com/osboot/make-initrd/tree/master/features/kickstart с 
тем, что предлагает офдок RedHad по Kickstart. А без полной 
совместимости ремейк этого старья 20-летней давности теряет смысл.

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

Вот концептуальные вопросы по этому разделу:

1.1. Нас устраивает текущий guile формат для файлов ответов? Если нет, 
тогда какой формат и почему?

1.2. Мы хотим возможность заранее сконфигурировать будущую установку без 
инсталлятора в GUI, т.е. отдельную программу в установленной системе, 
создающую файл ответов? Например, как часть будущего конфигуратора.

1.3. Как не повторить ошибок, из-за которых модули установщика и разных 
фронтэндов конфигуратора нельзя использовать во всех окружениях? Другими 
словами: насколько вообще нужно делать часть конфигуратора 
интегрированной в установщик? Может, пусть установщик разворачивает, а 
конфигуратор конфигурирует?

1.4. Разве вебовский UI/UX сейчас не приоритетней? Его давно не проблема 
встраивать в толстые приложения. И хотя этот подпункт скорее про 
конфигуратор, учитывая 1.2 и 1.3, вопрос звучит так: нам интересней 
ограничиться фронтэндом на guile, в т.ч. и дальше заниматься его 
поддержкой, или же интересней использовать простой декларативный язык 
UI/UX или даже готовую рисовалку интерфейсов на декларативном языке?


> 2. Сценарий автоустановки состоит из секций конфигураций, соответствующих бекенду. Если бекенд не доступен, секция конфига пропускается

Поскольку тут одни неизвестные, я это пока не буду комментировать.


> 3. Один и тот же сценарий автоустановки может использоваться для установки и запуска настройки первого запуска,

Возможно тут есть противоречие с п.7, зависит от того, насколько 
"необязательно". Но главное, конечно, это что настройка первого запуска 
-- другое приложение, выполняющееся в другом окружении уже установленной 
ОС. Если это то же приложение (Installer 2.0), то запускаемое в 
окружении установленной ОС с ключом --firsttime, при котором просто 
жёстко пропускается часть шагов. И это лучше, чем как сейчас дублировать 
код в разных пакетах.

На мой взгляд, важно для всего иметь разумный дефолт. Чтобы его можно 
было поменять в интерактиве, при желании, но без острой необходимости 
проходить какие-то "шаги".


> так как в инсталляторе и установленной системе разный набор бекендов (в установленной системе точно нет модуля разбивки диска).

И поэтому для форматирования флешек используется rosa-imagewriter, для 
работы с имеющимися разделами -- gnome-disk-utility, и т.д. Как раз к 
вопросу 1.3.


> 4. После того, как выполнена конфигурация и нажата кнопка установить (при настройке первого запуска - это Применить), происходит автоустановка. В графическом режиме процесс автоустановки визуализируется отдельным шагом "Установка", а в режиме автоустановки графический интерфейс не запускается и процесс визуализируется текстовыми сообщениями о выполненных операциях.
>
> 5. Установка разделена на две части: собственно установка и настройка при первом запуске.
>
> 5.1 Настройки установки
>
> [...]
>
> 5.2 Настройки первого запуска
>
> [...]
>
> 6. Настройка первого запуска является опциональной
>
> 7. Настройки из пунктов 5.1.1-5.1.7 *необязательно* выполнять при установке, если будет выполняться настройка первого запуска
>
> 8. Настройки выполняются параллельно
>
> 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.
>
> Предлагаю для начала определиться корректны изложенные тезисы или нет.
>

-- 
WBR, Leonid Krivoshein.