[systemd-devel] the correct way to define crypt partitions, going forward
Jonathan Dowland
jon+systemd-devel at alcopop.org
Fri Jan 22 03:55:19 PST 2016
Hi, [please CC me on replies if possible],
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.
I am wondering whether crypttab should be considered deprecated and
whether it would be better practice for new volumes to be defined soley
as systemd units. Is the plan for the crypttab-generator to go away
eventually?
To activate my filesystems, the steps are
1. cryptsetup luksOpen <backing device>
2. vgchange -a y <relevant VG name>
3. mount <mountpoint>
I know to create a systemd-cryptsetup at XYZ.service unit and a
somepath.mount.unit to cover 1. and 3. above. But should I define a
service for 2., or handle it with ExecStartPost= in the cryptsetup
service definition?
I'm leaning towards the former, 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).
Finally, does anyone have a good solution for multiplexing the
decrypting of dm-crypt partitions that happen to have the same
passphrases? In normal operation I have 2 such devices that I do not
want to mount at boot-time (as that is headless/unattended), but I do
want to mount (manually) in normal operation. It would be convenient to
only type my passphrase once. Is this something the passphrase-asking
logic in systemd can or could support? Should I be looking at key files
instead?
[ on the other hand, I have yet to look at a possible boot-time
decryption solution involving dropbear ssh for headless passphrase entry
at initramfs time, which might solve this nicely if it works. ]
Thanks,
--
Jonathan Dowland
More information about the systemd-devel
mailing list