更多来自 YaST 相关 ALP 工作组 的新闻。随着我们的可适应 Linux 平台第一个原型即将发布，我们继续在多个方面进行工作，例如

  • 改进 Cockpit 集成和文档
  • 增强 YaST 的容器化版本
  • 演进 D-Installer
  • 开发和记录 Iguana

这是一系列相当多样化的工作，所以让我们逐一进行。

ALP 上的 Cockpit - 这本书

Cockpit 已被选为执行 ALP 系统 1:1 管理的默认工具。因此，简化在 ALP 上采用 Cockpit 是 1:1 系统管理工作组的主要目标之一。由于清晰的文档至关重要，我们创建了 此 wiki 页面，解释如何在 ALP 上设置和开始使用 Cockpit。

该文档包含几个所谓的“开发说明”，介绍了我们希望致力于改进用户体验并使流程更加简化的方面。敬请期待更多相关新闻。

容器化 YaST 的改进

如你所知，Cockpit 将不是管理单个 ALP 系统的唯一方式。我们的 YaST 容器化版本也将是那些寻求更传统（open）SUSE 方法的人们的选择。因此，我们采取了一些措施来改进 YaST 在 ALP 上的行为。

首先，我们减少了容器镜像的大小，如以下表格所示。

容器 原始大小 新大小 节省空间
ncurses 433MB 393MB 40MB
qt 883MB 501MB 382MB
web 977MB 650MB 327MB

我们检测到更多减少容器镜像大小的机会，但在大多数情况下，这需要对 YaST 代码进行相对深入的更改，或者重新组织我们如何将 YaST 组件分布到多个镜像中。因此，我们决定将这些更改推迟一段时间，以便专注于其他方面的工作。

我们还调整了 Bootloader 和 Kdump YaST 模块以使其在容器化环境中工作，并将它们添加到可用的容器镜像中。

我们借此机会重新设计了 YaST 处理软件按需安装的方式。如你所知，YaST 有时会要求安装一组软件包才能继续工作或配置某些特定设置。

YaST asking for some packages

由于软件管理堆栈初始化时的某些竞态条件，YaST 有时会在容器中检查甚至安装软件包，而不是在正在配置的主机系统中执行此操作。现在已修复此问题，并且在可以立即安装软件包的任何系统中，无论 YaST 是本机运行还是在容器中运行，它都能按预期工作。但这仍然留下一个悬而未决的问题。在需要系统重启才能安装新软件的事务系统中该怎么办？我们目前还没有答案，但欢迎提出建议。

正如你所能想象的，我们还投入了大量时间来检查 YaST 在 ALP 之上的容器化行为。好消息是，除了前面提到的软件安装挑战外，我们在默认（事务性）ALP 系统和非事务性版本之间没有发现重大差异。不太好的消息是，我们发现了一些与 ncurses 界面渲染、sysctl 配置以及其他方面相关的问题。其中大多数看起来很容易修复，我们计划在未来几周内进行处理。

为 D-Installer 设计网络配置

致力于 Cockpit 和我们的容器化 YaST 并未阻止我们继续演进 D-Installer。如果你已经测试了我们的下一代安装程序，你可能会注意到它不包含配置网络的选项。我们最近花了一些时间研究这个主题，并从架构角度以及用户体验的角度设计网络配置在 D-Installer 中应该如何工作。

在短期内，我们决定涵盖两种最简单的用例：常规的有线和 WiFi 适配器。请记住，Cockpit 尚未允许设置 WiFi 适配器。我们同意直接使用 NetworkManager 提供的 D-Bus 接口。此时，无需添加我们自己的网络服务。在安装结束时，我们将直接从执行 D-Installer 的系统将配置复制到新系统。

实现将不基于现有的 Cockpit 网络配置组件，因为它们存在我们希望避免的几个弱点。相反，我们将重用 cockpit-wicked 扩展的组件，其架构更适合该任务。

D-Installer 作为一组容器

在我们的 上一份报告 中，我们宣布 D-Installer 0.4 是第一个具有模块化架构的版本。因此，除了已经存在的后端和两个现有用户界面（Web UI 和命令行）之间的分离之外，后端现在由几个互连的组件组成。

我们还介绍了 Iguana，一个能够运行容器的最小启动镜像。

你肯定已经猜到下一步是什么了。没错，D-Installer 作为一组容器运行！我们实施了三个概念验证，以检查可行性并研究内存消耗等影响

  • D-Installer 运行为包含后端和 Web 界面在一个容器中。
  • 将系统拆分为两个容器，一个用于后端，另一个用于 Web UI。
  • 将每个 D-Installer 组件（软件处理、用户管理等）运行在其自己的容器中。

值得一提的是，容器通过 D-Bus 进行通信，在每种情况下使用不同的技术。最好的消息是，所有解决方案似乎都能正常工作并能够执行完整的安装。

内存消耗如何？嗯，它显然比使用 YaST 的传统 SLE 安装要大，但在 D-Installer 或容器尚未进行任何优化的当前阶段，这是可以预期的。另一方面，我们没有发现三种概念验证之间有显着差异。

  • 单个一体化容器
    • 启动时使用的 RAM：230 MiB
    • 完成安装时使用的 RAM：505 MiB
  • 两个容器（后端 + Web UI）
    • 启动时：221 MiB（191 MiB 后端 + 30 MiB Web UI）
    • 完成安装时：514 MiB（478 MiB 后端 + 36 MiB Web UI）
  • 所有内容作为单独的容器
    • 启动时：272 MiB（92 MiB 软件 + 74 MiB 管理器 + 75 MiB 用户 + 31 Web）
    • 安装后：439 MiB（245 MiB 软件 + 86 管理器 + 75 用户 + 33 Web）

这些数字是在使用 podman stats 在传统的 openSUSE 系统中执行 D-Installer 时测量的。一旦我们能够在 Iguana 上运行这三个概念验证，我们将获得更准确的数字。这带我们到…

关于使用 Iguana 测试 D-Installer 的文档

到目前为止，Iguana 只能执行单个容器。这意味着它已经适用于一体化 D-Installer 容器，但尚未用于测试其他方法。我们目前正在开发一种受 GitHub Actions 提供的机制启发的容器编排机制。

与此同时，我们向项目添加了一些 基本文档，包括如何使用它来测试 D-Installer。

敬请期待

尽管在这篇博文中减少了出现频率，但我们也在容器化之外继续致力于 YaST。不仅修复错误，还实施新功能和工具，例如我们新的实验性 YaST 日志检查助手。因此，请继续关注 Cockpit、ALP、D-Installer、Iguana 以及 YaST 的更多更新！