暗号化されたパーティション/ドライブのsystemd "自動マウント"を手動でトリガーする方法は？

の各エントリは、/etc/crypttab起動時または実行時にsystemdによって自動的にsystemd-cryptsetup-generator単位に変換されますsudo systemctl daemon-reload。たとえば、LUKSファイルシステムのUUIDが1111...（完全には表示されていない）エントリであるとします。

mytest /dev/disk/by-uuid/1111...  /etc/luks/mykeyfile luks

依存関係などとともにファイルが生成されます。新しいディスクにUUIDが表示されると、デバイスが起動します。/run/systemd/generator/[email protected]BindsTo=dev-disk-by\x2duuid-1111....devicecryptsetup

/etc/fstab同様に、systemdのすべてのエントリは自動的にsystemd-fstab-generator単位に変換されます。たとえば、アイテム

/dev/mapper/mytest /mnt/mytest ext4 defaults

ファイルが存在すると/run/systemd/generator/mnt-mytest.mount（おそらくudevを介して）マウントを生成する/dev/mapper/mytest（によって生成される）ファイルが生成されます。cryptsetup

次のコマンドを使用して、両方のデバイスの状態を確認できます。

systemctl status systemd-cryptsetup@mytest mnt-mytest.mount

通常、復号化とマウントが正常に完了すると、次のように表示されます。

   Active: active (exited)
   Active: active (mounted)

ディスクを完全に削除するには、まず次のコマンドを発行します。

sudo systemctl stop mnt-mytest.mount
sudo systemctl stop systemd-cryptsetup@mytest

ディスクを再挿入すると、自動的にマウントされます。

---

これを行わずに取り付けられたディスクを取り外すと、デバイスが故障したままになる可能性があります。journalctl -fメッセージを表示するには、systemdログを追跡してください。

場合によっては、アンマウントせずにプラグを抜くと、カーネルはファイルシステムのI / Oエラーに関するメッセージを表示しますが、ファイルシステムを正常にアンマウントし、crypt detachでデバイスを正常にシャットダウンします。この場合、デバイスを再接続すると、介入なしに自動的に正常にインストールされます。

ただし、時にはI / Oエラーの後、カーネルはファイルシステムを読み取り専用に再マウントすることを決定します。これにより、デバイスが使用中であるため、失敗するcrypt detachコマンドに問題が発生します（systemdによってアンマウントが必要なときにマウントされます）。通常、ファイルシステムがマウント解除されるため、競合の問題があるようです。デバイスを再接続すると、復号化によってボリュームがすでに有効になっていると表示されるため、マウントがトリガーされないように見えます。

この場合、停止したジョブの障害状態をクリアし、分離コマンドを手動で実行すると機能するようです。デバイスを再接続すると、復号化メカニズムが正常に起動し、インストールが完了します。コマンドは

sudo systemctl reset-failed systemd-cryptsetup@mytest
sudo /usr/lib/systemd/systemd-cryptsetup detach mytest

dev-mapper-mytest.device状態を確認できるデバイスもあります。分離が失敗した場合はアクティブのままですが、上記の手動分離コマンドを実行した後は無効になります。

（LUKSの上に追加のLVMレイヤーをカバーする関連する回答については、以下を参照してください。https://serverfault.com/a/1120163/582319)

問題は、すべての種類の「ダイナミック」アタッチメント/セパレーターにデフォルトの取り付けメカニズムが設定されていないことです。しかし、 systemd（とともにudev）そのような機能をサポートするために必要なすべてのメカニズムを提供します。

ツール

systemctl show <unit>systemctl status <unit>そして、udevadm info /device/file一緒にjournalctl -eユニットが互いにつながる方法を理解/検証するのに便利/必要です。

質問

systemctl show systemd-crptsetup@<luksvolume>.serviceデフォルトでは、有効なサービスユニットはluksvolumeシステム起動時のWantedBy=標準cryptsetup.targetであり、それ以上ではないことを示します。

noauto,nofail（BTW：すべての部分を直接接続する責任があるため、「動的」luksボリュームには常にcrypttabオプションを追加することをお勧めします。）

離れた

udevを介して基本デバイスにサービスを接続する

udev私たちが望むのは、デバイスが（再）接続されていることが確認されるたびにサービスデバイスを起動することです。これは、次の規則を使用して実行できますudev。

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_UUID}=="your-UUID", ENV{SYSTEMD_WANTS}+="systemd-cryptsetup@<luksvolume>.service"

