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

[Evgeny Sinelnikov <sin@basealt.ru>]

Доброй ночи,

хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы 
ориентироваться на конструктивные предложения. Архитектурных решений не 
так много, на самом деле. Архитектурных решений реализуемых в разумные 
сроки еще меньше.


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

Удивительное дело. Давайте не будем путать. Общая тенденция создания 
безопасных систем приводит к очень сложным в сопровождении решениям, 
вроде SELinux. Проблема в том, что приложения под рутом невозможно 
проконтролировать иначе. Любое приложение под рутом может всё. И 
остаётся только доверять коду и надеяться на то, что этого кода будет 
немного и в нем не будет критических уязвимостей.

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

"При этом установить ОС можно только под рутом. И тогда непонятно, зачем
нужны все эти интерфейсы, разделение прав и тому подобные усложнения."

То есть упор был на инсталлятор, а конфигуратор остался как есть. А 
концепт, одних и тех же модулей сохранился.

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

Один из вариантов запуска нашего текущего инсталлятора - это запуск его, 
как приложения, в обычном livecd. В большинстве дистрибутивов оно так и 
работает. В графическом виде. При этом консольного (не графического) 
инсталятора у нас так пока и не было сделано.

А, если нам нужен графический инсталлятор, то графику, в любом случае, 
не стоит запускать под рутом.

____________________

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

На текущий момент имеется dbus - не вижу ничего противоестественного 
использовать его в инсталляторе. Кстати, как альтернативу, с недавних 
пор 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

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

И это, как раз, то, что предлагалось в рамках всех разумных альтернатив 
для dbus. Но... ресурсов спроектировать всё на новом стеке прямо сейчас 
пока не наблюдается.

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


-- 
Синельников Евгений Александрович
Руководитель обособленного подразделения
«Инженерный отдел «Саратовский» ООО "Базальт СПО"
тел. +7 (495) 123-47-99 (доб. 531)
моб. тел. +7-917-207-53-96