[devel-distro] Атомарный образ

[devel-distro] Атомарный образ

[Дмитрий]

Здравствуйте, хотел бы обсудить реализацию атомарного образа для 
домашних систем.
Описание текущего состояния проекта: ссылка <https://atomic.alt-gnome.ru/>


Вступление
Компания ALT уже активно внедряет технологии атомарных образов в 
серверных решениях — ярким примером служит проект ALT Container OS. Эти 
образы ориентированы на массовое развертывание, эффективное 
администрирование серверов, минималистичный подход и решение 
узкоспециализированных задач.

Как разработчик, я организовал рабочую среду на домашнем компьютере с 
использованием контейнеров: это позволяет изолировать окружения, гибко 
настраивать их и легко переносить конфигурации между системами. 
Атомарные образы (их особенности и нюансы опустим для краткости) стали 
для меня ключевым инструментом.

Сейчас я рассматриваю переход на ALT Linux, однако столкнулся с вопросом 
создания кастомного атомарного образа для домашней системы, который 
соответствовал бы моим потребностям для повседневного использования.

Технологии
На сегодняшний день флагманом в сфере атомарных дистрибутивов я считаю 
решения от Red Hat. Поэтому как и ALT Container OS, я сосредоточился на 
технологиях, которые эта компания активно развивает.
Краеугольным камнем для реализации этой задачи стал *bootc* — 
инструмент, на котором сейчас сфокусирована Red Hat. Его ключевая 
философия заключается в возможности преобразования /*любого*/ 
дистрибутива в атомарный образ при соблюдении определённых технических 
условий.

Подготовка базового образа
За основу берётся OCI-контейнер 
<https://registry.altlinux.org/image/sisyphus%2Fbase/tag/latest> из 
реестра ALT Linux. Для приведения его к совместимости с *bootc* 
выполняется ряд доработок:

1. В образ добавляются все доступные пакеты из репозитория Sisyphus,
    чтобы обеспечить базовую функциональность.

2. Пакеты, отсутствующие в репозитории, собираются вручную с учётом
    зависимостей и специфики ALT Linux.

3. Форк проекта |bootupd| и исправление исходного кода для
    совместимости с ALT.

4. Подготавливаю файловую систему, а именно создаю символьные ссылки,
    переношу директории чтобы структура образа соответствовала
    требованиям *bootc*.

Полученный и подготовленный образ является bootc совместимым и может 
быть использован как для установки так и для обновлений системы.

Установщик
Как оказалось готовых решений совместимых или хотя бы придерживающихся 
принципов совместимости с любым дистрибутивом для установки такого 
образа не существует, проекты привязаны к экосистеме других 
дистрибутивов, в частности bootc-image-builder который использует 
Anaconda установщик неразрывно связан с пакетным менеджером dnf.
Было принято решение сделать свой простенький установщик 
<https://github.com/SkyWar-design/atomic-actions/tree/main/models/installer> 
который бы потенциально мог установить любой bootc совместимый образ но 
в нашем случае полагающийся на готовый образ ALT.

Об изменении системы
Помимо разных вариантов установки программ многим юзерам может 
потребоваться установить пакеты напрямую с помощью встроенного пакетного 
менеджера или его аналогов. В данный момент единственный способ - это 
создание локального Dockerfile который наследует облачный образ и 
применяет в декларативном стиле какие-то команды, по сути любые, 
встроенный помощник системы atomic-actions прячет эту особенность за 
упрощенным вариантом взаимодействия с apt-get, но работает пока в весьма 
упрощенном виде. Теоретически можно попробовать интегрировать 
rpm-ostree, но насколько я знаю он слишком тесно связан с dnf и фокус 
разработки смещен в сторону dnf5 + bootc поэтому проект в будущем будет 
архивным.
Несмотря на кажущуюся абсурдность изменять систему через Dockerfile с 
философской точки зрения это намного удобнее чем спонтанные и хаотичные 
изменения которые привыкли совершать пользователи в системе так как 
любое изменение должно быть отражено и сохранено в файле, к тому же 
Dockerfile является легко переносимым и может быть повторно применен в 
другой аналогичной системе доступной пользователю или на его базе даже 
может быть сформирован образ в облаке.