/etc/udev/rules.d/ディレクトリにあり、名前を指定します。たとえば、99-usbactivation.rulesデバイス固有の環境変数および/または属性値を照会して使用することが重要ですudevadm info /device/name。これは==一致ですが、=（and +=）は割り当て項目であることを忘れないでください。

1つの珍しい点（少なくとも私の設定では）は、新しく作成された関係が表示されないことが多いが、systemctl show自動的に表示されると動作するかどうかがわかるということです。udevadm infowantsluksvolumelsblk

機器をさらに調査したところ、sytemd-cryptsetup@<luksvolume>.serviceその機器が基本機器であることがわかりましたBindsTo=。つまり、デバイスが消えるとすぐに自動的に停止するため、これに関連する特別な措置を講じる必要はありません。

以下を介してサービスをマウントポイントに接続します。/etc/fstab

fstabマウントポイントは最初にジェネレータを介してシステムを介して単位/mnt/fooに変換されます.mount。mnt-foo.mount翻訳された単位自体は、その中にある実際のファイルです/run/systemd/generator/（またはコンテンツを表示するためにのみ使用されますsystemctl cat <unit>）。すべてのシステム単位は、、などの同じ基本属性と、などBefore=の属性を持つことができ、など一般的に使用されるツールを使用して調べることができます。After=Requires=Wants=.mount.device.targetsystemctl show

システム単位ファイルへの変更（ファイルを直接/etc/fstab呼び出すか編集するなど）と同様に、すべての変更は、呼び出し後にのみsystemdによって選択されます。マウントポイントの場合、ディレクトリと埋め込み文書は完全に再生成されます。 。systemctl edit <unit>/etc/systemd/sytem/systemctl daemon-reload/run/systemd/generator

関連するマウントポイントは/etc/fstab次のとおりです。

/dev/mapper/<luksvolume>    /mnt/foo    ext4    defaults    0 2

〜のようにマウントユニットのsystemdドキュメント宣言は通常、通常の静的/ユーザートリガーのインストールと削除をエミュレートするのに十分であるため、systemdによって必要で注文された属性とデバイスをBindsTo=関連付けます。RequiresMountsFor=After=Before=

x-systemd.after=systemd-cryptsetup@<luksvolume>.serviceマウントデバイスがcryptsetupが操作を完了するのを待つように、特別なシステムマウントプロパティを追加する必要があります。

最後に、udevルールによって開始された「望ましいチェーン」（私の用語）を続けて、cryptsetupサービスがマウントデバイスを「起動したい」ようにします。これはセクション要素と同じfstabを使用して行われますx-systemd.wanted-by=。これは、に示すようにマウントデバイスファイルへのシンボリックリンクを使用してディレクトリを作成します。セルはセルを作成するためにのみ存在するため、このセルを処理することもできます。[Install]WantedBy=<unit><unit>.wants/run/systemd/generatorsystemd-cryptsetup@<luksvolume>.servicedev-mapper-<luksvolume>.devicex-systemd.wanted-by=dev-mapper-<luksvolume>.device

これらの結果はすべてfstab次の項目になります。

/dev/mapper/<luksvolume>    /mnt/foo    ext4    defaults,x-systemd.wanted-by=dev-mapper-<luksvolume>.device,x-systemd.after=systemd-cryptsetup@<luksvolume>.service    0 2

これですべてが「正常に動作する」必要があり、ドライブを取り外してもシステムデバイスを順番にシャットダウンする必要があります。

「削除」

関連するすべてのユニットは「ボトムアップ」で基本ユニットによって「円」になり、ユニットライフサイクルは「BindsTo =」関係（明示的または暗黙的）を介して基本ユニットにバインドされるため、無効にすることができます。これsystemd-cryptsetup@<luksvolume>.serviceでsystemctl stop十分でしょう。

別の可能性は、カスタム「トップダウン」[email protected]ユニットを作成して実行することです。このユニットの全体的な目的は、Conflicts=フィールド宣言に関連ユニットを使用することです。つまり、ユーザーがターゲットを実行すると、競合するユニットが停止します。これは、単にインストールデバイスを無効にするために必要です。確かにcryptsetup サービスを停止します。サービスユニットを変更するか、属性を追加することでsytemctl editこれを行うことができますBindsTo=。ただし、関連デバイスはすでに互いに順番に実行され実行されているため、ターゲットデバイスを起動すると、これらのデバイスが順番に停止することを保証できます。

これらのターゲットユニットは次のとおりです。

[Unit]
Conflicts=mnt-foo.mount systemd-cryptsetup@<luksvolume>.service
After=mnt-foo.mount systemd-cryptsetup@<luksvolume>.service

