内容

重构的网络即将登陆 Tumbleweed

几周前，我们向 Tumbleweed 提交了网络模块的第一轮更改。 此时，它仍然使用旧的数据模型进行大部分操作（除了路由和 DNS 处理），并且仍有大量工作要做。

我们一直在努力提高此模块的整体质量，并且将在未来几天提交一个更新的（并且改进很多）版本。 总而言之，以下是一些亮点

  • 完成了新的数据模型（支持 TUN/TAP、桥接、绑定、VLAN 等）。
  • 新的无线配置工作流程。
  • 改进了接口重命名和驱动程序分配的支持，包括更好的 udev 规则处理。
  • 修复了从静态配置切换到基于 DHCP 的配置时 /etc/hosts 的处理。
  • 在多个领域进行了许多小的修复。

我们完成了重构了吗？ 没有，我们仍在努力改进 S390 支持并修复一些小问题，但大部分工作已经完成。

当然，一旦完成，我们将发布一篇带有详细信息的博客文章。 但是，我们知道你喜欢截图，所以让我们给你展示一些截图。

虽然我们没有引入大的用户界面更改，但我们尝试改进一些小事情，例如正确显示接口是否属于 VLAN，或者隐藏虚拟接口的“硬件”选项卡。

安装过程中 DNS 解析不起作用，或者：openQA 与众不同

当我们收到一个错误报告，称安装过程中 DNS 解析不起作用（自从 SLE-15 以来），解决方案似乎很简单：/run/netconfig/resolv.conf 丢失，因为 /run 目录未镜像（绑定挂载）到目标系统。 这是一项在 SLE-15 之前由 yast-storage 完成的任务，并且由于某种未知原因，在实施 yast-storage-ng 时被遗忘了。 一个 单行修复 很容易完成、测试和提交。

或者说，看起来是这样。

几天后，我们从 SLE openQA 收到报告，称测试在应用此补丁后开始失败。 没有与网络相关的，但安装无法完成，因为安装结束时 10 秒倒计时对话框（“即将重新启动”）被冻结。 UI 完全没有响应任何输入。 但是，无论我们尝试什么，该问题在 openQA 之外都无法重现。 YaST 日志 来自 openQA 显示 /run 已按计划挂载，并在安装结束时干净地卸载——在冻结的对话框之前。 因此，目前还没有线索，这个问题被搁置了一段时间。 直到来自 Tumbleweed 测试的相同报告传来。 显然与这个单行补丁有关。 但是怎么会呢？

这仍然是个谜，直到与 openQA 专家的一次聊天才揭示了问题的真相。 我们认为发生的事情是：openQA 停止了对话框（通过按下按钮），当它尝试继续时，确定按钮没有响应。 我们学到的实际情况是：openQA 停止对话框，然后 从 X 切换到文本控制台，收集日志，切换回 X，然后 UI 停止响应。 因此，这是一个非常重要的缺失点。

有了这个，就可以在 openQA 之外轻松重现：X 日志显示 X 服务器在切换后失去了所有输入设备。 这是因为有人删除了整个 /run 目录。 YaST 日志没有提示（当然不会，否则就太容易了），但搜索源代码找到了 YaST 删除目录的位置。

这段代码是在收到安装留下混乱的 /run 目录的投诉后添加的——当然，安装会留下文件，因为忘记绑定挂载该目录了。 因此，一旦上述补丁再次绑定挂载了它，删除代码就会清理掉目标系统中不是 /run，而是真实的 /run——切断了 X 服务器与外部世界的连接，导致 openQA 测试冻结。

而这个故事的寓意是：可能没有。 但它再次强调，自动化测试设置可能会对测试本身产生意想不到的反馈。 幸运的是，在这种情况下，否则这个问题不会被注意到。

计算机，放大设备图形

分区模块有一个图形视图，可以帮助你查看更复杂的存储设置中的关系

如果你向上或向下转动鼠标滚轮，我们将放大或缩小视图。 现在方向与网络浏览器和在线地图中的行为相匹配，以前我们方向错了。

更新：在校对时，一位团队成员告诉我：“设备图形？那不是设备图形。这才是设备图形：