О хорошем
Проект уже протестирован и работает не только в виртуальной машине но и 
на реальном устройстве, добавлена поддержка nvidia, разработчики из ALT 
Gnome Development поддержали меня и помогают в доработке дистрибутива 
разными маркетинговыми и административными способами.


О плохом
1. Обновления

Размер готового образа на базе gnome со всей пакетной базой сжимается до 
состояния 2.7гб. Это довольно много для того что бы позволить себе часто 
совершать обновления поэтому были предпринятые некоторые шаги для 
улучшения ситуации, а именно базовый образ был сжат до 1 слоя и назван 
например base, затем в облаке выполняется dist-upgrade который наследует 
base образ уже под названием latest итого мы получаем:
- base слой 2,7 гб который редко обновляется
- latest слой который наследует base и содержит в себе результат 
dist-upgrade, знимает от 20 до 150 мегабайт (зависит от обновлений)
Такой подход позволяет получать микро обновления без необходимости 
тянуть весь образ, но есть некоторые сомнения в правильности этого 
подхода, возможно dist-upgrade может изменить модули которые связаны с 
определенной версией ядра, но ядро у нас хранится в base слое и случится 
конфликт, если это произойдет то будет разумным перенести формирование 
ядра и других ключевых вещей в latest слой вместо base. Тут вопрос 
скорее к знатокам, мне не хватает знаний что бы предугадать такого рода 
проблемы, а протестировать такой вариант не представляется возможным.

2. Совместимость пакетов

Что касается обновлений, ostree как указано в этом коммите 
<https://github.com/ostreedev/ostree/pull/3166/commits/f81b9fa1666c62a024d5ca0bbe876321f72529c7> 
уже давно полностью игнорирует папку /var оставляя ее на совесть 
пользователя. Предполагается что идеально совместимая система - это 
система которая хранит себя в /usr.
Понятное дело что любая система далека от такой философии поэтому при 
установку *новых* пакетов которым требуется папка в /var нужно быть 
особенно аккуратными и либо создавать папку на стороне клиента с помощью 
tmpfiles.d или придумывать какие-то другие варианты решения проблемы, я 
хочу посмотреть как это делают другие дистрибутивы что бы найти 
оптимальный путь.

Re: [devel-distro] Атомарный образ

[Дмитрий]

Если я правильно понял вопрос о мейнтейнерах, то для них, по сути, 
ничего не меняется, когда система на основе |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#

