web-dev-qa-db-ja.com

snapper-boot.serviceにすべての構成のスナップショットを作成させる方法は？

ファイルシステムのさまざまな場所に複数のサブボリュームがマウントされたbtrfsセットアップがあります。各サブボリュームには、スナッパーの構成があります。

cat /etc/conf.d/snapper

[...]
SNAPPER_CONFIGS="root home [...]"

起動時にスナップショットを作成するためのサービスは、ファイルで定義されています

cat /usr/lib/systemd/system/snapper-boot.service

[...]
ExecStart=/usr/bin/snapper --config root --cleanup-algorithm number --description "boot"
ExecStart=/usr/bin/snapper --config home --cleanup-algorithm number --description "boot"
[...]

サブボリュームごとに1行追加する代わりに、エラーが発生しやすいので、スナッパー構成のリストを読んで繰り返します。

これは可能ですか？

それはお勧めですか？

systemdbtrfssnapper
3
Archibald

はい、それを実装することは可能です。

簡単な方法は、構成ごとに1回、snapperを繰り返し呼び出すシェルスクリプトを使用することです。 forループで十分だと思われます。

Systemdユニットファイルでインラインで実行することもできます。

ExecStart=/bin/sh -e -c '. /etc/conf.d/snapper; for conf in $$SNAPPER_CONFIGS; do /usr/bin/snapper --config "$$conf" --cleanup-algorithm number --description "boot"; done'

Systemdがそれらをsystemd変数として解釈しようとせず、代わりにShellに解釈させるために、$sをエスケープする必要があることに注意してください。 （私の意見では、ExecStart=で呼び出す外部シェルスクリプトを使用する方がクリーンなアプローチであるため、エスケープを処理する必要も、すべてを1行に詰め込む必要もありません。）

もう1つのオプションは、snapper自体を変更して、それをネイティブに処理できるようにすることです。たとえば、その構成ファイルを読み取らせ、--config引数なしで呼び出されるたびにそれらの構成を処理します。それはさらにクリーンなアプローチになるでしょう。

それが賢明かどうか...私はそれが依存すると思います。ディストリビューションのパッケージからこのsnapper-boot.seviceユニットを取得している場合、そのファイルに影響を与えるパッケージのアップグレードがあると、問題が発生する可能性があります。したがって、ある意味では、それはあなたの特定の状況に依存します。

このユニットファイルが実際にLinuxディストリビューションのパッケージに同梱されている場合は、バグレポートを開いて、ユニットファイルに構成名をハードコーディングしないように依頼することを検討してください。

ディストリビューションが所有していない場合は、代わりに/etc/systemd/systemに保存することを検討してください。これは、/usr/libは通常、Linuxディストリビューションによって出荷および管理されるファイル用に予約されているためです。

2
filbranden