From: Denis Medvedev <nbr@altlinux.org> To: Michael Shigorin <mike@altlinux.org> Cc: Distributions development <devel-distro@lists.altlinux.org> Subject: Re: [devel-distro] [JT] Re: Конфигурация в пакетах vs ... ? Date: Fri, 18 Oct 2024 14:24:39 +0300 Message-ID: <20241018142439.3f959538@google-analytics.com> (raw) In-Reply-To: <20241018085440.GD8400@imap.altlinux.org> 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/ > (превозносимого Пола Кормье его бывший сотрудник и сосед > охарактеризовал как "мать продаст за квотер") > --
prev parent reply other threads:[~2024-10-18 11:24 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-10-10 19:29 [devel-distro] " Paul Wolneykien 2024-10-11 5:42 ` Anton Farygin 2024-10-11 9:11 ` Anton Farygin 2024-10-15 21:03 ` Paul Wolneykien 2024-10-16 19:02 ` Leonid Krivoshein 2024-10-18 10:11 ` Konstantin Lepikhov 2024-10-18 8:54 ` [devel-distro] [JT] " Michael Shigorin 2024-10-18 11:24 ` Denis Medvedev [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20241018142439.3f959538@google-analytics.com \ --to=nbr@altlinux.org \ --cc=devel-distro@lists.altlinux.org \ --cc=mike@altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git