Опыт разработки нового Альтератора (Михаил Чернигин, OSSDEVCONF-2024)
Материал из 0x1.tv
- Докладчик
- Михаил Чернигин
Доклад посвящён текущему состоянию разработки нового Альтератора — конфигуратора операционных систем «Альт».
Будут рассмотрены новые возможности и подходы разработки подсистем Альтератора, которые позволяют вести разработку на различных языках программирования с различными графическими и консольными фреймворками.
Содержание
Видео
Презентация
Thesis
Зачем мы разрабатываем новый Альтератор?
Альтератор — это инсталятор и конфигуратор операционных систем «Альт». Первоначальная его реализация предполагает возможность написания модулей на языке Scheme для фронтендов и на языке Bash для бэкендов. В этой реализации возникали следующие проблемы:
- отсутствие API модулей для приложений;
- Scheme с Qt значительно усложняет написание фронтендов;
- запуск в графическом интерфейсе доступен только по паролю root.
Целями создания нового Альтератора являются:
- спецификация интерфейсов бэкендов для создания фронтендов в различных графических и консольных приложениях;
- обеспечение свободы в выборе технологий для реализации фронтендов и бекэндов;
- предоставление разработчикам фреймфорка для создания собственных приложений;
- обобщение механизмов, используемых как для локального, так и удалённого конфигурирования системы.
Как это работает?
В основе нового Альтератора лежит служба alterator-manager, которая и занимается управлением всеми объектами на шине DBus.
Cоздание новой подсистемы Альтератора состоит из двух частей.
- Реализация бэкенда, предоставляющего свой интерфейс на DBus в объекте /ru/basealt/alterator.
- Реализация фронтенда, то есть пользовательского приложения, которое использует этот интерфейс на DBus.
Бэкенды
Модули Альтератора создают интерфейсы на DBus. В том числе модуль executor упрощает этот процесс, путём использования .backend файлов. Executor парсит эти файлы и генерирует по ним соответствующие интерфейсы на DBus. Например, рассмотрим инструмент диагностики сети:
[Alterator Entry]
Type = Backend
Module = executor
Name = diag_network
Interface = diag1
[Info]
execute = cat /usr/share/alterator/diag/diag-network.diag
stdout_bytes = enabled
action_id = Info
[Run]
execute = diag-network {test}
stdout_signal_name = diag1_stdout_signal
stderr_signal_name = diag1_stderr_signal
[List]
execute = diag-network -l
stdout_strings = enabled
При запуске службы alterator-manager, можно увидеть на DBus новый объект:
Фронтенды
Фронтенд можно реализовать в виде графического приложения на любом языке и фреймворке, которое будет обращаться к предоставляемому бекэндом интерфейсу на DBus. Например, для работы с инструментами диагностики существует приложение Alterator Diagnostic Tool, которое с помощью alterator-manager получает все объекты, реализующие интерфейс diag1 и отображает их в своём интерфейсе.
Чтобы реализованное приложение появилось в Alterator Browser, ему так же необходимо создать объект на DBus с интерфейсом application1. Например, для Alterator Diagnostic Tool:
[Alterator Entry] Type = Backend Module = executor Name = adt Interface = application1 [Info] execute = cat /usr/share/alterator/applications/adt.application stdout_bytes = enabled
Текущие недостатки и планы по их исправлению
Как уже было сказано в начале, новая архитектура определённо упрощает разработку и даёт больше свободы при выборе технологического стека, но были замечены и некоторые недостатки такого подхода.
Больше всего переживаний вызывает количество кода, до которого разрастаются фронтенды. В виду того, что все фронтенды являются независимыми, они часто требуют повторной реализации обращений и обработки сообщений через DBus и построения объектов в рамках ООП.
На данный момент решением данной проблемы видится содание библиотеки, условно называемой libalterator, предоставляющей инструменты для работы с alterator-manager на шине DBus, отправки сообщений и парсинга ответов.
!.jpg)