31.01.2025 17:10, Евгений Синельников пишет:
> Дмитрий,
>
> спасибо за подробное описание, внятное изложение и полезные ссылки.
>
> Думаю, эту историю нужно "переварить". Хотелось бы понять и осмыслить 
> куда мы движемся и общий прогресс вместе с нами куда движется.
>
> В каком смысле оказывается, в этом случае, существенной роль 
> сопровождающего пакетной базы - то есть, мэйнтейнера?
>
> Как не разорваться между этими мирами - пакетным и контейнерным?
>
> По уму, кроме таких артефактов, как gear-репозитрии, rpm-пакеты, 
> apt-репозитории и iso-образы, уже имеются docker/podman, flatpak (и 
> др.) образы...
>
> А тут мы получаем еще образы, и тоже через генерацию докерных чрутов, 
> при этом rpm-базу зачем-то им выпиливаем...
>
> https://github.com/alt-gnome/alt-atomic
>
> Хотя, в целом, понятно зачем -  используем генерацию docker-образов 
> вместо оригинальной.
>
> В общем, спасибо, интересная тема. Но концептуальные детали нужно 
> вычитывать. Видимо, из первоисточников. Какие посоветуете?
>
> PS: схема доверенной сборки контейнеров на сборочнице у нас, кстати, 
> прорабатывалась. Как для iso-образов, так и для docker-контейнеров. 
> Нужны добровольцы для развития и отладки этой истории. Особенно, и в 
> первую очередь, в рамках сообщества.
>
>
>
> 31 января 2025 г. 14:30:37 GMT+04:00, "Дмитрий" <dmitry@udalov.online> 
> пишет:
>
>     Здравствуйте, хотел бы обсудить реализацию атомарного образа для
>     домашних систем. Описание текущего состояния проекта: ссылка
>     <https://atomic.alt-gnome.ru/> Вступление Компания ALT уже активно
>     внедряет технологии атомарных образов в серверных решениях — ярким
>     примером служит проект ALT Container OS. Эти образы ориентированы
>     на массовое развертывание, эффективное администрирование серверов,
>     минималистичный подход и решение узкоспециализированных задач. Как
>     разработчик, я организовал рабочую среду на домашнем компьютере с
>     использованием контейнеров: это позволяет изолировать окружения,
>     гибко настраивать их и легко переносить конфигурации между
>     системами. Атомарные образы (их особенности и нюансы опустим для
>     краткости) стали для меня ключевым инструментом. Сейчас я
>     рассматриваю переход на ALT Linux, однако столкнулся с вопросом
>     создания кастомного атомарного образа для домашней системы,
>     который соответствовал бы моим потребностям для повседневного
>     использования. Технологии На сегодняшний день флагманом в сфере
>     атомарных дистрибутивов я считаю решения от Red Hat. Поэтому как и
>     ALT Container OS, я сосредоточился на технологиях, которые эта
>     компания активно развивает. Краеугольным камнем для реализации
>     этой задачи стал *bootc* — инструмент, на котором сейчас
>     сфокусирована Red Hat. Его ключевая философия заключается в
>     возможности преобразования /*любого*/ дистрибутива в атомарный
>     образ при соблюдении определённых технических условий. Подготовка
>     базового образа За основу берётся OCI-контейнер
>     <https://registry.altlinux.org/image/sisyphus%2Fbase/tag/latest>
>     из реестра ALT Linux. Для приведения его к совместимости с *bootc*
>     выполняется ряд доработок: 1. В образ добавляются все доступные
>     пакеты из репозитория Sisyphus,    чтобы обеспечить базовую
>     функциональность. 2. Пакеты, отсутствующие в репозитории,
>     собираются вручную с учётом    зависимостей и специфики ALT Linux.
>     3. Форк проекта |bootupd| и исправление исходного кода для   
>     совместимости с ALT. 4. Подготавливаю файловую систему, а именно
>     создаю символьные ссылки,    переношу директории чтобы структура
>     образа соответствовала    требованиям *bootc*. Полученный и
>     подготовленный образ является bootc совместимым и может быть
>     использован как для установки так и для обновлений системы.
>     Установщик Как оказалось готовых решений совместимых или хотя бы
>     придерживающихся принципов совместимости с любым дистрибутивом для
>     установки такого образа не существует, проекты привязаны к
>     экосистеме других дистрибутивов, в частности bootc-image-builder
>     который использует Anaconda установщик неразрывно связан с
>     пакетным менеджером dnf. Было принято решение сделать свой
>     простенький установщик
>     <https://github.com/SkyWar-design/atomic-actions/tree/main/models/installer>
>     который бы потенциально мог установить любой bootc совместимый
>     образ но в нашем случае полагающийся на готовый образ ALT. Об
>     изменении системы Помимо разных вариантов установки программ
>     многим юзерам может потребоваться установить пакеты напрямую с
>     помощью встроенного пакетного менеджера или его аналогов. В данный
>     момент единственный способ - это создание локального Dockerfile
>     который наследует облачный образ и применяет в декларативном стиле
>     какие-то команды, по сути любые, встроенный помощник системы
>     atomic-actions прячет эту особенность за упрощенным вариантом
>     взаимодействия с apt-get, но работает пока в весьма упрощенном
>     виде. Теоретически можно попробовать интегрировать rpm-ostree, но
>     насколько я знаю он слишком тесно связан с dnf и фокус разработки
>     смещен в сторону dnf5 + bootc поэтому проект в будущем будет
>     архивным. Несмотря на кажущуюся абсурдность изменять систему через
>     Dockerfile с философской точки зрения это намного удобнее чем
>     спонтанные и хаотичные изменения которые привыкли совершать
>     пользователи в системе так как любое изменение должно быть
>     отражено и сохранено в файле, к тому же Dockerfile является легко
>     переносимым и может быть повторно применен в другой аналогичной
>     системе доступной пользователю или на его базе даже может быть
>     сформирован образ в облаке. О хорошем Проект уже протестирован и
>     работает не только в виртуальной машине но и на реальном
>     устройстве, добавлена поддержка nvidia, разработчики из ALT Gnome
>     Development поддержали меня и помогают в доработке дистрибутива
>     разными маркетинговыми и административными способами. О плохом 1.
>     Обновления Размер готового образа на базе gnome со всей пакетной
>     базой сжимается до состояния 2.7гб. Это довольно много для того
>     что бы позволить себе часто совершать обновления поэтому были
>     предпринятые некоторые шаги для улучшения ситуации, а именно
>     базовый образ был сжат до 1 слоя и назван например base, затем в
>     облаке выполняется dist-upgrade который наследует base образ уже
>     под названием latest итого мы получаем: - base слой 2,7 гб который
>     редко обновляется - latest слой который наследует base и содержит
>     в себе результат dist-upgrade, знимает от 20 до 150 мегабайт
>     (зависит от обновлений) Такой подход позволяет получать микро
>     обновления без необходимости тянуть весь образ, но есть некоторые
>     сомнения в правильности этого подхода, возможно dist-upgrade может
>     изменить модули которые связаны с определенной версией ядра, но
>     ядро у нас хранится в base слое и случится конфликт, если это
>     произойдет то будет разумным перенести формирование ядра и других
>     ключевых вещей в latest слой вместо base. Тут вопрос скорее к
>     знатокам, мне не хватает знаний что бы предугадать такого рода
>     проблемы, а протестировать такой вариант не представляется
>     возможным. 2. Совместимость пакетов Что касается обновлений,
>     ostree как указано в этом коммите
>     <https://github.com/ostreedev/ostree/pull/3166/commits/f81b9fa1666c62a024d5ca0bbe876321f72529c7>
>     уже давно полностью игнорирует папку /var оставляя ее на совесть
>     пользователя. Предполагается что идеально совместимая система -
>     это система которая хранит себя в /usr. Понятное дело что любая
>     система далека от такой философии поэтому при установку *новых*
>     пакетов которым требуется папка в /var нужно быть особенно
>     аккуратными и либо создавать папку на стороне клиента с помощью
>     tmpfiles.d или придумывать какие-то другие варианты решения
>     проблемы, я хочу посмотреть как это делают другие дистрибутивы что
>     бы найти оптимальный путь.
>     ------------------------------------------------------------------------
>     devel-distro mailing list devel-distro@lists.altlinux.org
>     https://lists.altlinux.org/mailman/listinfo/devel-distro
>

