From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 18 Oct 2024 11:54:40 +0300 From: Michael Shigorin To: devel-distro@lists.altlinux.org Message-ID: <20241018085440.GD8400@imap.altlinux.org> References: <20241010222932.64bccb0c@legato> <20da660b-0c0e-42bc-bb7b-f1a204bf0612@basealt.ru> <20241016000311.73f7d145@legato> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241016000311.73f7d145@legato> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: [devel-distro] =?koi8-r?b?W0pUXSBSZTogIOvPzsbJx9XSwcPJ0SDXINDB?= =?koi8-r?b?y8XUwcggdnMgLi4uID8=?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2024 08:54:41 -0000 Archived-At: List-Archive: 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 > Евгений Синельников пишет: > > В этом инструменте предложено, по сути, писать грамматику > > для парсинга разных видов конфигов. > Таким образом, кажется, что не нужно писать специальные парсеры > конфигурации, а достаточно хранить изменения конфигурации > в виде набора патчей. И откатывать-накатывать их до-после > 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