Alterator on D-Bus: различия между версиями

Материал из ALT Linux Wiki
м (Категория)
м (EvgenySinelnikov переименовал страницу Alterator на D-Bus в Alterator on D-Bus: Убрать кириллицу из URL)
 
(не показана 1 промежуточная версия 1 участника)
Строка 17: Строка 17:


* модули не предоставляют программный интерфейс для приложений (API);
* модули не предоставляют программный интерфейс для приложений (API);
* нетривиальность пользовательского интерфейса, вызванная ограничением связки <tt>quile/qt</tt>;
* нетривиальность пользовательского интерфейса, вызванная ограничением связки <tt>guile/qt</tt>;
* ограниченность возможностей для реализации системной части:
* ограниченность возможностей для реализации системной части:
** слабоспецифицированный интерфейс;
** слабоспецифицированный интерфейс;

Текущая версия от 22:02, 8 ноября 2024


Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

История создания

Альтератор является основным базовым компонентом для построения дистрибутивных решений «Альт» (используется как инсталлятор и конфигуратор системы). Реализация исходного проекта Альтератор написана в рамках модульного подхода Scheme (диалект языка Lisp, в реализации Guile), C и sh+awk. Архитектура проекта предполагает возможность парного расширения модулей на языке программирования Scheme для фронтендов (под графический интерфейс на базе Qt и под веб-интерфейс на базе встроенного, отдельно устанавливаемого веб-сервера) и на языке Bash для бэкендов (со взаимодействием через собственную шину передачи сообщений — woo-bus).

Недостатки решения

Разработка предыдущей версии Альтератора, в которой взаимодействие с бэкендами осуществлялось через службу alteratord, столкнулась со следующими проблемами:

  • модули не предоставляют программный интерфейс для приложений (API);
  • нетривиальность пользовательского интерфейса, вызванная ограничением связки guile/qt;
  • ограниченность возможностей для реализации системной части:
    • слабоспецифицированный интерфейс;
    • сложность обработки ошибок бэкендов;
  • отсутствие системного контроля доступа:
    • отсутствует гибкая настройка контроля доступа в графическом интерфейсе;
    • в параметрах доступа к модулю через веб-интерфейс возможно указание только локальных пользователей;
  • запуск в графическом интерфейсе доступен только по паролю root'а;
  • подверженность уязвимости code injection.

Перечисленные недостатки привели к решению о смене архитектуры проекта Альтератор - к переходу от взаимодействия с бэкендами посредством alteratord (который «под капотом» использует woo-bus) к общению через службу alterator-manager, обращающуюся к шине D-Bus.

Цели перехода на новую реализацию

  • спецификация интерфейсов бэкендов для создания фронтендов в различных графических и консольных приложениях;
  • возможность защищённого, контролируемого выполнения привилегированных действий из-под непривилегированного окружения (то есть команд из-под root’а в графических приложениях без необходимости ввода только root’ового пароля, что определяется настройками);
  • интеграция шины D-Bus со всеми системными компонентами в современных Linux-дистрибутивах (начиная от systemd и заканчивая всеми графическими окружениями для управления, например, такими сервисами как UDisks2, NetworkManager, а также отдельными сервисами systemd);
  • сохранить возможность традиционного управления в консоли через ручное редактирование конфигурационных файлов;
  • расширение числа заинтересованных разработчиков (участников команды ALT Linux Team) в развитии проекта, позволяющего конфигурировать операционные системы «Альт» за счет реализации расширения модулей под декларативный сценарий;
  • предоставление разработчикам широких возможностей в виде фреймфорка для создания собственных приложений, управляемых как локально, так и по сети;
  • обобщение механизмов, используемых как для локального, так и удалённого управления, в том числе и через инструменты конфигурациями (такие как ssh, ansible и групповые политики, развиваемые в рамках проекта «Альт Домен»).

Архитектура проекта

