Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-02-12 Thread John Lane
On 11/02/15 20:03, Lennart Poettering wrote:

 Well, no. It would add Wants= and After=, instead of Requires= and
 After=. But I figure what you wrote was just a typo?
yes what you say is what I meant.
 I think we should switch over to use WantsMountsFor for this
 unconditionally. After all we can always query the user as fallback...
that sounds sensible.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-02-11 Thread Lennart Poettering
On Thu, 05.02.15 10:08, John Lane (syst...@jelmail.com) wrote:

 On 02/02/15 20:54, Lennart Poettering wrote:
  On Sat, 31.01.15 11:21, John Lane (syst...@jelmail.com) wrote:
 
  Further to this, I tried manually creating a systemd-cryptsetup unit
  instead of putting an entry in /etc/crypttab.
  This allowed me to remove the RequiresMountsFor entry.
  Yeah, I figure for your usecase a WantsMountsFor= setting would be
  useful. (Wants is generally the softer variant of Requires for us).
 
  Added to the TODO list for now.
 
  Lennart
 
 
 I assume WantsMountsFor will work similarly to RequiresMountsFor in
 that it will add a Wants and Requires dependencies.

Well, no. It would add Wants= and After=, instead of Requires= and
After=. But I figure what you wrote was just a typo?

 So, I just did a quick test by adding Wants and Requires has no
 detrimental effect on my use-case. My custom unit works fine without the
 dependency (thanks to the use of an automount) but adding those
 dependencies doesn't stop it working as desired.
 
 Will the TODO just replace the current use by the crypttab generator of
 RequiresMountsFor with WantsMountsFor,
 or will an additional crypttab option (x-systemd-...) be required to
 make it configure it that way ?

I think we should switch over to use WantsMountsFor for this
unconditionally. After all we can always query the user as fallback...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-02-05 Thread John Lane
On 02/02/15 20:54, Lennart Poettering wrote:
 On Sat, 31.01.15 11:21, John Lane (syst...@jelmail.com) wrote:

 Further to this, I tried manually creating a systemd-cryptsetup unit
 instead of putting an entry in /etc/crypttab.
 This allowed me to remove the RequiresMountsFor entry.
 Yeah, I figure for your usecase a WantsMountsFor= setting would be
 useful. (Wants is generally the softer variant of Requires for us).

 Added to the TODO list for now.

 Lennart


I assume WantsMountsFor will work similarly to RequiresMountsFor in
that it will add a Wants and Requires dependencies.

So, I just did a quick test by adding Wants and Requires has no
detrimental effect on my use-case. My custom unit works fine without the
dependency (thanks to the use of an automount) but adding those
dependencies doesn't stop it working as desired.

Will the TODO just replace the current use by the crypttab generator of
RequiresMountsFor with WantsMountsFor,
or will an additional crypttab option (x-systemd-...) be required to
make it configure it that way ?

I'll look out for this being implemented and will try it out.

Thanks for adding to the list.

John


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-02-04 Thread John Lane
On 02/02/15 20:49, Lennart Poettering wrote:
 BTW, just to mention this. You can also just write:

 # systemctl start /home/myuser/data
That's good to know, thanks.

 This will automatically be translated to
 home-myuser-data.mount. systemctl has some logic built in to
 translate strings that don't look like unit names into unit names.

 Essentially this hence means that this:

a) mount /home/myuser/data
b) systemctl start /home/myuser/data

 However, the latter respects the whole systemde depency logic, while
 the former just tries to mount the specified dir immediately, ignoring
 all deps.
yep, got that now. mount doesn't hit-up systemd so the deps don't happen.
I'll train my mind to remember option (b).


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-02-02 Thread Lennart Poettering
On Sat, 31.01.15 11:21, John Lane (syst...@jelmail.com) wrote:

 Further to this, I tried manually creating a systemd-cryptsetup unit
 instead of putting an entry in /etc/crypttab.
 This allowed me to remove the RequiresMountsFor entry.

Yeah, I figure for your usecase a WantsMountsFor= setting would be
useful. (Wants is generally the softer variant of Requires for us).

Added to the TODO list for now.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-02-02 Thread Lennart Poettering
On Thu, 29.01.15 17:31, John Lane (syst...@jelmail.com) wrote:

 I am looking for some advice about configuring encrypted volumes with
 systemd that I want to open on demand (noauto).
 
 I can add entries into /etc/crypttab and /etc/fstab for the device, for
 example
 
 # name   device
 password  options
 dataUUID=deadbeef   
 nonenoauto
 
 and
 
 # file systemdirtypeoptionsdumppass
 /dev/mapper/data /home/myuser/data ext4 noauto 0 0
 
 But the device doesn't unlock when I do
 
 $ mount /home/myuser/data
 mount: special device /dev/mapper/keyring does not exist
 
 But it does if I use
 
 $ systemctl start home-myuser-data.mount