バリエーション：.mountデバイスに直接接続

追加のLVMレイヤーを追加する方法の研究中（再度参照）サーバー障害の回答）ではなく、.mountデバイスに直接接続するために個人（LUKSのみ、LVMレイヤーなし）設定を再接続しました。 udevルールは次のようになります。udev[email protected]

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_UUID}=="your-UUID", ENV{SYSTEMD_WANTS}+="mnt-foo.mount"

入り口/etc/crypttab:

<luksvolume>    UUID=<uuid>    /dir/keyfile    luks,nofail,noauto

/etc/fstabこれにより、特別なマウントオプションなしで通常のマウントポイント定義を削除できますx-systemd.<opt>。

/dev/mapper/<luksvolume>    /mnt/foo    ext4    defaults,nofail,noauto    0 2

唯一の面倒なことは、基本的に、次のものを追加する新しいconfファイルを生成するなど、追加の設定を添付するsystemd-cryptsetup@<luksvolume>.service必要があることです。systemctl edit systemd-cryptsetup@<luksvolume>.service/etc/systemd/system/systemd-cryptsetup@<luksvolume>.service.d/override.conf

[Unit]
BindTo=mnt-foo.mount
Before=mnt-foo.mount

cryptsetup サービスのライフサイクルは、デフォルトのデバイスデバイスにバインドされます。またサポートデバイスが消えた場合のマウントポイントの寿命またはマウントポイントが停止し（たとえば、ユーザーが要求した場合）、サービスも停止します（正しい順序で）。

概念的には、このアプローチの利点は、ユーザーがcryptsetupユニットを無視してマウントポイントのみを開始/停止できることです。残念ながら、少なくとも私のディストリビューションでは、何らかの理由でmountクラシックコマンドは（実際には）動作しません。umount常に使用するsystemctl start/stop /mnt/fooことをお勧めします。期待どおりに動作します。

他の2つの答えは非常に便利で、多くの情報と指示を提供します。サービス.mountとsystemd-cryptsetup生成されたサービスの間の依存関係を定義する部分が欠けているようです。

/etc以下のようにシンボリックリンクを作成するだけです。単位依存関係とシンボリックリンクの詳細については、次を参照してください。男性システムユニット。

完全性のために、全体の設定は次のとおりです。

USBエンクロージャを介してリモートサーバーにドライブを接続したため、ドライブやエンクロージャに障害が発生してもサーバーを起動したいと思います。不要な場合automountやオプションをスキップできますnoauto。しかし、とにかくマウントされたドライブがなければマウントポイントにアクセスできないので、どちらにしても大丈夫だと思います。これにより、設定の柔軟性が向上します。

• /etc/fstab (注: UUID は、設定スタック方式に応じて LV または LUKS ボリュームの上に作成されたファイルシステムの UUID です。)

UUID=42a1f3eb-ba45-4e00-996c-a6c492fe345a /media/mymount                   xfs     defaults,x-systemd.automount,nofail        0 0

• / etc / crypttab（注：UUIDは私たちが暗号化したLVです。rawデバイスを暗号化する場合はパスを指定する必要があります。/dev/disks/by-*）

mycryptdevice UUID=3682cae2-cf73-4a5e-8904-b83a9b4c2e47 /etc/luks-keyfile nofail,noauto

*魔法はこちらです↓↓↓↓リンクサービス今

sudo mkdir /etc/systemd/system/media-mymount.mount.requires
sudo ln -s /run/systemd/generator/[email protected] /etc/systemd/system/media-mymount.mount.requires/

• systemdデバイスとinitrdの再ロード

sudo systemctl daemon-reload
sudo dracut -f # or whatever your init system requires

パーティション、LVM論理ボリューム、暗号化パーティション、またはLVを作成してUUIDを取得することは、この質問の範囲外です。ポインタ用にいくつかの便利なコマンドがあります。

(umask 077 && dd if=/dev/random bs=64 count=1 of=/etc/luks-keyfile)
vgcreate VGName /dev/sdc1 /dev/sdc2
lvcreate --size 200GiB -n lvname
mkfs.xfs -L fslabel /dev/mapper/VGName
cryptsetup luksFormat/luksAddKey/luksUUID/luksDump/open/close

LUKSデバイスからVGを作成するか、LUKS / cryptsetupを使用してLVを暗号化できます。デフォルトでは、LVはudevルールを介して自動的に有効になるため、サービスを作成する必要はありません。

私のLVが複数のRAWデバイスにまたがる設定の場合、私が作成する個々のPVの代わりにLVを暗号化する方が簡単です。

ファタイ