迄今为止，五月和六月对于 YaST 团队来说是充满意义的月份。我们努力完善最近发布的 openSUSE Leap 15.1 的最后细节，参加了 openSUSE Conference 2019（进行了许多富有成效的讨论），我们在没有电脑的情况下围坐在一起度过了不少时间（我们团队成员通常是地理位置分散的），许多团队成员享受了假期（欧洲现在是春天），我们组织了一场 Leap 15.1 在加那利群岛举办的发布会，并进行了技术演讲…而且我们耗尽了精力，无法在本博客中发布我们传统的冲刺报告。
我们将尝试通过这篇博客文章来弥补，总结最近三次开发冲刺的亮点，即第 77、78 和 79 次冲刺。所以请注意，这将是一篇很长的文章。
支持多设备 Btrfs 文件系统
在三次冲刺期间，我们一直在努力实施所有必要的组件，以便为安装和升级基于多个块设备、利用 Btrfs RAID 功能的 (open)SUSE 系统提供良好的体验。这包括对分区程序、AutoYaST、存储引导设置等的支持。
我们认为所有这些都值得一篇单独的博客文章。您可以在这里找到：在 YaST 中进一步使用 Btrfs。
分区程序更多改进
那篇博客文章提到了分区程序中的一些更改，虽然最初的动机是引入多设备 Btrfs，但其范围超出了此范围，旨在使所有设备列表更实用和信息丰富。
传统上，分区程序使用两个单独的列“类型”和“FS 类型”来描述每个设备的功能。这有时很难理解。此外，通常重要的信息（例如分区与其 RAID 或 LVM 之间的关系）在这些表中根本缺失。
我们将这些列合并为一个更具信息性的列，该列可以识别设备，并一目了然地概述它们之间的关系。此外，现在显示所有系统设备的表包括多设备文件系统。
缓解 YaST 中的 CPU 漏洞
如果您对安全性感兴趣（或者只是没有生活在岩石下），您可能听说过基于 CPU 的攻击，例如 Spectre 或 Meltdown。过去一年出现了一些这些 CPU 问题，它们都带有自己的内核选项，用于更改 Linux 行为，以牺牲一些性能为代价来减轻安全风险。
然而，并非所有用户都知道哪些因素会影响他们的架构或特定型号的 CPU，以及哪些内核参数可以在安全风险可接受的情况下用来提高性能。
为此目的，一个新的元选项“mitigations”被添加到 Linux 内核中。它允许一次启用和禁用多个可以防止 CPU 攻击的缓解措施。有关更多信息，请参阅 SUSE 发布此文档。
我们认为这个内核选项非常有用，因此我们决定为用户提供一种方便的方式来调整它。现在 YaST 引导加载程序屏幕包含一个新的设置，该设置提供三个预定义选项，甚至还有一个第四个选项，让用户可以自行微调设置。如您在下面的屏幕截图中看到的，我们已经在帮助对话框中包含了详细的文档，因此您将来无需搜索这篇博客文章。
也可以直接从安装摘要中修改此选项。为此，将“防火墙”部分重命名为“安全”，现在它包括调整 CPU 缓解选项的可能性，以及传统的防火墙设置和打开 SSH 端口的设置。
(open)SUSE 为我们的用户提供及时解决方案，以轻松适应不断变化的复杂需求的又一个成功案例。
安装期间的内存优化
在 openSUSE Leap 15.1 发布临近之际，我们收到了一些错误报告，指出 YaST 安装程序在仅使用 1GB RAM 且启用在线仓库时会冻结（参见 bug#1136051）。
事实证明，在某个时候 YaST 会加载所有可用软件包的详细信息。如果安装期间启用了在线仓库，则需要大量的内存。例如，OSS Leap 仓库包含超过 35,000 个二进制软件包！
问题在于 YaST 内部 API 访问软件包管理器库 (libzypp)。它不允许过滤对象，YaST 必须读取所有对象，然后才能在代码中进行过滤。并且对于每个对象，它都会返回所有属性，即使那些不需要的属性（例如软件包描述、完整的 RPM 名称等）。所有这些数据都需要大量的内存。
为了解决这个问题，我们引入了新的 API 调用，允许指定更多的过滤器（例如返回所有选定的软件包、特定仓库中的软件包等），并且您可以设置应返回哪些属性。如果您只需要知道名称和版本，那么您将不会获得其他无用的属性。为了方便 YaST 中新 API 的使用，我们提供了一个用 Ruby 编写的漂亮的面向对象包装器。
此优化可以节省大量内存，1GB 的 RAM 应该足以满足未来安装，即使在线仓库继续增长。
不幸的是，我们只能在 Leap 15.1 正式发布前几周诊断出问题并提供解决方案。在安装程序的这一敏感部分进行更改被认为风险太高（这将使已经执行的许多测试无效），因此包含在 openSUSE Leap 15.1 中的安装程序在启用在线仓库时仍然占用大量内存。对于该版本，我们只是将官方内存要求增加到 1.5 GiB。
从 openSUSE Leap 15.1 到 SLES15-SP1 的在线迁移
对于 openSUSE Leap 15.0，只能手动从 Leap 迁移到 SLES（SUSE Linux Enterprise Server）（参见 文档）。Leap 15.1 的目标是也支持使用 YaST 进行迁移。但是，我们收到了一份错误报告，指出从 openSUSE Leap 15.1 到 SLES15-SP1 的在线迁移显示错误的迁移摘要，并且无法正常工作。
事实证明，YaST 需要一些小的修复才能正确支持此操作。主要问题是 YaST 预计在在线迁移期间基本产品或软件包供应商不会发生变化，到目前为止，只能升级到下一个 SLE 服务包级别。但现在已修复。
想尝试从 openSUSE Leap 15.1 迁移到 SLES15-SP1 吗？然后按照以下步骤操作。
- 在 Leap 15.1 安装中安装
yast2-registration和yast2-migration软件包 - 确保安装了最新的在线更新（以安装上述修复程序）
- 启动 YaST 注册模块，并使用您的注册密钥注册 openSUSE Leap 15.1 产品
- 然后启动 YaST 迁移模块，选择迁移到 SLES15-SP1
- （迁移摘要中可能会报告一些软件包依赖性问题，请转到软件包管理器并解决它们。通常删除旧的 openSUSE 软件包是正确的解决方案。）
- 启动迁移，将下载并安装 SLES 软件包
- 最后，系统将重新启动以启动新安装的 SLES，尽情享受吧！
- （建议使用命令
zypper packages --orphaned查看孤立软件包，即 Leap 安装的残留物，并可能将其删除。）
请注意，仅支持 Leap 的最小服务器安装进行升级，完整的安装，尤其是带有第三方软件包的安装可能无法正常工作。
为什么我无法读取日志？
很久以前，任何 Linux 系统的日志都分布在 /var/log 子目录下的几个文件中。YaST 提供了“系统日志”模块，以便以方便的方式检查这些文件。自从引入 Systemd 及其日志记录机制以来，这些信息逐渐移动到这种新机制中，默认情况下。YaST 提供了“Systemd Journal”模块来检查和查询该日志。
这两个 YaST 模块都可以由系统中的任何用户执行，而不仅仅是 root。这是故意的，因为 Systemd 日志和传统的 Linux 日志文件都可以注册针对非特权用户的目标信息。但是，当此类用户尝试访问受保护的信息时，两个模块显示的错误消息都有改进的空间。
这是“系统日志”模块中新的更具解释性的消息。
这是“Systemd Journal”的扩展消息，现在提到了 systemd-journal 用户组。
YaST 办公室的又一天：适应变化
正如我们通常在博客文章中提到的那样，YaST 团队的大部分工作包括使 YaST 与底层系统不断变化保持同步。当然，这些冲刺在这方面也不例外。在不试图进行详尽的列表的情况下，让我们看看那些变化，因为这些变化可能对某些读者来说很有趣。
事实证明 Systemd 开发人员决定更改 Systemd 服务的可能状态列表。systemd-sigabrt 状态已过时，并添加了一个新的 systemd-watchdog 状态。在 YaST 团队中，我们已经了解到 Systemd 状态的列表比大多数人预期的变化更频繁。因此，我们有一个自动检查来检测这些情况。警铃响起，我们调整了代码，一切都正常工作。
Systemd 并不是唯一不断发展的技术。很久以前，RMT 取代了 SMT 作为 SUSE 客户中心的默认代理技术。虽然两者已经共存了一段时间，但从 SLE-15 开始，仅提供 RMT。因此，我们调整了 YaST 中仍然存在的对 SMT 的所有引用。从现在开始，仅提及 RMT 以避免混淆。
我们必须在 YaST 中执行的另一个常见调整是调整某个模块，当它在幕后运行的命令的输出发生变化时。最近我们发现 iscsiadm 命令的开发人员决定使用多个退出代码来指示成功的执行（传统上，只有零应该表示成功）。经过长时间的讨论，我们决定调整 YaST iSCSI 以也对错误代码 21 感到满意。这对您意味着什么？未来版本的 YaST iSCSI 在某些情况下应该可以更快地工作，因为混淆将不再导致超时。
YaST Firstboot：更好的示例文件
这些只是我们最近为系统变化所做的许多调整的示例。但并非所有调整都是由外部变化引起的。我们还意识到 YaST Firstboot 提供的示例配置文件（位于 /etc/YaST2/firstboot.xml）需要一些改进。由于 YaST Firstboot 的性质，该文件应在实际使用 YaST Firstboot 之前进行自定义。但是，提供一个包含三个不同步骤的示例文件，关于许可协议的接受（其中两个已启用，第三个已禁用）和其他不一致之处，显然无助于任何人了解如何使用该模块。
事实上，该默认示例配置文件的状态以及文档管理让 SUSE 的质量保证团队感到困惑。因此，我们改进了软件包中提供的示例文件，使其更具现实意义，并更新了 YaST Firstboot 文档，以阐明如何使用该文件。因为并非所有改进都总是通过编码完成的。
Leap 15.1 最令人恼火的错误：将主目录创建为 Btrfs 子卷
正如所有 openSUSE 用户都应该知道的那样，对于每个 Leap 版本，都会在 openSUSE wiki 中创建一个页面，列出所谓的“最令人恼火的错误”。Leap 15.1 是一个非常平稳的版本，这一次 相应的列表仅包含一个错误……而且是 YaST 的错误。
在已安装的系统中，当 YaST 创建新用户时，它总是尝试将其主目录创建为 Btrfs 子卷。即使在不可能的情况下也是如此。例如，如果要创建的目录不在 Btrfs 文件系统上。
幸运的是，此错误不会影响安装过程或 AutoYaST。我们创建了一个修复程序，该修复程序作为维护更新迅速可用。因此，请确保您的 openSUSE 系统已更新，然后再尝试使用 YaST 创建新用户。
YaST 网络重构：状态报告
自我们于四月底提交 yast2-network 重构的第一个组件以来，我们在此领域取得了相当大的进展。虽然这仍然是一项正在进行的工作，但我们想向您提供当前状态的更新。
我们可以说，我们一直在处理两个不同的领域：用户界面实现和未来的数据模型。
关于用户界面，团队对代码进行了大量的改进，使其更易于维护和扩展。我们引入了一些类来解耦小部件和数据，效果很好。此外，我们修复了一些错误（其中许多与验证相关），简化了添加新设备的过程，并重新组织了硬件选项卡。
关于内部数据模型，我们一直在思考以一种无关的方式来表示网络配置的最佳方法，以便将来我们不仅可以支持 Wicked，还可以支持其他选项（目前，NetworkManager 的支持非常有限）。如果您对细节感兴趣，我们已将一份描述该方法的文档添加到仓库中。
新的数据模型已经用于处理 DNS 和路由配置。因此，如果您使用的是 Tumbleweed，那么您已经在使用新的网络代码数周了，包括我们在 最新文章中介绍的 UI 增强功能。
虽然到目前为止，该数据模型仅用于上述部分，但计划在下一次 sprint 中向 Tumbleweed 提交一个经过大量重构的 UI 层。敬请期待。
为 YaST 包添加了 Appstream 元数据
YaST 包管理器并非 (open)SUSE 发行版中唯一的软件管理器。还有一些其他的，例如 KDE 中的 Discover 或 GNOME 软件管理器，更不用说在线 openSUSE 应用商店了。
虽然 YaST 管理器是软件包导向的，但那些其他的软件管理器是应用程序导向的。这产生了巨大的差异，尤其是对于初学者用户而言。
完整的软件包列表不仅包括应用程序（基本上是用户可以从桌面启动的任何内容），还包括共享库、为其他应用程序提供功能的组件或系统正常运行所需的的基本组件。由于有如此多的软件包（openSUSE OSS 仓库包含超过 35,000 个！），除非您知道自己在寻找什么，否则有时很难找到您需要的软件。
为了在所有这些之上提供应用程序导向的视图，应用程序管理器需要一些描述软件包中应用程序的特殊数据。如果您对技术细节感兴趣，请查看 Freedesktop.org 提供的 AppStream 文档，这些数据位于 /usr/share/metainfo/*.xml 文件中。
我们绝对优秀的社区贡献者 Stasiek Michalski（更广为人知的昵称是 lcp）意识到 YaST 没有在这些应用程序管理器中提供，并决定修复它。因此，他创建了一个 XML 生成器，该生成器从 YaST 包中收集数据并自动生成其他软件管理器所需的 metainfo XML 文件。
因此，Gnome 软件管理器、Discover 和其他软件管理器将在 Tumbleweed 中将 YaST 作为任何用户导向的应用程序提供。感谢 lcp！
AutoYaST 预安装脚本 & 存储
AutoYaST 具有一项特殊功能，允许用户自定义安装过程并在安装的不同阶段进行控制。为此，AutoYaST 配置文件提供了一个部分，您可以在其中插入自定义脚本。有 四种类型的脚本：预脚本、分区后脚本、chroot 脚本、后脚本和init 脚本。
对于预脚本的特殊情况，文档指出“您也可以在预脚本中更改分区”。这意味着，例如，您可以使用脚本来创建新分区或配置某种技术。因此，在运行用户预脚本后重新分析存储设备将非常方便。事实上，这是旧存储堆栈中的默认行为，但新的堆栈略有修改，仅在某些条件下才重新分析系统。
但事实证明，一些 SLE 客户正在使用预脚本来配置 多路径的行为，而这些更改未被 AutoYaST 注意到。
解决方案非常简单。我们只是决定在 AutoYaST 预脚本之后始终执行新的存储重新分析。我们没有找到不这样做的好理由，而且不应该有明显的性能损失。
并且，对于多路径的特殊情况，YaST 现在在执行新的安装时将一些配置文件（例如，/etc/multipath.conf 和 /etc/multipath/bindings）复制到目标系统。否则，安装的系统将不包含安装期间应用的配置。
澄清软件管理选项的使用
我们的软件管理器是 YaST 最复杂的模块之一，这使得其使用的一些方面对于某些用户来说并不完全明显。您可能已经注意到，这是 YaST 中唯一一个在文本模式和图形模式下执行时界面明显不同的模块。特别是界面顶部的菜单，其组织方式不同。
一些用户对某些选项在模块的不同执行之间没有持久化感到困惑。这些选项是为了修改模块的当前操作，而不是更改系统中的软件包管理配置。
在文本模式下执行时，这一点很清楚，因为这些选项被标记为“临时更改”，但图形模式中没有任何指示。如以下屏幕截图所示，现在已修复了这个问题。
产品许可证难以理解？尝试另一种语言！
有用户报告说，在文本模式安装中无法切换产品许可证的语言。虽然在图形化安装过程中一切正常，但在文本模式下语言切换小部件存在……但被禁用了。
关键在于这种行为并非完全是错误。事实上，我们很久以前就故意这样做了，因为在 Linux 控制台中我们无法显示许多语言的字符。希望我们的一些常客会大喊“这不真实！” 
这些用户记得在我们的 第 67 次 sprint 的报告中，我们解释说现在我们在文本模式下安装时始终使用 fbiterm，以便能够显示几乎每种语言的字符。
我们现在能够显示当前具有许可证翻译的所有语言，因此我们启用了语言切换小部件，现在图形化安装和基于文本的安装都提供相同的用户体验。
更多关于语言
这并不是我们在这些 sprint 中所做的与国际化相关的唯一更改。我们还添加了一条特定的警告消息，用于 YaST 用于更改系统语言但没有包含所需翻译软件包的仓库的情况。这显然只影响在非常受限的环境中配置系统的用户。
正如您在此和其他最新报告中看到的那样，我们不得不经常处理与翻译和国际化相关的困难。为了减少这些问题对最终用户的影响，我们还添加了一些额外的机制来检测开发过程中引入的国际化错误。希望这意味着在未来的报告中，用于评论与语言相关问题的空间会越来越少。
这只是一个总结！
尽管这篇文章看起来很长，但我们在这几周内所做的许多有趣的事情，有意或无意地都遗漏了。我们绝对应该避免连续跳过三份报告！
本周是 SUSE 的 Hack Week，这意味着常规的 YaST 开发将暂停……或者会变成完全不同的东西。你永远不知道 Hack Week 的结果会是什么！
但无论如何，我们将在八月份恢复基于 sprint 的节奏。因此，请在三周后期待新的博客文章。到那时再见！