[devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/14/24 22:57, Evgeny Sinelnikov wrote:
> Доброй ночи,
>
> хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы 
> ориентироваться на конструктивные предложения. Архитектурных решений 
> не так много, на самом деле. Архитектурных решений реализуемых в 
> разумные сроки еще меньше.
>

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


>
> 14.10.2024 11:17, Sergey V Turchin пишет:
>> On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote:
>>
>> [...]
>>>> От
>>>> механизма, в котором нет, по сути, определенных интерфейсов, к
>>>> механизму, где их можно задавать, фиксировать, контролировать доступ
>>>> на уровне каждого отдельного метода и получать возможность написания
>>>> фронтендов, не требующих выполнения под рутом.
>>> При этом установить ОС можно только под рутом. И тогда непонятно, зачем
>>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения.
>> Если помните, текущий aterator умееет и пользовательские 
>> настройки(реально
>> какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас
>> востребовано.
>>
>> [...]
>
> Удивительное дело. Давайте не будем путать. Общая тенденция создания 
> безопасных систем приводит к очень сложным в сопровождении решениям, 
> вроде SELinux. Проблема в том, что приложения под рутом невозможно 
> проконтролировать иначе. Любое приложение под рутом может всё. И 
> остаётся только доверять коду и надеяться на то, что этого кода будет 
> немного и в нем не будет критических уязвимостей.
>
> Текущий Альтератор построен на концепции общего набора механизмов 
> конфигуратора, как в инсталляторе, так и в установленной системе. 
> Недоработка текущей реализации в этом плане привела к тому, что 
> графический интерфейс мы вынуждены запускать под рутом. И это, я 
> полагаю, напрямую связано с тем, что кем-то тоже было сказано или 
> подумано нечто подобное:
>
> "При этом установить ОС можно только под рутом. И тогда непонятно, зачем
> нужны все эти интерфейсы, разделение прав и тому подобные усложнения."
>

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


> То есть упор был на инсталлятор, а конфигуратор остался как есть. А 
> концепт, одних и тех же модулей сохранился.
>
> Сейчас мы идём от обратного. Сначала конфигуратор, а потом 
> инсталлятор. Хоть под рутом, хоть не под рутом. С другой стороны, а в 
> чём, собственно, переусложнение?
>
> Один из вариантов запуска нашего текущего инсталлятора - это запуск 
> его, как приложения, в обычном livecd. В большинстве дистрибутивов оно 
> так и работает. В графическом виде. При этом консольного (не 
> графического) инсталятора у нас так пока и не было сделано.
>
> А, если нам нужен графический инсталлятор, то графику, в любом случае, 
> не стоит запускать под рутом.

Да.

Конфигуратор я бы рассматривал как веб-интерфейс, работающий не под 
root'ом, и не обязательно на том же хосте. Как фоновый агент, через 
который можно менять настройки системы, будучи администратором сети, у 
которого есть полномочия, а не только как локальный root. И одной из 
обязанностей этого фонового агента может быть периодическое обновление 
куска дерева конфигурации с какого-то условного контроллера домена.

Часть настроек может быть изначально в ведении обычного пользователя. В 
идеале иметь возможность как делегировать пользователям полномочия 
менять конкретные системные настройки, так и наоборот, забирать у 
обычного пользователя полномочия менять изначально пользовательские 
настройки. Всё это разделение прав решается в пределах одной программы 
конфигуратора без SELinux, Polkit и интроспекции dbus. Как вариант, в 
пределах иерархической БД конфигурации. К слову, в виндовом реестре, 
помимо древовидных "кустов" предусматривалась раздача ACL на целый "куст".


> ____________________
>
> Итого, по теме под рутом, не под рутом. Если будет графика, то не 
> понимаю что мы обсуждаем. Чем нам графика под рутом жизнь облегчит? 
> Тем, что shell-скрипты можно будет писать не только на bash, но и на C 
> или Python? На я имею в виду fork/exec консольных приложений.
>
> На текущий момент имеется dbus - не вижу ничего противоестественного 
> использовать его в инсталляторе.

Давно стоило акцентироваться, что dbus, прежде всего -- IPC, а зачем 
нужен IPC в инсталляторе? Это точно кажется противоестественным. И в 
конфигураторе-то он может быть нужен далеко не в каждом модуле.


> Кстати, как альтернативу, с недавних пор systemd рассматривает - 
> https://varlink.org/
>
> Systemd Looking At A Future With More Varlink & Less D-Bus For IPC
> https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future
>

Просто, по нужде люди работают много лет с этим dbus и понимают, что 
организовать взаимодействие можно намного проще. Причём там, где оно 
действительно нужно. Например, когда мы связываем фронт с бэком в UI/UX, 
JSON & Ко уместнее dbus, особенно, если мы выходим за пределы хоста, 
чего хотелось бы. Если конфигуратор -- одна программа, если наш тулкит 
уже позаботился о взаимодействии фронт и бэк частей модуля, нам даже не 
надо об этом думать и остаётся только решить, в каких случаях уместно 
использовать кем-то написанное с использованием dbus, чтобы подтянуть и 
этот дополнительный функционал.


> В выше приведенной статье указаны многие проблемы, с которыми 
> сталкиваются в systemd. Они там хорошо структурированы и технически 
> обоснованы. Возможно, нам тоже стоит к этому присмотреться к systemd 
> версии 257.
>
> И это, как раз, то, что предлагалось в рамках всех разумных 
> альтернатив для dbus. Но... ресурсов спроектировать всё на новом стеке 
> прямо сейчас пока не наблюдается.
>
> Предлагаю об этом подумать сразу после написания новых модулей. И, 
> главное, интерфейсов для них. В смысле бекендов. Сделать к ним 
> интерфейсы на varlink'е будет не сложно. И проблема необходимости dbus 
> перестанет быть.
>

-- 
WBR, Leonid Krivoshein.