我们再次启程！就在上一次报告之后的一周，我们已经准备好了一批（希望）令人兴奋的新消息。让我们来看看我们第 34 次 Scrum 冲刺的成果。
EFI 的可信启动支持
在 我们第 19 次冲刺的报告 中，我们已经介绍了 YaST2 启动加载程序中新的（当时）闪亮的 Trusted Boot 支持。到目前为止，仅支持 x86_64 系统上的传统启动（即，无 UEFI）场景。现在，感谢 TPM2，也可以使用 EFI 进行可信启动，因此我们在我们心爱的启动加载程序模块中添加了对其的支持。
因此，现在 YaST 启动加载程序在非 EFI 和 EFI 变体中看起来相同，无论实际使用哪种底层技术。当然，YaST 只是冰山一角，使用 EFI 进行可信启动要归功于所有最近添加了对 TPM2 支持的工具。openSUSE 开发者和打包人员太棒了！
在 CaaSP 中配置 NTP 服务
为了使 CaaSP 集群正常工作，所有节点的时间同步至关重要。因此，从现在开始，安装程序能够以适当的方式配置每个节点，并且管理节点将充当工作节点 NTP 服务器。
为此，将在管理节点安装期间要求用户指定一个或多个用作时间源的 NTP 服务器，YaST 将负责其余操作（更新配置并启用该服务）。
如果通过 SLP 宣布 NTP 服务，YaST 将自动提出。
对于工作节点，YaST 将配置系统以使其与管理角色保持同步。
存储重构：改进引导设置
通过之前的报告，您已经能够跟踪分区建议的翻新引导设置的演变。这个冲刺也不例外，我们进一步改进和调整了向导，使其更加智能和易于使用。
新版本能够根据当前场景决定显示哪些步骤。例如，在只有一个磁盘的系统中，将跳过整个磁盘选择对话框。通过禁用不适用于当前情况的小部件，简化了步骤。例如，如果没有先前的 Linux 安装，将禁用有关如何处理现有 Linux 分区的问题。
说到对预先存在的分区执行的操作，这些也得到了改进。在第一个引导设置版本中，这些选项仅用于说明目的，但现在它们是 100% 真实的，并且建议将遵守其值，因此用户可以轻松选择如何处理以前的 Windows 或 Linux 分区。我们甚至为其他类型的分区添加了第三个选项。
最后但并非最不重要（关于引导设置），加密的密码选择现在更易于使用，允许用户在确实需要时选择不太强的密码。
移除 Insserv
YaST 是一套复杂而庞大的软件。这意味着有时曾经很棒和闪亮的组件会变得过时并最终变得无用。生命的周期。
一段时间前，决定是时候让 insserv 退休了，并用一个存根替换了它。但 YaST 中仍然存在对 insserv 的调用，我们决定删除它们。做出这个决定的原因有很多。基本上（open）SUSE 已经使用了 systemd 好几年了，因此重新审视 YaST 代码依赖于 SySV 的地方是必须的。作为副作用，它缩短了 YaST 的依赖项列表，最终，这是朝着更小安装迈出的一个小步骤。
所以再见 insserv，与您合作很愉快。
改进 zKVM 在 S/390 上的 ZFCP 控制器配置
在 zKVM 虚拟机中的主框架上运行安装程序时，会显示有关未检测到 ZFCP 控制器的警告
但是，在 zKVM 虚拟机中运行时，磁盘可以通过 virtio 驱动程序访问，而不是通过模拟的 ZFCP 控制器。该警告毫无意义且令人困惑。
修复基本上只是一个单行代码，它在检测到 zKVM 虚拟化时跳过警告，但 YaST 模块通常不会收到太多的维护，因此我们应用了我们的 侦察兵规则 并改进了代码。
改进包括使用 Rubocop 以获得干净统一的编码风格，启用代码覆盖率以了解代码的测试程度（在这种情况下，结果非常低，只有大约 4%），删除未使用的文件等。您可以在 拉取请求 中找到详细信息。
存储重构：全面改进
正如我们在 关于 Hack Week 15 的报告 中所报告的那样，我们一直在致力于 一种替代方法，以向 Ruby 世界提供新存储库的力量。新的 API 终于准备好投入使用，并用于所有 Ruby 代码。
我们借此机会大大改进了开发人员文档，并翻新了 yast2-storage-ng README 和状态页面。
我们还进行了一些额外的检查，并添加了自动化测试，以确保我们的分区建议确保使用 ZFCP 的 S/390 系统的要求，以便主框架用户也能平稳过渡到新的存储堆栈。
我们还大大改进了新库处理设备替代名称方案的能力。到目前为止，仅完全支持使用纯内核设备名称（例如 /dev/sda1）。现在，我们可以通过设备名称、UUID、文件系统标签、设备 ID 和设备路径执行所有操作（特别是生成 /etc/fstab 文件）。
更多内容已经在酝酿中！
如您所知，至少我们经常重复， YaST 已经从 YCP 转换为 Ruby。但是，此转换是基于语言的。一些旧的设计决策和原则仍然存在，例如使用 SCR 来访问底层系统。
一段时间前，我们推出了 CFA（Config Files Api Gem） 作为 SCR 的更强大和灵活的 Ruby 驱动的替代方案。虽然我们已经在几个 YaST 模块中使用它，但我们觉得其操作背后的概念和原理并不那么清晰。
因此，我们花了一些时间改进文档并撰写博客文章，以正确地向世界介绍和解释 CFA。我们将在下周发布它，敬请期待！
好消息即将到来！
下一次冲刺将是整个 YaST 团队一起工作，将新的存储堆栈集成到 YaST 的每个部分中的第一次。因此，我们希望下一次报告充满有关专家分区的良好消息、AutoYaST 处理磁盘的改进等等。
当然，这只是我们计划工作的一小部分。三周后与您见面，了解更多新闻！