From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729105382; x=1729710182; darn=lists.altlinux.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=VAQXzhpVe1Q1Vt96c9afv3fpF5KiJK3S54S4Ruj8FIc=; b=UPbqnO4SQTDJkM1ljcLAFBY1VvTRdg68Cho1kotHvjKiLXB+GcLn6WWtaZwxXscUVV 1Qba26/1FHEYXR4p6z2g2JFkiJnF2xMwP5msEnuIpcRuO2Gt766IiluTqV37DQrLZwPy KXST+Jvz/j0wXSXB7ukXMg2k8lc1mspIvPIro7+4QDJ6QFbSFAmnNXHCImehFAf2DRn6 Tl96W+9/vFZICcILWw2HLJg1qR6ZwAeYZUgdGbX9HX3fyVq/ZCfGA70rSS9z9wKdJNFX UlLXV5RukPD/a1d4mRQAuuol30FBSZ6SDv8ULSa56ixMJiY0jbsL9sls/9DTa8xDYHpo af+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729105382; x=1729710182; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VAQXzhpVe1Q1Vt96c9afv3fpF5KiJK3S54S4Ruj8FIc=; b=GE9VZVIFeTAow4i372YF3DAMHjjsEh/qVvu48BP0zeL3PWoZV68Xya6KAyxhn0w8zp /+/x9OsI5zhRFXkYxHg5ShRcvRivrI0uCn4rOvTMDiEzLVhy29sA/JRMAN6V+5BAqpFv 07kyhQjy9AN/8NGznGiRBqSCS/vbmZrW496yTwP8cfs1h0IGvDBUwqtIBenGyekt3CN+ LkMrhWPILSQzUq8HUyH5xJHGu8DMMW1HzRj9qNcL67JsH9/QDByfRcWkfxmiFXNDWMfK +17/liVdGhlyoBBxEDAw+kb9onapUfS1alvLR6lBHjc0UG/85wMQiFVK1jA3/h19UwYq xWSQ== X-Gm-Message-State: AOJu0YxEQr63x1HgoUkMnCaEoBoX6/PVeEjDaoowTVf46orTc5BXjly7 by5+VEkLZjF6JzXdLDRLcp+Wr1waUlmKcLK4kmEwhq6t2Lx8mLcRDyU3wA== X-Google-Smtp-Source: AGHT+IGDKPi/i66jo22ReL4DBRM6YZLbvJdS1/4jTFitWJ3BCjltYj+rBBWtpMDMYNB+NDTBL7QtFg== X-Received: by 2002:a5d:6d04:0:b0:37d:34f6:92a with SMTP id ffacd0b85a97d-37d86d59906mr3672279f8f.51.1729105382143; Wed, 16 Oct 2024 12:03:02 -0700 (PDT) Message-ID: Date: Wed, 16 Oct 2024 22:02:59 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel-distro@lists.altlinux.org References: <20241010222932.64bccb0c@legato> <20da660b-0c0e-42bc-bb7b-f1a204bf0612@basealt.ru> <20241016000311.73f7d145@legato> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: <20241016000311.73f7d145@legato> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel-distro] =?utf-8?b?0JrQvtC90YTQuNCz0YPRgNCw0YbQuNGPINCyINC/?= =?utf-8?b?0LDQutC10YLQsNGFIHZzIC4uLiA/?= 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: Wed, 16 Oct 2024 19:03:06 -0000 Archived-At: List-Archive: Добрый вечер! В обсуждении конфигуратора добрались, наконец, до самого важного, а именно, чем он собственно будет оперировать и как мы видим его интеграцию с пакетами, т.к. здесь вероятно предполагаются ещё и усилия маинтейнеров. До ответов на вопросы Павла (ниже) придётся ответить самим себе на ещё один важный вопрос. Мне известно три наиболее распространённых подхода к конфигураторам: 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 пишет: > >> 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 > Евгений Синельников пишет: > >> В этом инструменте предложено, по сути, писать грамматику для парсинга разных видов конфигов. > Таким образом, кажется, что не нужно писать специальные парсеры > конфигурации, а достаточно хранить изменения конфигурации в виде набора > патчей. И откатывать-накатывать их до-после 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.