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

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

On 10/9/24 05:13, Evgeny Sinelnikov wrote:
> Здравствуйте.
>
> ср, 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 системы к их расширению.

Наш установщик давно перешёл на systemd? У нас все установочные образы 
на systemd? Чего нам в установщике нужно от systemd, дёргая его 
исключительно через dbus?


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

Команда systemctl на шеле -- одна строка. Мы готовы обучать детей и 
внуков механизму работы с dbus на Си, вместо того, чтобы сделать их 
счастливыми? :-)


> Чтобы увидеть перечень методов достаточно набрать и "потабать":
> $ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1
> org.freedesktop.systemd1.Manager
>
> Впрочем "потабать" можно всё. Это называется интроспекция. В некоторых
> случаях её скрывают, но это детали и особенности реализации.

Горячо поддерживаю интроспекцию, наследование, полиморфизм и повторную 
реализацию. :-) Но не думаю, что первое необходимо для всего и вся в 
установщике.


> Технологически мы движемся:
> 3) от не соответствующего потребностям автоустановки autoinstall.scm к
> формату, который нужно определить, зафиксировать (специфицировать) и

Да.


> реализовать "движок" инсталлятора с учётом возможностей бекендов -
> доступных методов и интерфейсов на dbus.

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


> 4) мы движемся от отсутствия API для администрирования к его
> оформлению для всех механизмов ОС, которым необходимо повышение
> привилегий.

Существуют и другие способы, не требующие манипулировать API.


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

+ https://pub.dev/ -- сюда же.

Если использование описанного через dbus -- цель полезная, просто ради 
переиспользования множества уже готовых наработок, то усложнять ещё и 
умножением бекендов и фронтендов -- напротив, цель сомнительная. У нас 
два фронтенда уже в полном рассинхроне, хотя цели нынешнего альтератора 
декларировались те же.

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

Почитал это и смежное про Alterator-manager, что дополнило мой немного 
критический взгляд. У нас не все дистрибутивы завязаны на 
dconf/gsettings. Не все установщики работают с systemd. Наработки по 
групповым политикам, компетенция по работе с dbus не пропадут даром. 
Делать же это концептуальным стержнем я бы точно не стал.

В копилку плюсов dbus&Co: 
https://events.canonical.com/event/2/contributions/48/attachments/34/49/Flutter%20on%20Linux.pdf 
, стр. 7. И даже установщик там это использует (Ubuntu Desktop 
Installer). Но стоит учесть, что это одна вполне конкретная среда, у нас 
же решения разные.


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

Мне кажется, сначала нужно решить, будет ли установщик связан с 
конфигуратором или нет. Если будет, то каким форматом данных будет 
манипулировать конфигуратор? Мы для установщика определяем конфигурацию 
решения, установщик её натягивает на устанавливаемое. А конфигуратором 
мы раскидываем её по 100500 машин домена.


> Один из вариантов взять вот этот для вдохновения и (может быть, совместимости):
> - 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).

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


-- 
WBR, Leonid Krivoshein.