💾 Archived View for tilde.team › ~rami › silverblue.gmi captured on 2024-08-18 at 17:35:23. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

-=-=-=-=-=-=-

~Rami ₪ MANUALS

רמי

SUBJECT: Fedora Silverblue (Immutable OS): rpm-ostree, sandboxes, portals, containers, flatpaks

AUTHOR: Rami Rosenfeld

DATE: 03/03/23; upd. 29/04/2023

TIME: 21.00

LANG: ru, en

LICENSE: GNU FDL 1.3

TAGS: gnu, gnome, software, opensource, linux, system, man, manual, bash, privacy, security, rhel, centos, mate, xfce, lxde, spin, de, systemd, systemctl, selinux, firewalld, dnf, rpm, ostree, flatpak, siverblue

Fedora Silverblue (Immutable OS): rpm-ostree, sandboxes, portals, containers, flatpaks - Базовое руководство пользователя

INTRO

Признаюсь, никогда не любил контейнерные технологии и старался всячески избегать их применения; в частности, стремился удалять их поддержку сразу после инсталляции ОС. И только сейчас, хорошенько изучив официальную документацию, сообразил - насколько я был далек от истины.

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

Как и всегда, моя основная задача на сегодня - познакомить с конкретными консольными командами управления, поэтому я не буду расписывать все преимущества этого вида immutable ОС - для этого вкратце предназначен раздел "Концепция" (см. ниже), побуждая вас в случае необходимости самостоятельно изучить официальную документацию... Коснусь лишь одного распространенного заблуждения, будто Flatpak в совокупности с OSTree - это "типичный Windows-way"... Отнюдь! Если вы припомните, как хаотично распаковывается из .exe файла его содержимое, а также в какие разнообразные места оно распределяется (в противовес этому - см. схему ниже), то согласитесь со мною, что данное утверждение присуще, скорее, малолетнему "эксперту с опеннета", нежели взрослому здравому человеку. Более того, в Windows однозначно не идет речь о какой-либо контейнеризации (т.е. о максимальном уменьшении прав, делегированных пакету/приложению и сведении к нулю их вмешательства в базовую часть ОС)... ну а уж если мы заведем более предметный и глобальный разговор о "безопасности" в этой операционной системе - тогда рекомендую мой давний материал "Что не так с Windows?"… or Windows: What’s wrong? (см. раздел Essays)...

Виноват, я отвлекся! Итак, переходим к главному.

NOTE

СХЕМА: Fedora Silverblue - Уровни, слои и связи в ОС

Тематические ссылки

Download a Silverblue Image

Fedora Silverblue User Guide

Flatpak’s documentation

Flathub: Quick Setup

Flathub: Apps for Linux

OSTree Overview

Концепция Fedora Silverblue

1. Базовая часть ОС является НЕИЗМЕНЯЕМОЙ. Она задействуется в режиме "ТОЛЬКО ДЛЯ ЧТЕНИЯ".

2. При апгрейде ОС базовый образ (т.е. нижний слой) инкрементально обновляется (см. ниже "rpm-ostree"). Примечание: На самом деле, данное утверждение не совсем корректно; но подробнее этот вопрос рассматривается в официальной документации.

3. Основной (и рекомендуемый!) способ установки программного обеспечения в ОС осуществляется с помощью flatpak-пакетов - самодостаточных приложений, не вносящих изменения в базовую систему.

4. Flatpak-пакеты запускаются в "песочницах" с максимально ограниченными правами доступа (см. ниже "sandboxes").

5. Права доступа приложений к некоторым функциям ОС делегируются при помощи "порталов" (см. ниже "portals").

6. Существует возможность установки обычных rpm-пакетов, необходимых пользователю. Для этого поверх неизменяемой системы создается специальный "слой", на котором и происходят все дальнейшие изменения (см. ниже "package layering"). Сама ОС остается в неприкосновенности; еще точнее - пересоздается т.н. "комбинированный образ".

7. Для разработчиков ПО имеются технологии Toolbox и Modularity (см. ниже), значительно расширяющие функционал ОС.

Приоритетные способы инсталляции ПО (по нисходящей)

1) flatpak-пакеты - оптимальный изолированный вариант, не вносящий изменения в базовую ОС, не создающий новый "слой" и не требующий пересборки при обновлениях;