Re: [devel-distro] Атомарный образ

[Дмитрий]

В данный момент я считаю что самое важное влияние которое оказывают 
мейнтейнеры и пакетная база в репозитории на такой образ - это 
следование следующим декларативам:

https://www.freedesktop.org/software/systemd/man/latest/systemd-sysusers.html

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

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

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# 
>
>
> 31.01.2025 17:10, Евгений Синельников пишет:
>> Дмитрий,
>>
>> спасибо за подробное описание, внятное изложение и полезные ссылки.
>>
>> Думаю, эту историю нужно "переварить". Хотелось бы понять и осмыслить 
>> куда мы движемся и общий прогресс вместе с нами куда движется.
>>
>> В каком смысле оказывается, в этом случае, существенной роль 
>> сопровождающего пакетной базы - то есть, мэйнтейнера?
>>
>> Как не разорваться между этими мирами - пакетным и контейнерным?
>>
>> По уму, кроме таких артефактов, как gear-репозитрии, rpm-пакеты, 
>> apt-репозитории и iso-образы, уже имеются docker/podman, flatpak (и 
>> др.) образы...
>>
>> А тут мы получаем еще образы, и тоже через генерацию докерных чрутов, 
>> при этом rpm-базу зачем-то им выпиливаем...
>>
>> https://github.com/alt-gnome/alt-atomic
>>
>> Хотя, в целом, понятно зачем -  используем генерацию docker-образов 
>> вместо оригинальной.
>>
>> В общем, спасибо, интересная тема. Но концептуальные детали нужно 
>> вычитывать. Видимо, из первоисточников. Какие посоветуете?
>>
>> PS: схема доверенной сборки контейнеров на сборочнице у нас, кстати, 
>> прорабатывалась. Как для iso-образов, так и для docker-контейнеров. 
>> Нужны добровольцы для развития и отладки этой истории. Особенно, и в 
>> первую очередь, в рамках сообщества.
>>
>>
>>
>> 31 января 2025 г. 14:30:37 GMT+04:00, "Дмитрий" 
>> <dmitry@udalov.online> пишет:
>>
>>     Здравствуйте, хотел бы обсудить реализацию атомарного образа для
>>     домашних систем. Описание текущего состояния проекта: ссылка
>>     <https://atomic.alt-gnome.ru/> Вступление Компания ALT уже активно
>>     внедряет технологии атомарных образов в серверных решениях — ярким
>>     примером служит проект ALT Container OS. Эти образы ориентированы
>>     на массовое развертывание, эффективное администрирование серверов,
>>     минималистичный подход и решение узкоспециализированных задач. Как
>>     разработчик, я организовал рабочую среду на домашнем компьютере с
>>     использованием контейнеров: это позволяет изолировать окружения,
>>     гибко настраивать их и легко переносить конфигурации между
>>     системами. Атомарные образы (их особенности и нюансы опустим для
>>     краткости) стали для меня ключевым инструментом. Сейчас я
>>     рассматриваю переход на ALT Linux, однако столкнулся с вопросом
>>     создания кастомного атомарного образа для домашней системы,
>>     который соответствовал бы моим потребностям для повседневного
>>     использования. Технологии На сегодняшний день флагманом в сфере
>>     атомарных дистрибутивов я считаю решения от Red Hat. Поэтому как и
>>     ALT Container OS, я сосредоточился на технологиях, которые эта
>>     компания активно развивает. Краеугольным камнем для реализации
>>     этой задачи стал *bootc* — инструмент, на котором сейчас
>>     сфокусирована Red Hat. Его ключевая философия заключается в
>>     возможности преобразования /*любого*/ дистрибутива в атомарный
>>     образ при соблюдении определённых технических условий. Подготовка
>>     базового образа За основу берётся OCI-контейнер
>> <https://registry.altlinux.org/image/sisyphus%2Fbase/tag/latest>
>>     из реестра ALT Linux. Для приведения его к совместимости с *bootc*
>>     выполняется ряд доработок: 1. В образ добавляются все доступные
>>     пакеты из репозитория Sisyphus,    чтобы обеспечить базовую
>>     функциональность. 2. Пакеты, отсутствующие в репозитории,
>>     собираются вручную с учётом    зависимостей и специфики ALT Linux.
>>     3. Форк проекта |bootupd| и исправление исходного кода для
>>     совместимости с ALT. 4. Подготавливаю файловую систему, а именно
>>     создаю символьные ссылки,    переношу директории чтобы структура
>>     образа соответствовала    требованиям *bootc*. Полученный и
>>     подготовленный образ является bootc совместимым и может быть
>>     использован как для установки так и для обновлений системы.
>>     Установщик Как оказалось готовых решений совместимых или хотя бы
>>     придерживающихся принципов совместимости с любым дистрибутивом для
>>     установки такого образа не существует, проекты привязаны к
>>     экосистеме других дистрибутивов, в частности bootc-image-builder
>>     который использует Anaconda установщик неразрывно связан с
>>     пакетным менеджером dnf. Было принято решение сделать свой
>>     простенький установщик
>> <https://github.com/SkyWar-design/atomic-actions/tree/main/models/installer>
>>     который бы потенциально мог установить любой bootc совместимый
>>     образ но в нашем случае полагающийся на готовый образ ALT. Об
>>     изменении системы Помимо разных вариантов установки программ
>>     многим юзерам может потребоваться установить пакеты напрямую с
>>     помощью встроенного пакетного менеджера или его аналогов. В данный
>>     момент единственный способ - это создание локального Dockerfile
>>     который наследует облачный образ и применяет в декларативном стиле
>>     какие-то команды, по сути любые, встроенный помощник системы
>>     atomic-actions прячет эту особенность за упрощенным вариантом
>>     взаимодействия с apt-get, но работает пока в весьма упрощенном
>>     виде. Теоретически можно попробовать интегрировать rpm-ostree, но
>>     насколько я знаю он слишком тесно связан с dnf и фокус разработки
>>     смещен в сторону dnf5 + bootc поэтому проект в будущем будет
>>     архивным. Несмотря на кажущуюся абсурдность изменять систему через
>>     Dockerfile с философской точки зрения это намного удобнее чем
>>     спонтанные и хаотичные изменения которые привыкли совершать
>>     пользователи в системе так как любое изменение должно быть
>>     отражено и сохранено в файле, к тому же Dockerfile является легко
>>     переносимым и может быть повторно применен в другой аналогичной
>>     системе доступной пользователю или на его базе даже может быть
>>     сформирован образ в облаке. О хорошем Проект уже протестирован и
>>     работает не только в виртуальной машине но и на реальном
>>     устройстве, добавлена поддержка nvidia, разработчики из ALT Gnome
>>     Development поддержали меня и помогают в доработке дистрибутива
>>     разными маркетинговыми и административными способами. О плохом 1.
>>     Обновления Размер готового образа на базе gnome со всей пакетной
>>     базой сжимается до состояния 2.7гб. Это довольно много для того
>>     что бы позволить себе часто совершать обновления поэтому были
>>     предпринятые некоторые шаги для улучшения ситуации, а именно
>>     базовый образ был сжат до 1 слоя и назван например base, затем в
>>     облаке выполняется dist-upgrade который наследует base образ уже
>>     под названием latest итого мы получаем: - base слой 2,7 гб который
>>     редко обновляется - latest слой который наследует base и содержит
>>     в себе результат dist-upgrade, знимает от 20 до 150 мегабайт
>>     (зависит от обновлений) Такой подход позволяет получать микро
>>     обновления без необходимости тянуть весь образ, но есть некоторые
>>     сомнения в правильности этого подхода, возможно dist-upgrade может
>>     изменить модули которые связаны с определенной версией ядра, но
>>     ядро у нас хранится в base слое и случится конфликт, если это
>>     произойдет то будет разумным перенести формирование ядра и других
>>     ключевых вещей в latest слой вместо base. Тут вопрос скорее к
>>     знатокам, мне не хватает знаний что бы предугадать такого рода
>>     проблемы, а протестировать такой вариант не представляется
>>     возможным. 2. Совместимость пакетов Что касается обновлений,
>>     ostree как указано в этом коммите
>> <https://github.com/ostreedev/ostree/pull/3166/commits/f81b9fa1666c62a024d5ca0bbe876321f72529c7>
>>     уже давно полностью игнорирует папку /var оставляя ее на совесть
>>     пользователя. Предполагается что идеально совместимая система -
>>     это система которая хранит себя в /usr. Понятное дело что любая
>>     система далека от такой философии поэтому при установку *новых*
>>     пакетов которым требуется папка в /var нужно быть особенно
>>     аккуратными и либо создавать папку на стороне клиента с помощью
>>     tmpfiles.d или придумывать какие-то другие варианты решения
>>     проблемы, я хочу посмотреть как это делают другие дистрибутивы что
>>     бы найти оптимальный путь.
>> ------------------------------------------------------------------------
>>     devel-distro mailing list devel-distro@lists.altlinux.org
>>     https://lists.altlinux.org/mailman/listinfo/devel-distro
>>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

