Cоздание и обновление OSTree-репозитория NiceOS

1. Введение

Что такое OSTree — простыми словами
  • OSTree — это «git для операционной системы».
  • Хранит снапшоты (коммиты) файловой системы.
  • Используется в RPM-OSTree для сборки иммутабельных (неизменяемых) систем.
Зачем нужен OSTree-репозиторий в NiceOS
  • Централизованное распространение обновлений системы.
  • Установка NiceOS из готового дерева пакетов.
  • Возможность откатов и атомарных апдейтов.
Почему нужен этот скрипт
  • Автоматизирует процесс инициализации и обновления OSTree-репозитория.
  • Подготавливает все необходимые файлы: .repo, treefile, структуру каталогов.
  • Делает процесс воспроизводимым и удобным для CI/CD.

2. Предварительные знания и требования

Что нужно знать
  • Базовые термины: пакетный менеджер, репозиторий, releasever, architecture.
  • Минимальные навыки работы в терминале.
Необходимые утилиты
  • rpm-ostree
  • ostree
  • (опционально) tdnf — для автоустановки зависимостей.
Прочие требования
  • Доступ к интернету для загрузки пакетов.
  • Права суперпользователя (если нужно ставить зависимости).

3. Как устроен процесс сборки OSTree

Сборка OSTree — это конвейер из нескольких шагов: описываем состав системы в treefile, указываем источники пакетов через .repo-файлы, выбираем целевую ветку ref, создаём коммит и обновляем summary, чтобы клиенты могли получать обновления.

3.1 Treefile (JSON): состав системы

Treefile — это JSON-файл, который описывает, какие пакеты и настройки войдут в образ системы. Его читает rpm-ostree compose tree и по нему собирает корневое дерево (rootfs).

  • Указывает имя ОС (osname), версию релиза (releasever) и целевой ref.
  • Содержит список используемых RPM-репозиториев (repos) по их ID.
  • Определяет набор пакетов (packages) и, при необходимости, пакеты для конкретной архитектуры (packages-x86_64 и т. п.).
  • Может включать системные юниты, опции dracut, SELinux и другие параметры.
Мини-пример: только идея состава
{
  "osname": "niceos",
  "releasever": "5.2",
  "ref": "niceos/5.2/x86_64/minimal",
  "repos": ["niceos", "niceos-updates", "niceos-extras"],
  "packages": ["bash", "systemd", "linux"]
}
Подсказка Держите treefile в git-репозитории: так удобно отслеживать изменения состава образа между сборками.

3.2 .repo-файлы: откуда брать пакеты

.repo-файлы описывают источники RPM-пакетов для DNF. Во время сборки их читает rpm-ostree (через dnf/libdnf) и на их основе загружает нужные пакеты, перечисленные в treefile.

Пример: niceos.repo
[niceos]
name=NiceOS $releasever ($basearch)
baseurl=https://p3.niceos.ru/niceos/$releasever/core
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-NICEOS
Пример: niceos-updates.repo
[niceos-updates]
name=NiceOS Updates $releasever ($basearch)
baseurl=https://p3.niceos.ru/niceos/$releasever/updates
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-NICEOS
Важно Если DNF не видит ваши .repo, сборка упадёт с ошибкой «Unknown rpm-md repository: …». Проверьте расположение файлов и совпадение ID репозиториев с именами в treefile.repos.

3.3 Рефы (refs): ветки репозитория

Ref — это «ветка» в OSTree, по которой клиенты обращаются к нужному дереву (снимку системы). Именование обычно следует схеме:

osname/releasever/arch/profile
# пример:
niceos/5.2/x86_64/minimal
  • Как клиенту выбрать ветку? Клиент знает свой arch, выбирает нужный releasever и желаемый profile (например, minimal или workstation), и подписывается на соответствующий ref.
  • Один репозиторий может содержать много рефов для разных редакций и архитектур.

3.4 Коммиты и summary: публикация результатов

Каждый запуск сборки создаёт новый коммит — зафиксированное состояние файловой системы. Клиенты получают обновления, когда в репозитории появляется новый коммит по их ref.

Обновление и просмотр summary
# обновить summary
ostree summary --repo=/path/to/repo --update

