- 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`，它會阻止層次結構。所有這些都與新的使用者隔離功能（例如 ` 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 背後的理念是允許定義一個 OverlayFS 基於一個名為「特殊目錄」的結構 .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 生態系統中的核心地位。對於西班牙和歐洲的管理員和開發人員而言，眼下的挑戰在於審查核心、調整啟動配置和服務，並利用這些特性建立更安全、更自動化的基礎架構，以適應目前的系統使用情況。