2) toolbox - работает со стандартными командами dnf и rpm-пакетами. Внимание! Toolbox НЕ является "истинным" контейнером!

3) rpm-ostree - не столь желателен, т.к. плодит дополнительные сущности: т.н. новый "слой" для исполнения установленного ПО.

Подробнее см.:

Basic concepts

Предварительное разбиение разделов для установки ОС

В Fedora Silverblue рекомендовано автоматические разбиение разделов. Как указано в руководстве, ее производители не советуют также устанвливать ОС на машины с двойной загрузкой. Тем не менее, самостоятельное разбиение разделов возможно - с учетом нюансов, о которых будет сказано ниже.

Ручное разбиение позволяет использовать BTRFS, XFS, а также LVM или разбиение на физические разделы (ну и, конечно же, их шифрование).

В системе предусмотрены ТОЛЬКО следующие разделы (и их подкаталоги). Это жесткая структура, которую необходимо соблюдать:

/boot

/

/var

Подкаталоги /var:

/var/home (symlink с /home на /var/home)

/var/log

/var/containers

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

Таким образом, ручная разметка разделов сводится к определению объемов и ФС /boot, /, /swap и /var/, а также их шифрованию (за исключением /boot).

Примечание: О ненужности - и об этом сообщают сами разработчики! - раздела /swap в новых версиях Fedora я подробно писал ранее (см. раздел Manuals); по поводу же необходимости его создания в Fedora Silverblue не могу сказать ничего конкретного, так как пока не нашел об этом никаких упоминаний в официальном руководстве.

Подробнее см.:

Manual Partitioning

Структура файловой системы

Важно: Fedora Silverblue является т.н. "immutable ОС". Это значит, что /, /usr (и их подкаталоги) используются в режиме "только для чтения".

/var является областью, предназначенной для хранения изменяемых данных (т.е. runtime, пользовательских настроек, файлов и т.п.). В ОС используются следующие симлинки, чтобы имитировать прежнюю "традиционную" структуру каталогов:

/home → /var/home

/opt → /var/opt

/srv → /var/srv

/root → /var/roothome

/usr/local → /var/usrlocal

/mnt→ /var/mnt

/tmp → /sysroot/tmp

Это означает, что все домашние подкаталоги должны создаваться исключительно в /var/home.

Подключение репозитория Flathub

В Fedora Silverblue это осуществляется двумя способами: посредством графического интерфейса Центра обновлений или из консоли:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Кроме того, некоторые flatpak-пакеты доступны непосредственно из репозитория Fedora.

Подробнее см.:

Flathub: Quick Setup

Глобальные команды обновления базовой ОС

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

Для применения готовых обновлений следует перезагрузить ОС. В случае возникновения ошибок при последующей загрузке, можно осуществить "rollback", т.е. "откат" ОС до предыдущего состояния.

Управление ОС из консоли осуществляется следующими командами:

• Проверка обновлений

rpm-ostree upgrade --check

• Просмотр обновлений

rpm-ostree uprgade --preview

• Установка обновлений

rpm-ostree upgrade --reboot

Примечание: После окончания операции система будет перезагружена.

Глобальное обновление - "релиз на релиз" (rebase)

Важно! "Пропуск" релизов не тестировался разработчиками и крайне НЕ рекомендуется! Таким образом, обновляйте ОС только на следующую версию, например с 37-й - на 38-ю.

ПОДГОТОВИТЕЛЬНАЯ СТАДИЯ:

1) Обновление ОС и перезагрузка ее после применения обновлений:

rpm-ostree upgrade --reboot

2) Сохранение "развернутых" приложений при апгрейде ОС с релиза на релиз

ostree admin pin 0

Примечание: Это действие сохранит ("закрепит") ранее установленные приложения, используемые по умолчанию, но все остальные будут удалены.

Удаление ранее "закрепленного слоя" осуществляется командой:

ostree admin pin --unpin 2

Примечание: "2" - номер позиции в статусе rpm-ostree (см. команду ниже)

3) Проверка исполнения команды pin

rpm-ostree status

4) RPM Fusion Layer

Если в ОС развернут слой, связанный с пакетами, установленными из репозиториев RPM Fusion, необходимо выполнить следующую команду ДО(!) исполнения общей команды обновления "rpm-ostree rebase ...":

rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

ДЕЙСТВИЯ ПО АПГРЕЙДУ:

1) Проверка наличия нового релиза ОС

ostree remote refs fedora | grep silverblue

2) Апгрейд на следующую версию (например, с 37 на 38)

rpm-ostree rebase fedora:fedora/38/x86_64/silverblue

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

• Дополнительная информация

1) Возврат (откат) к предыдущему состоянию ОС после исполнения команды "rpm-ostree rebase". Здесь возможны два варианта:

- Временный - достаточно выбрать в загрузочном меню (grub menu) предшествующую версию ОС.

- Постоянный - необходимо исполнить команду:

rpm-ostree rollback --reboot

Примечание: После окончания операции система будет перезагружена.

Примечание: Будьте внимательны! После выполнения отката ОС, система окажется в предшествующем состоянии, и вам будет предложено вновь обновить ее до следующей версии. Вполне естественно, что это действие отменит rollback.

2) Местонахождение конфигурационного файла rpm-ostreed.conf:

/etc/rpm-ostreed.conf

3) Опциональный апгрейд последнего релиза ОС до rawhide-версии (не рекомендуется):

rpm-ostree rebase fedora:fedora/rawhide/x86_64/system

Внутренняя структура пакетов Flatpak

Для обеспечения работоспособности и независимости/переносимости приложений в последние включаются т.н. runtimes, встраиваемые в каждое приложение (Flatpak также может подгружать дополнительные). Таким образом, Flatpak-пакеты не зависят от текущей версии ОС и являются кросс-платформенными. В одно и то же время, т.е. параллельно и независимо, могут быть установлены разные версии одного и того же runtime или приложения.

Кроме runtimes, существует также понятие "встроенные библиотеки". К ним могут относиться:

- библиотеки, не входящие в runtime;

- библиотеки, схожие с включенными в runtime, но различающиеся версиями;

- видоизмененные (patched) библиотеки.

Sandboxes / "Песочница"

В целях безопасности Flatpak использует "песочницы" (Sandboxes), изолирующие приложения в специальном окружении от ОС и другого ПО. "Песочница" имеет все необходимые компоненты для запуска того или иного приложения; последнее же имеет доступ только к содержимому своей "песочницы". Доступ к пользовательским файлам, сети, сокетам, bus-подсистемам, девайсам и т.п. может быть опеределен/задан особо. Доступ к иным процессам невозможен. По необходимости, некоторое содержимое "песочницы" может быть экспортировано в хост-машину, например .desktop-файлы и иконки.

Sandboxes - важнейшая часть обеспечения безопасности ОС и ПО, поэтому, чтобы быть точным, я процитирую часть руководства администратора без перевода: "...applications that are run with Flatpak have extremely limited access to the host environment. This includes:

- No access to any host files except the runtime, the app, ~/.var/app/$FLATPAK_ID, and $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Only the latter two being writable.

- No access to the network.

- No access to any device nodes (apart from /dev/null, etc).

- No access to processes outside the sandbox.

- Limited syscalls. For instance, apps can’t use nonstandard network socket types or ptrace other processes.

- Limited access to the session D-Bus instance - an app can only own its own name on the bus.

- No access to host services like X11, system D-Bus, or PulseAudio."

Дополнительно см.:

Sandbox Permissions

Flatseal: Graphical utility to review and modify permissions

Portals / "Порталы"

Кроме того, задействуется механизм т.н. "порталов", когда каждое приложение может интерактивно взаимодействовать с хост-системой, данными, файлами и сервисами без изменения разрешений "песочницы", например: выбор файлов для открытия, функции печати, сохранения и т.д. Цитирую подробно, потому что это очень важная информация, позволяющая понять механизм взаимодействия с ОС:

"They are a framework for providing access to resources outside of the sandbox, including:

- Opening files with a native file chooser dialog.

- Opening URIs.

- Printing.

- Showing notifications.

- Taking screenshots.

- Inhibiting the user session from ending, suspending, idling or getting switched away.

- Getting network status information.

In many cases, portals use a system component to implicitly ask the user for permission before granting access to a particular resource. For example, in the case of opening a file, the user’s selection of a file using the file chooser dialog is interpreted as implicitly granting the application access to whatever file is chosen.

• Standard permissions

The following permissions provide access to basic resources that applications commonly require, and can therefore be freely used:

--share=network - access the network;

--socket=x11 - show windows using X11;