# показать подробности summary
ostree summary -v --repo=/path/to/repo
Результат После успешной сборки у вас есть новый коммит в ветке ref, а клиенты смогут его увидеть и применить благодаря обновлённому summary.

4. Что делает скрипт mkostreerepo

Скрипт автоматизирует полный цикл подготовки OSTree-репозитория: от разбора параметров и подготовки каталогов до сборки дерева, создания коммита и публикации summary. Ниже — процесс по шагам, максимально прозрачно и дружелюбно.

4.1 Разбор аргументов

Скрипт принимает ключевые параметры: где хранить данные репозитория, где лежат .repo, какой treefile использовать и т. д. В большинстве случаев достаточно указать только --repopath — остальное он сделает сам.

  • --repopath — рабочая папка (внутри появятся repo/ и cache/).
  • --treefile — пользовательский JSON; если не указан — будет сгенерирован минимальный.
  • --generate-default-repos/--no-default-repos — управляет автогенерацией .repo.
  • --reposdir, --osname, --releasever, --arch, --ref, --repo-mode — тонкая настройка.
# типовой запуск: всё по умолчанию, только путь
mkostreerepo --repopath=/srv/niceos/repos.d --verbose

# с явным treefile и каталогом .repo
mkostreerepo \
  --repopath=/srv/niceos/ostree \
  --treefile=./my-tree.json \
  --reposdir=/srv/niceos/repos.d \
  --no-default-repos --verbose

4.2 Подготовка каталогов

Скрипт создаёт рабочую структуру и нормализует пути. Это гарантирует повторяемость и чистоту окружения.

  • REPOPATH — корень рабочей области.
  • REPODATAPATH = REPOPATH/repo — сам OSTree-репозиторий.
  • CACHEDATAPATH = REPOPATH/cache — кэш сборки.
  • REPOSDIR — каталог с .repo (автодетект или явно).
/srv/niceos/repos.d/
├─ repo/    # объекты OSTree, refs, summary
├─ cache/   # кэш rpm-ostree compose
└─ *.repo   # при автогенерации или если вы положили их сюда сами

4.3 Проверка зависимостей

Перед сборкой требуется наличие rpm-ostree и ostree. Опционально — tdnf для автоматической установки (если включено соответствующим флагом).

rpm-ostree --version
ostree --version
# при использовании автоустановки:
# mkostreerepo --repopath=... --auto-install
Если команды не найдены — установите пакеты из дистрибутива или запустите скрипт с --auto-install (там, где доступен tdnf).

4.4 Настройка каталога .repo

Если .repo не найдены, скрипт создаст дефолтные файлы с ID niceos, niceos-updates, niceos-extras. Эти ID должны совпадать с именами в repos внутри treefile.

Пример: niceos.repo
[niceos]
name=NiceOS $releasever ($basearch)
baseurl=https://p3.niceos.ru/niceos/$releasever/core
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-NICEOS
Пример: niceos-updates.repo
[niceos-updates]
name=NiceOS Updates $releasever ($basearch)
baseurl=https://p3.niceos.ru/niceos/$releasever/updates
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-NICEOS
Если DNF не видит ваши .repo, сборка завершится с ошибкой Unknown rpm-md repository. Проверьте расположение файлов и совпадение ID.

4.5 Подготовка treefile

Если вы не указали свой JSON, скрипт сгенерирует минимальный treefile с базовыми пакетами, рефом и привязкой к вашим .repo.

{
  "osname": "niceos",
  "releasever": "5.2",
  "ref": "niceos/5.2/x86_64/minimal",
  "repos": ["niceos", "niceos-updates", "niceos-extras"],
  "packages": ["bash", "systemd", "linux"]
}
Держите ваш treefile в системе контроля версий (git) — это упростит аудит изменений.

4.6 Инициализация репозитория (первый запуск)

При первом запуске скрипт создаёт новый репозиторий в режиме archive-z2 (оптимально для публикации по HTTP/HTTPS).

# выполняется автоматически при отсутствии refs
ostree --repo=/srv/niceos/repos.d/repo init --mode=archive-z2

4.7 Сборка дерева

Главный шаг: rpm-ostree compose tree читает ваш treefile и .repo, собирает rootfs, а затем записывает новый коммит в репозиторий.

