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

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

[Paul Wolneykien]

  Всем привет. Пишу по мотивам текущего соседнего обсуждения про
инсталлятор 2.0 и вот одного нашего разговора с sin@, в котором он
сказал, что "делать настройки в виде пакетов - очень плохая история".

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

  Как мы сейчас её решаем? Насколько мне известно, комбинируем
следующие механизмы:

  1. если программа, которую нужно настроить, умеет собирать
конфигурацию из частей (à la conf.d/), то делаем пакет с нужными нам
настройками и включаем его в образ;

  2. в противном случае приходится или вносить изменения в основной
конфиг, то есть делать форк пакета;

  3. либо же использовать сценарий в install2/postinstall.d/ для
внесения изменений в конфиг уже после установки пакета;

  4. либо выполнять то же самое из firsttime.d/.


  Недостатки во всём этом известные, и я хотел бы направить
обсуждение на поиск лучших решений. Какие есть соображения и
планы на этот счёт?

  По тому, что я услышал на прошедшей OSSDEVCONF, у Жени есть
(частично реализованные) планы хранить настройки в дереве dconf
и применять их к системе после установки. Во-первых, самый главный
вопрос: как именно применять? И во-вторых, в чём принципиальное
отличие от пп. 3 и 4 выше?

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

[Anton Farygin]

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

Есть более простое решение - присоединиться к этому проекту:

https://augeas.net/

рекомендуемые настройки хранить в виде дерева, которое будет просто 
применяться к конфигурации через augeas.

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

[Anton Farygin]

Ну насчёт "брошенная 5 лет назад" я бы так не говорил - новые версии 
выходят регулярно.
https://github.com/hercules-team/augeas

On 11.10.2024 12:05, Евгений Синельников wrote:
> Надо смотреть. Я попозже отвечу.
>
> Augeas выглядит как сомнительная, брошенная еще 5 лет назад история.
>
> В этом инструменте предложено, по сути, писать грамматику для парсинга 
> разных видов конфигов.
>
> Во-первых, не все сводится к конфигам. Во-вторых, синтаксис конфигов 
> не зафиксирован между версиями.
>
> В общем, как идея, интересно. Как кодовая база, давайте посмотрим.
>
> LGPLv2.1+ - хороший вариант лицензии.
>
>
>
> 11 октября 2024 г. 09:42:56 GMT+04:00, Anton Farygin 
> <rider@basealt.ru> пишет:
>
>     On 10.10.2024 22:29, Paul Wolneykien wrote:
>
>         По тому, что я услышал на прошедшей OSSDEVCONF, у Жени есть
>         (частично реализованные) планы хранить настройки в дереве
>         dconf и применять их к системе после установки. Во-первых,
>         самый главный вопрос: как именно применять? И во-вторых, в чём
>         принципиальное отличие от пп. 3 и 4 выше? 
>
>     Есть более простое решение - присоединиться к этому проекту:
>     https://augeas.net/ рекомендуемые настройки хранить в виде дерева,
>     которое будет просто применяться к конфигурации через augeas.
>     ------------------------------------------------------------------------
>     devel-distro mailing list devel-distro@lists.altlinux.org
>     https://lists.altlinux.org/mailman/listinfo/devel-distro
>