--socket=fallback-x11 - show windows using X11, if Wayland is not available, overrides x11 socket permission. Note that you must still use --socket=wayland for wayland permission;

--share=ipc - share IPC namespace with the host (necessary for X11);

--socket=wayland - show windows with Wayland;

--device=dri - OpenGL rendering;

--socket=pulseaudio - play sound with PulseAudio.

• D-Bus access

Access to the entire bus with --socket=system-bus or --socket=session-bus should be avoided, unless the application is a development tool.

• Ownership

Applications are automatically granted access to their own namespace. Ownership beyond this is typically unnecessary, although there are a small number of exceptions, such as using MPRIS to provide media controls.

• Talk

Talk permissions can be freely used, although it is recommended to use the minimum required.

• Filesystem access

It is common for applications to require access to different parts of the host filesystem, and Flatpak provides a flexible set of options for this. Some examples include:

--filesystem=host - access normal files on the host, not including host os or system internals described below;

--filesystem=home - access the user’s home directory;

--filesystem=/path/path - access specific paths;

--filesystem=xdg-download - access a specific XDG folder.

As a general rule, Filesystem access should be limited as much as possible. This includes:

- Using portals as an alternative to blanket filesystem access, wherever possible.

- Using read-only access wherever possible, using the :ro option.

- If some home directory access is absolutely required, using XDG directory access only.

- The full list of available filesystem options can be found in the Sandbox Permissions Reference.

• Other filesystem access guidelines include:

The --persist=path option can be used to map paths from the user’s home directory into the sandbox filesystem. This makes it possible to avoid configuring access to the entire home directory, and can be useful for applications that hardcode file paths in ~/.

If an application uses $TMPDIR to contain lock files you may want to add a wrapper script that sets it to $XDG_RUNTIME_DIR/app/$FLATPAK_ID.

Retaining and sharing configuration with non-Flatpak installations is to be avoided.

As mentioned above the host option does not actually provide complete access to the host filesystem. The main rules are:

These directories are blacklisted: /lib, /lib32, /lib64, /bin, /sbin, /usr, /boot, /root, /tmp, /etc, /app, /run, /proc, /sys, /dev, /var

Exceptions from the blacklist: /run/media

These directories are mounted under /var/run/host: /etc, /usr

The reason many of the directories are blacklisted is because they already exist in the sandbox such as /usr or are not usable in the sandbox.

The home permission also has exceptions as it does not grant access to the subdirectories for other applications in ~/.var/app/.

• Device access

While not ideal, --device=all can be used to access devices like controllers or webcams.

• dconf access

As of xdg-desktop-portal 1.1.0 and glib 2.60.5 (in the runtime) you do not need direct DConf access in most cases.

As of now this glib version is included in org.freedesktop.Platform//19.08 and org.gnome.Platform//3.34 and newer.

If an application existed prior to these runtimes you can tell Flatpak (>= 1.3.4) to migrate the DConf settings on the host into the sandbox by adding --metadata=X-DConf=migrate-path=/org/example/foo/ to finish-args. The path must be similar to your app-id or it will not be allowed (case is ignored and _ and - are treated equal).

If you are targeting older runtimes or require direct DConf access for other reasons you can use these permissions:

--filesystem=xdg-run/dconf

--filesystem=~/.config/dconf:ro

--talk-name=ca.desrt.dconf

--env=DCONF_USER_CONFIG_DIR=.config/dconf

With those permissions glib will continue using dconf directly.

• gvfs access

As of gvfs 1.48, the gvfs daemons and applications use an on-disk socket to communicate, rather than an abstract socket so that the gvfs infrastructure still works when network support is disabled in the application’s sandbox.

A number of different options need to be passed depending on the application’s use of gvfs.

--talk-name=org.gtk.vfs.* is necessary to talk to the gvfs daemons over D-Bus and list mounts using the GIO APIs.

--filesystem=xdg-run/gvfsd is necessary to use the GIO APIs to list and access non-native files using the GIO APIs, using URLs rather than FUSE paths.

--filesystem=xdg-run/gvfs is necessary to give access to the FUSE mounts non-GIO and legacy applications can use. This is what will make native files appear under /run/user/`id -u`/gvfs/.

• Typical GNOME and GTK applications should use:

--talk-name=org.gtk.vfs.*

--filesystem=xdg-run/gvfsd

