Client administration 客户端管理

1. Administering an rpm-ostree based system
   管理基于 rpm-ostree 的系统
   1. Hybrid image/packaging via package layering
      通过软件包层实现混合镜像/打包
   2. Override rpm files 覆盖 rpm 文件
   3. Rebasing 变基
   4. Other local state changes
      其他本地状态更改
   5. Experimental interface 实验性接口
2. Using overrides and usroverlay
   使用覆盖和 usroverlay
   1. Resetting overrides 重置覆盖
   2. Inactive overrides 未激活的覆盖
   3. Applying overrides live 应用实时覆盖
   4. Using usroverlay 使用 usroverlay
   5. Removing a base package
      移除基础包
3. Filesystem layout 文件系统布局
4. Operating system changes
   操作系统更改

Administering an rpm-ostree based system
管理基于 rpm-ostree 的系统

At the moment, there are four primary commands to be familiar with on an rpm-ostree based system.
目前，在基于 rpm-ostree 的系统上有四个主要命令需要熟悉。

# rpm-ostree status

Will show you your deployments in the order in which they will appear in the bootloader, the first deployment in the list being the current default one. The ● shows the currently booted deployment.
将按照它们在引导加载程序中出现的顺序显示您的部署，列表中的第一个部署是当前默认的部署。 ● 显示当前引导的部署。

# rpm-ostree upgrade

Will prepare a system upgrade offline, creating a new deployment (root filesystem) and set it as the default for the next boot. The update will be “finalized” at shutdown and a new bootloader entry prepared. Hence, use reboot to apply the update.
将离线准备系统升级，创建一个新的部署（根文件系统）并将其设置为下一次引导的默认部署。更新将在关机时“完成”，并准备一个新的引导加载程序条目。因此，请使用 reboot 应用更新。

# rpm-ostree rollback

This rolls back to the previous state, i.e. the default deployment changes places with the non-default one. By default, the rpm-ostree upgrade will keep at most two bootable “deployments”, though the underlying technology supports more.
这将回滚到先前的状态，即默认部署更改与非默认部署交换位置。默认情况下， rpm-ostree upgrade 最多保留两个可引导的“部署”，尽管底层技术支持更多。

# rpm-ostree deploy <version>

This command makes use of the server-side history feature of OSTree. It will search the history of the current branch for a commit with the specified version, and deploy it. This can be used in scripts to ensure consistent updates. For example, if the upstream OS vendor provides an update online, you might not want to deploy it until you’ve tested it. This helps ensure that when you upgrade, you are getting exactly what you asked for.
此命令利用 OSTree 的服务器端历史功能。它将搜索当前分支的历史记录，查找具有指定版本的提交，并部署它。这可用于脚本中以确保一致的更新。例如，如果上游操作系统供应商在线提供更新，您可能不希望在测试之前部署它。这有助于确保升级时获得您要求的内容。

Hybrid image/packaging via package layering
通过软件包分层进行混合镜像/打包

It is possible to dynamically add more packages onto the system that are not part of the commit composed on the server. These additional “layered” packages are persistent across upgrades, rebases, and deploys (contrast with the ostree unlocking mechanism).
可以动态地向系统添加更多不属于在服务器上组合的提交的软件包。这些额外的“分层”软件包在升级、重基和部署时是持久的（与 ostree 解锁机制形成对比）。

This is where the true hybrid image/package nature of rpm-ostree comes into play; you get a combination of the benefits of images and packages. The package updates are still fully transactional and offline.
这就是 rpm-ostree 真正的混合镜像/软件包特性发挥作用的地方；您将获得镜像和软件包的好处结合体。软件包更新仍然是完全事务性和离线的。

For example, you can use package layering to install 3rd party kernel modules, or userspace driver daemons such as pcsc-lite-ccid. While most software should go into a container, you have full flexibilty to use packages where it suits.
例如，您可以使用软件包分层来安装第三方内核模块，或用户空间驱动程序守护程序，如 pcsc-lite-ccid 。虽然大多数软件应该放入容器中，但您完全可以根据需要使用软件包。

# rpm-ostree install <pkg>

Will download the target package, its dependencies, and create a new deployment with those packages installed. It is also possible to specify a local package which is not part of a repository.
将下载目标软件包、其依赖项，并创建一个安装了这些软件包的新部署。也可以指定一个不在存储库中的本地软件包。

To remove layered packages, use:
要删除分层软件包，请使用：

# rpm-ostree uninstall <pkg>

By default, every rpm-ostree operation is “offline” - it has no effect on your running system, and will only take effect when you reboot. This “pending” state is called the “pending deployment”. Operations can be chained; for example, if you invoke rpm-ostree upgrade after installing a package, your new root will upgraded with the package also installed.
默认情况下，每个 rpm-ostree 操作都是“脱机”的 - 它不会影响您正在运行的系统，并且只有在重新启动时才会生效。这种“挂起”状态称为“挂起部署”。操作可以链接；例如，如果在安装软件包后调用 rpm-ostree upgrade ，您的新根目录将升级，并安装了该软件包。

