- Systemd 260では、System Vスクリプトのサポートが完全に削除され、すべてのサービスでネイティブ単位が必須となります。
- このバージョンでは、SRK管理やtpm2_id、systemd-pcrextendなどのユーティリティを含め、TPM2との統合が強化されています。
- サンドボックス機能、ネットワーク制御、サービスごとのリソースが大幅に拡張され、コンテナや一時的なマシンに関する新しいオプションも追加されました。
- このプロジェクトでは、AIエージェント向けの具体的なドキュメントと、貢献の質を向上させるための新しい支援型レビューワークフローを組み込んでいます。
systemd 260の登場により、 Linuxディストリビューションは、クラウド環境、仮想化、自動化に対応した、よりモダンで安全なエコシステムに向けて、また一つ重要な一歩を踏み出しました。このバージョンは、単に細部を磨き上げるだけでなく、ブート、サービス管理、ネットワーク、整合性と暗号化のためのTPM2の使用、そしてドライブレベルのサンドボックス機能に大幅な変更を加えています。
同時に、このプロジェクトはドキュメントと人工知能エージェントとの連携方法を強化しており、systemdがますます多くの開発ツールや監視ツールが接続する重要な柱であることを明確にしています。サーバー、クラウド、企業デスクトップ、またはラボでLinuxシステムを管理している場合は、これらの新機能をすべて確認し、アップデートや構成調整の計画を立てる価値があります。
System Vとの最後の別れ、そしてネイティブドライブへの完全な依存
systemd 260における最も顕著な変更点の1つは、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（Trusted Platform Module 2.0）との統合です。このチップは、最新のUEFIマザーボードやミドルレンジ、ハイエンドのハードウェアでますます普及しており、システム状態に秘密情報を固定したり、ブートフェーズを測定したり、環境が想定どおりになったときに暗号化されたボリュームを自動的にロック解除したりすることを可能にします。
Systemd 260 では、ブートプロセスのさまざまな段階をカバーするツールとサービスを追加することで、この統合がさらに強化されています。重要なコンポーネントの一つがsystemd-tpm2-setup で、TPM のストレージ ルート キー (SRK)に関するインフラストラクチャの準備を担当します。このルート キーは、チップとの通信を保護し、その他の秘密情報を安全に保存するための暗号化の基盤となります。
起動時には、initrd の非常に早い段階とルート システムでの段階の 2 つのフェーズが区別されます。最初のフェーズでは、「Early TPM SRK Setup」と呼ばれるサービスが、TPM に既に SRK が保存されているかどうかを確認し、存在しない場合は作成して一時的に/run/systemd/tpm2-srk-public-key.*の下に配置します。その後、実際のファイルシステムがマウントされると、このサービスは SRK を統合し、/var/lib/systemd/tpm2- srk-public-key.pem に保存されているキーが TPM のキーと一致することを確認します。
適切に構成されたシナリオでは、「SRK は既に TPM に保存されています」などのジャーナルエントリや、SRK のフットプリントが想定どおりであることを示すメッセージが表示されます。しかし、環境が適切に構成されていない場合 (たとえば、Yocto を使用するセットアップや、SPI ベースの TPM と U-Boot や計測ブートなどのカスタムブート方式を備えた Raspberry Pi のようなボードの場合)、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 はブートフローの暗号的に検証可能な記録を蓄積することができ、これは Trusted Boot ポリシーやUKI (Unified Kernel Images)で、キーを解放する前にマシンの状態を検証するために使用できます。
systemdによるセキュリティ対策とサービスのサンドボックス化
Systemdはプロセスを起動するだけでなく、サービスを隔離し、侵害が発生した場合の被害を最小限に抑えるための包括的なサンドボックスディレクティブも提供します。この「多層防御」アプローチは、cgroups、名前空間、カーネル機能、およびシステムコールフィルタ（seccomp）に依存しています。
特定のサービスのセキュリティを評価するために、systemd にはsystemd-analyze セキュリティツールが含まれています。このツールを実行すると、0 から 10 のスケールで露出スコアを示すレポートが生成されます。スコアが低いほどセキュリティが優れています。レポートには、どの保護機能が有効または無効になっているか (ネットワーク分離、ファイルシステムへのアクセス、デバイスへのアクセスなど) が詳細に表示されるため、不足している設定を簡単に特定し、変更によって実際にスコアが改善されるかどうかを確認できます。
元のユニットを編集すると将来のパッケージ更新で失われるため、 オーバーライド en /etc/systemd/system/mi-servicio.service.d/ 例えばファイルを使って、 sandbox.conf変更後、以下のコマンドで設定を再読み込みしてください。 systemctlデーモンリロード そして、新しい制限が有効になるようにサービスを再起動してください。
ファイルシステムレベルでは、最も重要なオプションの1つは ProtectSystem=次のような値 strict, full o true これらはツリーのさまざまな部分を読み取り専用モードでマウントします。可能な場合は、通常、 ProtectSystem=strictこれにより、/usr、/boot、/efi、および/etcはサービスに対して読み取り専用になります。アプリケーションが特定のディレクトリに書き込む必要がある場合は、次の方法で書き込みが許可されます。 ReadWritePaths=/path 団結して。
プライバシーをさらに強化するために、 `ProtectHome=true`を使用してユーザーディレクトリへのアクセスを制限することも推奨されます。これにより、サービスが `/home`、`/root`、または `/run/user` を読み取ることができなくなります。さらに、`PrivateTmp=true` は隔離された `/tmp` および `/var/tmp` スペースを作成し、プロセス間で一時ファイルが相互に参照されることを防ぎます。
デバイスでは、`PrivateDevices=true`によって実際の `/dev` ツリーが隠蔽され、最小限の安全な擬似デバイス (null、ゼロ、ランダムなど) に置き換えられます。ドライブが特定のデバイス (たとえば、シリアルポートやディスクブロック) を必要とする場合は、`DeviceAllow=/dev/xxx rw`を使用するか、読み取り専用モードで許可することができます。
ネットワークも重要なベクトルです。 PrivateNetwork=true 分離されたネットワーク名前空間が作成され、ループバックのみが残ります。サービスは物理インターフェイスを認識せず、外部と通信できません。または、使用できるアドレスファミリーを制限することもできます。 RestrictAddressFamilies=IPv4/IPv6 には AF_INET と AF_INET6 のみを許可し、ローカルソケットには AF_UNIX を許可します。 none ネットワーク機能を完全に日本化するため。
権限に関して言えば、`NoNewPrivileges=true`ディレクティブは最も強力なものの1つです。これは、setuid バイナリや機能変更によってプロセスが新しい権限を取得することを防ぎます。つまり、サービスが脆弱なコードを実行したとしても、従来のメカニズムによってルート権限に昇格することはできません。許可される機能の正確なリストを定義する`CapabilityBoundingSet=` (たとえば、低ポートでリッスンするには `CAP_NET_BIND_SERVICE` のみを許可するなど) と組み合わせることで、攻撃対象領域を最小限に抑えることができます。
さらに、systemd はシステムコールをフィルタリングできます。 システムコールフィルター=システムコールの手動リストを維持する代わりに、次のような事前定義されたグループが使用されます。 @system-service, @network-io, @basic-io または次のようなグループを拒否する ~@privileged。 とともに systemd-analyze syscall-filter どの呼び出しがどのグループに属するかを具体的に検査することが可能です。これにより、専用のサンドボックスと同様の、非常に限定的な実行プロファイルを構築できます。
その他の関連設定には、 `ProtectKernelTunables=true`（`/proc/sys` および `/sys` 内のカーネル パラメータの変更をブロック）、`ProtectKernelModules=true`（モジュールのロードまたはアンロードを防止）、`ProtectKernelLogs=true`（カーネル ログの読み取りを防止）、`ProtectControlGroups=true`（cgroups 階層への書き込みをブロック）などがあります。これらはすべて、`PrivateUsers=full` などの新しいユーザー分離機能とシームレスに連携します。バージョン 260 では、` PrivateUsers=full`が更新され、ユーザー ID の全範囲をマッピングするようになったため、ネストされた systemd 環境で必要だった以前の回避策が不要になりました。
PrivateUsers、xaccess、および新しいデバイスアクセス制御
サービスを隔離されたユーザーID空間で実行できるように設計されたPrivateUsersメカニズムは、systemd 260で統合されました。PrivateUsers =fullオプションは、識別子の全範囲をマッピングするようになり、コンテナ内や、古いバージョン（257以前）に基づくネストされたsystemdインスタンスを持つシステムでの動作が簡素化されました。この改善により、これらの古いインスタンスを検出するために以前使用されていた回避策が不要になりました。
並行して、systemd-logindやsystemd-udevdといったコンポーネントは、 xaccessという概念を導入しました。このメカニズムは、ローカルマシン上でフォアグラウンドグラフィックスセッションを持つユーザーに特定のデバイス（例えば、オーディオやビデオ）へのアクセスを許可する従来のuaccessのロジックを補完するものです。xaccessを使用すると、特別なマークを付けたセッションを持つリモートユーザーに権限を委任できるため、例えば、リモートデスクトップ経由で接続したユーザーは、システム全体に広範な権限を与えることなく、ローカルのGPUレンダリングデバイスにアクセスできます。
これらのセッションの設定には、PAM を介して公開される環境変数、具体的にはPAMXDG_SESSION_EXTRA_DEVICE_ACCESS=が使用され、これにより、このロジックに含まれる特定のデバイスを定義できます。このアプローチは、機密性の高いハードウェアへのアクセスに粒度と追跡可能性が求められる欧州連合の規制遵守およびデータ保護要件に高度に適合しています。
mstack、systemd-mstack、および新しいコンテナツール
コンテナ化の分野では、systemd 260 で以下の機能が導入されました。 mstack および関連するコマンド、 systemd-mstackmstack の背後にあるアイデアは、 オーバーレイFS 特殊ディレクトリの構造に基づいて .mstack/これは、レイヤーの構成に関する特定の仕様に従っています。
新しいコマンドラインツールであるsystemd-mstackを使用すると、これらのファイルシステムスタックを対話的に操作しやすくなり、コンテナや高度に分離されたサービス用の階層型環境をセットアップする際の柔軟性が向上します。この機能は、 OCIイメージのダウンロードと管理のサポートを拡張するsystemd-importdの改善にも関連しており、ヨーロッパのクラウドプロバイダーや最新のホスティングプラットフォームで広く利用されているコンテナ化およびサンドボックス化エンジンとしての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と統合された方法で仮想マシンを起動するために設計されたツールであるsystemd-vmspawnは、ユーザーセッション内でsystemd-machinedに登録する機能を拡張しました。また、使用完了時に破棄される一時的なマシンを作成するための`-ephemeral`オプションも導入しました。これは、仮想マシンの迅速かつ制御された作成と破棄を必要とするCI/CDパイプライン、仮想教室、またはヨーロッパの教育プラットフォームに最適です。
SCHED_EXTとTHPによるCPU、メモリ、スケジューリングのきめ細かな制御
Systemd 260では、新しいポリシーによるパフォーマンス制御も強化されています。サービスオプション CPUスケジューリングポリシー= 値を受け入れる extスケジューラをアクティブ化します SCHED_EXTこの代替プランナーは、 さまざまな計画政策を用いた実験 カーネル規格に準拠しており、研究開発ラボや高度に専門化された導入環境では関心を集める可能性がある。
メモリ領域には、`MemoryTHP=`という設定項目があり、サービスごとに透過的巨大ページ (THP)の使用を管理できます。システム全体に適用されるグローバル設定ではなく、特定のユニットが THP を使用するか、無効にするか、中間モードを採用するかを個別に決定できます。銀行、保険、政府機関などの重要なアプリケーションでは、このきめ細かな制御によって、レイテンシ、メモリ消費量、パフォーマンスに大きな違いが生まれます。
systemctl の新しいコマンドと Varlink の利用範囲の拡大
使い慣れたsystemctlコマンドに、 enqueue-marked という新しいコマンドが追加されました。このコマンドは内部的に D-Bus メソッドEnqueueMarkedJobs()を呼び出し、事前にマークされたジョブやサービスのキューを操作できるようにします。些細なことのように思えるかもしれませんが、大規模なサーバーファームを運用するチームにとっては、デプロイメントと自動化のワークフローを改善するための新たなツールとなります。
並行して、このプロジェクトでは、コンポーネント間の通信メカニズムとしてVarlinkの利用を拡大し続けています。systemdの多くの部分は安定したVarlinkインターフェースを公開しており、これにより、システム情報への構造化されたアクセスを必要とする外部ツール、カスタムダッシュボード、または監視エージェントとの統合が容易になります。
システム識別フィールドとユーザーエクスペリエンス
一部のディストリビューションにとって興味深いが便利な新機能は、フィールドの導入である。 ファンシーネーム= アーカイブ内 /etc/os-releaseこのフィールドは PRETTY_NAME に似ていますが、 ANSIシーケンスとより複雑なUnicode文字これにより、特定の配布版やエディションを、より目を引く、あるいは特徴的な名前で提示することが可能になります。
FANCY_NAMEの値は、systemdマネージャのsystemd-hostnamedコマンドを使用するか、hostnamectlコマンドを実行することで確認できます。これは小さな変更ですが、デスクトップ環境やグラフィカルな管理パネルでは、特に多くの派生バージョンを扱う場合に、管理対象のシステムを素早く識別するのに役立ちます。
AIエージェントとアシストレビューワークフローに関する具体的なドキュメント
systemdの開発方向を示す最も興味深い兆候の一つは、人工知能エージェントに特化したドキュメントが登場したことです。リポジトリには、コード分析ツールやプログラミングアシスタントがプロジェクトのアーキテクチャ、スタイル、開発フロー、貢献ガイドラインをよりよく理解できるように設計されたAGENTS.mdファイルや、いくつかの技術ガイドが含まれています。
このドキュメントでは、コンポーネント、ビルドパス、テストと統合の実行方法、および適切なパッチを生成するためのガイドラインについて説明します。目的は、コードレビューや変更を行うAIエージェントがsystemdの構成をしっかりと理解できるようにし、エラーや不適切な提案を減らすことです。
AGENTS.md の横にはCLAUDE.mdというファイルがあり、これは AGENTS.md を明示的に参照し、最も広く使われている AI ベースの開発支援ツールの 1 つである Claude Code ツールをガイドするように設計されています。このようにして、このプロジェクトは開発サイクルに AI を明確に組み込んでいます。
さらに、設定ファイルも同梱されています。 claude-review.ymlここでは、Claude Code の助けを借りて、変更要求 (プルリクエスト) の分析プロセスをどのようにレビューするかが定義されています。この文脈では、AI を使用した貢献には、 開示ラベル として Co-developed-by パッチの中に、自動化ツールがコードの作成に関与した痕跡が残っている。
レガシーサポートの整理、サンドボックス機能の改良、TPM2とSRKの改善、高度なネットワーク統合、新たな移植性機能、インテリジェントエージェント向けドキュメントなど、包括的な変更が加えられたsystemd 260は、現代のLinuxエコシステムにおける中心的な役割をさらに強化します。スペインおよびヨーロッパの管理者と開発者にとって、当面の課題はカーネルの見直し、ブート構成とサービスの適応、そしてこれらの機能を活用して、現在のシステム利用状況に合わせた、より安全で自動化されたインフラストラクチャを構築することです。