• Typical non-GNOME and non-GTK applications should use:

--filesystem=xdg-run/gvfs

No application should be using --talk-name=org.gtk.vfs in its manifest, as there are no D-Bus services named org.gtk.vfs.

Дополнительно см.:

Portals

Репозитории

Flatpak-приложения обычно публикуются и хранятся в репозиториях, схожими по структуре с Git. Репозиторий Flatpak может содержать как единичный объект, так и несколько; каждый из них будет иметь свою версию, которые позволяют осуществлять функции upgrade/downgrade. К любой ОС с установленным Flatpak может быть подключено неограниченное количество репозиториев с возможностями поиска и предоставления дополнительной информации. При обновлении пакета (по аналогии с Git) будет загружена только "разница" между версиями, что делает процесс обновления крайне эффективным и схожим с механизмом delta-RPM в "стандартном" дистрибутиве Fedora.

И приложения, и runtimes, и их репозитории могут быть подключены в ОС как для всей системы в целом, так и для конкретного пользователя. Последнее удобно для тестирования приложений. По умолчанию в командах используется system-wide принцип. Если же в команде будет использована опция "--user", то установленные пакеты будут недоступны другим пользователям. Последнее может еще больше поднять уровень безопасности ОС и ПО.

Идентификаторы пакетов

При создании пакетов Flatpak маркирует каждое приложение и его runtime-компоненты уникальным идентификатором ("Identifiers"), состоящим из трех частей. В целом, они выглядят как "com.company.App" (схожая система применяется в Android). Более предметно идентификаторы делятся на следующие части: "name/architecture/branch", например: "com.company.App/i386/stable".

Базовые команды Flatpak

Конечный пользователь может легко управлять пакетами с помощью графического интерфейса, действующего по принципу: "найти приложение - ознакомиться с описанием и скриншотами - установить нажатием ЛКМ" (то есть как в распространенных сейчас "магазинах приложений"). Ниже приводятся консольные команды управления.

• Вызов помощи

flatpak --help

• Просмотр содержимого

flatpak remotes

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

• Добавление файла .flatpakrepo, содержащего детали пакетов и их ключ GPG:

1) Fedora Flatpaks:

flatpak remote-add --if-not-exists fedora oci+https://registry.fedoraproject.org

2) Flathub:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

3) Flabhub Beta:

flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo

В данном случае, "flathub", "fedora" и "flathub-beta" будут локальными именами репозиториев.

• Удаление установленного .flatpakrepo

flatpak remote-delete flathub

• Поиск пакета

flatpak search gimp

• Установка пакета

flatpak install flathub org.gimp.GIMP

В данном случае, flathub - локальное имя подключенного репозитория, а org.gimp.GIMP - имя пакета.

Начиная с версии Flatpak 1.2, команда установки может работать следующим образом:

flatpak install gimp

• Файл .flatpakref

.flatpakref содержит дополнительные описания/спецификации устанавливаемых пакетов (программ) и ключ GPG. По сути, его использование - простейший путь онлайн-установки приложения.

flatpak install https://flathub.org/repo/appstream/org.gimp.GIMP.flatpakref

или (локально)

flatpak install org.site.APP_NAME.flatpakref

Примечание: Как понял лично я (но не тестировал на практике!), офлайн-"коллекцию" этих небольших файлов можно использовать для автоматизации установки ОС, ибо их список равнозначен стандартной команде "dnf install pkg_1 pkg_2 pkg_3". Чтобы получить такой список (с перечислением в одну строку), исполните команду:

flatpak list --app --columns=application | xargs echo -n > installed_flatpaks.txt

• Структура файла .flatpakref

[Flatpak Ref]

Name=org.site.APP_NAME

Branch=stable

Title=org.site.APP_NAME from flathub

Url=https://dl.flathub.org/repo/

RuntimeRepo=https://dl.flathub.org/repo/flathub.flatpakrepo

IsRuntime=false

GPGKey=mQINBFl (...)

• Запуск приложения

flatpak run org.gimp.GIMP

• Обновление всех установленных приложений и их runtimes до последней версии

flatpak update

• Просмотр списка установленных приложений и их runtimes

flatpak list

• Просмотр списка установленных приложений

flatpak list --app

• Просмотр информации об установленном приложении

flatpak info org.gimp.GIMP

