読み取り専用ファイルシステムでsystemdサービスの有効化と無効化を管理する方法に関するポリシーを探しています。 multi-user.target.wants ディレクトリの内容が変更されたため、これは不可能です。
/etc/systemd/systemがサービスのデフォルトの場所である場合、ターゲットで実行されているアプリケーションまたはスクリプトが引き続き有効または無効になるように開始する「テーブル」/multi-user.target.wantsディレクトリを管理する方法を試みた人ありますか?ファイルシステムはROですか、それとも特定のサービス(またはサービス)を指定できますか?
私は、multi-user.target.wantsディレクトリを小さなrw "config"パーティションの場所と、必要に応じて起動/再起動時に事前設定されたmulti-user.target.wantsディレクトリとの間にシンボリックリンクすることを検討しました。または、スクリプトまたはアプリケーションがアイテムを追加または削除して、このシンボリックリンクの場所を直接変更できると思います。
まだテストしていません。誰もがこれについての経験があるのか、可能な戦略があるのか、より標準化されたアプローチを知っているのかを知りたいです。ありがとうございます。
答え1
完全な答えではありませんが、コメントに詳細が多すぎます。
変更するには、ファイルシステムへの書き込みアクセス権が必要です。今は書き込み権限がありますが、読み取り専用にロックして後で変更できるようにしたいと思います。
systemd
/run
読み取り専用以外のデバイスパスは複数の場所から取得されます。サービスを非常に早くロードし、次のロードパスのいずれかでいくつかのユニットを作成/編集する機会があるかもしれません。
引用:https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20File%20Load%20Path
道 | 説明する |
---|---|
/etc/systemd/system.control | dbus APIを使用した永続的および一時的な構成の作成 |
/run/systemd/system.control | 」 |
/run/systemd/一時的 | 一時装置の動的構成 |
/run/systemd/generator.early | 優先順位の高いユニット生成(systemd.generator(7)のEarly-dir参照) |
/etc/systemd/システム | 管理者が作成したシステムデバイス |
/実行/システム/システム | ランタイムユニット |
/run/systemd/generators | 中間優先順位の生成装置 (systemd.generator(7) の Normal-dir 参照) |
/usr/local/lib/systemd/システム | 管理者がインストールしたシステムデバイス |
/usr/lib/systemd/システム | 配布パッケージマネージャによってインストールされたシステムデバイス |
/run/systemd/generator.late | 優先順位の低いユニットの生成(systemd.generator(7)のLate-dir参照) |
起動プロセスの最初に実行され、コマンドセンターのソケットに接続し、ユニット命令をインポートしてから、dbus-APIを使用してユニットを作成するアプリケーションを作成できます。/run/systemd/system.control
別のオプションはジェネレータを書くことです。バラよりsystemd.generator(7)もっと学ぶ。ジェネレータは、起動プロセスの初期(ユニットファイルがロードされる前)にsystemdによって実行されるプログラムです。これらのジェネレータは/run/systemd/generator/
読み取り専用ファイルシステムの外部になければなりません。
ジェネレータの例は、基本システムユニットをsystemd-fstab-generator
読み込んで生成することです。/etc/fstab
*.mount