Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024)

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

Докладчик
Даниил Скачедубов

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

В докладе будет предложено решение этой проблемы путём систематизации хранения конфигурационных параметров с использованием инструмента Dconf.

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

Видео

Презентация

Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024).pdf

Thesis

В фоновых сервисах возникает необходимость обновления конфигурационных параметров в режиме реального времени. Обычно это достигается перезапуском сервиса или отправкой специализированных сигналов, например, SIGUSR1 или SIGUSR2, чтобы сервис перечитал конфигурационные файлы. Однако подобная логика обновления параметров должна быть реализована в каждом приложении заново, что усложняет разработку и поддержание кода.

Для того чтобы избежать необходимости отправки сигналов, таких как SIGUSR1 или SIGUSR2, приложения могут использовать шину D-Bus и единообразный интерфейс, позволяющий уведомлять о внесённых изменениях конфигурации в реальном времени. Dconf предоставляет решение этой задачи, позволяя распределять ключи конфигурации по группам, каждая из которых имеет соответствующий префикс, относящийся к конкретному приложению. Эта конфигурация может храниться как в централизованном наборе баз данных, так и в специализированных, обеспечивая гибкость в управлении. Примером такого подхода является использование Dconf в IBus для управления его настройками.

Архитектура и принципы работы Dconf

Dconf основан на концепции «профиля», который представляет собой список баз данных конфигурации. Профиль определяет порядок загрузки этих баз, задавая приоритеты при чтении и записи данных. Базы данных бывают системные, хранящиеся в /etc/dconf/db/, и пользовательские, расположенные в \ /.config/dconf/user. Пользовательские настройки перезаписывают системные для конкретного пользователя. В профиле базы данных расположены в порядке приоритета вычитывания, с первой в списке имеющей наивысший приоритет. Dconf также поддерживает «блокировки», которые предотвращают изменение ключей в базах данных, следующих за заблокированным ключом, если блокировка выставлена в нескольких базах, то приоритет вычитывания будет инвертирован.

Например, традиционный базовый профиль может выглядеть так:

   user-db:user 
   system-db:local 
   system-db:site

В этом примере пользовательская база данных (user-db:user) имеет наивысший приоритет, позволяя пользователю переопределять локальные системные настройки (system-db:local). Однако настройки в базе system-db:site могут содержать блокировки, которые запрещают изменение определённых параметров, даже если пользователь пытается их изменить через свою базу данных.

Для разработки и применения групповых политик в Dconf предусмотрены два типа расширенных профилей: пользовательские и системные. Был добавлен слой Policy, который располагается между слоями Local и User, что позволяет отделить управляемые политиками параметры от локальных настроек. Это даёт возможность точно контролировать, какие параметры будут регулироваться политиками, а какие останутся на усмотрение локальных настроек.

Введён также слой Default, который обеспечивает наличие базовых настроек по умолчанию, используемых системой, если они не переопределены другими слоями. Это гарантирует, что всегда будут применены какие-то настройки, даже если остальные слои не задействованы. Дополнительно в Dсonf используется возможность блокировки (Lock), которая защищает важные параметры от изменений. Совмещение слоёв Policy и Local с блокировками позволяет точно определить, какие параметры могут быть изменены пользователем, а какие защищены от изменений.

Схема расширенных профилей

Текущее использование Dconf и планы на дальнейшую разработку

В версии 0.10.0-alt1 в утилите gpupdate был изменён способ хранения ключей реестра, полученных из шаблонов групповой политики (GPT), переместив их из SQLite в Dconf. Это улучшило прозрачность и управляемость ключами политик, что позволило простыми методами реализовать утилиту, отображающую текущее состояние применённых политик.

Dconf теперь используется для хранения как системных, так и пользовательских политик, а также для хранения конфигурационных настроек самого Alterator, который управляет настройками системы. Механизм Dconf планируется использовать для централизованного хранения настроек различных сервисов и приложений, разрабатываемых в рамках проекта Alterator, ADMC и других приложений. Это позволит унифицировать управление конфигурациями и обеспечить централизованное хранение параметров для всех компонентов системы.

Архитектурный подход к хранению системных настроек (Даниил Скачедубов, OSSDEVCONF-2024)!.jpg

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