Re: [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, то есть умеющие редактировать файлы
определённого формата.

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

[Leonid Krivoshein]

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


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

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

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@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, то есть умеющие редактировать файлы
> определённого формата.
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

-- 
WBR, Leonid Krivoshein.

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

[Michael Shigorin]

On Wed, Oct 16, 2024 at 12:03:11AM +0300, Paul Wolneykien wrote:
> Возможно я не прав, но как программисту мне кажется, что
> обслуживание того или иного набора специализированных
> модификаций конфигурационных файлов очень близко к
> сопровождению набора специализированных модификаций кода.

Именно.  И это достаточно давно копаемая по миру тема,
чтобы игнорировать уже набитые шишки -- .rpmorig/.rpmnew
в том же rpm появились как бы ещё не в прошлом веке отнюдь
не случайно.

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

Ещё на эту тему припоминаются семантические патчи:
darcs и если кто замечал -- многие "патчи" Ильи Курдюкова,
которые он оформляет не патчами, а sed'ами; на эту тему
применительно к коду есть и противоположное мнение,
см. тж. fortunes-ALT:

---
Свойство патчей "отваливаться в случае изменений" - это важное
преимущество, а вовсе не недостаток, как полагают многие.
(ldv@ в devel@)
---

Также помню твой проект verborum-caterva.

Из всего этого делаю такой вывод, что в зависимости от того,
сколько ВНИМАНИЯ получилось уделить:

* разработчикам апстримного проекта при продумывании конфигов
  и обратной совместимости по ним;

* майнтейнеру пакета и/или разработчику модуля управления им;

* сисадмину на местах

-- предпочтительные варианты ("оставить/пропатчить/отодвинуть")
могут быть весьма разными.

Возможно, это даже стоит системной политики, которую можно
устанавливать в рамках хоста или подразделения/компании.
(из которой тоже должны быть возможны исключения вида
"этот пакет ТОЧНО сломается со старым конфигом").

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

> В Fri, 11 Oct 2024 13:05:55 +0400
> Евгений Синельников <sin@basealt.ru> пишет:
> > В этом инструменте предложено, по сути, писать грамматику
> > для парсинга разных видов конфигов.
> Таким образом, кажется, что не нужно писать специальные парсеры
> конфигурации, а достаточно хранить изменения конфигурации
> в виде набора патчей. И откатывать-накатывать их до-после
> dist-upgrade. Кажется, в apt для этого предусмотрены хуки.
> 
> Но можно пойти и иным путём: при обновлении устанавливать
> конфиг из пакета, а затем вызывать бакенд конфигуратора для
> внесения специализированных изменений. Насколько я помню по
> новой концепции, которую излагали Женя и его ребята,
> конфигурация хранится в некоем дереве настроек отдельно от
> конфигурационных файлов, а бакенды эту конфигурацию применяют
> к конфигурационным файлам. По-сути, конфигурация системы в этом
> случае дублируется, но пока примем это.

Боюсь, это отличный путь закопаться навсегда в сопровождение
буквально всего, что предлагается таким образом конфигурировать
-- причём став заложником выбора (в т.ч. по ресурсам).

Когда ты Microsoft и задаёшь правила игры на СВОЕЙ платформе,
продавить на хранение настроек в реестре более-менее всех
разработчиков прикладного ПО возможно.

А когда ты мы -- то сопровождение кода, умеющего разбирать
и точечно изменять конфиги всего подлежащего централизованному
конфигурированию (не путать с "вообще всего") -- на тебе.

Из хорошего: если хранить именно смысловые изменения
(что требует ещё большей погружённости в конкретику
конфигурирования каждого конкретного проекта) --
переживать изменения форматов конфигов может стать
в итоге легче.

Вот только я не понимаю -- что тут дают dconf и dbus на хосте?
Если мы говорим о централизованном управлении -- задача на
изменение формируется в одном месте (и база патчей нужна по сути
там); если о применении на конкретном хосте хоть централизованно,
хоть по принятому root@localhost решению -- автономная шина
для передачи любой требуемой информации в бэкенд давно есть.

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

Потому и говорю молодым да горячим: прежде чем городить новое
и тем более называть это Alterator -- изучите то, что уже было
сделано, поймите проблематику, которую уже думали и решали.

Имя -- важно: нельзя замахиваться на то, чего не заслужил.

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

Ключевое слово: идемпотентность.

> Таким образом мне кажется, что нужно поставить на контроль то, в какие
> файлы данному бакенду можно вносить изменения, а в какие нельзя. Но как
> это сделать? Выход, по-моему, ровно один: бакенд должен работать под
> nobody

Технически говоря, nobody в альте как раз потому и не задействуется,
чтобы не возникло неочевидных проблем из-за общности прав у *разных*
"никого"; наверняка тут речь про обособленного непривилегированного
пользователя. :)

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

И что делать, если трогался?  Тыща хостов, на двух потрогали.

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

Когда-то в 2003 я постеснялся сообщить создателям ruby gems,
что у них ошибка дизайна, которая вылезла лет через 10--15
при попытке автоматизации сборки самоцветовъ (и которой уже
тогда не было в CPAN).

Сейчас я уже не стесняюсь ругаться, что бежать впереди IBM,
делая windows из linux -- безумие.

Юниксы вырвались вперёд на простоте, человекопостижимости,
отлаживаемости (пусть и глючности по сравнению с тем же VMS,
как старшее поколение рассказывает).

