YaST 开发冲刺 48 亮点

AutoYaST 中的 Chrony 支持

作为我们努力支持 Chrony 作为 (open)SUSE 的默认 NTP 服务的举措，我们改进了 AutoYaST 处理此类服务配置的方式。最显著的变化是我们重新设计了模式，该模式不再包含低级配置选项，而是由一组应用于默认设置之上的高级选项组成。

以下是新的（更简洁）配置的样子

<ntp-client>
  <ntp_policy>auto</ntp_policy>
  <ntp_servers config:type="list">
    <ntp_server>
      <iburst config:type="boolean">false</iburst>
      <address>cz.pool.ntp.org</address>
      <offline config:type="boolean">true</offline>
    </ntp_server>
  </ntp_servers>
  <ntp_sync>15</ntp_sync>
</ntp-client>

更新远程管理功能

在此冲刺期间，远程管理客户端经过了深度修改。首先，由于 xinetd 正在被 systemd sockets 取代，我们删除了该依赖项（并相应地调整了代码）。

此外，VNC 处理也得到了改进。过去，YaST 提供了通过 Java applet 在 Web 浏览器中连接的可能性。现在 YaST 允许用户启用/禁用此功能（请查看下面的屏幕截图以了解现在的外观）。值得一提的是，Michal Srb 用 novnc（基于 JavaScript 的程序）取代了旧的查看器。非常感谢你，Michal！

最后但并非最不重要的一点，我们借此机会进行了一些代码清理，使用通用小部件操作面向对象 API 重新实现了某些对话框。

在安装期间修改 AutoYaST 配置文件

AutoYaST 提供了一个很酷的功能，允许在安装的初始阶段使用用户脚本修改配置文件。因此，您可以运行一个调整配置文件的脚本，AutoYaST 将再次读取它。如果您对该功能感兴趣，可以在官方文档中找到更多信息。

另一方面，在我们的上一份报告中，我们提到 AutoYaST 再次可以使用新的存储堆栈使用多路径设备。但我们没有考虑到可以在运行时修改配置文件，因此初始化发生得太早了。

现在该错误已修复，您可以使用上述功能再次调整任何存储设置。

正确处理选定的模块

如您所知，我们之前添加了对多产品介质（DVD，其中包含多个存储库/产品在单独的子目录中）的支持。这次我们修复了一些与此功能相关的问题。

最初，在选择多个产品后，只有其中一个产品实际被选中进行安装，并且只有其中一个产品显示在安装建议中。幸运的是，这些问题现在已经得到解决。

多产品选择对话框的统一外观和感觉

对于多产品 DVD 介质，我们使用了这个选择对话框

该功能与在注册系统后显示的在线产品选择对话框非常相似

如您所见，外观和感觉有所不同，但从可用性的角度来看，无论产品是从 DVD 介质还是在线源（注册服务器）添加的，对话框都应该看起来相同。

本次冲刺我们改进了 DVD 介质对话框，使其更好地匹配注册对话框

对话框仍然不完全相同，但现在看起来更相似，因此用户应该会更熟悉它。此外，还显示了一条关于不自动处理产品依赖关系的附加说明。此说明已经存在于帮助文本中，但默认情况下是隐藏的。由于我们收到了很多关于此问题的错误报告，因此我们决定使这一事实更加突出。

（注意：对话框实际上不能完全相同，因为 DVD 介质当前缺少一些信息，例如依赖关系、beta 状态、详细描述……）。

删除 SYSTEMCTL_OPTIONS 变量支持

我们一直在使用名为 SYSTEMCTL_OPTIONS（SUSE 特有的）的环境变量在我们的 systemd 服务中防止依赖关系中的锁。由于此解决方法对于即将发布的 (open)SUSE 15 版本不再必要，因此它将从 systemd 中删除，因此我们已经将其从我们的 systemd 服务中删除。

统一 AutoYaST 中的磁盘标签处理

在指定 AutoYaST 分区方案时，您可以选择对每个设备使用哪种分区类型（MSDOS、GPT、DASD 等）。过去，AutoYaST 实现了自己的逻辑来选择在用户未指定的情况下使用哪种分区类型。在本次冲刺之后，AutoYaST 依赖于新的存储堆栈来决定在用户未指定时哪个选项更合适。

奖励：自动检查定义的 Systemd 状态

我们之前在 YaST 中遇到过严重的系统服务管理问题（请参阅 bug#1012047 和 bug#1017166）。该问题是由引入 YaST 未预期的新的 systemd 服务状态引起的。我们通过正确处理新状态解决了该问题。

但主要问题是，我们（作为 YaST 开发人员）没有收到此重大系统更改的通知，并且是在收到 Bugzilla 中的错误报告后才发现此更改。为了避免将来再次出现此问题，我们决定实现一个脚本，该脚本将定期检查定义的 systemd 状态，并在检测到未知状态时通知我们。

为了实现定期检查，我们使用 Travis cron job 功能，该功能不仅允许在将更改推送到存储库后运行持续集成构建，还允许以定期的时间间隔运行构建，即使代码中没有更改。

或者，您可以使用任何 CI 服务，但我们选择了 Travis，因为它易于使用，并且我们已经使用 Docker 进行常规 CI 作业，这使我们能够以一种简单的方式运行 openSUSE Tumbleweed 中的最新 systemd。

在这种情况下，我们可能可以在构建 yast2-services-manager 包时在 OBS 中运行该脚本，但这需要将 systemd 添加到 BuildRequires，这听起来不是一个好主意……

因此，如果您也需要定期运行一些检查脚本，可以在此拉取请求中找到更多详细信息。

结论

2017 年是一个激动人心的一年，有很多有趣的事情：新的存储层、多产品安装介质、集成新组件（firewalld、chrony 等）。看起来 2018 年也不会不同，我们将有很多乐趣。

感谢您的支持，新年快乐！

YaST开发冲刺48亮点