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=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FUZZY_XPILL autolearn=no autolearn_force=no version=3.4.1 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udalov.online; s=mail; t=1738848733; bh=uyzgTjHS7vfn+qIDwvvf5vEMuxpWdEef51JypM3QfCo=; h=Subject:From:To:Date:Message-ID; b=mx+KzjHnH5fmgr7BQQ53pA+MFvc/a8r86QPcxIcXNFMSsGumAA92lgMwNnO83eibR RS/+1rwD5nR3UhMqAX6nYeZ64igmtSLjsgjTCDSsilsQrxVJwB7686BPxX63Hz3g38 3txkRUEaVo9QZWphJzB56dVTd/wAYc5sbvLY7zsM= Authentication-Results: mail-nwsmtp-smtp-production-main-52.vla.yp-c.yandex.net; dkim=pass header.i=@udalov.online Message-ID: Date: Thu, 6 Feb 2025 19:32:11 +0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US, ru-RU To: Distributions development From: =?UTF-8?B?0JTQvNC40YLRgNC40Lk=?= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [devel-distro] =?utf-8?b?0J/RgNC40LzQtdC90LXQvdC40LUgc3lzdGVtZC10?= =?utf-8?q?mpfiles?= 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: Thu, 06 Feb 2025 13:32:15 -0000 Archived-At: List-Archive: Здравствуйте, я бы хотел еще раз затронуть тему systemd-sysusers и systemd-tmpfiles. Я честно признаюсь что не являюсь мейнтейнером и не знаю в подробностях как работает сборка пакетов в ALT поэтому был бы рад услышать Ваше мнение. Я видел что в bugzilla заведен репорт для поддержки systemd-sysusers поэтому хотел бы еще раз затронуть эту тему и обсудить текущие состояние systemd-tmpfiles который как мне казалось уже интегрирован и придерживается. Начнем с плюсов и целей которые я вижу своим субьективным взглядом: 1. Декларативная конфигурация базовых системных сущностей. Пользователи, группы, каталоги и временные файлы определяются в конфигурационных файлах, это упрощает их управление и поддержку. 2. Повышенная надёжность. Система всегда гарантированно запускается с правильно созданными системными учетными записями и необходимой инфраструктурой каталогов, что снижает вероятность сбоев и проблем с правами доступа. 2. Герметичность системы. В образах, где /usr является неизменяемым (например атомарные), а все динамические данные создаются при загрузке, эти инструменты позволяют обеспечить полную функциональность системы без ручного вмешательства в /var каталог 3. Упрощённое обновление системы. Благодаря декларативным инструментам обновление сводится к изменению централизованных конфигурационных файлов, определяющих системных пользователей, группы и необходимые каталоги (например, /etc/passwd и /etc/group), вместо прямого редактирования этих файлов вручную или путем переустановки пакета. Проверка работы systemd-tmpfiles Я проверял разные пакеты и их поведение в основном идентичное следующем примеру. Для корректной работы пакета redis требуется наличие системной группы *_redis*, пользователя *_redis* и следующих директорий: */var/lib/redis* – для хранения данных, */var/log/redis* – для логов, */run/redis* – для временных файлов, создаваемых во время работы (например, PID-файлов). в tmpfiles.d мы видим следующее: cat redis.conf d /run/redis 0755 _redis _redis что я ожидал увидеть (приблизительно): cat redis.conf # Создание временной директории для redis d /run/redis 0755 _redis _redis # Создание постоянных директорий для данных и логов d /var/lib/redis 0755 _redis _redis - d /var/log/redis 0750 _redis _redis - Из этого можно сделать вывод, что в текущей реализации systemd-tmpfiles в основном используется для создания временных каталогов (например, */run/redis*) у большинства пакетов. Создание постоянных директорий (например, */var/lib/redis* и */var/log/redis*) выполняется на этапе установки пакета. Хотя есть исключения, некоторые пакеты создают для себя /var/lib директорию но это выглядит как случайность нежели правило. В контексте атомарного образа возникают определённые ограничения при переключении между различными ветками. Если в рамках одной системы пакеты продолжают создавать каталоги в /var в момент установки, то при переходе на образы с отличающейся пакетной базой могут возникнуть конфликты. Это происходит потому, что /var трактуется как пространство пользователя, которое не должно изменяться вручную, а управляться исключительно через конфигурационные механизмы. Для проблемы отсутствия поддержки systemd-sysusers я уже реализовал скрипт, который динамически сравнивает системных пользователей и группы внутри образа и корректирует локальные файлы /etc/passwd и /etc/group. Однако с неполной поддержкой systemd-tmpfiles мне пока не удалось найти решение – единственный вариант, который остаётся, – попробовать написать макросы для rpm.