BTW, just to mention this. You can also just write:

# systemctl start /home/myuser/data

This will automatically be translated to
home-myuser-data.mount. systemctl has some logic built in to
translate strings that don't look like unit names into unit names.

Essentially this hence means that this:

   a) mount /home/myuser/data
   b) systemctl start /home/myuser/data

However, the latter respects the whole systemde depency logic, while
the former just tries to mount the specified dir immediately, ignoring
all deps.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-31 Thread John Lane
On 30/01/15 09:49, Jan Janssen wrote:

 But really: why not use automounting logic in fstab?:
 /dev/mapper/data /home/myuser/data ext4 noauto,x-systemd.automount 0 0

 No need to manually trigger a mount. And you can even use noauto in
 crypttab so that the encrypted device is only opened once the mount point is
 accessed the first time.
Thanks Jan. as it happens, I've just been trying automount as a solution
before I read your answer ;)

But it leads me on to another question, if that's ok...

I've set up an encrypted volume configured in crypttab/fstab with
key/header on a path that is automounted.
That path is on a encrypted removable usb keyring that's inserted at
boot and everything works: the keyring is unlocked (passphrase
requested) and mounted and then the other volumes are unlocked using
their key/header on the keyring and mounted.

However, after boot I want to pull out the keyring (it's only needed for
the key/header during systemd-cryptsetup).
But when I do this, the encrypted volume is unmounted and I don't want
this to happen.

Here's what I have in crypttab:

|# name  device   password options
keyring   PARTLABEL=keyring  none   noauto
abc   /dev/lvm/abc   /root/keyring/abc.key  header=/root/keyring/abc.hdr
xyz   /dev/lvm/xyz   /root/keyring/xyz.key  
header=/root/keyring/xyz.hdr|


and fstab:

| file system dir typeoptions
/dev/mapper/keyring /root/keyring ext4  ro,noauto,x-systemd.automount
/dev/mapper/abc /srv/abc  ext4
/dev/mapper/xyz /srv/xyz  ext4|


I don't want to lose abc and xyz when I pull out keyring.

I think it might be due to the RequiresMountsFor=/root/keyring/abc.key
entries that systemd generates in the cryptsetup unit.
I have tried using a drop-in to cancel that option:

[Unit]
RequiresMountsFor=

but that didn't affect the setting, as I verified with

$ systemctl daemon-reload
$ systemctl show systemd-cryptsetup\@abc --property RequiresMountsFor
RequiresMountsFor=/root/keyring/abc.key

Do you know if/how I can achieve this functionality?

Much appreciated,
John


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-31 Thread John Lane
On 31/01/15 10:25, John Lane wrote:
 On 30/01/15 09:49, Jan Janssen wrote:

 But really: why not use automounting logic in fstab?:
 /dev/mapper/data /home/myuser/data ext4 noauto,x-systemd.automount 0 0

 No need to manually trigger a mount. And you can even use noauto in
 crypttab so that the encrypted device is only opened once the mount point is
 accessed the first time.
 Thanks Jan. as it happens, I've just been trying automount as a
 solution before I read your answer ;)

 But it leads me on to another question, if that's ok...

 I've set up an encrypted volume configured in crypttab/fstab with
 key/header on a path that is automounted.
 That path is on a encrypted removable usb keyring that's inserted at
 boot and everything works: the keyring is unlocked (passphrase
 requested) and mounted and then the other volumes are unlocked using
 their key/header on the keyring and mounted.

 However, after boot I want to pull out the keyring (it's only needed
 for the key/header during systemd-cryptsetup).
 But when I do this, the encrypted volume is unmounted and I don't want
 this to happen.

 Here's what I have in crypttab:

 |# name  device   password options
 keyring   PARTLABEL=keyring  none   noauto
 abc   /dev/lvm/abc   /root/keyring/abc.key  
 header=/root/keyring/abc.hdr
 xyz   /dev/lvm/xyz   /root/keyring/xyz.key  
 header=/root/keyring/xyz.hdr|

 and fstab:

 | file system dir typeoptions
 /dev/mapper/keyring /root/keyring ext4  ro,noauto,x-systemd.automount
 /dev/mapper/abc /srv/abc  ext4
 /dev/mapper/xyz /srv/xyz  ext4|

 I don't want to lose abc and xyz when I pull out keyring.

 I think it might be due to the
 RequiresMountsFor=/root/keyring/abc.key entries that systemd
 generates in the cryptsetup unit.
 I have tried using a drop-in to cancel that option:

 [Unit]
 RequiresMountsFor=

 but that didn't affect the setting, as I verified with

 $ systemctl daemon-reload
 $ systemctl show systemd-cryptsetup\@abc --property RequiresMountsFor
 RequiresMountsFor=/root/keyring/abc.key

 Do you know if/how I can achieve this functionality?

 Much appreciated,
 John




 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Further to this, I tried manually creating a systemd-cryptsetup unit