Более десятилетия уже это всё успешно гробится теми, кто вырос
на винде с её "хоть экспоненциальный рост сложности, лишь бы
поддержать линейный рост потребительских качеств и главное --
затруднительность воспроизведения для конкурентов".

Мы этот кредитный подход (брать в долг у тех, кому тащить дальше)
не вытянем в принципе: ни людей, ни денег столько не будет.

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

См. тж.:
http://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
http://arstechnica.com/information-technology/2012/02/how-red-hat-killed-its-core-productand-became-a-billion-dollar-business/
(превозносимого Пола Кормье его бывший сотрудник и сосед
охарактеризовал как "мать продаст за квотер")

-- 
Michael Shigorin
http://altlinux.org/elbrus

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

[Konstantin Lepikhov]

Hi Leonid!

On 10/16/2024, at 10:02:59 PM you wrote:

> Добрый вечер!
> 
> 
> В обсуждении конфигуратора добрались, наконец, до самого важного, а 
> именно, чем он собственно будет оперировать и как мы видим его 
> интеграцию с пакетами, т.к. здесь вероятно предполагаются ещё и усилия 
> маинтейнеров. До ответов на вопросы Павла (ниже) придётся ответить самим 
> себе на ещё один важный вопрос.
> 
> Мне известно три наиболее распространённых подхода к конфигураторам:
> 
> 1. Собственный инструмент, тесно связанный с пакетной базой и 
> дистрибутивами. Примеры: YaST, RSAT & Ко, Ред АДМ.
> 2. Система управления конфигурациями, независимая от дистрибутива, и 
> поддерживаемая большим сообществом. Примеры: Puppet, Ansible, Salt.
> 3. Не классический конфигуратор, т.к. нет конфигурации и нет интеграции 
> с пакетным менеджером. По сути отдельные модули, которыми можно что-то 
> менять в системе. Примеры: system-config-SOMETHING от RedHat, нынешний 
> Альтератор в Альте.
> 
> Готовы ли мы идти по пути 1 и обеспечить тесную интеграцию отдельно 
> хранимой конфигурации как некоего обслуживаемого и переносимого набора 
> важных данных с нашим пакетным менеджером, чтобы при установке, 
> обновлении и удалении ПО конфигурация решения учитывалась? И не только 
> конфигурация исходного решения, определённая нами, но и те изменения, 
> которые впоследствии вносились администраторами.
По моему скромному мнению, если хочется решить задачу с "корпортативным"
управлением, то в первую очередь тут нужен ответ на вопрос "а какая система будет
использоваться для управления". Иначе все эти метания похожи на поиск
некого perpetuum mobile.

-- 
WBR et al.

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

[Denis Medvedev]

On Fri, 18 Oct 2024 11:54:40 +0300
Michael Shigorin <mike@altlinux.org> wrote:

