On 12/08/2011 10:00 PM, Ken Bass wrote:
On 12/8/2011 3:45 PM, Zbigniew Jędrzejewski-Szmek wrote:
maybe I'm misunderstanding you, but I think that you are looking at
the meaning of cryptsetup.target in a wrong way: cryptsetup.target
comes after all encrypted devices configured in /etc/crypttab are
ready. So it makes sense to do something with After=cryptsetup.target
(== after all encrypted devices have been opened), but not with
Before=cryptsetup.target.
I guess that you might have to declare the ordering dependence between
mnt-subkey.mount with Before=cryptsetup@encrypt_storage.service directly.
Hi Zbyszek,
I understand what you are saying and perhaps I am looking at it from a
different angle. But the problem with your suggestion is that it is a
non-generic way to handle it. The 'cryptsetup@encrypt_storage.service '
is completely dependent on whatever is listed in the /etc/crypttab and
that could be changed by the user at any time. If that /etc/crypttab
entry was renamed or commented out, the dependency would mysteriously
break. Maybe there needs to be a cryptsetup-begin.target and
cryptsetup-done.target instead? I don't think its is far stretch to want
to ensure some happens before ANY encrypted devices has been opened.
Hi Ken,
I think that there's a better solution: to make the
cryptsetup@....service wait for the appearance of the key file.
The generator could be changed for cases only when the keyfile is
specified.
Something like this:
== cryptsetup@...crypt.service ==
[Unit]
ConditionPathExists=/somewhere/keyfile
An additional path unit would need to be created:
== cryptse...@...crypt.path ==
[Path]
PathExists=/somewhere/keyfile
I've done some testing with a normal service and a file in /tmp, and it
seems to behave properly -- since the service has RemainAfterExit=true,
it can safely be started multiple times.
One problem (potentially fatal :( ) with this setup is that the
cryptsetup@...service doesn't wait for they keyfile, but instead first
fails, and then is started when the path unit condition triggers after
the file is created. This means that you would properly get the
decrypted device created after the key file and the encrypted block
device are available, but it would not be subject to normal timeout.
OK, I now see that this is very hacky, but maybe it will give you some
useful idea.
Best,
Zbyszek
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