rpm-ostree compose tree --unified-core \
  --cachedir=/srv/niceos/repos.d/cache \
  --repo=/srv/niceos/repos.d/repo \
  /srv/niceos/repos.d/niceos-base.json
  • По завершении появляется новый коммит по вашему ref.
  • Повторный запуск → следующий коммит (история изменений сохраняется).

4.8 Обновление summary

После каждого коммита скрипт обновляет индекс summary — он нужен клиентам, чтобы быстро увидеть новые версии и доступные рефы.

ostree summary --repo=/srv/niceos/repos.d/repo --update
ostree summary -v --repo=/srv/niceos/repos.d/repo

4.9 Вывод информации

В конце скрипт сообщает, какой REF использован, какой получен commit SHA, и где лежит репозиторий. Это удобно для логов и CI.

# узнать последний коммит по ref вручную
ostree --repo=/srv/niceos/repos.d/repo rev-parse niceos/5.2/x86_64/minimal
# пример вывода:
# 1a2b3c4d5e6f7... (укорочено)
Готово! Репозиторий обновлён: клиенты увидят новый коммит по вашему ref и смогут применить обновление.

6. Как проверить результат

После успешного запуска вы хотите убедиться, что в репозитории появился реф, у него есть новый коммит, а индекс summary указывает на актуальное состояние. Ниже — три быстрых, но исчерпывающих проверки и как интерпретировать вывод.

6.1 Список рефов: есть ли нужная ветка?

Посмотрите, какие ветки (refs) присутствуют в репозитории. В списке должен быть ваш целевой ref.

ostree --repo=/srv/niceos/repos.d/repo refs

Ожидаемый фрагмент вывода:

niceos/5.2/x86_64/minimal
# ...возможны и другие ветки (workstation, server, testing)
  • Что проверить: нужный реф niceos/5.2/x86_64/minimal присутствует в списке.
  • Если его нет: сборка могла не дойти до коммита или реф отличается от ожидаемого (проверьте ref в treefile и логи сборки).
Быстрая проверка «в одну строку»: ostree --repo=... refs | grep -F "niceos/5.2/x86_64/minimal". Если строка не найдена — ветка не создана.
6.2 История коммитов: создан ли новый снимок?

Посмотрите историю для конкретного рефа. Свежий коммит должен стоять первым.

ostree --repo=/srv/niceos/repos.d/repo log niceos/5.2/x86_64/minimal

Пример верхушки лога:

commit 1a2b3c4d5e6f7...                # SHA коммита
Date:   2025-08-13 08:37:21 +0000     # время сборки
Version: 5.2_minimal.20250813.0837    # если добавляете метаданные версии
(no subject)

# parent e9f8d7c6b5a4...              # предыдущий коммит (если не первый)
  • Что проверить: есть строка commit ... — это SHA нового снимка.
  • Сверка «коротким путём»:
    ostree --repo=/srv/niceos/repos.d/repo rev-parse niceos/5.2/x86_64/minimal
    Полученный SHA должен совпадать с верхним коммитом из log.
  • Если лог пустой: коммит не записан — проверьте код возврата сборки и rpm-ostree compose tree логи.
Хотите увидеть содержимое снимка? Полезны команды: ostree ls -R --repo=... <SHA> / или ostree show --repo=... <SHA> — для быстрой ревизии метаданных.
6.3 Индекс summary: опубликовано ли актуальное состояние?

Индекс summary должен ссылаться на тот же коммит, что вы увидели в логе. Это то, что увидят клиенты при обращении к репозиторию.

ostree summary -v --repo=/srv/niceos/repos.d/repo

На что смотреть в выводе:

  • Timestamp / Last-Modified — свежая дата генерации индекса.
  • Секция со списком рефов — среди них должен быть niceos/5.2/x86_64/minimal.
  • Для этого рефа указан последний SHA — он должен совпасть с тем, что вернул rev-parse.
Если SHA не совпадает или реф отсутствует:
1) Перегенерируйте индекс: ostree summary --repo=... --update.
2) Убедитесь, что вы смотрите на тот же путь --repo, где создавался коммит.
3) Проверьте права доступа и наличие файла summary в каталоге репозитория.
Итог проверки Реф существует, лог показывает свежий коммит, а summary указывает на его же SHA — репозиторий готов для клиентов.
Мини-чеклист «всё сходится»
  1. В refs есть niceos/5.2/x86_64/minimal.
  2. rev-parse выдаёт SHA, совпадающий с верхним коммитом в log.
  3. summary -v показывает тот же SHA и актуальную дату.

7. Что делать дальше

После того как репозиторий OSTree успешно собран и проверен, следующим шагом будет его публикация, подключение клиентов и организация дальнейших обновлений.

7.1 Публикация репозитория
  • Разместите содержимое каталога repo/ на веб-сервере (HTTP или HTTPS).
  • Проверьте, что клиент может скачать summary и объекты по прямой ссылке.
  • При использовании HTTPS убедитесь в корректности TLS-сертификата.
Рекомендуется использовать nginx или Apache и настраивать кэширование объектов для ускорения загрузки клиентами.
7.2 Настройка клиента

На клиентской системе необходимо:

  1. Создать .repo-файл с baseurl, указывающим на ваш веб-сервер с OSTree.
  2. Использовать rpm-ostree rebase для переключения на ваш реф.
rpm-ostree rebase niceos:$(arch) niceos/5.2/x86_64/minimal
Перед ребейзом рекомендуется сохранить все важные данные, так как переключение изменит базовую файловую систему.
7.3 Обновления
  • При изменении состава пакетов или конфигураций снова запустите скрипт для формирования нового коммита.
  • Клиенты смогут получить обновление командой rpm-ostree upgrade.
OSTree обеспечивает атомарность обновлений: новая версия загружается параллельно, и переключение происходит мгновенно.
7.4 Откаты
  • OSTree позволяет вернуться на предыдущий коммит в случае проблем.
  • Откат выполняется командой rpm-ostree rollback.
Это особенно полезно для тестирования новых сборок: можно безопасно проверить обновление и быстро вернуться на стабильную версию.

8. Типичные ошибки и их решения

Ниже собраны наиболее частые проблемы при сборке и публикации OSTree-репозитория, а также проверенные шаги для их быстрого устранения.

8.1 Unknown rpm-md repository: niceos

Ошибка означает, что DNF не нашёл репозиторий с ID niceos. Обычно это отсутствие .repo-файлов либо неверный каталог reposdir.

Проверьте наличие и ID репозиториев
  • В каталоге REPOSDIR должны быть файлы: niceos.repo, niceos-updates.repo, niceos-extras.repo.
  • Секции внутри должны называться строго так же: [niceos], [niceos-updates], [niceos-extras].
  • Эти имена должны совпадать со значениями массива repos в вашем treefile.
[niceos]
name=NiceOS $releasever ($basearch)
baseurl=https://p3.niceos.ru/niceos/$releasever/core
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-NICEOS
Проверьте, что DNF видит ваш REPOSDIR

Скрипт экспортирует переменные окружения для dnf/libdnf, но в некоторых окружениях (dnf4) может потребоваться явная настройка:

# запуск с указанием каталога .repo (для совместимости)
DNF_REPOS_DIRS=/srv/niceos/repos.d \
rpm-ostree compose tree --unified-core \
  --cachedir=/srv/niceos/repos.d/cache \
  --repo=/srv/niceos/repos.d/repo \
  /srv/niceos/repos.d/niceos-base.json
Если используете системный dnf4: добавьте reposdir=/srv/niceos/repos.d в /etc/dnf/dnf.conf или временно положите .repo в /etc/yum.repos.d/.
Также проверьте сетевую доступность baseurl, валидность GPG-ключа и что $releasever/$basearch реально существуют на сервере.

8.2 No previous commit for ...

Это нормальное сообщение при первой сборке: репозиторий только создаётся, родительского коммита ещё нет.

  • Убедитесь, что перед сборкой репозиторий инициализирован: ostree init --mode=archive-z2 (скрипт делает это сам).
  • После успешного compose появится первый коммит: проверьте его ostree --repo=... log <ref>.
ostree --repo=/srv/niceos/repos.d/repo log niceos/5.2/x86_64/minimal

8.3 ostree: command not found

Утилита ostree не установлена или не в PATH.

Мини-чек:

command -v ostree || echo "ostree отсутствует"
ostree --version
Установите пакет ostree из вашего дистрибутива и убедитесь, что исполняемый файл доступен пользователю, под которым запускается сборка (в CI — тоже).