Re: [devel-distro] Атомарный образ

[Arseny Maslennikov]

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

> 31 января 2025 г. 14:30:37 GMT+04:00, "Дмитрий" <dmitry@udalov.online> пишет:
> > Здравствуйте, хотел бы обсудить реализацию атомарного образа для домашних систем.
> > Описание текущего состояния проекта: ссылка <https://atomic.alt-gnome.ru/>
> 
On Fri, Jan 31, 2025 at 03:10:44PM +0400, Евгений Синельников wrote:
> Дмитрий,
> 
> спасибо за подробное описание, внятное изложение и полезные ссылки.
> 
> Думаю, эту историю нужно "переварить". Хотелось бы понять и осмыслить
> куда мы движемся и общий прогресс вместе с нами куда движется. В каком
> смысле оказывается, в этом случае, существенной роль сопровождающего
> пакетной базы - то есть, мэйнтейнера? Как не разорваться между этими
> мирами - пакетным и контейнерным?

Они концентрически вкладываются друг в друга. Пакеты формируются и
сопровождаются по-прежнему, а из них уже (для тех, кому так удобнее)
складываются образы.

Вообще, насколько я понимаю, всё это движение за распространение ОС в
образах не пытается совсем вытеснить пакеты (кроме фанатиков от GNOME OS
people — тот же человек-colord Richard Hughes успел 6 лет назад нагло
объявить[1], что packagekit устарел — будто он в одно лицо это решает! —
но и фиг с ними), а предлагает альтернативные механизмы обновления и,
возможно, установки.
Лучше эти механизмы, чем существующие, или хуже, каждый решает сам...

