How to set up services depending on encrypted filesystems with systemd (was Re: How to do this ?)
Hi Erwan,
Firstly I've changed the subject for this thread because the original was not
terribly descriptive.
On Mon, Oct 13, 2014 at 07:57:00AM +0100, Jonathan Dowland wrote:
> On Sun, Oct 12, 2014 at 09:40:44PM +0200, Erwan David wrote:
> > And how to do this is a big problem. There are many mans but to use them
> > you must know what you are looking for.
>
> I plan to come back and fill this in with the specifics as I have a similar
> problem to solve. I'm confident it's not hard.
OK, I have 90% of the problem solved, here's the solution, first, let's ignore
luks disks for a the time being and instead outline the solution with a simple
mount.
Imagine you have a simple mount at /torrents that you want to be there before
the transmission-daemon service is started. You must write a systemd unit file
of the "mount" type, named "torrents.mount"[1] containing something like the
following. In this example, the source filesystem has a label "torrents", but
you could use a hard path (/dev/mapper/cryptdisk_front) instead.
> [Mount]
> What=LABEL=torrents
> Where=/torrents
Drop that in /etc/systemd/system, possibly run "systemctl daemon-reload", and
you can do "systemctl start /torrents", "systemctl stop /torrents".
Next step, adjust the daemon to depend on this. In my example,
transmission-daemon supplies a .service file in the package. Copy this to
/etc/systemd/system, and add a line (the line prefixed +):
> [Unit]
> Description=Transmission BitTorrent Daemon
> After=network.target
> +Requires=torrents.mount
>
> [Service]
> User=debian-transmission
After another "systemctl daemon-reload", you should find that starting
that daemon with the filesystem unmounted will first mount it. Great.
So the other part of the puzzle for you was the LUKS filesystem. I got this
working but there may be some improvements that can be made to the below.
I created a test luks filesystem using "luksformat", the backing device in my
case is /dev/qusp_vg/cryptback, I wrote the following line into /etc/crypttab:
> front /dev/qusp_vg/cryptback none luks,noauto
I now ran (by hand) /lib/systemd/system-generators/systemd-cryptsetup-generator
This is run by systemd in the early boot phase, and might possibly be run by
"daemon-reload". It's supposed to generate systemd unit files corresponding to
the entries in /etc/crypttab. And indeed, when ran by hand like that, it has
done so for me, into /tmp/systemd-cryptsetup@front.service
If I drop that into /etc/systemd/system and use "systemctl status
systemd-cryptsetup@front.service", I can see it is recognised, and a "systemctl
start systemd-cryptsetup@front.service" results in /dev/mapper/front appearing,
after prompting me for the password (and they have a fairly intelligent
password prompt it would appear)
I'm going to stop here for tonight, but I don't think it will be much work to
clean up this last service file (it looks like some of the stuff that has been
included by systemd-cryptsetup-generator can be stripped out) and then set up
the chain of dependencies so transmission-daemon -> /torrents ->
/dev/mapper/front, and after that, starting transmission-daemon will cause the
luks FS to be mounted after prompting for the password.
[1] the naming convention is to replace any slashes in the path with dashes,
after removing any prefixed or suffixed slashes. So, /torrents -> torrents,
but /home/jon would be home-jon.
Reply to: