On Fri, Jan 22, 2016 at 5:09 PM, Jonathan Dowland <j...@debian.org> wrote: > 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 have a similar setup. I used crypttab to get systemd to generate a service file, which I then moved over to /etc/systemd/system and modified. I had to modify it because there are some crazy things happening with systemd-cryptsetup in combination with multi-device btrfs filesystems. Having them as service files is fine, and you should be ok if you use LVM on them. > 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). I guess having a separate unit for this could be nice, but is it really necessary? Having used LVM on top of LUKS, I can't recall having to do that step manually. > [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. I do this on one machine, haven't decided if I'm happy with the setup or not. There are too many issues with systemd+encryption in Jessie right now.
