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
.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
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
.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 нового снимка. -
Сверка «коротким путём»:
Полученный SHA должен совпадать с верхним коммитом изostree --repo=/srv/niceos/repos.d/repo rev-parse niceos/5.2/x86_64/minimal
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
.
1) Перегенерируйте индекс:
ostree summary --repo=... --update
.2) Убедитесь, что вы смотрите на тот же путь
--repo
, где создавался коммит.3) Проверьте права доступа и наличие файла
summary
в каталоге репозитория.
summary
указывает на его же SHA — репозиторий готов для клиентов.
Мини-чеклист «всё сходится»
- В
refs
естьniceos/5.2/x86_64/minimal
. rev-parse
выдаёт SHA, совпадающий с верхним коммитом вlog
.summary -v
показывает тот же SHA и актуальную дату.
7. Что делать дальше
После того как репозиторий OSTree успешно собран и проверен, следующим шагом будет его публикация, подключение клиентов и организация дальнейших обновлений.
7.1 Публикация репозитория
- Разместите содержимое каталога
repo/
на веб-сервере (HTTP или HTTPS). - Проверьте, что клиент может скачать
summary
и объекты по прямой ссылке. - При использовании HTTPS убедитесь в корректности TLS-сертификата.
7.2 Настройка клиента
На клиентской системе необходимо:
- Создать
.repo
-файл сbaseurl
, указывающим на ваш веб-сервер с OSTree. - Использовать
rpm-ostree rebase
для переключения на ваш реф.
rpm-ostree rebase niceos:$(arch) niceos/5.2/x86_64/minimal
7.3 Обновления
- При изменении состава пакетов или конфигураций снова запустите скрипт для формирования нового коммита.
- Клиенты смогут получить обновление командой
rpm-ostree upgrade
.
7.4 Откаты
- OSTree позволяет вернуться на предыдущий коммит в случае проблем.
- Откат выполняется командой
rpm-ostree rollback
.
8. Типичные ошибки и их решения
Ниже собраны наиболее частые проблемы при сборке и публикации OSTree-репозитория, а также проверенные шаги для их быстрого устранения.
8.1 Unknown rpm-md repository: niceos
Ошибка означает, что DNF не нашёл репозиторий с ID niceos
. Обычно это отсутствие .repo
-файлов либо неверный каталог reposdir
.
- В каталоге
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
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
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=
.
- У пользователя есть права записи в
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
Используйте staging-репозиторий перед продакшеном
Перед публикацией обновлений в основной (production) репозиторий:
- Соберите и протестируйте дерево в staging-репозитории.
- Проверьте установку и обновления на тестовых машинах.
- Только после успешной проверки — синхронизируйте с production.
rsync -avz /srv/niceos/staging/repo/ \
user@prod-server:/srv/niceos/prod/repo/
10. Заключение
Скрипт mkostreerepo
— это удобный и надёжный инструмент для работы с OSTree-репозиториями NiceOS.
- Автоматизация: упрощает создание и обновление OSTree-репозитория, минимизируя количество ручных действий.
- Гибкость: подходит как для разовых сборок, так и для интеграции в CI/CD процессы.
- Простота: чёткая структура каталогов, предсказуемый результат, минимальная вероятность ошибок при использовании.
- Готовность к использованию: сразу после запуска можно публиковать репозиторий и использовать его для установки или обновления систем NiceOS.