• Удаление приложения

flatpak uninstall org.gimp.GIMP

• Удаление runtimes и extensions, не используемых более ни одним приложением

flatpak uninstall --unused

• Разрешение конфликтов

flatpak repair

• Сброс "portal permissions" (т.е. разрешений) установленного приложения до изначального уровня

flatpak permission-reset org.gimp.GIMP

• Просмотр истории (начиная с версии 1.2)

flatpak history

Дополнительно см.:

Using Flatpak

Flatpak Command Reference

Администрирование rpm-ostree ОС (расширенная информация)

• Общие понятия о Package layering

Т.н. "Package layering" (можно перевести как "слой пакетов) модифицирует установленную immutable Fedora Silverblue. По сути, это расширение функционала ОС, за счет которого в нее можно подключить такие компоненты, как sway, libvirt, fish и т.п. Большинство (но не все) RPM-пакетов предлагаются к установке непосредственно из репозитория Fedora.

По сути, "package layering" создает новый "базис для развертывания", т.е. "верхний слой" для устанавливаемого ПО или, как указано в руководстве: "bootable filesystem root" (хотя последнее никак не сказывается на текущих настройках root). Этот способ сохраняет возможности отката ОС ("rollback"), но означает, что ОС должна быть перезагружена после установки или обновления конкретного пакета. Альтернативно, для мгновенного (т.е. не требующего перезагрузки) получения результатов, можно использовать команду:

rpm-ostree install --apply-live <pkg>

Package layering предназначен для малого количества пакетов, которые не имеются в виде flatpak-файлов в репозиториях; он применим из командной строки.

• Просмотр развернутых пакетов

rpm-ostree status

Примечание: Список отобразит их в порядке, используемом в bootloader'e

- Первая позиция в списке - используется по умолчанию.

- Значок "●" - маркер загруженного.

• Добавление сторонних RPM-репозиториев

1) RPMFusion (free/nonfree)

rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

rpm-ostree install https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

2) Copr

ostree remote add <name-of-repo> <repository-url>

Примечание: Процесс добавления сторонних репозиториев схож с аналогичным в Fedora, разве что RPM-пакеты будут установлены не непосредственно в ОС, а в отдельный "слой".

• Обновление системы и пакетов, установленных средствами rpm-ostree

rpm-ostree upgrade

или

rpm-ostree upgrade --reboot

Команда подготовит офлайн-обновление, создаст новый deployment (т.е. root filesystem) и пометит его дефолтным для следующей загрузки. Обновление "заканчивается" в момент финиша подготовки нового загрузчика и выключения системы (т.е. исполнения команды shutdown).

• Возврат / "откат" к предыдущему состоянию ОС

rpm-ostree rollback

или

rpm-ostree rollback --reboot

или

rpm-ostree rollback fedora/35/x86_64/system

Возврат к предыдущему состоянию: настройки "по умолчанию" перестают быть таковыми. Стандартно, rpm-ostree upgrade удерживает два предшествующих состояния (это можно сравнить с сохранением двух предшествующих ядер при обновлении системы в "обычном" дистрибутиве ОС).

• Просмотр истории OSTree с сервера

rpm-ostree deploy <version>

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

• Установка пакета

rpm-ostree install <package name>

Эта команда загрузит пакет и необходимые зависимости, а затем перенастроит текущий образ ОС. Система rpm-ostree использует стандартные имена пакетов для Fedora, которые могут быть найдены средствами DNF, однако следует учитывать, что эта операция недоступна непосредственно на хосте Fedora Silverblue, но применима в т.н. "toolbox" (его описание см. ниже). При подобном способе установки пакет будет обновляться автоматически - во время обновления ОС (и при наличии его новых версий).

• Удаление пакета

rpm-ostree uninstall <pkg>

По умолчанию, каждая операция rpm-ostree происходит "офлайн" и не вносит никаких изменений в текущее состояние запущенной ОС. Все изменения будут внесены только при перезагрузке. Это состояние пакета называется "pending deployment".

• Удаление ВСЕХ пакетов, установленных средствами rpm-ostree

rpm-ostree uninstall --all

Примечание: Это действие гарантированно не затронет базовый слой ОС

• Замена пакетов

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

rpm-ostree override replace <path to package>

Также можно вместо пути к физическому пакету использовать ссылки на koji или bodhi, например:

