[devel-distro] Конфигурация в пакетах vs ... ?

[Paul Wolneykien]

  2sin: там в конце предложение по разделению бакендов на
привилегированную и не привилегированную части. Возможно,
ты уже об этом подумал. :-)

В Fri, 11 Oct 2024 08:42:56 +0300
Anton Farygin <rider �� basealt.ru> пишет:

> On 10.10.2024 22:29, Paul Wolneykien wrote:
> >    По тому, что я услышал на прошедшей OSSDEVCONF, у Жени есть
> > (частично реализованные) планы хранить настройки в дереве dconf
> > и применять их к системе после установки. Во-первых, самый главный
> > вопрос: как именно применять? И во-вторых, в чём принципиальное
> > отличие от пп. 3 и 4 выше?  
> 
> Есть более простое решение - присоединиться к этому проекту:
> 
> https://augeas.net/
> 
> рекомендуемые настройки хранить в виде дерева, которое будет просто 
> применяться к конфигурации через augeas.

  Каждый раз при обновлении пакета? И откатываться до обновления?
Поясню, с какой целью я затеял этот разговор: два с половиной варианта
(4, 3 и частично 2), указанных в исходном письме, создают одну
"маленькую" проблему: после изменения конфигов пакеты невозможно
нормально обновлять. Конечно, технически dist-upgrade проходит
нормально. Вот только после него остаются одни *.rpmnew-файлы:
ведь изменённые конфиги специально не заменяются новыми версиями
из пакета.

  И правильно делают, скажет кто-то! Правильно, но только в том случае,
если изменения в конфигах сделал администратор системы для себя (будучи
"в сознанке"). Иное дело, преднастроенная система. Где-то по середине
между этими крайностями, как мне думается, находится система,
настроенная через конфигуратор (Альтератор, Альтератор 2.0).

  Поэтому давайте не будем торопиться с выбором того или иного augeas,
а сперва подумаем, какие требования мы к нашей системе (и возможному
решению вышеизложенной проблемы) предъявляем.

  Возможно я не прав, но как программисту мне кажется, что обслуживание
того или иного набора специализированных модификаций конфигурационных
файлов очень близко к сопровождению набора специализированных
модификаций кода. Классический случай: в репозитории много кода и мало
моих изменений. Они, эти изменения, точечные, но важные. Как я их храню,
в виде ли отдельных патчей или прямо в дереве git, не важно --- если
изменения точечные, то при обновлении кода в 90% случаев патчи
приложатся без изменений, а git merge пройдёт автоматически. И вот мне
думается, что в случае dist-upgrade по тому же принципу должны
обновляться и конфигурационные файлы: новая "апстримная" версия приходит
из пакета, а закреплённые за данной установкой изменения накладываются
поверх неё. Если возникают проблемы --- сообщается администратору.
Примерно так, насколько я помню, работает dist-upgrade в Debian. А вот
есть ли там автоматический merge я забыл.

В Fri, 11 Oct 2024 13:05:55 +0400
Евгений Синельников <sin �� basealt.ru> пишет:

> В этом инструменте предложено, по сути, писать грамматику для парсинга разных видов конфигов.

  Таким образом, кажется, что не нужно писать специальные парсеры
конфигурации, а достаточно хранить изменения конфигурации в виде набора
патчей. И откатывать-накатывать их до-после dist-upgrade. Кажется,
в apt для этого предусмотрены хуки.

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

  Естественно, автоматический перенос настроек (хоть в виде патчей,
хоть в виде backend reapply) можно делать только в том случае, если
администратор не менял файл вручную. Значит за этим нужно как-то
следить.

  Что может помешать backend reapply? Во-первых, нужно каким-то образом
знать, что после обновления файла /etc/X, нужно вызвать бакенд Y.
То есть знать, за какой файл какой бакенд отвечает. Во-вторых, я
написал в своей жизни несколько бакендов для Альтератора и помню, что
часто у меня получалось так: бакенд по команде "Apply" меняет сразу
несколько конфигов! Это казалось логичным: пользователь в окошке
сформулировал свои желания, а бакенд это окошко транслирует на один или
несколько файлов --- в зависимости от ситуации. Однако, если мы хотим
иметь возможность вторично "накатывать" изменения на конкретный
обновлённый конфиг, то желательно, чтобы остальные файлы бакенд при
этом не трогал. Возможно, ничего страшного и не случится от повторного
применения настроек ко всем файлам, о которых знает бакенд, но с другой
стороны, если уж продумывать новую архитектуру, стоит подумать о том,
чтобы у бакендов в обязательном порядке была такая функция: "применить
настройки к данному конкретному файлу". На мой взгляд, это необходимо
дополняет соотношение /etc/X --> backends/Y.

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

  Если проектировать решение исходя из модели, которой Женя сейчас
придерживается, то есть D-bus-based модели, то думается, на D-bus должны
висеть интерфейсы, по возможностям аналогичные текущим /bin/shell-config
и /bin/shell-ini-config, то есть умеющие редактировать файлы
определённого формата.