リムーバブル暗号化USB「キーリング」フラッシュドライブに含まれているキーを使用して複数のストレージボリュームを暗号化するシナリオがあります。私はArch Linuxを実行していますが、この質問はシステム依存関係の設定に関するものです。
キーリングが存在する限り、システムはボリュームを起動してマウントするように構成されています。キーリングパスワードは起動時に手動で入力されます。
システム起動後にUSBキーリングを削除できるようにしたいが、systemdがすべてを削除するために問題が発生します。
以下は私がしたことの例です。まず、/etc/crypttab
# <name> <device> <password> <options>
keyring PARTLABEL=keyring none noauto
abc /dev/lvm/abc /root/keyring/abc.key header=/root/keyring/abc.hdr
xyz /dev/lvm/xyz /root/keyring/xyz.key header=/root/keyring/xyz.hdr
私は
systemdこのオプションをサポートする最近のGitチェックアウトを使用していますheader。このオプションは1月8日にリポジトリに追加されました。バックアップ/利便性のために複数の物理キーリングがあるため、キーリングにパーティションラベルを使用します。 UUIDは異なる場合がありますが、同じPARTUUID設定を使用します。
私が使用している
noautoキーリングは、暗号化を解除する必要があるすべてのデバイスへの依存関係です。
以下は次のとおりです/etc/fstab。
# <file system> <dir> <type> <options>
/dev/mapper/keyring /root/keyring ext4 ro,noauto
/dev/mapper/abc /srv/abc ext4
/dev/mapper/xyz /srv/xyz ext4
同様に、キーリングはnoauto依存関係なのでインストールされます。さらに、読み取り専用でマウントされており、安全に引き出すことができる。
これで、ボリュームとキーリングの間の依存関係を作成するために、以下を使用しました。オーバーライドの挿入、例えば：
# /etc/systemd/system/systemd-cryptsetup\@abc.service.d/override.conf
[Unit]
Requires=root-keyring.mount
これはすべて素晴らしいと起動するのに最適です。問題は、キーリングを削除すると、それに依存するデバイスが停止することです。私はこのようなことが起こりたくありません。依存関係は、ボリュームがロック解除されたときにキーとヘッダーにアクセスできるようにするためにのみ必要です。ロックが解除されると、キーとヘッダーは不要になります。
だから私の質問は尋ねることです。「ExecStart」コマンド期間中にのみ存在するキーリングの依存関係をソートする方法[Eメール保護]単位？
あるいは、これが間違ったアプローチである場合は、改善されたソリューションを歓迎します。
答え1
明示的な依存関係の代わりに、次を使用できます。自動マウント。
Systemdがあったことを覚えています。Poetteringのブログオリジナル投稿、暗黙の依存関係です。これは（systemdを使用して）ソケットにリクエストを作成し、適切なサービス（たとえば「ソケットを有効にする」）を開始する方法と同じです。この場合、ファイルシステムにアクセスすると、そのファイルシステムがマウントされます。
このアプローチを使用すると、サービスまたはファイルシステムが準備されるまでブロックできます。 ノート：これは、システムにそのディレクトリを表示しようとすると（「キーリング」ドライブを削除した後）、ブロックされるディレクトリがあることを意味します。おそらく他の目的で/ rootを使用している場合は、インストールする方が良いでしょう。たとえば/automount/keyring、ぶら下がらないように他の場所に置いてください。個人的には、私はこの問題が自動マウントをやや混乱させると思います。しかし、問題を非常に迅速に解決するようです。
ファイルシステムがにリストされている場合は、オプションリストに/etc/fstab追加するだけです。x-systemd.automount
ネイティブファイルとして.mount記述する場合は、.automount同じ名前のファイルを作成する必要があるようです。たとえば、次のようなものがありroot-keyring.automountます。
[Automount]
Where=/root/keyring
答え2
現在のバージョンのsystemd（この記事を書く時点では218）では、エントリのためにシステムの起動/etc/crypttab時にsystemdが実行するユニットによってインスタンスが作成されます。[email protected]systemd-cryptsetup-generator
生成される単位には、キーファイルパスへの依存関係が含まれます。
RequiresMountsFor=/path/to/key_file
この依存関係レコードは、指定されたパスにアクセスするために必要なインストール済みのすべての依存関係がman systemd.unit接続される場所を説明します。Requires=After=
この依存関係によってマウントデバイスが無効になっていると、Requires=systemdはcryptsetupデバイスを停止します。
つまり、キーを含むデバイスをアンマウントすると、cryptsetupデバイスはボリュームを無効にしてロックします。
現在唯一の回避策は、/etc/crypttab問題を引き起こす可能性があるボリュームを使用せず、依存関係をRequiresMountsFor=含まないカスタム単位を提供することです。 。以下は、ジェネレータによって生成された単位に基づいて適切なカスタム単位です。
# /etc/systemd/system/systemd-cryptsetup\@.service
[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:[email protected](8)
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
BindsTo=dev-lvmvg-%i.device
After=dev-lvmvg-%i.device
Before=umount.target
[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%i' '/dev/lvmvg/%i' '/root/keyring/%i.key' 'header=/root/keyring/%i.hdr'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%i'
[Install]
WantedBy=dev-mapper-%i.device
この項目の代わりに、次の例が使用されます/etc/crypttab。
# <name> <device> <password> <options>
mail /dev/lvmvg/mail /root/keyring/mail.key header=/root/keyring/mail.hdr
この問題はsystemd開発者に提起され、次に追加されました。やることリスト。