Они говорят: мол, чем держать btrfs + timeshift, плодить там сложность и
хранимую избыточность, лучше перетащить хранимую избыточность в
инфраструктуру доставки + установки, на тот же уровень, где apt и rpm, а
также упростить эту инфраструктуру, ещё увеличив эту хранимую
избыточность. (Все ж согласны, что домашнему пользователю терабайтный
диск нужен не для лично ценных данных, а для бесконечных логов и
доккерных слоёв. %D %D %D)

Главный, imho, аргумент в пользу всего этого — R/O /usr надёжнее, чем R/W
/usr.

Есть ещё те, кто и так собирает герметичную ОС-прошивку и никогда не
делал никаких распространяемых независимо пакетов, вроде yocto. Мы тоже
не про них.

[1] https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/

> По уму, кроме таких артефактов, как gear-репозитории, rpm-пакеты,
> apt-репозитории и iso-образы, уже имеются docker/podman, flatpak (и
> др.) образы... 
> А тут мы получаем еще образы, и тоже через генерацию докерных чрутов,
> при этом rpm-базу зачем-то им выпиливаем...
> https://github.com/alt-gnome/alt-atomic
> Хотя, в целом, понятно зачем -  используем генерацию docker-образов
> вместо оригинальной. 

Я не всё понял в первом тексте Дмитрия (много как buzzwords, так и
совсем непонятных утверждений), но удалось выцепить идею применять
Docker при подготовке ОС для настольной персоналки, а то и в процессе её
использования.

