I have several LUKS-encrypted volumes, upon which I have placed LVM PVs.
Prior to systemd, I would define them in /etc/crypttab. Right now, due
to systemd-cryptsetup-generator, this gets interpreted and translated
into systemd units at early-boot time.
I am wondering whether to consider crypttab should be considered deprecated and
whether it would be better practice for new volumes to be defined soley as
systemd units. I do want them as systemd units, one way or the other, so that
I can write other units that depend on them. It's quite nice to type 'systemctl
start /backup' and for it to correctly prompt for a decryption passphrase for
the depended-upon dm-crypt device.[1]
I currently do not decrypt these filesystems at boot time. The machine
is a headless NAS box and I want it to be able to boot without having
to plug a monitor into it.[2]
To activate my filesystems, the manual steps are
1. cryptsetup luksOpen <backing device>
2. vgchange -a y <relevant VG name>
3. mount <mountpoint>
I know to create a systemd-cryptsetup@XYZ.service unit and a
somepath.mount.unit to cover 1. and 3. above. But should I define a
service for 2.? The alternative would be to try and handle it with
ExecStartPost= in the cryptsetup service definition.
I'm leaning towards defining a full unit for it, because one also needs to
handle vgchange -a n prior to luksClose, but I'd appreciate your opinions (it
might just be a matter of style).
Thanks,
[1] If I was not using LVM on top of dm-crypt, then there'd be no advantage in
using 'systemctl start /backup' over 'cryptdisks_start /backup', but the
cryptdisks approach does not know to invoke the vgchange step.
[2] I am planning to investigate having a dropbear sshd running in the
initramfs environment in the future, so I can do an ssh-in to decrypt
the filesystems, including /, but I haven't looked at this yet. There
are several dracut modules that seem to do it.
--
Jonathan Dowland
Please do not CC me, I am subscribed to the list.