instead of putting an entry in /etc/crypttab.
This allowed me to remove the RequiresMountsFor entry.

By doing this, removing the keyring doesn't unmount the encrypted volumes.

The unit I used looks like this:
/etc/systemd/system/systemd-cryptsetup@.service

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8)
man:systemd-cryptsetup@.service(8)
#SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
#RequiresMountsFor=/root/keyring//%i.key
BindsTo=dev-lvm-%i.device
After=dev-lvm-%i.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%i'
'/dev/lvm/%i' '/root/keyring/%i.key' 'header=/root/keyring/%i.hdr'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%i'

[Install]
WantedBy=dev-mapper-%i.device

I wonder if it's possible for an /etc/crypttab option to soften the
requirement for the mount to something like StartRequiresMountsFor...




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-30 Thread Jan Janssen
John Lane systemd at jelmail.com writes:
 $ mount /home/myuser/data
 mount: special device /dev/mapper/keyring does not exist
Your crypttab entry uses noauto as an option. This means that it won't get
activated and no plain text device is created. Hence your manual mount can
only fail.

 I'm guessing that mount doesn't effect systemd and, therefore, the
 dependency isn't actioned. But the docs for systemd.mount state that
 configuring mount points through /etc/fstab
 is the preferred approach so I'm wondering if there's something I
 missed from my crypttab or fstab entries?
 Thanks.

But really: why not use automounting logic in fstab?:
/dev/mapper/data /home/myuser/data ext4 noauto,x-systemd.automount 0 0

No need to manually trigger a mount. And you can even use noauto in
crypttab so that the encrypted device is only opened once the mount point is
accessed the first time.

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-29 Thread John Lane
I am looking for some advice about configuring encrypted volumes with
systemd that I want to open on demand (noauto).

I can add entries into /etc/crypttab and /etc/fstab for the device, for
example

# name   device
password  options
dataUUID=deadbeef   
nonenoauto

and

# file systemdirtypeoptionsdumppass
/dev/mapper/data /home/myuser/data ext4 noauto 0 0

But the device doesn't unlock when I do

$ mount /home/myuser/data
mount: special device /dev/mapper/keyring does not exist

But it does if I use

$ systemctl start home-myuser-data.mount

I'm guessing that mount doesn't effect systemd and, therefore, the
dependency isn't actioned. But the docs for systemd.mount state that
configuring mount points through |/etc/fstab| is the preferred
approach so I'm wondering if there's something I missed from my
crypttab or fstab entries?

Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-29 Thread Andrei Borzenkov
On Thu, Jan 29, 2015 at 8:31 PM, John Lane syst...@jelmail.com wrote:
 I am looking for some advice about configuring encrypted volumes with
 systemd that I want to open on demand (noauto).

 I can add entries into /etc/crypttab and /etc/fstab for the device, for
 example

 # name   device password
 options
 dataUUID=deadbeefnone
 noauto

 and

 # file systemdirtypeoptionsdumppass
 /dev/mapper/data /home/myuser/data ext4 noauto 0 0

 But the device doesn't unlock when I do

 $ mount /home/myuser/data
 mount: special device /dev/mapper/keyring does not exist

 But it does if I use

 $ systemctl start home-myuser-data.mount

 I'm guessing that mount doesn't effect systemd and, therefore, the
 dependency isn't actioned. But the docs for systemd.mount state that
 configuring mount points through /etc/fstab is the preferred approach so
 I'm wondering if there's something I missed from my crypttab or fstab
 entries?


No, you did not. systemd know about additional dependencies and tries
to resolve them. Plain mount does not know anything about them. It
is irrelevant where exactly this mount point is configured and
decsribed.

May be one day mount will forward mount request to systemd. Who knows.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel