YaST 开发报告 - 2022 年第 7 章

最近，我们的博客主要报道了 ALP（可适应 Linux 平台）领域的开发进展，但我们从未停止改进 YaST 在我们当前维护的系统上的工作方式。在本报告中，我们将首先了解我们计划为 openSUSE Tumbleweed 发布的安装程序功能，以及作为 Leap 和 SUSE Linux Enterprise 当前版本的维护更新。当然，这并不会阻止我们为您提供对中期未来的抢先一瞥。整个菜单包括

介绍在安装过程中验证安全策略的新机制
宣布官方 YaST 容器镜像
关于 Cockpit 和 YaST 在 ALP 上的当前状态的一些报告
Iguana 和 D-Installer 的开发更新

安装程序中的安全策略

我们都知道，为了最大限度地减少安全隐患，在安装和管理任何计算机系统时都必须遵守一系列良好实践。在某些情况下，这些良好实践被形式化为所谓的安全策略，该策略定义了为了使给定系统被接受在安全环境中必须遵守的准则。在这方面，DISA（国防信息系统局）和 SUSE 共同编写了 STIG（安全技术实施指南），描述了如何加固 SUSE Linux Enterprise 系统。

STIG 是一个长长的规则列表，每个规则都包含描述、问题检测以及如何逐条修复问题。甚至有一些工具可以自动检测和修复已安装系统中的许多问题。但是，如果操作系统安装过程中未正确设置某些方面，则很难纠正，例如需要加密所有相关文件系统或遵守有关设备格式化方式和挂载点定义的某些限制。

因此，我们正在积极地将安全策略的概念添加到交互式安装 (https://github.com/yast/yast-security/pull/128) 和 AutoYaST (https://github.com/yast/yast-autoinstallation/pull/845) 中。这仍在进行中，当功能准备好发布到仓库时，我们将提供更详细的审查。

官方 YaST 容器镜像

其他新闻是，您知道我们一直在努力使 YaST 能够作为容器运行。到目前为止，需要执行脚本才能使用容器化的 YaST 版本。它甚至作为 openSUSE Tumbleweed 上的软件包提供。但是现在，随着 ALP 和其所谓的 workload 概念的最新进展，我们找到了一个更好的 YaST 容器分发方式。

我们现在在 SUSE:ALP:Workloads 仓库中提供了三个“官方”YaST 容器。虽然该仓库，顾名思义，应该为要在 ALP 之上执行的容器化 workload 提供服务，但我们决定无论您是在 ALP、最新的 SLE、最新的 Leap 还是 openSUSE Tumbleweed 之上运行它，它都将是容器化 YaST 的官方来源。在所有情况下都应该以相同的方式工作。

因此，从现在开始，您可以通过执行以下操作在任何地方运行容器化的 YaST

podman container runlabel run 
registry.opensuse.org/suse/alp/workloads/tumbleweed_containerfiles/suse/alp/workloads/yast-mgmt-ncurses:latest

将“ncurses”替换为“qt”或“web”以享受替代版本。

这条路径有点冗余，将来可能会更改，但这超出了 YaST 团队的控制范围。无论如何，我们将始终使用官方 ALP workload 仓库。

有关更多详细信息，请参阅完整的公告在 yast-devel 邮件列表的存档中。

此外，我们也很自豪地指出，这些容器镜像包括 YaST Kdump 和 YaST Bootloader 模块。我们最近将其调整为可容器化运行，我们认为这是一个重要的里程碑，因为它意味着 libstorage-ng 现在能够从容器中分析正在运行的主机系统。

YaST 在 ALP 上

如您所知，容器化 YaST 的主要动机是使其可供 ALP 用户使用。但 ALP 是 Linux 发行版中的一个新概念，它对某些系统管理领域采取了创新的方法。因此，我们并不期望容器化的 YaST 或 YaST 能够直接在 ALP 之上平稳运行。因此，我们在 ALP 的早期预览中持续评估情况，以检测 YaST（甚至 ALP 本身）需要修复的领域，并决定在每个给定时刻将重点放在哪里。

好消息是，大多数事情似乎在 ALP 的非事务性变体中有效。我们只检测到一些小问题，现在我们正在跟踪这些问题，并将在时间允许的情况下逐步修复它们。

但在事务性 ALP 系统上，这很可能是大多数场景中的默认版本，我们遇到了一个关于软件安装的非常明显的问题。 YaST 不使用静态 RPM 依赖项来预先强制执行其依赖的工具的安装。相反，YaST 在其执行期间按需安装所需的任何软件。这在由 ALP 或 openSUSE MicroOS 定义的事务性系统中是一个问题。值得庆幸的是，我们检查了绕过软件安装问题，大多数其他功能也同样适用于事务性 ALP 系统，唯一的例外是前面提到的 YaST Kdump 和 YaST Bootloader。虽然这两个模块在任何非事务性系统中都可以很好地容器化运行，但我们仍然需要找到一种方法，在 /boot 无法直接写入的情况下使用它们。

简而言之，YaST 在 ALP 上看起来相对有希望，但我们仍然需要在各个方面进行许多调整。我们将随时向您通报进展情况。

Cockpit 怎么样？

如前所述，ALP 是一个创新的系统，这不仅影响 YaST。 Cockpit，ALP 上默认的 1:1 系统管理平台，也面临着 ALP 第一个原型的一些特殊性，尤其是在其事务性风格中。

因此，我们也在投入大量时间来测试 ALP 上的所有 Cockpit 功能，并记录需要调整的部分……甚至重新思考 Cockpit 或 ALP 对某些主题的方法。与 YaST 的情况一样，我们已经在一些方面工作，并将随时向您通报我们解决每个现有问题的情况。

继续推进 Iguana 和 D-Installer

说到 ALP，您知道我们正在利用它来重新思考未来如何在具有复杂存储技术、网络设置等要求的真实硬件上安装（open）SUSE 系统。在这方面，我们继续开发 D-Installer 和 Iguana。

对于前者，最近的新闻是关于内部架构。您可能还记得之前的报告，我们正在尝试使 D-Installer 尽可能模块化，并使用单独的进程来处理软件管理、用户创建、国际化等。为了使该机制更强大，我们现在定义了一个 D-Bus API，以便不同的进程可以通过集中的用户界面与用户交互。请参阅相应的 pull request 以获取更多详细信息。

对于 Iguana，我们专注于扩展其范围（例如，使其在 Saltboot 的上下文中很有用）和文档。 Iguana Orchestrator (iguana-workflow) 现在提供了一些可能的用例示例，例如将 D-Installer 作为两个单独的容器运行，一个用于后端，另一个用于 Web 界面。如果您想运行自己的实验，请安装来自 OBS 的 iguana 软件包将安装一个内核和 iguana-initrd，然后可以用于 PXE 启动或在虚拟机中直接启动内核。