setting up systemd units for dm-crypt devices

[Jonathan Dowland <jmtd@debian.org>]

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.