Архитектура новой реализации проекта Альтератор опирается на опыт конфигурирования ОС «Альт» и концептуальный подход, заложенный в нем.

Alterator использует Alterator Manager, который добавляет объекты и интерфейсы на шину D-Bus.

Alterator-manager это модульный сервис ("замена" alteratord). Его функционал реализуется в модулях (механизмах). Модули представлены в виде динамически подгружаемых библиотек (.so). Интерфейс описывается в специальных конфигурационных файлах. Сервис может работать в двух режимах: обычном и пользовательском. В первом случае сервис запускается из-под root'а и регистрирует имя (ru.basealt.alterator) на системной шине D-Bus, во втором - из-под обычного пользователя и имя регистрирует на сессионной шине D-Bus. После запуска сервис alterator-manager считывает конфигурационные файлы .backend и сохраняет информацию из них в собственную таблицу. Далее alterator-manager загружает модули, которые будут пользоваться информацией из этой таблицы.

На данный момент реализован модуль alterator-module-executor. Модуль alterator-module-executor предоставляет интерфейс на D-Bus для запуска исполняемых файлов. Подробнее.

Другие модули могут не пользоваться конфигурационными файлами .backend, а добавлять информацию о своих объектах и интерфейсах напрямую в базу данных alterator-manager'а.

Объектами и интерфейсами на D-Bus, предоставленными alterator-manager'ом, пользуются фронтенды (Alterator Browser, ADT, AMC, AMP).

Примечание:
  • имена интерфейсов или имя шины - с точками, например, ru.basealt.alterator.manager;
  • имена объектов с символами косой черты, например, /ru/basealt/alterator.

Cхема различий реализаций Альтератора

Alterator (старый) Alterator на D-Bus
Ключевым звеном является служба alteratord, реализующаяся как взаимодействие через шину woo-bus, так и запуск бэкендов в виде отдельных процессов, обрабатывающих запросы на шине. Ключевым звеном является служба alterator-manager, обеспечивающая:
  • подключение к шине D-Bus;
  • разбор декларативных описаний интерфейсов для модулей Альтератора;
  • загрузку бинарных модулей, обрабатывающих запросы на объектах D-Bus для интерфейсов, загруженных из описаний.

Реализация нового подхода

Alterator Manager и Executor

На текущий момент реализован базовый каркас в виде alterator-manager и alterator-module-executor. Пакеты доступны в хранилище «Сизиф» в ветке sisyphus и p11.

Данный каркас обеспечивает следующий набор возможностей:

  • в рамках базового интерфейса ru.basealt.alterator.manager - поиск любых объектов Альтератор, предоставляющих заданный интерфейс, а также вывод перечня интерфейсов предоставляемых заданным объектом Альтератор;
  • в рамках расширенного модуля executor - возможность создания любого количества объектов, реализующих заданные интерфейсы через Unixway на D-Bus;
  • для всех создаваемых интерфейсов - генерировать базовый ограниченный набор правил PolicyKit;
  • контролировать соответствие интерфейсов, создаваемых для объектов, заданному шаблону (имена методов и их сигнатуры).

Клиентские приложения

  • alterator-browser,Alterator Browser - интерфейс добавления модулей Альтератора; графическое приложение, предназначенное для просмотра, запуска приложений для использования функционала объектов на D-Bus (замена Alterator Control Center). Разработка должна обеспечить прозрачный запуск как графических модулей Альтератора старой версии, так и новых графических интерфейсов, обращающихся к интерфейсам на D-Bus и управляемых через групповые политики.
  • adt, ADT - графическое приложение для диагностики операционной системы: обеспечивает поиск и загрузку гибко расширяемого набора диагностических интерфейсов;
  • alteratorctl, Alteratorctl (в разработке </>) - консольная утилита, позволяющая использовать функционал объектов на D-Bus без дополнительных приложений.

Планы и перспективы развития

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

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

Публикации на тему