Alterator-manager (Иван Савин, OSSDEVCONF-2023)

Материал из 0x1.tv

Докладчик
Иван Савин

Доклад посвящён анализу текущего состояния разработки новой версии конфигуратора для операционных систем семейства «Альт», а также концептуальным особенностям и техническим возможностям его реализации на базе шины Dbus.

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

Видео

on youtube

Презентация

Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf Alterator-manager (Иван Савин, OSSDEVCONF-2023).pdf

Thesis

Alterator-manager — это сервис для управления операционной системой через D-Bus. Его функционал реализуется в модулях, а интерфейс описывается в специальных конфигурационных файлах.

Как работает alterator-manager

Alterator-manager может быть запущен в двух режимах — обычном и пользовательском:

$systemctl start alterator-manager.service

или

$systemctl --user start alterator-manager.service

В первом случае сервис запускается с полномочиями суперпользователя (root) и регистрирует имя (ru.basealt.alterator) на системной шине D-Bus. Во втором случае сервис запускается от обычного пользователя и регистрирует имя на сессионной шине D-Bus. После запуска происходит считывание конфигурационных файлов из /usr/share/alterator/backends/ и загрузка модулей из /usr/libexec/alterator/. Конфигурационные файлы — это glib-овские key-value файлы, они должны иметь расширение .backend для обычного режима работы и .user.backend для пользовательского. На их основе формируется интроспекция для D-Bus и правила polkit (только в обычном режиме).

Формат конфигурационных файлов

[Manager]
module_name = executor
node_name = example
interface_name = example
thread_limit = 5
[make_ls2]
execute = ls -al {param}
[make_ls3]
execute = ls -al {param}
[example]
execute = ls -al {param}
stdout_strings = enabled
stdout_bytes = enabled
stderr_strings = enabled
stdout_signal_name = stdout_signal_example
stderr_signal_name = stderr_signal_example
stdout_byte_limit = 200000
stdout_strings_limit = 200000
stderr_strings_limit = 200000
thread_limit = 3
action_id = method-name

Первая секция Manager обязательная, она имеет следующие пары ключ-значение:

  • module_name — имя модуля который будет обрабатывать запросы;
  • node_name — имя узла в поддереве D-Bus;
  • interface_name — имя интерфейса D-Bus;
  • thread_limit — максимальное число тредов для данного интерфейса.


К interface_name автоматически добавляется префикс

«ru.basealt.alterator.</tt»>. Имя интерфейса может содержать только <tt>[A-Z][a-z][0-9]_. Если оно состоит из нескольких секций, то они разделяются точкой. Пустые секции не допускаются. Из имени интерфейса формируется action_id (polkit) по умолчанию для методов интерфейса, для чего подчёркивания заменяются на тире.

Опция thread_limit не обязательна. Если её явно не задать, то её значение будет равно 10 (максимальное число методов, выполняемых одновременно).

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

В секции example приведены возможные опции метода для модуля executor. Поле execute — обязательное, остальные — нет. Поле execute содержит строку для bash с исполняемым файлом. Внутри фигурных скобок могут задаваться параметры для метода D-Bus. Параметров может не быть. Имя параметра может содержать только латинские буквы, цифры и символ подчёркивания. В примере выше метод make_ls2 будет выполнять команду ls -al с параметром param, в который можно будет передать имя директории или файла.

С помощью полей stdout_strings, stdout_bytes и

stderr_strings можно включить возможность возврата массива строк или массива байт из stdout и массива строк из stderr. Для этого полю нужно задать значение enabled. Если включён возврат массива байт, то возврат строк из stdout отключается (в том числе сигналами). Максимальный размер в байтах для соответствующего массива можно задать с помощью полей stdout_byte_limit, stdout_strings_limit и stderr_strings_limit. Значение по умолчанию — 524288. Допустимый диапазон — от 0 до 2147483647. Вывод из stdout и stderr можно также получать с помощью сигналов. Имя сигнала получается путём конкатенации sender'а и значения соответствующего поля (stdout_signal_name или stderr_signal_name). В sender'е «:</tt»> и «<tt>.</tt»> заменяются на «<tt>_».

Значения полей stdout_signal_name и stderr_signal_name могут содержать только латинские буквы, цифры и символ подчёркивания. Сигналы для stdout и stderr включены, если соответствующему полю задано значение. С помощью поля thread_limit можно задать ограничение на количество тредов для метода, т.е. сколько экземпляров этого метода можно запустить параллельно. Значение по умолчанию — 1. В поле action_id можно задать action_id polkit для метода. Поле может содержать только следующие символы [A-Z][a-z][0-9].-. К значению этого поля будет автоматически добавлен префикс сформированный из имени интерфейса.

Пример

Создадим example.backend:

[Manager]
module_name = executor
node_name = example
interface_name = example
[hexdump]
execute = hexdump -C {param}
stdout_strings = enabled
stdout_strings_limit = 7000000
thread_limit = 3

В этом примере мы получаем вывод (stdout) запускаемой команды массивом строк, но, как уже писалось выше, вывод мы можем получать и в виде массива байт.

Запустим наш сервис и посмотрим на дерево D-Bus.

Дерево D-Bus для ru.basealt.alterator

Объект /ru/basealt/alterator/example

Интерфейс ru.basealt.alterator.example

Метод hexdump возвращает массив строк из stdout.

Выполним метод hexdump.

Выполнение метода hexdump

Таким образом, можно сформировать backend для какого-либо приложения с API на D-Bus.


Alterator-manager (Иван Савин, OSSDEVCONF-2023)!.jpg

Примечания и ссылки