Конкретно Docker для этого не подходит, он не предназначен для
применения в самосопровождающейся инсталляции, т. е. с отсутствующим
сисадмином.

Да и из примера по ссылке не очень понятно, что Docker даёт такого, чего
нельзя добиться без него.

> В общем, спасибо, интересная тема. Но концептуальные детали нужно
> вычитывать. Видимо, из первоисточников. Какие посоветуете?
> 
> PS: схема доверенной сборки контейнеров на сборочнице у нас, кстати,
> прорабатывалась. Как для iso-образов, так и для docker-контейнеров.
> Нужны добровольцы для развития и отладки этой истории. Особенно, и в
> первую очередь, в рамках сообщества.

Да, конечно, мы всегда рады предложениям. Я к image based updates,
особенно в свете альта как операционки общего назначения, отношусь
скорее скептически, но если есть желающие развивать такой путь
и желающие этим пользоваться — почему нет. :)

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

Re: [devel-distro] Атомарный образ

[Дмитрий]

Согласен что каждый решает какой механизм использовать, но если оно не 
мешает друг друга почему бы и его не развивать по /тихоньку/? На мой 
взгляд это только в плюс пойдет сообществу ALT.

Что касается количества слоев ostree внутри машины, по умолчанию их 
всегда два, акутальный и предыдущий. Есть возможно "закрепить" состояние 
и тогда будет еще один слой, зависит от использования.

Боюсь ошибиться но timeshift в регулярном образе максимально будет 
хранить около 20 бэкапов для @ и @home, но конечно это все можно 
настроить. Я это скорее к тому что избыточность определяет пользователь 
и дистрибьютор и если оно избыточно - значит таков был план )

Вижу здесь избыточность у самой технологии только в размере базового 
образа, но тут есть куда стремиться и как оптимизировать доставку, я 
пока не достиг полного понимания в этом вопросе.

