- Systemd 260 永久移除了对 System V 脚本的支持，并要求所有服务都使用原生单元。
- 此版本加强了与 TPM2 的集成，包括 SRK 管理和 tpm2_id 和 systemd-pcrextend 等实用程序。
- 沙盒功能、网络控制和每个服务的资源都得到了显著扩展，同时还增加了容器和临时机器的新选项。
- 该项目包含针对人工智能代理的特定文档和新的辅助审查工作流程，以提高贡献的质量。
随着 systemd 260 的发布， Linux 发行版正朝着更加现代化、安全的生态系统迈出重要一步，该生态系统旨在服务于云环境、虚拟化和自动化。此版本并非仅仅完善细节，而是对启动、服务管理、网络、TPM2 的完整性和加密功能以及驱动器级沙箱功能进行了重大改进。
与此同时，该项目正在加强文档编写和人工智能代理协作方式，明确表明 systemd 是一个关键支柱，越来越多的开发和可观测性工具都与之对接。如果您管理服务器、云端、企业桌面或实验室中的 Linux 系统，那么不妨花些时间了解一下这些新功能，以便规划更新和配置调整。
最终告别 System V 和对原生驱动器的完全依赖
systemd 260 最显著的变化之一是完全移除了对 System V 脚本的支持。基于 /etc/init.d 的传统启动过程已经逐步淘汰多年，而现在它实际上已经从 systemd 代码中消失了。
这意味着负责连接 SysV 脚本和本地单元的组件已被移除：systemd-rc-local-generator、rc-local.service、systemd-sysv-generator 和 systemd-sysv-install已不再存在。因此，任何仍然依赖这些旧机制的服务在采用 systemd 260 的系统上都将无法启动。
在清理过程中，一些 Meson 构建选项也被标记为过时或移除。例如，-Drc-local=、-Dsysvinit-path= 和 -Dsysvrcnd-path=这几个标志已被归档，而-Dintegration-tests= 和 -Dcryptolib=等其他标志则被彻底移除。这传递了一个明确的信息：所有功能现在都必须由原生单元和现代 systemd 基础架构来处理。
对于许多仍然依赖旧组件的欧洲基础设施而言，这一变化需要对内部服务、自定义脚本和遗留部署进行审查。迁移到定义完善的单元文件不再仅仅是建议；如果您想继续在集成 systemd 260 的发行版上运行服务，则必须这样做。
更高的内核要求以及对当前环境的关注
新版本提高了内核的要求：从现在起，最低支持的 Linux 版本为 5.10，不再支持 5.4 等非常旧的内核版本。此外，该项目指出，理想情况下，用户应该使用5.14 或更高版本的内核，并特别推荐使用6.6 系列内核以充分利用所有可用功能。
这种需求增加在现代发行版中通常不是问题，但在非常保守的环境或维护多年的嵌入式解决方案中可能会使情况变得复杂。在升级到 systemd 260 之前，建议先确认当前使用的内核版本，尤其是在欧洲数据中心长期部署或使用自定义镜像的情况下。
另一方面，像 Arch Linux 或 openSUSE Tumbleweed 这样的滚动发布发行版，因其追求最新功能而广受用户欢迎，往往会迅速整合新的内核和 systemd 的新分支。而像 Fedora 这样的发行版，则会在每个版本的生命周期内保持 systemd 主版本的稳定性，从而为迁移预留更多时间。
TPM2、启动完整性和高级SRK支持
systemd 发展最快的领域之一是与TPM2（可信平台模块 2.0）的集成。这种芯片在现代 UEFI 主板以及中高端硬件中越来越常见，它允许将密钥与系统状态关联起来，测量启动阶段，并在环境符合预期时自动解锁加密卷。
Systemd 260 通过添加涵盖启动过程不同阶段的工具和服务，进一步增强了这种集成。其中一个关键组件是systemd-tpm2-setup，它负责围绕TPM 的存储根密钥 (SRK)准备基础架构。该根密钥作为加密基础，用于保护与芯片的通信以及安全存储其他密钥。
启动过程中分为两个阶段：一个是 initrd 中的早期阶段，另一个是根系统中的阶段。在早期阶段，名为“Early TPM SRK Setup”的服务会检查 TPM 是否已存储 SRK，如果不存在，则会创建 SRK 并将其临时放置在/run/systemd/tpm2-srk-public-key.*目录下。之后，一旦实际文件系统挂载完毕，该服务会将 SRK 合并，并验证存储在/var/lib/systemd/tpm2-srk-public-key.pem中的密钥是否与 TPM 中的密钥匹配。
在配置良好的场景下，会显示诸如“SRK 已存储在 TPM 中”之类的日志条目，以及表明 SRK 占用空间与预期相符的消息。但是，如果环境配置不当（例如，在使用 Yocto 的系统，或者在像 Raspberry Pi 这样采用基于 SPI 的 TPM 和自定义启动方法（例如 U-Boot 和测量启动）的开发板上），则可能会出现 systemd 无法在 /var/lib/systemd 下创建这些文件的情况，从而导致对 SRK 配置是否正确的怀疑。
当 TPM 状态发生改变、分区被修改或启动顺序被更改时，相关的策略可能不再有效。在这种情况下，一些维护人员建议清除 TPM 插槽或策略，并重新注册密钥。操作步骤类似于 openSUSE 等环境中 TPM 磁盘加密指南中描述的步骤，这些指南详细介绍了如何重新创建 PCR 策略并重新链接卷解锁。
除了SRK之外，另一个实用的改进是在udev中引入了一个名为tpm2_id的内部实用程序。当系统检测到TPM2设备时，该集成工具会运行并自动提取制造商和型号标识符。这简化了安全硬件的清单管理，对于公共管理机构、受监管企业或关键基础设施等需要精确了解已部署哪些TPM模块的机构来说非常有用。
通过诸如systemd-pcrextend之类的特定单元，可以进一步加强与启动测量基础架构的集成。这些单元会记录各种 PCR（例如 PCR 11）中的“enter-initrd”、“leave-initrd”、“sysinit”和“ready”等事件。这一系列扩展使得 TPM 能够积累一个加密可验证的启动流程记录，该记录可用于可信启动策略或UKI（统一内核映像），以便在释放密钥之前验证机器状态。
使用 systemd 采取安全措施和服务沙箱
Systemd 不仅启动进程，还提供了一套全面的沙箱指令，用于隔离服务并在系统遭到入侵时最大限度地减少损失。这种“纵深防御”方法依赖于 cgroups、命名空间、内核功能和系统调用过滤器 (seccomp)。
为了评估特定服务的安全性，systemd 内置了systemd-analyze 安全工具。运行该工具会生成一份报告，其中包含一个风险评分，评分范围为 0 到 10，分数越低越好。该报告会详细列出已启用或已禁用的保护措施（例如网络隔离、文件系统访问、设备访问等），方便用户识别缺失的设置并验证更改是否确实提高了评分。
与其编辑原始单元（这将导致未来的软件包更新丢失），不如创建一个新的单元。 覆盖 en /etc/systemd/system/mi-servicio.service.d/ 例如，使用文件时 sandbox.conf修改完成后，只需重新加载配置即可。 systemctl守护进程重新加载 然后重启服务，使新的限制生效。
在文件系统层面，最重要的选项之一是 ProtectSystem=价值观，例如 strict, full o true 它们以只读模式安装树的不同部分。通常的做法是，如果可能的话，使用 ProtectSystem=严格这使得 /usr、/boot、/efi 和 /etc 目录对该服务而言变为只读。如果应用程序需要写入特定目录，则允许使用以下命令进行写入： ReadWritePaths=/路径 团结一致。
为了进一步增强隐私保护，建议使用`ProtectHome=true`限制对用户目录的访问，这将阻止服务读取 `/home`、`/root` 或 `/run/user` 目录。此外，`PrivateTmp=true`会创建隔离的 `/tmp` 和 `/var/tmp` 空间，防止进程间临时文件的交叉访问。
在设备配置中，`PrivateDevices=true`会隐藏实际的 `/dev` 目录树，并将其替换为一组最小的安全伪设备（例如 null、0、随机数等）。如果某个驱动器需要特定的设备（例如串口或磁盘块），可以使用`DeviceAllow=/dev/xxx rw`或以只读模式授予访问权限。
网络也是一个关键的载体。 PrivateNetwork=true 创建一个隔离的网络命名空间，仅保留环回接口；该服务将无法访问物理接口，也无法与外部世界通信。或者，您可以通过以下方式限制其可以使用的地址族： 限制地址族=仅允许 AF_INET 和 AF_INET6 用于 IPv4/IPv6，AF_UNIX 用于本地套接字，甚至 none 实现网络能力的全面日本化。
关于权限控制，`NoNewPrivileges=true`指令是最强大的指令之一：它可以阻止进程通过 setuid 二进制文件或功能变更来获取新权限。简而言之，即使服务执行了易受攻击的代码，它也无法通过传统机制提升到 root 权限。结合`CapabilityBoundingSet=` 指令（该指令定义了允许的功能列表，例如，仅允许 `CAP_NET_BIND_SERVICE` 监听低端口），可以最大限度地减少攻击面。
更进一步，systemd 允许过滤系统调用。 系统调用过滤器=系统调用不再需要手动维护列表，而是使用预定义的组，例如： @system-service, @network-io, @basic-io 或拒绝类似团体 ~@privileged。 同 systemd-analyze 系统调用过滤器 可以检查哪些具体调用属于哪个组。这使得构建一个非常有限的执行配置文件成为可能，类似于专用沙箱所提供的功能。
其他相关设置包括`ProtectKernelTunables=true`，它会阻止修改 `/proc/sys` 和 `/sys` 中的内核参数；`ProtectKernelModules=true`，它会阻止加载或卸载模块；`ProtectKernelLogs=true`，它会阻止读取内核日志；以及`ProtectControlGroups=true`，它会阻止写入 cgroups 层次结构。所有这些都与新的用户隔离功能（例如 ` PrivateUsers=full` ）无缝协作，该功能在 260 版本中已更新，可映射所有用户 ID，从而无需像以前那样在嵌套 systemd 环境中使用变通方法。
PrivateUsers、xaccess 和新的设备访问控制
用于允许服务在隔离的用户 ID 空间中运行的PrivateUsers机制已在 systemd 260 中得到整合。PrivateUsers =full选项现在可以映射所有标识符，从而简化容器和基于旧版本（257 之前）的嵌套 systemd 实例系统中的操作。此改进消除了之前用于检测这些旧版本实例的变通方法。
与此同时，systemd-logind 和 systemd-udevd等组件引入了xaccess的概念。该机制是对经典uaccess逻辑的补充，uaccess 允许本地计算机上拥有前台图形会话的用户访问特定设备（例如音频或视频）。借助 xaccess，可以将权限委派给具有特殊标记会话的远程用户，例如，通过远程桌面连接的用户无需授予整个系统的广泛权限即可访问本地 GPU 渲染设备。
这些会话的配置涉及通过 PAM 公开的环境变量，特别是PAMXDG_SESSION_EXTRA_DEVICE_ACCESS=，它允许定义哪些特定设备包含在该逻辑中。这种方法高度符合欧盟的监管合规性和数据保护要求，这些要求对敏感硬件的访问具有精细化和可追溯性。
mstack、systemd-mstack 和新的容器工具
在容器化领域，systemd 260 引入了以下功能 堆栈 以及相关的命令， systemd-mstackmstack 背后的理念是允许定义一个 Overlay文件系统 基于一个名为“特殊目录”的结构 .mstack/它遵循特定的组织层规范。
新的命令行工具 systemd-mstack 简化了与这些文件系统堆栈的交互操作，在为容器或高度隔离的服务设置分层环境时提供了更大的灵活性。此功能还与systemd-importd的改进相关联，后者扩展了其对下载和管理 OCI 镜像的支持，从而强化了 systemd 作为容器化和沙箱引擎的角色，这在欧洲云服务提供商和现代托管平台中非常普遍。
网络：与 ModemManager 集成以及新的性能选项
在网络层，systemd-networkd 的重要性日益凸显。其中一个显著的新特性是它通过“简单连接”协议与 ModemManager 集成，从而允许直接从 networkd 管理调制解调器和移动连接，而无需依赖外部工具。
为了支持这一流程，新增了一个部分。 添加到配置文件中，包含诸如以下参数： APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=这有助于部署 农村地区或基于移动网络连接的环境在欧洲某些地区非常普遍，因为这些地区并不总是有光纤或高质量的固定电话线路。
在性能方面，systemd-networkd 的.link文件包含专门针对以太网设备的新选项。这些选项包括ScatterGather、ScatterGatherFragmentList、TCPECNSegmentationOffload、TCPMangleIdSegmentationOffload、GenericReceiveOffloadList 和 GenericReceiveOffloadUDPForwarding。这些选项允许对硬件和驱动程序的工作负载卸载进行微调，这对于需要最大限度减少每一毫秒延迟的企业网络、数据中心和服务提供商至关重要。
此外，systemd-networkd 的Varlink 和 JSON接口现在可以以人类可读的格式（字符串）报告 IP 地址，同时保持其整数数组的表示形式。这简化了与监控仪表板、管理脚本或不愿处理难以理解的数字格式的第三方工具的集成。
服务可移植性、临时虚拟机和非特权服务
负责管理打包在镜像中的“可移植”服务的systemd-portabled组件获得了一项非常有趣的功能：它现在可以作为用户级服务运行。这意味着非特权用户在其普通会话中，无需使用 sudo 或提升权限，即可在其自身权限范围内启动和管理可移植服务。
此外，从这个版本开始，portabled 可以生成策略并锁定与可移植服务关联的镜像，防止在不重新附加镜像的情况下对其进行修改。这使得用户可以设置具有更高不可变性保证的独立环境，对于实验室、开发环境和测试沙箱而言，这是一个特别有吸引力的功能。
另一方面，systemd-vmspawn（一款旨在与 systemd 集成启动虚拟机的工具）扩展了其功能，使其能够在用户会话中向 systemd-machined注册。它还引入了`-ephemeral`选项，用于创建临时虚拟机，这些虚拟机在使用完毕后即被销毁。这非常适合需要快速、可控地创建和销毁虚拟机的CI/CD 流水线、虚拟教室或欧洲教育平台。
利用 SCHED_EXT 和 THP 对 CPU、内存和调度进行精细控制
Systemd 260 还通过新的策略深入探讨了性能控制。服务选项 CPU调度策略= 现在接受这个值 ext这会激活调度器 SCHED_EXT这种另类规划方式为以下方面打开了大门： 不同规划政策的实验 符合内核标准，这可能对研发实验室或高度专业化的部署有所帮助。
在内存区域中，您会找到`MemoryTHP=` ，它允许您按服务管理透明大页 (THP)的使用。与系统级全局设置不同，您可以决定特定单元是否应使用 THP、禁用 THP 或采用中间模式。对于银行、保险或政府等关键应用，这种精细的控制可以显著改善延迟、内存消耗和性能。
systemctl 中的新命令和 Varlink 的扩展使用
熟悉的systemctl命令新增了一个功能：enqueue-marked。此操作会在内部调用 D-Bus 方法EnqueueMarkedJobs()，从而允许操作预先标记的作业和服务队列。虽然这看似微不足道，但对于负责编排大规模服务器集群的运维团队而言，它却是优化部署和自动化工作流程的又一利器。
与此同时，该项目持续扩展Varlink作为组件间通信机制的应用。systemd 的许多部分都提供了稳定的 Varlink 接口，方便与需要结构化访问系统信息的外部工具、自定义仪表盘或监控代理集成。
系统识别字段和用户体验
对于某些分布而言，一个有趣但有用的新特性是引入了该字段。 FANCY_NAME= 在档案中 /etc/os-release此字段类似于 PRETTY_NAME，但允许 ANSI 序列和更复杂的 Unicode 字符因此，特定的发行版本可以采用更引人注目或更具特色的名称。
FANCY_NAME 的值可以通过 systemd 管理器查看，可以使用systemd-hostnamed 命令，也可以通过hostnamectl查询。虽然这只是一个很小的改动，但在桌面环境和图形管理面板中，它对于快速识别正在管理的系统非常有用，尤其是在处理许多衍生版本时。
AI代理和辅助审核工作流程的具体文档
systemd 发展方向中最引人注目的标志之一是出现了专门针对人工智能代理的文档。该代码库包含一个AGENTS.md文件，旨在帮助代码分析工具和编程助手以及一些技术指南更好地理解项目的架构、风格、开发流程和贡献指南。
本文档介绍了 systemd 的组件、构建路径、测试和集成运行方式，以及生成合格补丁的指南。其目的是让审查代码或进行修改的 AI 代理能够深入了解 systemd 的组织结构，从而减少错误和不恰当的建议。
与 AGENTS.md 文件并列的还有一个名为CLAUDE.md的文件，该文件明确引用了前者，旨在指导 Claude Code 工具的使用。Claude Code 是应用最广泛的基于人工智能的开发助手之一。通过这种方式，该项目将人工智能明确地融入到其开发周期中。
此外，还包含一个配置文件。 claude-review.yml其中定义了如何借助 Claude Code 来审查变更请求（拉取请求）的分析流程。在此背景下，使用人工智能的贡献需要纳入其中。 披露标签 如 Co-developed-by 补丁中留下的证据表明，自动化工具参与了代码的创建。
凭借这一系列全面的改进——包括清理遗留系统支持、优化沙箱机制、提升 TPM2 和 SRK 的性能、增强网络集成、新增可移植性功能以及面向智能代理的文档——systemd 260进一步巩固了其在现代 Linux 生态系统中的核心地位。对于西班牙和欧洲的管理员和开发人员而言，眼下的挑战在于审查内核、调整启动配置和服务，并利用这些特性构建更安全、更自动化的基础架构，以适应当前的系统使用情况。