1. Введение
Что такое OSTree — простыми словами
- OSTree — это «git для операционной системы».
- Хранит снапшоты (коммиты) файловой системы.
- Используется в
RPM-OSTreeдля сборки иммутабельных (неизменяемых) систем.
Зачем нужен OSTree-репозиторий в NiceOS
- Централизованное распространение обновлений системы.
- Установка NiceOS из готового дерева пакетов.
- Возможность откатов и атомарных апдейтов.
Почему нужен этот скрипт
- Автоматизирует процесс инициализации и обновления OSTree-репозитория.
- Подготавливает все необходимые файлы:
.repo, treefile, структуру каталогов. - Делает процесс воспроизводимым и удобным для CI/CD.
2. Предварительные знания и требования
Что нужно знать
- Базовые термины: пакетный менеджер, репозиторий,
releasever,architecture. - Минимальные навыки работы в терминале.
Необходимые утилиты
rpm-ostreeostree- (опционально)
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/minimallog. -
Если лог пустой: коммит не записан — проверьте код возврата сборки и
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.