Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Evgeny Sinelnikov <sin@altlinux.org>]

Здравствуйте.

ср, 9 окт. 2024 г. в 03:29, Leonid Krivoshein <klark.devel@gmail.com>:
> On 10/8/24 16:43, Антон Мидюков wrote:
> > Доброго времени суток
> >
> > Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.
> >
> > По результатам обсуждения я сформулировал следующие тезисы:
> > [...]
>
> На мой взгляд, вот до этого пункта:
>
> > 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.
> >
> > Предлагаю для начала определиться корректны изложенные тезисы или нет.
>
> ...именно как тезисы -- нет, но перечисленное тоже можно обсудить. Нет,
> потому что начинать стоит с того: от чего, к чему и почему мы движемся,
> это даст определённые критерии оценки. А многое из перечисленного --
> детали повторной реализации того, что уже есть.

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

В том виде, как сейчас, затруднительно делать многое. Большую часть
того, к чему мы движемся осуществить невозможно без полной
переработки.

Технологически мы движемся:
1) от службы alteratord на базе woo-bus к службе alterator-manager на базе dbus.
2) от дублирования механизмов, встроенных в современные
GNU/Linux/Systemd системы к их расширению.

Например, очень странно только из-под-рута уметь запускать через
unix-socket shell-скрипт, который выполняет systemctl, который в свою
очередь обращается к dbus, вместо того, чтобы напрямую обращаться к
интерфейсу org.freedesktop.systemd1.Manager.

Чтобы увидеть перечень методов достаточно набрать и "потабать":
$ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1
org.freedesktop.systemd1.Manager

Впрочем "потабать" можно всё. Это называется интроспекция. В некоторых
случаях её скрывают, но это детали и особенности реализации.

Технологически мы движемся:
3) от не соответствующего потребностям автоустановки autoinstall.scm к
формату, который нужно определить, зафиксировать (специфицировать) и
реализовать "движок" инсталлятора с учётом возможностей бекендов -
доступных методов и интерфейсов на dbus.
4) мы движемся от отсутствия API для администрирования к его
оформлению для всех механизмов ОС, которым необходимо повышение
привилегий.

5) мы движемся от строгой технической необходимости реализовывать
фронтэнды вместе с бекендами к возможности (например, по аналогии с
NetworkManager) реализации множества фронтендов под соответствующие
среды исполнения (графические, консольные, любые). Например, с помощью
новых бекендов на базе alterator-manager можно расширять возможности
уже применяемого на практике cockpit (но, это при желании):
- https://cockpit-project.org/applications

6) мы движемся от сценария один, бекенд один фронтенд к сценариям:
+ один бекенд, множество разных реализаций фронтендов;
+ один фронтенд, множество разных бекендов, реализующих один и тот же
интерфейс на разных объектах шины dbus.

Оба сценария уже активно задействованы в существующих наработках.
Ключевые детали по текущим наработкам опубликованы у нас на wiki:
- https://www.altlinux.org/Alterator_на_D-Bus


___________________

На текущий момент важно ввести уровень абстракции инсталлятора, как
расширенного приложения исполняющего пошаговую "инструкцию",
использующую специфицированный формат. Выбором этого формата
необходимо заняться в первую очередь.

Один из вариантов взять вот этот для вдохновения и (может быть, совместимости):
- https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/
- https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/kickstart-commands-and-options-reference_rhel-installer
- https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html
- https://rhinstaller.github.io/anaconda-addon-development-guide/sect-anaconda-addon-architecture.html

И далее, постепенно, реализовать на его основе своё подмножество. Не
хотелось бы брать anaconda. Хотя... если делать эту часть на python,
то что-то форкнуть, урезать и переписать под себя - вариант.
Вообще, конечно, один в один оно достаточно тяжелое. Главное - формат:
Есть ли технический смысл брать kickstart за основу?

Мне кажется, что в этом формате, как минимум, проведён теханализ
потребностей инсталлятора. Хотя бы к ним стоит присмотреться.


___________________________

PS: Последней, требующей внимание особого внимания особенностью
реализации нового стека на dbus, которая ещё только предстоит,
является переход от пространства имён /ru/basealt/alterator к
пространству /org/altlinux/alterator (от ru.basealt.alterator к
org.altlinux.alterator).


-- 
Sin (Sinelnikov Evgeny)