systemd 259:Musl 支持、run0 赋能以及告别 System V

关键点:
  • 对 Musl libc 的部分支持(需要在 Meson 中手动配置)。
  • run0 --empower 允许执行特权操作,而无需更改用户 UID。
  • 已确认弃用 System V 脚本并提高要求(内核 5.10+)。
  • libsystemd 现在使用 dlopen() 加载外部库,以减少依赖项。
  • 日志存储现在默认是“持久化”的。

systemd

经过三个多月的开发, 推出 新版本 259。 本次更新对系统架构进行了更改,突出了对替代标准库的开放性、更严格的权限管理以及对未来版本更严格的技术要求。

本轮变革中最受关注的趋势之一是向更高的模块化和消除遗留依赖项过渡,这为 Linux 生态系统彻底摆脱过去几十年的标准铺平了道路。

systemd 259的主要新功能

新的 systemd 版本 259 的突出之处在于…… 第一个版本增加了与Musl的部分兼容性这是轻量级发行版和嵌入式环境中流行的 C 标准库。这种集成 它是通过 Meson 构建系统中的 libc 选项进行管理的。 但是,由于 Musl 没有实现 NSS(名称服务切换)功能,因此在此配置中,几个 systemd 组件仍然处于禁用状态。

在a使用 Musl 编译时明显缺失 他们是 nss-systemd、nss-resolve、systemd-homed、systemd-userdbd 和 DynamicUser 参数此外,在此库下,无法以非特权模式运行 systemd-nspawn。开发者已发出警告,未来版本是否继续支持此功能将取决于社区需求以及任何新增兼容层的稳定性。

新版本的另一个新功能是 在 run0 实用程序中被设计成 sudo 的现代且安全的替代方案,并已获得 新选项——赋权. 这个功能 它允许您以更高的权限登录。 无需将用户标识符 (UID) 更改为 root。

除此之外, 而不是完全委托控制权 通过用户切换,–empower 使用内核功能指示符,例如 CAP_SYS_ADMIN, 颁发绝对必要的许可证 执行特权系统调用。此外,生成的进程会被集成到一个特定的组中,该组授予它们访问 Polkit 操作的权限,从而比传统的 sudo 模型保持更强大的权限分离。

一个时代的终结:告别System V和新的需求

systemd 259 标志着终结的开始 与以下方面兼容 System V 服务脚本官方宣布,在下一个版本中,systemd-sysv-generator、systemd-rc-local-generator 和 systemd-sysv-install 等旧版组件将被永久移除。

随着旧代码的清理,systemd 生态系统的最低软件要求也大幅提高:

  • Linux 内核:最低版本 5.10。
  • Glibc:2.34。
  • OpenSSL:3.0.0。
  • Util-linux:2.37。
  • 其他:Python 3.9.0、cryptsetup 2.4.0 和 libseccomp 2.4.0。

libsystemd 中的模块化和动态加载

科莫 这是减少依赖性举措的一部分 直接在创业公司 libsystemd 现在使用 dlopen() 进行动态加载 对于 libacl、libblkid、libseccomp、libselinux 和 libmount 等库,系统仅在进程需要其特定功能时才会将其加载到内存中,从而优化资源使用。此外,libcap 的功能已直接集成到 libsystemd 中,简化了依赖链。

El 日志处理已更改其默认配置: 日志存储模式(Blog) 从“自动”更改为“持久”无论 /var/log/journal 目录之前是否存在。

在网络和虚拟化领域:

  • systemd-networkd 和 systemd-nspawn: 已移除对使用 iptables 的 NAT 规则的支持,只剩下 nftables 是唯一兼容的选项。
  • systemd-resolved: 现在允许在 /run/systemd/resolve.hook/ 中使用本地钩子(hooks)来干预名称解析请求。
  • systemd-importd: 处理 TAR 文件的逻辑已原生集成。此外,`importd` 和 `machined` 现在都可以在用户级别运行,从而允许在用户的本地目录(`~/.local/state/machines/`)中进行图像管理。

其他创新

基于协议的API Varlink 获得了增强功能,允许访问服务设置并进行 IPC 调用 例如 Reload() 和 Reexecute() 函数。对于系统管理员来说,在服务中加入 OOMKills 属性将非常有用,因为它允许他们直接通过 systemd 工具跟踪进程因内存不足而被终止的次数。

最后,随着 systemd-boot 中对 TPM 1.2 的支持被移除,系统启动过程变得更加现代化,并将所有安全工作集中在 TPM 2.0 标准上。

如果您有兴趣了解更多,可以咨询 以下链接中提供了详细信息。