rpm-ostree override replace https://kojipkgs.fedoraproject.org//packages/podman/3.1.2/1.fc34/x86_64/podman-3.1.2-1.fc34.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/podman/3.1.2/1.fc34/x86_64/podman-plugins-3.1.2-1.fc34.x86_64.rpm

• Удаление пакетов из базовой поставки ОС

rpm-ostree override remove <pkg>

Вместо "override replace" можно использовать "override remove" - это "скроет" предустановленный пакет. При этом он останется существовать на "нижнем базовом слое" ОС, однако не будет использован при последующей загрузке ОС. Таким образом, после операции пакет будет присутствовать в локальном репозитории OSTree по адресу: /ostree/repo, но не будет видим.

Важно: "override replace" и "override remove" в целом НЕ рекомендованы разработчиками rpm-ostree.

• Сброс/отмена команд "overrides"

rpm-ostree override reset <pkg>

• Перезагрузка rpm-ostree

rpm-ostree reload

Дополнительно см.:

rpm-ostree Administrator Handbook

ДОПОЛНИТЕЛЬНО

Fedora Modularity и Toolbox вряд ли пригодятся в моей работе. Однако привожу краткие анонсы этих технологий для всех интересующихся, а также некоторые специфичные (на самом деле - весьма привычные!) команды управления.

Важно! Будьте внимательны: Toolbox НЕ является истинным контейнером с точки зрения безопасности.

Toolbox

Краткая справка по командам

• Создание toolbox

toolbox create --distro

toolbox create --release

toolbox create --image [image_name]

• "Вход" в toolbox

toolbox enter --distro

toolbox enter --release

toolbox enter --distro --release

• Просмотр

toolbox list

toolbox list --containers

toolbox list --images

• Удаление контейнера

toolbox rm <container name>

toolbox rm --force <active container name>

toolbox rm --all

• Удаление образа

toolbox rmi <image name>

toolbox rmi --force <active image name>

toolbox rmi --all

• Вызов справки

toolbox --help

• Работа с пакетами

dnf search <pkg>

dnf install <pkg>

dnf remove <pkg>

Примечание: Любые действия внутри контейнера toolbox производятся стандартными средствами, характерными для "обычной" Fedora GNU/Linux. В частности, вы можете выполнять команду "dnf update", чтобы обновить содержимое контейнера, редактировать конфигурационный файл DNF /etc/dnf/dnf.conf - то есть работать, как с привычной системой.

Описание разработчиков

Toolbox makes it easy to use a containerized environment for everyday software development and debugging. On immutable operating systems, like Fedora Silverblue, it provides a familiar package-based environment in which tools and libraries can be installed and used. However, toolbox can also be used on package-based systems. Using Toolbox for running your workflows in a containerized manner brings you several advantages:

- It keeps the host OS clean and stable, and helps to avoid the clutter that can happen after installing lots of development tools and packages.

- You get access to different versions of supported distributions independent of the version you are running.

- Containers are a good way to isolate and organise the dependencies needed for different projects.

- Containers are a safe space to experiment: if things go wrong, it’s easy to throw a toolbox away and start again.

However, it is very important to note that toolbox containers are still integrated with your host system, so you should not attempt to do things or run software you otherwise wouldn’t on your host system. Toolbox containers are not completely isolated environments like virtual machines.

Дополнительно см.:

Toolbox

Modularity

Описание разработчиков

Any RPM repository can be converted into a modular RPM repository with the inclusion of modular metadata and corresponding binary RPMs. Modularity can expand a RPM repository with following features:

- Module streams add additional packages with the same name, but built from different sources and with different build configurations.

- Module streams can have different life cycles. For example a package in a distribution can have a different life cycle than the life cycle of the distribution.

- Module streams can have different installation profiles of its components i. e. you can define one or several module stream profiles which will contain groups of RPMs which should be installed together.

Дополнительно см.:

Modularity

Опциональные действия

• Добавление поддержки Nvidia и Nvidia System Management Interface (nvidia-smi) или CUDA

rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia

rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia-cuda

Примечание: Добавил две последние команды на всякий случай - а вдруг придется столкнуться с картами от Nvidia!

Дополнительно см.:

Silverblue Postinstall Upgrade

₪ Back to home ₪

🄯 Rami Rosenfeld, 2023. GNU FDL 1.3.