8.4 rpm-ostree: command not found

Утилита rpm-ostree не установлена. Без неё сборка невозможна.

Проверьте наличие:

command -v rpm-ostree || echo "rpm-ostree отсутствует"
rpm-ostree --version
Установите rpm-ostree через пакетный менеджер. Если используете наш скрипт, включите флаг --auto-install (в средах с tdnf) — он попробует поставить зависимости автоматически.
# пример с автоустановкой
mkostreerepo --repopath=/srv/niceos/repos.d --auto-install --verbose

8.5 Дополнительные причины с похожими симптомами

Сеть и доступность репозиториев
  • Проверьте, что baseurl доступен (HTTP 200/206).
  • Проверьте DNS/прокси/файрвол: на CI это частая причина таймаутов.
  • GPG-ключ ОС доступен по пути, указанному в gpgkey=.
Права и SELinux
  • У пользователя есть права записи в repo/ и cache/.
  • При включённом SELinux проверьте контексты каталога публикации (для HTTP-сервера).
Для быстрого аудита конфигурации удобно запускать скрипт с --verbose и сохранять лог в артефакты CI. Так проще сопоставить шаги с выводом rpm-ostree и ostree.

9. Советы по best practices

Эти рекомендации помогут сделать работу с OSTree-репозиторием более надёжной, прозрачной и удобной для дальнейшей поддержки.

Храните treefile в Git

Размещайте ваш JSON-файл (описание пакетов и конфигурации системы) в системе контроля версий. Это позволит:

  • Отслеживать изменения в составе пакетов.
  • Возвращаться к прошлым конфигурациям.
  • Проводить код-ревью перед изменениями.
git add niceos-base.json
git commit -m "Добавлен пакет vim в базовую сборку"
Делайте коммиты с понятными комментариями

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

rpm-ostree compose tree ... \
  --add-metadata-string="version=5.2.1" \
  --add-metadata-string="message=Добавлен пакет htop"
Хорошие комментарии сокращают время анализа проблем и помогают при откатах.
Публикуйте репозиторий через HTTPS с GPG-подписью

Защитите цепочку поставки:

  • Используйте HTTPS для шифрования и аутентификации сервера.
  • Подписывайте RPM-пакеты GPG-ключом вашей организации.
  • Раздавайте публичный ключ клиентам для проверки.
gpg --armor --export <KEY_ID> > /etc/pki/rpm-gpg/RPM-GPG-KEY-NICEOS
rpm --addsign /path/to/packages/*.rpm
При использовании HTTPS проверьте, что сертификат не просрочен и корректно установлен на сервере.
Используйте staging-репозиторий перед продакшеном

Перед публикацией обновлений в основной (production) репозиторий:

  1. Соберите и протестируйте дерево в staging-репозитории.
  2. Проверьте установку и обновления на тестовых машинах.
  3. Только после успешной проверки — синхронизируйте с production.
rsync -avz /srv/niceos/staging/repo/ \
  user@prod-server:/srv/niceos/prod/repo/
Это особенно важно для критичных систем, чтобы избежать катастрофических ошибок.

10. Заключение

Скрипт mkostreerepo — это удобный и надёжный инструмент для работы с OSTree-репозиториями NiceOS.

  • Автоматизация: упрощает создание и обновление OSTree-репозитория, минимизируя количество ручных действий.
  • Гибкость: подходит как для разовых сборок, так и для интеграции в CI/CD процессы.
  • Простота: чёткая структура каталогов, предсказуемый результат, минимальная вероятность ошибок при использовании.
  • Готовность к использованию: сразу после запуска можно публиковать репозиторий и использовать его для установки или обновления систем NiceOS.
Благодаря этому скрипту процесс управления OSTree-репозиториями становится прозрачным, повторяемым и безопасным — как для разработчиков, так и для администраторов.
Комментарии
Обратная связь

Нашли ошибку или хотите предложить улучшение? Напишите нам.

Отправить отзыв

НАЙС.ОС включена в реестр российского ПО (#23155) и готова к сертификации ФСТЭК. Свидетельство о государственной регистрации программы для ЭВМ №2025612870 от 05 февраля 2025 г.