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

Wed Oct 16 22:02:59 MSK 2024

Добрый вечер!

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

Мне известно три наиболее распространённых подхода к конфигураторам:

1. Собственный инструмент, тесно связанный с пакетной базой и 
дистрибутивами. Примеры: YaST, RSAT & Ко, Ред АДМ.
2. Система управления конфигурациями, независимая от дистрибутива, и 
поддерживаемая большим сообществом. Примеры: Puppet, Ansible, Salt.
3. Не классический конфигуратор, т.к. нет конфигурации и нет интеграции 
с пакетным менеджером. По сути отдельные модули, которыми можно что-то 
менять в системе. Примеры: system-config-SOMETHING от RedHat, нынешний 
Альтератор в Альте.

Готовы ли мы идти по пути 1 и обеспечить тесную интеграцию отдельно 
хранимой конфигурации как некоего обслуживаемого и переносимого набора 
важных данных с нашим пакетным менеджером, чтобы при установке, 
обновлении и удалении ПО конфигурация решения учитывалась? И не только 
конфигурация исходного решения, определённая нами, но и те изменения, 
которые впоследствии вносились администраторами.

On 10/16/24 00:03, Paul Wolneykien wrote:
>    2sin: там в конце предложение по разделению бакендов на
> привилегированную и не привилегированную части. Возможно,
> ты уже об этом подумал. :-)
>
> В Fri, 11 Oct 2024 08:42:56 +0300
> Anton Farygin <rider at 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 at 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, то есть умеющие редактировать файлы
> определённого формата.
> _______________________________________________
> devel-distro mailing list
> devel-distro at lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

-- 
WBR, Leonid Krivoshein.