在 12 月 5 日的夜晚,由三人组成的小队在捷克小镇的街道上疾驰,挨家挨户拜访:Mikuláš(开发者)、čert(Scrum 主管)和 anděl(产品负责人)。如果你是个坏孩子,你会得到煤块或棕色土豆。好孩子,另一方面,将获得新的 YaST 功能

  • 性能:适应 jemalloc,一种更好的 Ruby 内存分配器
  • 已替换组件:s/ntpd/chrony/g s/SUSEFirewall2/firewalld/g
  • 存储:调整分区大小,调整 RAID 大小
  • 软件包模块和扩展:预选它们,自动解决依赖关系,使用 mksusecd 创建自己的安装 ISO
  • 安全相关:可重现构建的 tar 包,root 用户的 SSH 密钥
  • AutoYaST:请求磁盘

性能

在 Ruby 中使用 Jemalloc 内存分配器

MRI Ruby(原始 C 实现)解释器允许使用 jemalloc 库来分配内存,而不是通常的 glibc 默认库。其优点是内存使用率更高(此处报告称内存使用量减少了 30-40%),并且它还具有一些额外的调试功能。

但在 openSUSE Factory 和 SLE15 中启用 Ruby 的此功能后,许多 YaST 软件包无法构建。事实证明,这是 YaST 动态加载库导致的问题。一个解决方法是直接将 YaST 链接到 libjemalloc。

后来我们发现有些包仍然无法构建。这次问题是由库在错误输出中打印的警告引起的。这种情况只发生在运行旧的 YaST 测试套件时,该套件仍然使用嵌入式 Ruby 解释器(正常的 YaST 使用或新的单元测试使用完整的 Ruby,没有这个问题)。修复方法是只在检查测试中的错误输出时忽略该警告。

如果您想检查您的 Ruby 是否使用了 jemalloc 功能,请运行此命令

ruby -r rbconfig -e "puts RbConfig::CONFIG['LIBS']"

如果输出包含 -ljemalloc 选项,则您的 Ruby 正在使用 jemalloc 库。

替换的组件

将 NTP 从 ntpd 切换到 chrony

现在是时候将网络时间协议 (NTP) 实现从 ntpd 切换到 chrony 了,因为它更安全、更好、更优。因此 YaST 也必须适应并修改其 NTP 客户端模块以与 chrony 配合使用。该模块也显示出它的年代感,并且有点复杂,所以我们借此机会进行了一些清理。

最明显的变化是正在运行系统上的用户界面。请注意,用户界面尚未最终确定,它主要只是一个概念验证。但目标很明确:第一个目标是真正做到只作为客户端,因为之前 NTP 也允许配置 NTP 服务器,这使得用户界面对于大多数只想选择服务器进行同步的用户来说变得复杂和混乱。第二个目标是专注于大多数用户,他们希望有一个简单的用户界面来配置普通的 NTP 客户端,将微调留给直接修改配置文件的专家。

在安装程序中,现在调用 chrony 而不是 ntpdate。此更改对用户不可见,并且其工作方式与以前相同。

我们还决定放弃 NTP 客户端模块的命令行界面 (CLI),因为 chrony 本身带有一个不错的 CLI chronyc。我们的 CLI 不再重复工作,而是建议使用 chronyc

另请注意,更改尚未完成,后续会有更多更改。其中一项更改是 AutoYaST 支持,目前已被跳过。但让我们通过一些图片来向您展示它在 Tumbleweed 中很快会是什么样子,并在此过程中解释我们的决定

第一张图片来自主屏幕。它显示了三个主要区域

  1. 时间同步的方式。它允许纯手动运行,以给定间隔同步或使用始终运行的守护程序。
  2. 同步服务器源的配置。它可以是动态的或静态的。对于静态,只使用服务器表中(见第 3 点)的服务器。对于动态,它还会添加来自网络的 NTP 服务器(例如 DHCP 中的服务器)。因此,当用户只使用公共服务器时,静态配置运行良好。但是当使用内部 NTP 服务器并且它们可能会更改时,使用动态选项是有意义的。
  3. 同步服务器列表。这指定了一个静态定义的 NTP 服务器列表,用于同步。您可以使用熟悉的 添加/编辑/删除 按钮。

Main NTP settings

第二张图片来自 编辑 对话框。它也被简化为最常见的选项。测试 按钮允许快速检查服务器是否可达以及其地址是否有错别字。快速初始同步 选项在连接到网络时快速同步时间非常有用。而 离线启动 是 chrony 的一个不错的功能,它允许在启动期间将服务器定义为离线,并且仅在连接到网络时才将其标记为在线并同步。它极大地有助于启动时间,并且是快速启动很重要的笔记本电脑的好选择,并且网络由 Network Manager 管理。