> On Wed, Oct 16, 2024 at 12:03:11AM +0300, Paul Wolneykien wrote:
> > Возможно я не прав, но как программисту мне кажется, что
> > обслуживание того или иного набора специализированных
> > модификаций конфигурационных файлов очень близко к
> > сопровождению набора специализированных модификаций кода.
> 
> Именно.  И это достаточно давно копаемая по миру тема,
> чтобы игнорировать уже набитые шишки -- .rpmorig/.rpmnew
> в том же rpm появились как бы ещё не в прошлом веке отнюдь
> не случайно.
> 
> > Классический случай: в репозитории много кода и мало
> > моих изменений. Они, эти изменения, точечные, но важные. Как я их
> > храню, в виде ли отдельных патчей или прямо в дереве git, не важно
> > --- если изменения точечные, то при обновлении кода в 90% случаев
> > патчи приложатся без изменений, а git merge пройдёт автоматически.
> > И вот мне думается, что в случае dist-upgrade по тому же принципу
> > должны обновляться и конфигурационные файлы: новая "апстримная"
> > версия приходит из пакета, а закреплённые за данной установкой
> > изменения накладываются поверх неё. Если возникают проблемы ---
> > сообщается администратору. Примерно так, насколько я помню,
> > работает dist-upgrade в Debian. А вот есть ли там автоматический
> > merge я забыл.
> 
> Ещё на эту тему припоминаются семантические патчи:
> darcs и если кто замечал -- многие "патчи" Ильи Курдюкова,
> которые он оформляет не патчами, а sed'ами; на эту тему
> применительно к коду есть и противоположное мнение,
> см. тж. fortunes-ALT:
> 
> ---
> Свойство патчей "отваливаться в случае изменений" - это важное
> преимущество, а вовсе не недостаток, как полагают многие.
> (ldv@ в devel@)
> ---
> 
> Также помню твой проект verborum-caterva.
> 
> Из всего этого делаю такой вывод, что в зависимости от того,
> сколько ВНИМАНИЯ получилось уделить:
> 
> * разработчикам апстримного проекта при продумывании конфигов
>   и обратной совместимости по ним;
> 
> * майнтейнеру пакета и/или разработчику модуля управления им;
> 
> * сисадмину на местах
> 
> -- предпочтительные варианты ("оставить/пропатчить/отодвинуть")
> могут быть весьма разными.
> 
> Возможно, это даже стоит системной политики, которую можно
> устанавливать в рамках хоста или подразделения/компании.
> (из которой тоже должны быть возможны исключения вида
> "этот пакет ТОЧНО сломается со старым конфигом").
> 
> Возможно даже, что стоит делать проверки вроде glibc-preinstall
> или ещё лучше -- интегрировать в apt возможность откладывания
> (или исключения из неинтерактивного) обновления вборок пакетов,
> которые заведомо потребуют внимания человека к конфигурации.
> 
> > В Fri, 11 Oct 2024 13:05:55 +0400
> > Евгений Синельников <sin@basealt.ru> пишет:
> > > В этом инструменте предложено, по сути, писать грамматику
> > > для парсинга разных видов конфигов.
> > Таким образом, кажется, что не нужно писать специальные парсеры
> > конфигурации, а достаточно хранить изменения конфигурации
> > в виде набора патчей. И откатывать-накатывать их до-после
> > dist-upgrade. Кажется, в apt для этого предусмотрены хуки.
> > 
> > Но можно пойти и иным путём: при обновлении устанавливать
> > конфиг из пакета, а затем вызывать бакенд конфигуратора для
> > внесения специализированных изменений. Насколько я помню по
> > новой концепции, которую излагали Женя и его ребята,
> > конфигурация хранится в некоем дереве настроек отдельно от
> > конфигурационных файлов, а бакенды эту конфигурацию применяют
> > к конфигурационным файлам. По-сути, конфигурация системы в этом
> > случае дублируется, но пока примем это.
> 
> Боюсь, это отличный путь закопаться навсегда в сопровождение
> буквально всего, что предлагается таким образом конфигурировать
> -- причём став заложником выбора (в т.ч. по ресурсам).
> 
> Когда ты Microsoft и задаёшь правила игры на СВОЕЙ платформе,
> продавить на хранение настроек в реестре более-менее всех
> разработчиков прикладного ПО возможно.
> 
> А когда ты мы -- то сопровождение кода, умеющего разбирать
> и точечно изменять конфиги всего подлежащего централизованному
> конфигурированию (не путать с "вообще всего") -- на тебе.
> 
> Из хорошего: если хранить именно смысловые изменения
> (что требует ещё большей погружённости в конкретику
> конфигурирования каждого конкретного проекта) --
> переживать изменения форматов конфигов может стать
> в итоге легче.
> 
> Вот только я не понимаю -- что тут дают dconf и dbus на хосте?
> Если мы говорим о централизованном управлении -- задача на
> изменение формируется в одном месте (и база патчей нужна по сути
> там); если о применении на конкретном хосте хоть централизованно,
> хоть по принятому root@localhost решению -- автономная шина
> для передачи любой требуемой информации в бэкенд давно есть.
> 
> > Естественно, автоматический перенос настроек (хоть в виде
> > патчей, хоть в виде backend reapply) можно делать только в том
> > случае, если администратор не менял файл вручную. Значит за
> > этим нужно как-то следить.
> 
> Потому и говорю молодым да горячим: прежде чем городить новое
> и тем более называть это Alterator -- изучите то, что уже было
> сделано, поймите проблематику, которую уже думали и решали.
Вот кстати, давайте НОВОМУ продукту дадим НОВОЕ имя.
Неужели нет красивых имен? Например Ясень?, Березка? Кварц?
Хоровод? Коло? SystemHelmsman?
А то получится как с python3 или kde4 - насильное пропихивание
чужеродной по сути замены c тем же именем вызывает очень большую
демотивацию пользователей, которые были бы рады остаться на старом.
Из современных вещей назову Комета-120Р, которая была разработана
полностью с нуля в России, а теперь ее путают со старой Кометой
Алексеева.
> 
> Имя -- важно: нельзя замахиваться на то, чего не заслужил.
> 
> > Что может помешать backend reapply? Во-первых, нужно каким-то
> > образом знать, что после обновления файла /etc/X, нужно вызвать
> > бакенд Y. То есть знать, за какой файл какой бакенд отвечает.
> > Во-вторых, я написал в своей жизни несколько бакендов для
> > Альтератора и помню, что часто у меня получалось так: бакенд по
> > команде "Apply" меняет сразу несколько конфигов! Это казалось
> > логичным: пользователь в окошке сформулировал свои желания, а
> > бакенд это окошко транслирует на один или несколько файлов --- в
> > зависимости от ситуации. Однако, если мы хотим иметь возможность
> > вторично "накатывать" изменения на конкретный обновлённый конфиг,
> > то желательно, чтобы остальные файлы бакенд при этом не трогал.
> > Возможно, ничего страшного и не случится от повторного применения
> > настроек ко всем файлам, о которых знает бакенд, но с другой
> > стороны, если уж продумывать новую архитектуру, стоит подумать о
> > том, чтобы у бакендов в обязательном порядке была такая функция:
> > "применить настройки к данному конкретному файлу". На мой взгляд,
> > это необходимо дополняет соотношение /etc/X --> backends/Y.
> 
> Ключевое слово: идемпотентность.
> 
> > Таким образом мне кажется, что нужно поставить на контроль то, в
> > какие файлы данному бакенду можно вносить изменения, а в какие
> > нельзя. Но как это сделать? Выход, по-моему, ровно один: бакенд
> > должен работать под nobody
> 
> Технически говоря, nobody в альте как раз потому и не задействуется,
> чтобы не возникло неочевидных проблем из-за общности прав у *разных*
> "никого"; наверняка тут речь про обособленного непривилегированного
> пользователя. :)
> 
> > и только тот код, который непосредственно трогает конфигурационные
> > файлы должен работать под root! Перед тем, как внести изменение
> > в файл, эта привилегированная часть обязана будет свериться
> > с табличкой ACL, декларирующей, какому бакенду что можно
> > трогать.  И ещё проверить, что файл не редактировался вручную,
> > то есть сторонними средствами.
> 
> И что делать, если трогался?  Тыща хостов, на двух потрогали.
> 
> > Если проектировать решение исходя из модели, которой Женя
> > сейчас придерживается, то есть D-bus-based модели, то думается,
> > на D-bus должны висеть интерфейсы, по возможностям аналогичные
> > текущим /bin/shell-config и /bin/shell-ini-config, то есть
> > умеющие редактировать файлы определённого формата.
> 
> Когда-то в 2003 я постеснялся сообщить создателям ruby gems,
> что у них ошибка дизайна, которая вылезла лет через 10--15
> при попытке автоматизации сборки самоцветовъ (и которой уже
> тогда не было в CPAN).
> 
> Сейчас я уже не стесняюсь ругаться, что бежать впереди IBM,
> делая windows из linux -- безумие.
> 
> Юниксы вырвались вперёд на простоте, человекопостижимости,
> отлаживаемости (пусть и глючности по сравнению с тем же VMS,
> как старшее поколение рассказывает).
> 
> Более десятилетия уже это всё успешно гробится теми, кто вырос
> на винде с её "хоть экспоненциальный рост сложности, лишь бы
> поддержать линейный рост потребительских качеств и главное --
> затруднительность воспроизведения для конкурентов".
> 
> Мы этот кредитный подход (брать в долг у тех, кому тащить дальше)
> не вытянем в принципе: ни людей, ни денег столько не будет.
> 
> Понимаю, что погрузившись крепко в Samba, получаешь своего рода
> профдеформацию -- но всё-таки из любой шахты стоит порой вылезать
> (у меня такое же по эльбрусам, если что).
> 
> См. тж.:
> http://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
> http://arstechnica.com/information-technology/2012/02/how-red-hat-killed-its-core-productand-became-a-billion-dollar-business/
> (превозносимого Пола Кормье его бывший сотрудник и сосед
> охарактеризовал как "мать продаст за квотер")
> 



--