[devel-distro] sysusers (was: Атомарный образ)

[Arseny Maslennikov <arseny@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 8521 bytes --]

> > 31.01.2025 17:10, Евгений Синельников пишет:
> > > Дмитрий,
> > > 
> > > спасибо за подробное описание, внятное изложение и полезные ссылки.
> > > 
> > > Думаю, эту историю нужно "переварить". Хотелось бы понять и
> > > осмыслить куда мы движемся и общий прогресс вместе с нами куда
> > > движется.

On Fri, Jan 31, 2025 at 07:29:26PM +0600, Дмитрий wrote:
> В данный момент я считаю что самое важное влияние которое оказывают
> мейнтейнеры и пакетная база в репозитории на такой образ - это следование
> следующим декларативам:
> 
> https://www.freedesktop.org/software/systemd/man/latest/systemd-sysusers.html

Мы (как минимум в моём лице) давно мечтаем переехать на декларативное
описание "системных" UID/GID из пакетов. Но внедрить sysusers — это
задача непростая.

Во-первых, systemd-sysusers никогда не будет поддерживать
https://altlinux.org/tcb по двум причинам:
— потому что они там, в проекте systemd, курят непонятно что[1],
— "ALT is a niche distro"[2] (c) Lennart Poettering.
[1] https://github.com/systemd/systemd/commit/9ab315ccf22a56ce28d442d94c5e4e3c416739c5
[2] https://github.com/systemd/systemd/issues/33787#issuecomment-2296116655
Т. е. для успокоения утилиты grpck, решающей непонятно какую задачу и
лезущей в shadow database непонятно зачем, были проделаны особые усилия,
сделавшие код systemd-sysusers зависящим от реализации shadow. А для tcb
теперь требуются особые усилия, которые Леннарт реально не хочет
ни предпринимать, ни даже сопровождать.

Во-вторых, в альте поддерживается и жизнь без systemd. sysusers может
быть собрана и использована как standalone-утилита, но см. предыдущий
абзац.

Поэтому разбирать sysusers.d/*.conf нужно какой-то своей программой.

В-третьих, нужна будет поддержка со стороны rpm-build и rpm. Если
вызывать sysusers в секции %pre, то для инсталляций со свободным
управлением пакетами (т. е. всех, кроме таких, о которых ваш тред)
большой разницы нет. Пока у меня не сложилось устойчивого мнения о том,
как здесь быть. (Предложения лучше в devel@)

> https://www.freedesktop.org/software/systemd/man/latest/systemd-tmpfiles-setup.service.html

А вот это в ALT успешно применяется. :)

> А ALT в данный момент очень мало пакетов собраны с учетом этих правил.
> Вероятно мне придется проверять каждый пакет которые будет добавлен в
> систему после ее установки и описывать эти правила вручную. Но если все
> пакеты будут собраны с использованием этих правил - переключением между
> образами и обновление будут тривиальной задачей, необходимые юзеры и папки
> буду созданы автоматически и для самовоспроизведения и корректной работы
> единственным важным обновлением будут папки /usr и /etc

Каталоги.
Папки — это mbox/Maildir, а директория — это орган власти в I французской
республике. :)

> 31.01.2025 18:29, Дмитрий пишет:
> > Если я правильно понял вопрос о мейнтейнерах, то для них, по сути,
> > ничего не меняется, когда система на основе |bootc| находится в режиме
> > контейнера с системой можно работать как угодно, используя любые
> > пакетные менеджеры, будь то |apt-get|, |epm| или другие.
> > 
> > В частности, используется пакетная база Sisyphus со всеми её
> > особенностями. Когда система запускается на хостовой машине, появляются
> > некоторые нюансы в работе с ней, но в процессе внесения изменений мы
> > снова оказываемся в контейнерной среде, где можем применять любые
> > встроенные механизмы установки пакетов локально.
> > 
> > Однако, под "чистым" использованием системы следует понимать минимизацию
> > установки пакетов непосредственно в саму систему. Вместо этого
> > рекомендуется опираться на контейнерные установщики, такие как
> > |flatpak|, |brew|, |distrobox| и подобные. Это скорее рекомендация, чем
> > строгая необходимость, но такой подход помогает сохранить систему более
> > предсказуемой и управляемой.
> > 
> > Так же благодаря особенностям сборки, мы можем гибко настраивать образ:
> > добавлять аргументы в загрузку ядра (nvidia), изменять любые
> > конфигурации в /etc (не затронутые пользователем) и многое другое. Это
> > позволяет создавать готовые образы, адаптированные под различные цели и
> > устройства.
> > 
> > По сути главное что меняется -  это доставка пакетов: вместо
> > традиционного подхода используется OCI-контейнер с его слоями и
> > особенностями. Кроме того, мы получаем дополнительные преимущества,
> > такие как хранение всех изменений в виде |ostree| коммитов с
> > возможностью "путешествовать" по ним на этапе загрузки через |GRUB|.
> > Либо путешествовать на разные состояния образа в облаке, так как в в OCI
> > лежит образ целиком или даже в перспективе перемещаться между любыми
> > bootc-совместимыми образами на основе ALT (/var куда переместился home и
> > другие папки не затрагиваются)
> > 
> > Делюсь ссылками:
> > 
> > 1. Концептуальная составляющей такого рода системы
> > https://0pointer.net/blog/fitting-everything-together.html
> > 
> > 2. Об используемых технологиях и перспективах
> > https://containers.github.io/bootable/
> > 
> > 3. В частности документация bootc
> > https://containers.github.io/bootc/
> > 
> > 4. Так же у Red Hat полно документации разной
> > https://developers.redhat.com/articles/2024/09/24/bootc-getting-started-bootable-containers#
> > 
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]