31.01.2025 19:51, Arseny Maslennikov пишет:
>> 31 января 2025 г. 14:30:37 GMT+04:00, "Дмитрий" <dmitry@udalov.online> пишет:
>>> Здравствуйте, хотел бы обсудить реализацию атомарного образа для домашних систем.
>>> Описание текущего состояния проекта: ссылка <https://atomic.alt-gnome.ru/>
> On Fri, Jan 31, 2025 at 03:10:44PM +0400, Евгений Синельников wrote:
>> Дмитрий,
>>
>> спасибо за подробное описание, внятное изложение и полезные ссылки.
>>
>> Думаю, эту историю нужно "переварить". Хотелось бы понять и осмыслить
>> куда мы движемся и общий прогресс вместе с нами куда движется. В каком
>> смысле оказывается, в этом случае, существенной роль сопровождающего
>> пакетной базы - то есть, мэйнтейнера? Как не разорваться между этими
>> мирами - пакетным и контейнерным?
> Они концентрически вкладываются друг в друга. Пакеты формируются и
> сопровождаются по-прежнему, а из них уже (для тех, кому так удобнее)
> складываются образы.
>
> Вообще, насколько я понимаю, всё это движение за распространение ОС в
> образах не пытается совсем вытеснить пакеты (кроме фанатиков от GNOME OS
> people — тот же человек-colord Richard Hughes успел 6 лет назад нагло
> объявить[1], что packagekit устарел — будто он в одно лицо это решает! —
> но и фиг с ними), а предлагает альтернативные механизмы обновления и,
> возможно, установки.
> Лучше эти механизмы, чем существующие, или хуже, каждый решает сам...
>
> Они говорят: мол, чем держать btrfs + timeshift, плодить там сложность и
> хранимую избыточность, лучше перетащить хранимую избыточность в
> инфраструктуру доставки + установки, на тот же уровень, где apt и rpm, а
> также упростить эту инфраструктуру, ещё увеличив эту хранимую
> избыточность. (Все ж согласны, что домашнему пользователю терабайтный
> диск нужен не для лично ценных данных, а для бесконечных логов и
> доккерных слоёв. %D %D %D)
>
> Главный, imho, аргумент в пользу всего этого — R/O /usr надёжнее, чем R/W
> /usr.
>
> Есть ещё те, кто и так собирает герметичную ОС-прошивку и никогда не
> делал никаких распространяемых независимо пакетов, вроде yocto. Мы тоже
> не про них.
>
> [1] https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
>
>> По уму, кроме таких артефактов, как gear-репозитории, rpm-пакеты,
>> apt-репозитории и iso-образы, уже имеются docker/podman, flatpak (и
>> др.) образы...
>> А тут мы получаем еще образы, и тоже через генерацию докерных чрутов,
>> при этом rpm-базу зачем-то им выпиливаем...
>> https://github.com/alt-gnome/alt-atomic
>> Хотя, в целом, понятно зачем -  используем генерацию docker-образов
>> вместо оригинальной.
> Я не всё понял в первом тексте Дмитрия (много как buzzwords, так и
> совсем непонятных утверждений), но удалось выцепить идею применять
> Docker при подготовке ОС для настольной персоналки, а то и в процессе её
> использования.
>
> Конкретно Docker для этого не подходит, он не предназначен для
> применения в самосопровождающейся инсталляции, т. е. с отсутствующим
> сисадмином.
>
> Да и из примера по ссылке не очень понятно, что Docker даёт такого, чего
> нельзя добиться без него.
>
>> В общем, спасибо, интересная тема. Но концептуальные детали нужно
>> вычитывать. Видимо, из первоисточников. Какие посоветуете?
>>
>> PS: схема доверенной сборки контейнеров на сборочнице у нас, кстати,
>> прорабатывалась. Как для iso-образов, так и для docker-контейнеров.
>> Нужны добровольцы для развития и отладки этой истории. Особенно, и в
>> первую очередь, в рамках сообщества.
> Да, конечно, мы всегда рады предложениям. Я к image based updates,
> особенно в свете альта как операционки общего назначения, отношусь
> скорее скептически, но если есть желающие развивать такой путь
> и желающие этим пользоваться — почему нет. :)

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

[Arseny Maslennikov]

[-- 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 --]

Re: [devel-distro] sysusers

[Vitaly Lipatov]

Arseny Maslennikov писал(а) 31.1.25 17:30:
...
> Мы (как минимум в моём лице) давно мечтаем переехать на декларативное
> описание "системных" 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://bugzilla.altlinux.org/52893


-- 
С уважением,
Виталий Липатов,
ALT Linux Team