NTP Edit dialog

Firewalld 将成为 SLE15 的默认防火墙(安装程序已适配)

FirewalldSuSEFirewall2 具有一些不错的优势:它可以动态管理,允许更多区域,运行时和永久配置选项之间有分离,维护良好,并且已在某些应用程序或库中得到支持。

这些是决定完全用 firewalld 替换 SuSEFirewall2 的一些主要原因。

上一次冲刺报告中,我们宣布 yast-firewall 已适配支持 firewalld,但这主要是代码的适配,以支持两种后端。

在此次冲刺中,我们已在安装程序中完全替换了 SuSEFirewall2,使用了新的 firewalld API,尽管用户界面似乎没有发生任何变化,但防火墙对话框已使用 CWM (我们面向 YaST 控件的面向对象 API)完全重新实现。

Firewall proposal

Firewall/SSH settings

在接下来的冲刺中,我们将继续调整 firewalld API 和 YaST 模块以完成替换。下一个目标将是支持 AutoYaST 中的 firewalld

存储

专家分区器:调整大小

专家分区器重新获得了调整分区大小的功能。现在在 硬盘 视图以及特定磁盘或特定分区的视图中都提供了 调整大小 按钮。当您尝试调整分区大小时,会显示一个新对话框,其中包含三个选项:最大大小、最小大小和自定义大小。

Partitioner: Resizing

当选择 自定义大小 选项时,您必须手动指定新的分区大小,但请不要担心,专家分区器会阻止您输入错误的大小。此外,它会自动对齐分区以获得更好的性能。

Partitioner: Resizing error

RAID 管理改进

与分区一样,现在也可以调整软件 RAID 的大小,尽管在 RAID 的情况下,调整大小是通过向其添加或移除设备来执行的完全不同的操作。分区器将确保您已选择当前 RAID 类型所需的最小设备数量。请注意,调整软件 RAID 的大小只适用于正在创建的新 RAID,也就是说,当 RAID 存在于磁盘上时不允许执行调整大小操作。

RAID management

如您在该屏幕截图中所示,在此次冲刺期间,设备列表右侧也添加了用于在 RAID 中对设备进行排序的按钮。这些按钮在创建新 RAID 和调整其大小时都可用。

最后但同样重要的是,现在也可以像处理普通磁盘一样处理 BIOS RAID。您可以在专家分区器的 硬盘 部分找到所有 BIOS RAID,在那里您可以向 RAID 设备添加或移除分区。

软件模块和扩展

SLE15 产品被拆分为多个存储库,安装介质只包含启动系统所需的最小软件包集。如果您想要更多功能,则必须注册系统或使用额外的介质。

为了方便用户,注册模块现在预选了推荐的模块或扩展。但是,如果您出于某种原因确实需要一个最小系统,您仍然可以取消选择预选的项目。

推荐插件列表在服务器端 (SCC) 维护,因此无需更新 YaST 安装程序即可进行更改。

在 AutoYaST 中添加模块和扩展

由于基础 SLE15 产品已被拆分为多个模块,SLE15 可用模块和扩展的列表已经相当长。这使得从注册服务器添加模块比 SLE12 更复杂。

最初,AutoYaST 完全按照指定的顺序在 XML 配置文件中注册插件。这带来了麻烦,因为 SCC 要求先注册依赖模块。在 SLE15 中,以正确的注册顺序写入配置文件中的模块并不容易。

为了使其更简单,AutoYaST 现在根据它们的依赖关系自动重新排序模块,甚至注册配置文件中缺少的依赖模块。显然,这只有在缺少的模块不需要注册密钥的情况下才能很好地工作。

mksusecd 和 linuxrc 支持新的媒体布局

从 SLE15 开始,安装介质的布局略有不同。简而言之:包含产品信息和校验和列表的 content 文件已移除,并已被 .treeinfoCHECKSUMS 替换。此外,软件包存储库现在是 repomd 存储库。

此外,SLE15 已被拆分为几个所谓的模块。安装介质本身只包含最少的软件包。您必须在安装过程中注册才能访问其他模块或使用包含它们的单独介质。

为了避免您随身携带多个 U 盘,mksusecd 允许您构建自己的定制安装介质。

首先,检查媒体上有哪些内容。安装 ISO 只包含基本产品

# mksusecd --list-repos SLE-15-Installer.iso
Repositories:
  SLES15 [15-0]

