在我们的 上一篇帖子 中，我们承诺了关于这个博客的消息，但行政方面的工作进展缓慢，惊喜还没有准备好。好消息是，我们有一些关于 YaST 的消息。所以让我们开始吧！
CaaSP 一键系统安装
如你所知，SUSE 一直致力于使容器更易于使用，通过 SUSE Container as a Service Platform。我们在之前的几篇帖子中提到了它，使用了 CASP 这个缩写，尽管现在正确的缩写是 CaaSP（也许我们可以将新的“a”作为闪亮的功能来销售 
）。
这个即将推出的产品也包含了一个使用老牌 YaST 的交互式安装选项。CaaSP 使用 SLE 可能性的一个有限子集，我们希望使安装更简单，以反映这一点。因此，我们减少了你必须点击的对话框数量……减少到仅剩一个！
正如你所看到的，这是以牺牲在屏幕上填充比平时更多的控件为代价的。尽管如此，你必须做出决定的部分只有 root 密码。
我们预计大多数 CaaSP 安装实际上不会使用它，因为它们将使用 AutoYaST 自动完成。但即使只是刚开始使用，它也应该很有用。
完善只读安装建议
已经可以 一段时间 提出“只读”建议了。但是，它的黑白逻辑对于某些用例来说不够充分。因此，它被重新设计，你可以将建议标记为硬只读或软只读。区别在于用户将永远无法更改硬只读建议。但是，如果建议报告错误，他们将能够修改软只读建议。例如，这对于软件建议中的错误恢复很有用。它最初是为 CaaSP 实现的，但它也将适用于 SLE-12-SP3 和 Leap 42.3。
直接从 repomd 仓库安装
在安装 (open)SUSE 时，到目前为止，你需要一个专门准备好的安装仓库。除了包含 RPM 包的仓库之外，它还需要一堆专门准备的文件，其中包含安装系统和我们心爱的 YaST 安装程序。
这一切都消失了！
现在你可以将安装程序指向任何纯 repomd 仓库。为了使之工作，你必须将安装程序指向 repomd 仓库 和 安装系统（现在它们可以完全分开）。
例如
install=http://download.opensuse.org/tumbleweed/repo/oss instsys=disk:/boot/x86_64/root
在这个例子中，我们从 openSUSE 网站安装 Tumbleweed，并使用来自一些本地介质（也许是 NET iso）的安装程序。
为了使事情更简单，现在有一个常规包 (tftpboot-installation-openSUSE)，其中包含安装系统和一些示例配置文件。
查看 此 linuxrc 文档 以获取技术细节。
存储重构：移除安装路径中的障碍
在我们的 最新帖子 中，我们展示了我们用作基础来与可用性专家讨论新的专家分区 UI 的文档。现在轮到建议设置对话框了。我们收集了当前状态，进行了一次富有成效的讨论，并最终提出了一个新的界面建议。你可以查看 生成的文档，涵盖所有这些内容。
正如所提到的，SUSE UX 专家将使用该文档作为设计最终界面的起点。但是，我们希望该过程像 YaST 周围的一切一样开放，所以请随时提供反馈。
为系统角色提供更多支持
我们继续扩展系统角色的功能，现在可以指定要启用的 systemd 服务。由于角色可以定义安装在系统中的软件，因此让它们能够指定这些软件中包含的服务的所需状态是合理的。
例如，对于给定的产品（假设是定制的 openSUSE），定义一个“静态 Web 服务器”角色是可能的。在安装期间选择该角色将导致一个已经安装并启用的 HTTP 服务器的系统，因此用户只需要将要提供的文件复制到正确的目录即可。
专家分区程序现在对加密的限制较少
使用自动存储建议设置加密 LVM 始终都很容易——只需在建议设置中选择“加密 LVM”，就完成了。
但是手动执行几乎是不可能的：专家分区程序不允许任何系统挂载点（“/”、“/usr”、“/var”、…）位于任何加密分区上，并且它也不允许加密但不格式化用于 LVM 物理卷的“LVM”类型的分区。
这两个限制现在都已解除；现在你可以创建一个带有加密的 LVM 物理卷，或者如果你更喜欢，可以在逻辑卷上进行加密层。你也可以创建一个带有文件系统直接在其上的加密普通分区，而无需 LVM。
多年来，Grub2 已经学会了如何做到这一点，因此你不再需要 /boot 分区了。目前，你需要在 Grub2 提示符处输入两次加密密码，尽管稍后在图形控制台中才能挂载这些文件系统。我们的基础系统开发人员正在努力寻找一种安全的解决方案来避免这种情况。
将 Travis CI 迁移到 Docker
这实际上不是 YaST 本身的变化，而是其开发基础设施的变化。尽管如此，我们认为这对于我们博客的普通读者来说会很有趣。
到目前为止，我们使用 Travis CI 来构建和测试 GitHub 上的提交和拉取请求。但是问题是，默认情况下 Travis 在构建工作器上运行 Ubuntu 12.04 或 14.04。这对于我们来说有几个缺点，因为在 Ubuntu 上编译和测试 YaST 并不容易，并且结果并不总是与 openSUSE 完全等效。所有这些意味着我们需要做额外的维护工作。
幸运的是，Travis 允许在工作器上使用 Docker 容器，这允许使用基本上任何 Linux 发行版。这个冲刺中，我们花了一些时间将 Travis 配置转换为使用 dockerized openSUSE Tumbleweed 在 Travis 上运行。
工作是成功的，我们切换了所有 YaST 模块以使用这种新的构建，并且结果已经在几个层面上得到了回报，尽管这需要我们 超过 100 个拉取请求（所有这些都经过手动调整和审查）才能实现。
当前的解决方案 已记录，我们还进行了一次简短的内部演示来介绍此更改。演示笔记 在此处提供。
改进 Snapper 的持续集成
我们还为 Snapper 启用了 Travis 集成 Docker。如你所知，Snapper 是一种可移植的软件，它始终为许多 Linux 发行版提供 filesystems:snapper OBS 仓库中的软件包。
因此，我们将持续集成进一步推进了一步，并在更多发行版上启用了 Travis 构建，目前我们为 openSUSE Tumbleweed、openSUSE Leap 42.2、Fedora 25、Debian 8 和 Ubuntu 16.10 构建。你可以在 此处 查看一个示例构建，或在 文档 中了解更多详细信息。
这意味着我们可以在合并拉取请求之前确保该软件包仍然可以在所有这些发行版上构建！
为 YaST 服务提供更好的 systemd 集成
Systemd 识别服务在经典 Unix 启用/禁用和运行/停止之外的许多可能状态，并且该状态列表随着每个 systemd 版本的发布而增长。过去 YaST 在显示服务状态方面遇到了一些问题。
现在问题已通过将从具体状态到旧的已知 Unix 等效状态的转换委托给 systemd 来解决。因此，用户现在可以获得有关系统上运行的所有服务的更精确信息。
存储重构：重新设计安装用户体验
在最新的帖子中，我们向你展示了我们用作基础来与可用性专家讨论新的专家分区 UI 的文档。现在轮到建议设置对话框了。我们收集了当前状态，进行了一次富有成效的讨论，并最终提出了一个新的界面建议。你可以查看 生成的文档，涵盖所有这些内容。
正如所提到的，SUSE UX 专家将使用该文档作为设计最终界面的起点。但是，我们希望该过程像 YaST 周围的一切一样开放，所以请随时提供反馈。
从 libzypp 读取产品重命名信息
在执行升级时，YaST 需要知道产品是否已重命名或被另一个产品取代。例如，过去，Subscription Manager Tool (SMT) 存在于自己的产品中，但它包含在 SUSE Linux Enterprise 12 中。因此，YaST 需要知道 suse-smt 产品只是被 sles 取代。
通常由 SUSE Customer Center (SCC) 提供此信息。但是，如果例如我们正在执行离线升级会发生什么？直到现在，YaST 使用 硬编码的回退列表。
从现在开始，在回退到这样的列表之前，YaST 将向 libzypp 询问该信息，因此希望它能够避免在升级扩展程序时出现一些问题，并减少维护硬编码列表的麻烦。
存储重构：确保安装存储相关包
YaST 存储子系统长期以来一直在处理与存储相关的软件包。例如，如果系统使用特定的文件系统类型，如 Btrfs 或 XFS，我们需要确保安装必要的支持包，如 btrfsprogs 或 xfsprogs。
现在由新的 libstorage 来确定使用了哪些功能。在这个冲刺中，我们创建了一个 Ruby 类，该类将这些功能映射到各自的包，以及 一个类，该类处理包安装本身。一个有趣的方面是 Ruby 自省能力是如何用来避免从 C++ 部分（即 libstorage）复制定义的特征列表的。
赋予变色龙力量
除了 YaST 中的所有这些变化以及我们未包含在此摘要中的更多变化之外，我们还有一些值得庆祝的事情。2 月 1 日，SUSE 的 YaST 团队增加了一名新成员 Iván，他将使该项目能够更快更好地发展……而且这不会是该方向的最后公告，所以请继续关注。
但是不要忘记，你也可以帮助 YaST 和 openSUSE 保持发展。本周，我们向 Google Summer of Code 添加了几个想法到 openSUSE 导师页面，包括一个为 YaST 做贡献的想法。你有一个更好的计划来度过这个夏天吗？
不到三周后见，因为下一次冲刺将由于 Hack Week 15 而略短。