As a special case, it is supported to live-apply just package additions, assuming that there are not other pending changes:
作为一个特例，支持仅应用软件包的添加，假设没有其他待处理的更改：

# rpm-ostree install -yA <pkg>

Override rpm files 覆盖 rpm 文件

Normally, RPM does not allow one package to overwrite files from another. But it can make sense to relax this restriction in some cases; for example, where one just wants to overwrite one kernel module without rebuilding the whole kernel package. The install --force-replacefiles option allows this.
通常情况下，RPM 不允许一个软件包覆盖另一个软件包中的文件。但在某些情况下放宽这一限制是有意义的；例如，当只想要覆盖一个内核模块而不重新构建整个内核软件包时。安装 --force-replacefiles 选项允许这样做。

# rpm-ostree install --force-replacefiles <pkg>

Rebasing 变基

# rpm-ostree rebase -b $branchname

Your operating system vendor may provide multiple base branches. For example, Fedora Atomic Host has branches of the form:
您的操作系统供应商可能提供多个基本分支。例如，Fedora Atomic Host 具有以下形式的分支：

• fedora/27/aarch64/atomic-host
• fedora/27/aarch64/testing/atomic-host
• fedora/27/aarch64/updates/atomic-host
• fedora/27/ppc64le/atomic-host
• fedora/27/ppc64le/testing/atomic-host
• fedora/27/ppc64le/updates/atomic-host
• fedora/27/x86_64/atomic-host
• fedora/27/x86_64/testing/atomic-host
• fedora/27/x86_64/updates/atomic-host

You can use the rebase command to switch between these; this can represent a major version upgrade, or logically switching between different “testing” streams within the same release. Like every other rpm-ostree operation, All layered packages and local state will be carried across.
您可以使用 rebase 命令在这些分支之间切换；这可以表示主要版本升级，或在同一版本中逻辑地在不同的“测试”流之间切换。与其他 rpm-ostree 操作一样，所有分层包和本地状态都将被保留。

Other local state changes
其他本地状态更改

See man rpm-ostree for more. For example, there is an rpm-ostree initramfs command that enables local initramfs generation by rerunning dracut.
查看 man rpm-ostree 以获取更多信息。例如，有一个 rpm-ostree initramfs 命令，通过重新运行 dracut 启用本地 initramfs 生成。

Experimental interface 实验性接口

There is a generic rpm-ostree ex command that offers experimental features.
有一个通用的 rpm-ostree ex 命令，提供实验性功能。

See man rpm-ostree for more information.
查看 man rpm-ostree 获取更多信息。

Using overrides and usroverlay
使用覆盖和 usroverlay 。

While some people talk about “immutability” when referring to image-based systems like rpm-ostree, in fact a top level goal of rpm-ostree is to empower users and system administrators. When something goes wrong, you are root on your own computer and should have the ability to apply overrides locally.
尽管一些人在谈论像 rpm-ostree 这样的基于镜像的系统时提到“不可变性”，但实际上 rpm-ostree 的一个最高级目标是赋予用户和系统管理员权力。当出现问题时，您是自己计算机上的 root 用户，应该有能力在本地应用覆盖。

First, there is the rpm-ostree override replace command, which will replace an RPM, and apply that change persistently for the next boot - this is symmetric with how rpm-ostree install works.
首先，有 rpm-ostree override replace 命令，它将替换一个 RPM，并在下一次启动时持久应用该更改 - 这与 rpm-ostree install 的工作方式是对称的。

For example, suppose you want to test a fix to podman. You can pass both direct HTTP URLs as well as local files:
例如，假设您想测试对 podman 的修复。您可以传递直接的 HTTP URL 和本地文件：

$ sudo rpm-ostree override replace https://kojipkgs.fedoraproject.org//packages/podman/3.3.1/1.fc34/x86_64/podman-3.3.1-1.fc34.x86_64.rpm

$ curl https://rpmfind.net/linux/fedora/linux/updates/testing/38/Everything/x86_64/Packages/p/podman-4.5.1-1.fc38.x86_64.rpm --output podman.rpm
$ sudo rpm-ostree override replace ./podman.rpm

It is also supported to pull from the Fedora Koji/Bodhi systems. The following two examples override podman to a previous build listed in Koji and Bodhi:
也支持从 Fedora Koji/Bodhi 系统拉取。以下两个示例将 podman 覆盖为 Koji 和 Bodhi 中列出的先前构建：

$ sudo rpm-ostree override replace https://koji.fedoraproject.org/koji/buildinfo?buildID=2150598
$ sudo rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2023-130f786970

Another example with the kernel package; note you need to override exactly the set of installed packages:
另一个使用内核包的示例；请注意，您需要准确覆盖已安装软件包的集合：

$ ls -al kernel*.rpm
-rw-r--r--. 1 root root  8085596 Jan 27 22:02 kernel-4.18.0-123.el8.x86_64.rpm
-rw-r--r--. 1 root root 40709632 Jan 27 22:02 kernel-core-4.18.0-123.el8.x86_64.rpm
-rw-r--r--. 1 root root 32533504 Jan 27 22:02 kernel-modules-4.18.0-123.el8.x86_64.rpm
-rw-r--r--. 1 root root  8790996 Jan 27 22:02 kernel-modules-extra-4.18.0-123.el8.x86_64.rpm
$ rpm-ostree override replace ./kernel*.rpm

