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

[Michael Shigorin <mike@altlinux.org>]

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