你需要一个额外的镜像来安装模块

# mksusecd --list-repos SLE-15-Packages.iso 
Repositories:
  Basesystem-Module [15-0]
  Desktop-Productivity-Module [15-0]
  Desktop-Applications-Module [15-0]
  Development-Tools-Module [15-0]
  HA-Module [15-0]
  HPC-Module [15-0]
  Legacy-Module [15-0]
  Public-Cloud-Module [15-0]
  SAP-Applications-Module [15-0]
  Server-Applications-Module [15-0]

然后选择要添加到安装介质的模块

# mksusecd --create new.iso \
  --include-repos Basesystem-Module,Legacy-Module \
  SLE-15-Installer.iso SLE-15-Packages.iso
Repositories:
  SLES15 [15-0]
  Basesystem-Module [15-0]
  Legacy-Module [15-0]
assuming repo-md sources
El-Torito legacy bootable (x86_64)
El-Torito UEFI bootable (x86_64)
building: 100%
calculating sha256...

现在使用 new.iso 开始安装。

安全/开发

创建可重现的 Tar 包

我们使用 Jenkins 自动将 YaST 包从 Git 仓库提交到 OBS 项目。我们使用两个 Jenkins 实例,公共 Jenkins 提交到 openSUSE Factory/Tumbleweed,内部 Jenkins 提交相同的包到 SLE15。

OBS 将 SLE15 软件包与 openSUSE 版本进行比较,以确保两个项目中都构建了相同的软件包。但是此检查仅比较文件校验和,而不比较存档内容。

问题是内部和外部 Jenkins 创建了一个校验和不同的 tar 包,尽管里面的文件完全相同。如果您运行简单的 tar cfjv archive.tar.bz2 files,您会发现每次运行的 tar 包校验和都不同。那么如何以可重现的方式创建 tar 包呢?

为了构建一个可重现的 tar 包,我们使用这些 tar 选项

  • --owner=root --group=root – 确保文件所有者和组始终相同,无论是谁构建 tar 包或谁拥有系统上的文件
  • --mtime=<timestamp> – 以保持文件时间戳不变,无论何时下载源文件。使用固定时间戳(例如 0)不是一个好主意,因为您不知道文件实际有多旧,但使用当前时间会使 tar 包无法重现。因此,我们使用 Git 仓库中最后一次提交的日期(git show -s --format=%ci),它在多次运行中保持稳定,并且仍然描述文件有多旧。
  • --format=gnu – 使用 GNU tar 格式,默认的 POSIX 格式包含一些归档时间戳
  • --null --files-from - – 这告诉 tar 从标准输入读取文件名,我们将此选项与 find ... -print0 | LC_ALL=C sort -z 一起使用,以对文件进行排序,使其始终保持完全相同的文件顺序。

注意:这也取决于您用于压缩 tarball 的压缩方法。例如,gzip 默认也会向存档添加一些时间戳,而 bzip2 则不会。如果您想使用 gzip,请使用 -n 选项。

有关实现细节,请参阅 tarball Rake 任务

AutoYaST 支持部署 root SSH 授权密钥

安全角度来看,建议使用 SSH 登录远程机器,而不是使用明文的用户和密码。但是,记住用户和密码,特别是如果您尝试使用一个强壮且不可预测的密码,也是困难且难以维护的。

因此,SSH 提供基于公钥加密的身份验证,并且自SLE-12-SP2以来,AutoYaST 支持为普通用户部署 SSH 授权密钥,但它不适用于root用户。

我们已在 SLES-12-SP3 中修复了此问题,允许也将 SSH 授权密钥部署到 root 用户,并将其导出到克隆的系统配置文件中。

AutoYaST 持续改进

基于 storage-ng 的 AutoYaST 版本已经获得了一些改进,例如改进了分区大小处理(支持逻辑卷)或多路径支持。此外,我们修复了一些错误,例如将 LVs 的 size=max 设置为 max(bsc#1070131)或在未定义任何分区时出现的一些问题(bsc#1070790bsc#1065061)。

但更有趣的是,我们带回了一个隐藏的(且未文档化的)功能。你知道吗,如果你将 <device/> 元素设置为 ask,AutoYaST 会询问你使用哪个设备进行安装?很酷,对吧?这个功能将在 (open)SUSE 15 中继续工作,现在它已被文档化!

结论

我的同事告诉我,Scrum 实践可能让我有点恼火,因为我对圣尼古拉斯传统的描述中有几个错误。他们肯定错了。敬请期待来自一个全新改进的 Scrum 团队的下一份报告:Ježíšek、Santa 和 Christkind。