Resetting overrides 重置覆盖

Use e.g. rpm-ostree override reset podman to undo the previous change. If invoked now, nothing will have happened to the booted filesystem tree.
使用例如 rpm-ostree override reset podman 来撤销上一个更改。如果现在调用，引导文件系统树将不会发生任何变化。

Inactive overrides 未激活的覆盖

It can happen (especially in a “fast-tracking” workflow) that an override for a package version becomes redundant (i.e. the package version provided in the override is the exact same as the one in the base image). In this case, the override becomes inactive. Inactive overrides will appear in the output of status -v.
可能会发生（特别是在“快速跟踪”工作流中）覆盖包版本变得多余的情况（即，覆盖中提供的包版本与基础镜像中的版本完全相同）。在这种情况下，覆盖将变为未激活状态。未激活的覆盖将出现在 status -v 的输出中。

Inactive overrides become active again once the base changes again and the package versions differ. They can be reset as described in the previous section just like active overrides. There is currently no way to have rpm-ostree automatically ‘drop out’ inactive overrides once the base “catches up”.
一旦基础再次更改并且软件包版本不同时，非活动覆盖将再次变为活动状态。它们可以像活动覆盖一样按照前一节中描述的方式进行重置。目前没有办法让 rpm-ostree 在基础“赶上”后自动“退出”非活动覆盖。

Applying overrides live 应用实时覆盖

Now, suppose that you want to test this change live. There are two choices. The first choice is to run the rpm-ostree override replace command above to stage the deployment, and then run
现在，假设您想要实时测试此更改。有两种选择。第一种选择是运行上面的 rpm-ostree override replace 命令来分阶段部署，然后运行

$ rpm-ostree apply-live --allow-replacement

This will pull the pending changes and apply them live. You can rpm-ostree apply-live --reset to revert back to the booted tree.
这将拉取待处理的更改并实时应用它们。您可以 rpm-ostree apply-live --reset 以恢复到引导树。

Using usroverlay 使用 usroverlay

The second choice is rpm-ostree usroverlay which creates a transient writable overlayfs over /usr where you can do anything, such as e.g. copying in a podman binary generated on a build server somewhere that may not be in an RPM even.
第二个选择是 rpm-ostree usroverlay ，它在 /usr 上创建一个瞬态可写的 overlayfs ，您可以在其中执行任何操作，例如复制在构建服务器上生成的 podman 二进制文件，这些文件可能不在 RPM 中。

The changes here will not persist across reboots, which makes this a great choice for testing.
这里的更改不会在重新启动后保留，这使得它成为测试的一个很好的选择。

One downside though is it does not currently work to rpm-ostree apply-live --reset today when rpm-ostree usroverlay is in place. It’s possible to find the original binaries in a previous deployment, or via ostree checkout of the base commit, etc.
不过一个缺点是，当 rpm-ostree usroverlay 存在时，它目前无法在 rpm-ostree apply-live --reset 中工作。可以在先前的部署中找到原始二进制文件，或通过基本提交的 ostree checkout 等方式找到。

Removing a base package
移除基本包

You can also just simply remove a base package with rpm-ostree override remove <pkg>. It will still be present in the underlying OSTree repository in /ostree/repo, but it will not be visible in the generated derived commit.
您也可以使用 rpm-ostree override remove <pkg> 简单地移除基础包。它仍然存在于底层的 OSTree 存储库中 /ostree/repo ，但在生成的派生提交中不可见。

Similar to the override replace case, using rpm-ostree override reset will undo the change.
与 override replace 情况类似，使用 rpm-ostree override reset 将撤消更改。

Filesystem layout 文件系统布局

The only writable directories are /etc and /var. In particular, /usr has a read-only bind mount at all times. Any data in /var is never touched, and is shared across upgrades.
唯一可写的目录是 /etc 和 /var 。特别是， /usr 始终具有只读绑定挂载。 /var 中的任何数据都不会被触及，并且在升级过程中保持共享。

At upgrade time, the process takes the new default /etc, and adds your changes on top. This means that upgrades will receive new default files in /etc, which is quite a critical feature.
在升级时，该过程采用新的默认 /etc ，并在其上添加您的更改。这意味着升级将在 /etc 中接收新的默认文件，这是一个非常关键的功能。

For more information, see OSTree: Adapting.
欲了解更多信息，请参阅 OSTree: Adapting。

Operating system changes
操作系统更改

• The RPM database is stored in /usr/share/rpm, and is immutable.
  RPM 数据库存储在 /usr/share/rpm 中，且不可变。
• A package nss-altfiles is required, and the system password database is stored in /usr/lib/passwd. Similar for the group database. This might change in the future; see this issue.
  需要一个包 nss-altfiles，并且系统密码数据库存储在 /usr/lib/passwd 中。组数据库类似。这可能会在将来更改；请参阅此问题。