Managing encrypted partitions with systemd?

Hi,

I have a 12.3 test system, running under vmplayer - but this is not a
question related to virtualization, mind - do not think of moving it
there :wink:

I have created several filesystems for testing, including two encrypted
partitions (one set for mounting at boot, another for not). Files posted
below.

I do not want plymouth, so it was removed right from the installation
screen. Also the system is defined to boot in textmode, splash=verbose,
what was level 3, but has a different name now (multiuser text mode
target with network, or something similar).

The system boots correctly, asks for the password to the encrypted
partition, and a bit later prompts for the text login. Fine, so far.

The problem is if I fail to enter the right password the first time, it
says nothing, just sits there waiting for a while, then I get the login
prompt. And then I see that the encrypted partition is not mounted.

I also get a repeated broadcast “wall” message on all terminals, local
and remote (ssh):


> eleanor3:~ #
> Broadcast message from root@eleanor3.valinor (Sun, 2013-05-05 23:45:48 CEST):
>
> Password entry required for 'Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta1) on /data/cripta1!' (PID 3238).
> Please enter password with the systemd-tty-ask-password-agent tool!


What is that agent for, how do I use it? The hint is useless. The agent
is running, but I do not know where to enter the password.

How do I enter that password? I tried:


> eleanor3:~ # systemd-tty-ask-password-agent
> eleanor3:~ #
> eleanor3:~ # ps afxu | grep systemd-tty-ask-password-agent
> root      3287  0.0  0.1   7088   860 pts/0    S+   00:06   0:00          \_ grep --color=auto systemd-tty-ask-password-agent
> root      2779  0.0  0.1  12744   936 ?        Ss   May05   0:00 /usr/bin/systemd-tty-ask-password-agent --wall
>
>
> eleanor3:~ # mount /data/cripta1
> eleanor3:~ #

It fails silently.

> eleanor3:~ # l /dev/mapper/
> total 0
> drwxr-xr-x  2 root root      60 May  5 23:30 ./
> drwxr-xr-x 18 root root    4000 May  5 23:32 ../
> crw-------  1 root root 10, 236 May  5 23:30 control
> eleanor3:~ #


Previously, I would have used “rccrypto” to activate them, but now I
don’t know what to use. I’m reviewing posts (specially from
“arvidjaar”), but I don’t get it clear.

For instance:

On 2013-04-04 20:06, arvidjaar wrote:>

Commands have uniform structure. You have single tool (systemctl),
action (start, stop, status), unit name. Unit names are built using
fixed rules. Mount unit for filesystem /v1 will always be v1.mount.
You use “systemctl status|start|stop” for every unit type. So this is
single command to remember. Heck, there is completion. “systemctl TAB”
lists all commands, “systemctl status TAB” lists all units :slight_smile:

Ok, tab completion gives me 292 targets… I do not know which one to use.

Ok, lets play around guessing a bit.

>
>
> eleanor3:~ # systemctl status /data/cripta1.mount
> data-cripta1.mount.mount
>           Loaded: error (Reason: No such file or directory)
>           Active: inactive (dead)
>
> eleanor3:~ #

> eleanor3:~ # systemctl status /data/cripta1
> data-cripta1.mount - /data/cripta1
>           Loaded: loaded (/etc/fstab)
>           Active: inactive (dead)
>            Where: /data/cripta1
>             What: /dev/mapper/cr_data_cripta1
>           CGroup: name=systemd:/system/data-cripta1.mount
>
> May 05 23:32:22 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.
> May 05 23:32:24 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.
> May 05 23:34:35 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.
> May 05 23:47:18 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.
>
> Warning: Unit file changed on disk, 'systemctl --system daemon-reload' recommended.
> eleanor3:~ # systemctl --system daemon-reload
> eleanor3:~ # systemctl status /data/cripta1
> data-cripta1.mount - /data/cripta1
>           Loaded: loaded (/etc/fstab)
>           Active: inactive (dead)
>            Where: /data/cripta1
>             What: /dev/mapper/cr_data_cripta1
>           CGroup: name=systemd:/system/data-cripta1.mount
>
> May 05 23:32:22 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.
> May 05 23:32:24 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.
> May 05 23:34:35 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.
> May 05 23:47:18 eleanor3.valinor systemd[1]: Dependency failed for /data/cripta1.

What dependency has failed?

> eleanor3:~ # systemctl start /data/cripta1
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta1) on /data/cripta1! ***********
> eleanor3:~ # systemctl status /data/cripta1
> data-cripta1.mount - /data/cripta1
>           Loaded: loaded (/etc/fstab)
>           Active: active (mounted) since Mon, 2013-05-06 00:13:57 CEST; 3s ago
>            Where: /data/cripta1
>             What: /dev/mapper/cr_data_cripta1
>          Process: 3380 ExecMount=/bin/mount /dev/mapper/cr_data_cripta1 /data/cripta1 -t ext4 -o noatime,acl,user_xattr,nofail (code=exited, status=0/SUCCESS)
>           CGroup: name=systemd:/system/data-cripta1.mount
>
> May 06 00:13:56 eleanor3.valinor systemd[1]: Mounting /data/cripta1...
> May 06 00:13:57 eleanor3.valinor systemd[1]: Mounted /data/cripta1.
> eleanor3:~ #


And when I run “systemctl start /data/cripta1” I also get a wall on tty1
to enter the password via that agent - useless, as I’m using an ssh
session on the host, ie, I’m accessing remotely.

And this is curious:



> eleanor3:~ # systemctl stop /data/cripta1
> eleanor3:~ # ls /data/cripta1
> eleanor3:~ # touch /data/cripta1/not_mounted
> eleanor3:~ # touch /data/cripta2/not_mounted
> eleanor3:~ # systemctl start /data/cripta1
> eleanor3:~ # systemctl start /data/cripta1
> eleanor3:~ # ls /data/cripta1
> lost+found
> eleanor3:~ #


Notice that it does not ask for the partition password, this could be
dangerous. There should be a manner to force the system to forget the
password - if someone comes behind me, just issue the command and he
gets my partition without knowing the password.

And the configuration is:



> eleanor3:~ # cat /etc/fstab
> LABEL=Root                      /               ext4    	noatime,acl,user_xattr 1 1
> /dev/mapper/cr_data_cripta1     /data/cripta1   ext4    	noatime,acl,user_xattr,nofail 0 2
> /dev/mapper/cr_data_cripta2     /data/cripta2   ext4    	noatime,noauto,acl,user_xattr,nofail 0 0
> LABEL=User                      /usr            ext4    	noatime,acl,user_xattr 1 2
> LABEL=Swap                      swap            swap    	defaults 0 0
> LABEL=Reiserfs                  /data/reiserfs  reiserfs      noatime,acl,user_xattr 1 2
> LABEL=Xfs                       /data/xfs       xfs     	defaults 1 2
> LABEL=Btrfs                     /data/btrfs     btrfs   	defaults 0 0
>
> proc    /proc                   proc    defaults        0 0
> sysfs   /sys                    sysfs   noauto          0 0
> debugfs /sys/kernel/debug       debugfs noauto          0 0
> usbfs   /proc/bus/usb           usbfs   noauto          0 0
> devpts  /dev/pts                devpts  mode=0620,gid=5 0 0
>
> telcontar.valinor:/data/storage_c/repositorios_zypp     /var/cache/zypp/nfs_packages    nfs4    defaults 0 0
> eleanor3:~ # cat /etc/crypttab
> cr_data_cripta1 /dev/sda7            none       none
> cr_data_cripta2 /dev/sda8            none       noauto
> eleanor3:~ #


I don’t know how grub2 is configured, though. I have to read the doc on
it yet.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

I don’t know the answer, so I’m partly guessing here.

I do notice that there is a command “systemd-tty-ask-password-agent” in “/usr/bin”, and it has a man page.

I’m guessing that if you did:

systemd-tty-ask-password-agent --query

it would tell you what password is needed and allow you to respond, even over an ssh session.

My suggestion is that you edit “/etc/crypttab”, and change the second “none” on the first line to “initrd”.

After that change, run:


# mkinitrd

That way, the prompting for the crypto key for your first mount should be done in the “initrd” environment before “systemd” has been started. If you mistype the key, I’m pretty sure that it will prompt again, and it will wait forever if appropriate.

On 2013-05-06 01:46, nrickert wrote:
>
> I don’t know the answer, so I’m partly guessing here.
>
> I do notice that there is a command “systemd-tty-ask-password-agent” in
> “/usr/bin”, and it has a man page.
>
> I’m guessing that if you did:
>
> systemd-tty-ask-password-agent --query
>
> it would tell you what password is needed and allow you to respond,
> even over an ssh session.

Right! It worked. I rebooted (there was an update just now), I entered
the wrong password on purpose, then over ssh I tried:



> eleanor3:~ # systemd-tty-ask-password-agent --query
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta1) on /data/cripta1! ***********
> eleanor3:~ # df -h
> Filesystem                                           Size  Used Avail Use% Mounted on

....

> /dev/mapper/cr_data_cripta1                          385M   11M  355M   3% /data/cripta1
> eleanor3:~ #


So that’s it. I notice that the program is running this way:



> eleanor3:~ # ps afxu | grep systemd-tty-ask-password-agent
> root      3255  0.0  0.1   7088   860 pts/0    S+   02:10   0:00          \_ grep --color=auto systemd-tty-ask-password-agent
> root      2818  0.0  0.1  12744   904 ?        Ss   02:04   0:00 /usr/bin/systemd-tty-ask-password-agent --wall
> eleanor3:~ #


And the manual you mentioned - it did not occur to me to look for it - says:



--wall
Forward password requests to wall(1) instead of
querying the user on the calling TTY.


What I would like is not to have it use “–wall”, the rest of the world
is not interested that I have an encrypted partition. I’ll have to find
out who runs it.

> My suggestion is that you edit “/etc/crypttab”, and change the second
> “none” on the first line to “initrd”.
>
> After that change, run:
>
> Code:
> --------------------
>
> # mkinitrd
>
> --------------------
>
> That way, the prompting for the crypto key for your first mount should
> be done in the “initrd” environment before “systemd” has been started.
> If you mistype the key, I’m pretty sure that it will prompt again, and
> it will wait forever if appropriate.

Interesting possibility, and I’m making a note of it, thanks. But this
is a data partition, it is not absolutely necessary to have it available
on boot.

Actually, this time it prompted for the password three times.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On 2013-05-06 02:28, Carlos E. R. wrote:

> What I would like is not to have it use “–wall”, the rest of the world
> is not interested that I have an encrypted partition. I’ll have to find
> out who runs it.

I found it.

/usr/lib/systemd/system/systemd-ask-password-wall.service



> #  This file is part of systemd.
> #
> #  systemd is free software; you can redistribute it and/or modify it
> #  under the terms of the GNU Lesser General Public License as published by
> #  the Free Software Foundation; either version 2.1 of the License, or
> #  (at your option) any later version.
>
> [Unit]
> Description=Forward Password Requests to Wall
> Documentation=man:systemd-ask-password-console.service(8)
> After=systemd-user-sessions.service getty@tty1.service
>
> [Service]
> ExecStartPre=-/usr/bin/systemctl stop systemd-ask-password-console.path systemd-ask-password-console.service systemd-ask-password-plymouth.path systemd-ask-password-plymouth.service
> ExecStart=/usr/bin/systemd-tty-ask-password-agent --wall


Maybe I should just remove the --wall

There is another service named “systemd-ask-password-console.service”.
Both are “loaded”, but only the first one is “active”. I have to learn
what that means before attempting any change O:-)



> eleanor3:~ # systemctl status systemd-ask-password-wall
> systemd-ask-password-wall.service - Forward Password Requests to Wall
>           Loaded: loaded (/usr/lib/systemd/system/systemd-ask-password-wall.service; static)
>           Active: active (running) since Mon, 2013-05-06 02:04:51 CEST; 42min ago
>             Docs: man:systemd-ask-password-console.service(8)
>          Process: 2805 ExecStartPre=/usr/bin/systemctl stop systemd-ask-password-console.path systemd-ask-password-console.service systemd-ask-password-plymouth.path systemd-ask-password-plymouth.service (code=exited, status=5)
>         Main PID: 2818 (systemd-tty-ask)
>           CGroup: name=systemd:/system/systemd-ask-password-wall.service
>                   └ 2818 /usr/bin/systemd-tty-ask-password-agent --wall
>
> May 06 02:04:51 eleanor3.valinor systemd[1]: Starting Forward Password Requests to Wall...
> May 06 02:04:51 eleanor3.valinor systemctl[2805]: Failed to issue method call: Unit systemd-ask-password-plymouth.path not loaded.
> May 06 02:04:51 eleanor3.valinor systemctl[2805]: Failed to issue method call: Unit systemd-ask-password-plymouth.service not loaded.
> May 06 02:04:51 eleanor3.valinor systemd[1]: Started Forward Password Requests to Wall.
> May 06 02:05:03 eleanor3.valinor systemd[1]: Started Forward Password Requests to Wall.
> May 06 02:05:03 eleanor3.valinor systemd[1]: Started Forward Password Requests to Wall.
> eleanor3:~ #

> eleanor3:~ # systemctl status systemd-ask-password-console
> systemd-ask-password-console.service - Dispatch Password Requests to Console
>           Loaded: loaded (/usr/lib/systemd/system/systemd-ask-password-console.service; static)
>           Active: inactive (dead) since Mon, 2013-05-06 02:04:51 CEST; 43min ago
>             Docs: man:systemd-ask-password-console.service(8)
>          Process: 414 ExecStart=/usr/bin/systemd-tty-ask-password-agent --watch --console (code=exited, status=0/SUCCESS)
>           CGroup: name=systemd:/system/systemd-ask-password-console.service
>
> May 06 02:04:07 eleanor3.valinor systemd[1]: Starting Dispatch Password Requests to Console...
> May 06 02:04:07 eleanor3.valinor systemd[1]: Started Dispatch Password Requests to Console.
> May 06 02:04:18 eleanor3.valinor systemd[1]: Started Dispatch Password Requests to Console.
> May 06 02:04:24 eleanor3.valinor systemd[1]: Started Dispatch Password Requests to Console.
> May 06 02:04:51 eleanor3.valinor systemd[1]: Stopping Dispatch Password Requests to Console...
> May 06 02:04:51 eleanor3.valinor systemd[1]: Stopped Dispatch Password Requests to Console.
> eleanor3:~ #



Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

When starting the service that requested password times out, password request is canceled.

And when I run “systemctl start /data/cripta1” I also get a wall on tty1
to enter the password via that agent - useless, as I’m using an ssh
session on the host, ie, I’m accessing remotely.

Well … wall is wall, it walls on all logged in terminals. How should you otherwise know there is password request?

eleanor3:~ # systemctl stop /data/cripta1
eleanor3:~ # systemctl start /data/cripta1

Notice that it does not ask for the partition password, this could be
dangerous.

Because you stop and start mount point, not encrypted container. You simply did “umount /data/cripta1; mount /data/cripta1”. Encrypted device remained available.

On 2013-05-06 05:16, arvidjaar wrote:
>
> robin_listas;2554156 Wrote:
>> How do I enter that password? I tried:
>>
>>>
> Code:
> --------------------
> > >
> > eleanor3:~ # systemd-tty-ask-password-agent
> > eleanor3:~ #
> >
> --------------------
>>>
> When starting the service that requested password times out, password
> request is canceled.

It did not, it said that a password was pending but did not ask for it.
And it repeats that on every terminal every few minutes, disrupting work.

>> And when I run “systemctl start /data/cripta1” I also get a wall on tty1
>> to enter the password via that agent - useless, as I’m using an ssh
>> session on the host, ie, I’m accessing remotely.
> Well … wall is wall, it walls on all logged in terminals. How should
> you otherwise know there is password request?

How does it knows that it is telling me only? It is telling it to all
users, and only one knows the password. And it doesn’t say what command
to type to enter the password.

I would prefer it to ask me on only on the boot terminal. If that fails,
don’t ask again, die.

I have seen that there is a service doing it, but I don’t know yet if I
should disable it and how.

> Code:
> --------------------
> > >
> >
> > > eleanor3:~ # systemctl stop /data/cripta1
> > > eleanor3:~ # systemctl start /data/cripta1
> >
> >
> --------------------
>>>
>>
>> Notice that it does not ask for the partition password, this could be
>> dangerous.
> Because you stop and start mount point, not encrypted container. You
> simply did “umount /data/cripta1; mount /data/cripta1”. Encrypted device
> remained available.

Ok, so how do I stop both?

I know how to umount partitions with umount, I don’t see why there is a
need for a systemd service for that.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Hmm … I tested it and I got single broadcast (wall) after system reached run level 3. So there may be other conditions when it is repeated non-stop.


linux-vmd4:~ # systemd-tty-ask-password-agent --list
linux-vmd4:~ #

And when I run “systemctl start /data/cripta1” I also get a wall on tty1
to enter the password via that agent - useless, as I’m using an ssh
session on the host, ie, I’m accessing remotely.

Well … wall is wall, it walls on all logged in terminals. How should
you otherwise know there is password request?

How does it knows that it is telling me only? It is telling it to all
users, and only one knows the password.

Well … I guess it was the most straightforward way to implement and nobody objected so far.

But consider that a) encrypted container is set up by background service and b) it may not be started due to explicit user request but indirectly as requirement for some other service. So how would systemd know who to ask in this case? It can just announce that password is needed and hope someone will provide it.

And it doesn’t say what command
to type to enter the password.

Sorry? “Please enter password with the systemd-tty-ask-password-agent tool”. It names exact command to use.

I would prefer it to ask me on only on the boot terminal. If that fails,
don’t ask again, die.

The workflow is agent-oriented. It is assumed there is some agent started as part of user session that intercepts password requests and provides nice GUI

You can of course stop systemd-ask-password-wall.service, but then you may never know you need password unless there is session level agent.

Ok, so how do I stop both?

linux-vmd4:~ # systemctl start v1.mount
Please enter passphrase for disk VMware_Virtual_S (cr_sde1) on /v1! *****
linux-vmd4:~ # grep cr_sde1 /proc/mounts
/dev/mapper/cr_sde1 /v1 ext4 rw,relatime,data=ordered 0 0
linux-vmd4:~ # ll /dev/mapper
total 0
crw------- 1 root root 10, 236 May  6 12:12 control
lrwxrwxrwx 1 root root       7 May  6 14:25 cr_sde1 -> ../dm-0
linux-vmd4:~ # systemctl stop systemd-cryptsetup@cr_sde1.service
linux-vmd4:~ # grep cr_sde1 /proc/mounts
linux-vmd4:~ # ll /dev/mapper
total 0
crw------- 1 root root 10, 236 May  6 12:12 control

On 2013-05-06 12:36, arvidjaar wrote:
>
> robin_listas;2554199 Wrote:
>>
>>> When starting the service that requested password times out, password
>>> request is canceled.
>>
>> It did not, it said that a password was pending but did not ask for it.
>> And it repeats that on every terminal every few minutes, disrupting
>> work.
> Hmm … I tested it and I got single broadcast (wall) after system
> reached run level 3. So there may be other conditions when it is
> repeated non-stop.

Dunno.

I did not wait long enough this time for the repeat. The repeat
situation happened months ago. I assumed that it was going to happen
again, did not wait long enough to verify.

>>>> And when I run “systemctl start /data/cripta1” I also get a wall on tty1
>>>> to enter the password via that agent - useless, as I’m using an ssh
>>>> session on the host, ie, I’m accessing remotely.>
>>> Well … wall is wall, it walls on all logged in terminals. How should
>>> you otherwise know there is password request?>
>>
>> How does it knows that it is telling me only? It is telling it to all
>> users, and only one knows the password.
> Well … I guess it was the most straightforward way to implement and
> nobody objected so far.
>
> But consider that a) encrypted container is set up by background
> service and b) it may not be started due to explicit user request but
> indirectly as requirement for some other service. So how would systemd
> know -who- to ask in this case? It can just announce that password is
> needed and hope someone will provide it.

Ok, that’s a a valid point.

But it is not my situation: I decide when to mount encrypted partitions,
so I do not want a wall if somebody else “borrows” my laptop.

So, what can I do so that I get prompted for the password at boot, as I
get now, but never again unless I do it myself? Should I just edit the
/usr/lib/systemd/system/systemd-ask-password-wall.service file and
remove the “–wall” option from it?

>> And it doesn’t say what command
>> to type to enter the password.
>
> Sorry? “Please enter password with the systemd-tty-ask-password-agent
> tool”. It names exact command to use.

As I posted on my first message, that does not work. I typed that exact
command and got nothing, just the shell prompt back. It does not say
that you have to add the option “–query” in order to get a prompt for
the password.

>> I would prefer it to ask me on only on the boot terminal. If that fails,
>> don’t ask again, die.
>
> The workflow is agent-oriented. It is assumed there is some agent
> started as part of user session that intercepts password requests and
> provides nice GUI
>
> You can of course stop systemd-ask-password-wall.service, but then you
> may never know you need password unless there is session level agent.

But the agent does not work in text mode!

To clarify: I get the WALL telling me to enter the password with the
agent, but there is nowhere to type the password. Then, I have to run:


systemd-tty-ask-password-agent --query

in order to type the password.

Ok, so how do I stop both?

Code:

linux-vmd4:~ # systemctl start v1.mount

Please enter passphrase for disk VMware_Virtual_S (cr_sde1) on /v1! *****
linux-vmd4:~ # grep cr_sde1 /proc/mounts
/dev/mapper/cr_sde1 /v1 ext4 rw,relatime,data=ordered 0 0
linux-vmd4:~ # ll /dev/mapper
total 0
crw------- 1 root root 10, 236 May 6 12:12 control
lrwxrwxrwx 1 root root 7 May 6 14:25 cr_sde1 → …/dm-0
linux-vmd4:~ # systemctl stop systemd-cryptsetup@cr_sde1.service
linux-vmd4:~ # grep cr_sde1 /proc/mounts
linux-vmd4:~ # ll /dev/mapper
total 0
crw------- 1 root root 10, 236 May 6 12:12 control


Ok, let’s try:



> eleanor3:~ # systemctl status {TAB}{TAB} ... no completion.
>
> eleanor3:~ # ls /data/cripta {TAB}{TAB}
> cripta1/ cripta2/
> eleanor3:~ # ls /data/cripta1
> lost+found
> eleanor3:~ # systemctl status /data/cripta1
> data-cripta1.mount - /data/cripta1
>           Loaded: loaded (/etc/fstab)
>           Active: active (mounted) since Mon, 2013-05-06 02:05:51 CEST; 12h ago
>            Where: /data/cripta1
>             What: /dev/mapper/cr_data_cripta1
>          Process: 3230 ExecMount=/bin/mount /dev/mapper/cr_data_cripta1 /data/cripta1 -t ext4 -o noatime,acl,user_xattr,nofail (code=exited, status=0/SUCCESS)
>           CGroup: name=systemd:/system/data-cripta1.mount
>
> May 06 02:05:51 eleanor3.valinor systemd[1]: Mounting /data/cripta1...
> May 06 02:05:51 eleanor3.valinor systemd[1]: Mounted /data/cripta1.
> eleanor3:~ # systemctl stop /data/cripta1
> eleanor3:~ # systemctl stop systemd-cryptsetup{TAB}{TAB}@cr_data_cripta1.service
> eleanor3:~ # systemctl start /data/cripta1
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta1) on /data/cripta1! ***********
> eleanor3:~ #


Well, deactivating needs two commands. Activating just one.

I agree that it is useful to be able to just umount the mount (to do a
manual fsck, for instance), but that’s something I can do for myself
with a simple “umount partition”, as in any Unix/Linux system; so I do
not see the need for a new command to do it - unless that one also does
something extra, like removing the encrypted mapped device.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Ehh … that’s exactly what happens right now. You never get prompted for password; you get information that there are pending password requests. That’s not the same as being “prompted for”.

Should I just edit the
/usr/lib/systemd/system/systemd-ask-password-wall.service file and
remove the “–wall” option from it?

You can just mask this service so it never runs. In this case default service that displays prompt on boot terminal remains active.

>
> Sorry? “Please enter password with the systemd-tty-ask-password-agent
> tool”. It names exact command to use.

As I posted on my first message, that does not work. I typed that exact
command and got nothing, just the shell prompt back.

Is it also your experience from the past? It works as long as there is pending password request. As I already said, when service stops, it should also cancel pending requests.

It does not say
that you have to add the option “–query” in order to get a prompt for
the password.

–query is default. You do not need this option.

linux-vmd4:~ # systemctl --no-ask-password start v1.mount

Broadcast message from root@linux-vmd4.site (Mon, 2013-05-06 17:14:56 MSK):

Password entry required for 'Please enter passphrase for disk VMware_Virtual_S (cr_sde1) on /v1!' (PID 1741).
Please enter password with the systemd-tty-ask-password-agent tool!


^C
linux-vmd4:~ # systemd-tty-ask-password-agent --list
'Please enter passphrase for disk VMware_Virtual_S (cr_sde1) on /v1!' (PID 1741)
linux-vmd4:~ # systemd-tty-ask-password-agent
Please enter passphrase for disk VMware_Virtual_S (cr_sde1) on /v1! *****
linux-vmd4:~ # systemctl status v1.mount
v1.mount - /v1
          Loaded: loaded (/etc/fstab)
          Active: active (mounted) since Mon, 2013-05-06 17:15:19 MSK; 2s ago
           Where: /v1
            What: /dev/mapper/cr_sde1
         Process: 1808 ExecMount=/bin/mount /dev/mapper/cr_sde1 /v1 -t ext4 -o noauto,acl,user_xattr (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/v1.mount

May 06 17:15:19 linux-vmd4.site systemd[1]: Mounted /v1.
linux-vmd4:~ #


I would prefer it to ask me on only on the boot terminal. If that fails,
don’t ask again, die.

The workflow is agent-oriented. It is assumed there is some agent
started as part of user session that intercepts password requests and
provides nice GUI

You can of course stop systemd-ask-password-wall.service, but then you
may never know you need password unless there is session level agent.

But the agent does not work in text mode!

I think at this point we need to stop and agree what “agent” means here. There is no background program started as part of text mode session that magically displays password prompt when needed. For a simple reason - there is no universal way to do it on text mode terminal.

To clarify: I get the WALL telling me to enter the password with the
agent, but there is nowhere to type the password. Then, I have to run:

systemd-tty-ask-password-agent --query

in order to type the password.

Right (except you do not need --query). And if you use systemctl to start encrypted container (directly or indirectly) it will ask you for password inline. I also demonstrated it above.

Well, deactivating needs two commands.

Deactivating needs **one **command as I demonstrated above. If you prefer to use two commands, it is up to you, but why you blame systemd for it?

On 2013-05-06 15:36, arvidjaar wrote:
>
> robin_listas;2554276 Wrote:
>>
>> So, what can I do so that I get prompted for the password at boot, as I
>> get now, but never again unless I do it myself?
> Ehh … that’s exactly what happens right now. You never get prompted
> for password; you get information that there are pending password
> requests. That’s not the same as being “prompted for”.

Well, it’s a different interpretation :slight_smile:

>> Should I just edit the
>> /usr/lib/systemd/system/systemd-ask-password-wall.service file and
>> remove the “–wall” option from it?
> You can just mask this service so it never runs. In this case default
> service that displays prompt on boot terminal remains active.

Would that be:


eleanor3:~ # systemctl mask systemd-ask-password-wall
ln -s '/dev/null' '/etc/systemd/system/systemd-ask-password-wall.service'
eleanor3:~ #

?

I have done that and rebooted, entering 3 times the wrong password. I
see that “systemd-tty-ask-password-agent --watch --console” is active.
No warning about password yet.

After some minutes, I run



> eleanor3:~ # systemctl start systemd-cryptsetup@cr_data_cripta1.service
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta1) on /data/cripta1! ***********
> eleanor3:~ # ls /data/cripta1/
> lost+found
> eleanor3:~ #


This I run on the ssh session - however, I get some extra output on tty1
about systemd-fsck running on the partition.

I now try for the other partition:



> eleanor3:~ # systemctl start systemd-cryptsetup@cr_data_cripta2.service
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta2) on /data/cripta2! ************
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta2) on /data/cripta2! ***********
> eleanor3:~ # ls /data/cripta2
> not_mounted
> eleanor3:~ # mount /data/cripta2
> eleanor3:~ # ls /data/cripta2
> lost+found
> eleanor3:~ #


Notice that partition 1 was mounted automatically, but not the second.
Also, there was no fsck.

Sorry? “Please enter password with the systemd-tty-ask-password-agent
tool”. It names exact command to use.>

As I posted on my first message, that does not work. I typed that exact
command and got nothing, just the shell prompt back.

Is it also your experience from the past?

Yes, I tested this in 12.2 as well, when it came out.

It works as long as there
is pending password request.

There is a pending password request.

As I already said, when service stops, it
should also cancel pending requests.

Maybe I did not wait long enough to see if that happens.

It does not say
that you have to add the option “–query” in order to get a prompt for
the password.
–query is default. You do not need this option.

Yes you do. See my first post, I did just that and it did not prompt for
the password, it is there. Read that post carefully, please.

I can not replicate it again as I disabled the systemd-ask-password-wall
service above.

Ok, I rebooted and tried again. It works without the --query if I do it
fast. If I wait several minutes, it doesn’t.

I would prefer it to ask me on only on the boot terminal. If that fails,
don’t ask again, die.>

The workflow is agent-oriented. It is assumed there is some agent
started as part of user session that intercepts password requests and
provides nice GUI

You can of course stop systemd-ask-password-wall.service, but then you
may never know you need password unless there is session level agent.

But the agent does not work in text mode!
I think at this point we need to stop and agree what “agent” means
here. There is no background program started as part of text mode
session that magically displays password prompt when needed. For a
simple reason - there is no universal way to do it on text mode
terminal.

Well, then the message is unclear.

To clarify: I get the WALL telling me to enter the password with the
agent, but there is nowhere to type the password. Then, I have to run:

Code:

systemd-tty-ask-password-agent --query


in order to type the password.
Right (except you do not need --query). And if you use systemctl to
start encrypted container (directly or indirectly) it will ask you for
password inline. I also demonstrated it above.

Yes, I do need the “–query”. If I don’t use it, I get the wall message
with no prompt for the password.

I have tried this several times.

Well, deactivating needs two commands.
Deactivating needs *one *command as I demonstrated above. If you prefer
to use two commands, it is up to you, but why you blame systemd for it?

Please note that it is you who says that I’m blaming systemd.
I’m merely asking questions, and you are getting defensive.

Right, it works with one command, this:


eleanor3:~ # systemctl stop systemd-cryptsetup@cr_data_cripta1.service
eleanor3:~ # ls /data/cripta1
not_mounted
eleanor3:~ #

However.

With the second encrypted partition,


systemctl start systemd-cryptsetup@cr_data_cripta2.service

does not mount the partition. I have to use:



> eleanor3:~ # systemctl start /data/cripta2
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta2) on /data/cripta2! ***********
> eleanor3:~ # ls /data/cripta2
> lost+found
> eleanor3:~ # systemctl stop systemd-cryptsetup@cr_data_cripta2.service
> eleanor3:~ # ls /data/cripta2
> not_mounted
> eleanor3:~ #


And it does no fsck that I can see.

I have to use different services for starting and stopping. However, for
the first partition, I can do:



> eleanor3:~ # systemctl start systemd-cryptsetup@cr_data_cripta1.service
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta1) on /data/cripta1! ***********
> eleanor3:~ # ls /data/cripta1
> lost+found
> eleanor3:~ # systemctl stop systemd-cryptsetup@cr_data_cripta1.service
> eleanor3:~ # ls /data/cripta1
> not_mounted
> eleanor3:~ #


Not very consistent, eh?

I altered fstab to request fsck, no go.



> /etc/fstab
>
> /dev/mapper/cr_data_cripta1     /data/cripta1   ext4            noatime,acl,user_xattr,nofail 0 3
> /dev/mapper/cr_data_cripta2     /data/cripta2   ext4            noatime,noauto,acl,user_xattr,nofail 0 3
>
> /etc/crypttab:
>
> cr_data_cripta1 /dev/sda7            none       none
> cr_data_cripta2 /dev/sda8            none       noauto



Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

I cannot “Reply with quote” to this message - I get empty text field. Tried with two different browsers …

Would that be

Yes, something like this.

Not very consistent, eh?

Consistency is in the eyes of beholder …

But it demonstrates interesting point that I did not notice before. systemd interpretation of “auto” in /etc/fstab (resp. lack of “noauto”) is - mount filesystem when device becomes available. Which is consistent with idea of dynamic event driven service manager. Now, for most cases devices appear just once on boot and never disappear again, so it looks like good old “mount on boot” semantic. But here you have device that comes later. In your example /data/cripta1 is set to automount and /data/cripta2 not and systemd behaves accordingly.

Thank you for this excellent test case.

It works without the --query if I do it fast. If I wait several minutes, it doesn’t.

Could you show log where systemd-tty-ask-password-agent does not work but “systemd-tty-ask-password-agent --query” immediately following it works? And explain step by step what you did?

–query is default, whether you believe it or not and I would be interested to understand the difference you describe.

I can not replicate it again as I disabled the systemd-ask-password-wall service above.

Do not be confused. systemd-ask-password-wall has very little to do with systemd-tty-ask-password-agent and systemd-tty-ask-password-agent does not need systemd-ask-password-wall.

On 2013-05-06 21:26, arvidjaar wrote:
>
> I cannot “Reply with quote” to this message - I get empty text field.
> Tried with two different browsers …

I read some one just commenting about having to disable javascript. As I
use nntp, I do not notice.

>> Would that be
> Yes, something like this.
>
>> Not very consistent, eh?
> Consistency is in the eyes of beholder …
>
> But it demonstrates interesting point that I did not notice before.
> systemd interpretation of “auto” in /etc/fstab (resp. lack of “noauto”)
> is - mount filesystem when device becomes available. Which is consistent
> with idea of dynamic event driven service manager. Now, for most cases
> devices appear just once on boot and never disappear again, so it looks
> like good old “mount on boot” semantic. But here you have device that
> comes later. In your example /data/cripta1 is set to automount and
> /data/cripta2 not and systemd behaves accordingly.

I think I understand, kind of :slight_smile:

So perhaps it would work if I left ‘noauto’ in ‘crypttab’, and ‘auto’ in
fstab :-?

> Thank you for this excellent test case.

Welcome!

That’s what I’m doing, testing situations for when I upgrade my 12.1
system to 12.3 soon.

Notice that, if you did not see it on the first post, that I removed
plymouth right from the initial yast window. Reasons are several: one, I
boot to text mode, and I want to see messages going by, no splash
display whatsoever. I still have to modify grub for this to be to my
liking, but that is waiting in the to·do list (I’m not familiar with
grub2). Second, I use separate /boot partitions, of 200 MB. I upgrade,
not install fresh, so they have to stay. 200 MB was ample space not long
ago, now it is scarce with 3 kernels and plymouth in initrd.

After boot completes, I log in, do a few things if needed, and then run
“init 5”. Subsequently, the system is hybernated, never rebooted till
absolutely necessary.

I mention this because perhaps the “agent” is normally handled by
plymouth. I do not know.

Another peculiarity is that I use a separate /usr partition. This I’m
emulating in this 12.3 virtual system I’m using for the tests, except
that I do not use a separate /boot here.

>> It works without the --query if I do it fast. If I wait several minutes,
>> it doesn’t.
> Could you show log where systemd-tty-ask-password-agent does not work
> but “systemd-tty-ask-password-agent --query” immediately following it
> works? And explain step by step what you did?

Well, the details are in the first post. Look at it, the wall happens at
2013-05-05 23:45:48.

See that sometime later I run - exact time unknown:


eleanor3:~ # systemd-tty-ask-password-agent
eleanor3:~ #

See? no password prompt.

The logs for that period are:



> <3.6> 2013-05-05 23:45:48 eleanor3 systemd 1 - -  Expecting device dev-mapper-cr_data_cripta1.device...
> <3.6> 2013-05-05 23:45:48 eleanor3 systemd 1 - -  Starting Cryptography Setup for cr_data_cripta1...
> <3.6> 2013-05-05 23:45:48 eleanor3 systemd 1 - -  Starting Cleanup of Temporary Directories...
> <3.6> 2013-05-05 23:45:48 eleanor3 systemd 1 - -  Started Forward Password Requests to Wall.
> <3.4> 2013-05-05 23:45:48 eleanor3 systemd-tmpfiles 3239 - -  Two or more conflicting lines for /tmp/systemd-private-* configured, ignoring.
> <3.4> 2013-05-05 23:45:48 eleanor3 systemd-tmpfiles 3239 - -  Two or more conflicting lines for /var/tmp/systemd-private-* configured, ignoring.
> <3.6> 2013-05-05 23:45:48 eleanor3 systemd 1 - -  Started Cleanup of Temporary Directories.
> <3.4> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Job dev-mapper-cr_data_cripta1.device/start timed out.
> <3.3> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Timed out waiting for device dev-mapper-cr_data_cripta1.device.
> <3.3> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Dependency failed for Cryptography Setup for cr_data_cripta1.
> <3.5> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Job systemd-cryptsetup@cr_data_cripta1.service/start failed with result 'dependency'.
> <3.3> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Dependency failed for /data/cripta1.
> <3.5> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Job data-cripta1.mount/start failed with result 'dependency'.
> <3.3> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Dependency failed for File System Check on /dev/mapper/cr_data_cripta1.
> <3.5> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Job systemd-fsck@dev-mapper-cr_data_cripta1.service/start failed with result 'dependency'.
> <3.5> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Job dev-mapper-cr_data_cripta1.device/start failed with result 'timeout'.
> <3.5> 2013-05-05 23:47:18 eleanor3 systemd-cryptsetup 3238 - -  Timed out
> <3.3> 2013-05-05 23:47:18 eleanor3 systemd-cryptsetup 3238 - -  Failed to query password: Timer expired
> <3.5> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  systemd-cryptsetup@cr_data_cripta1.service: main process exited, code=exited, status=1/FAILURE
> <3.5> 2013-05-05 23:47:18 eleanor3 systemd 1 - -  Unit systemd-cryptsetup@cr_data_cripta1.service entered failed state


See the timer expired entries, that’s probably the reason that
“systemd-tty-ask-password-agent” failed to ask for the pasword - just
guessing.

There are no more systemd entries in the log for a while, till what I
post below.

See later on the same post a paragraph that contains this text:


Active: active (mounted) since Mon, 2013-05-06 00:13:57 CEST; 3s ago

This matches with this section of the log later:



> <3.6> 2013-05-06 00:13:25 eleanor3 systemd 1 - -  Reloading.
> <3.6> 2013-05-06 00:13:47 eleanor3 systemd 1 - -  Starting Cryptography Setup for cr_data_cripta1...
> <3.6> 2013-05-06 00:13:47 eleanor3 systemd 1 - -  Expecting device dev-mapper-cr_data_cripta1.device...
> <3.6> 2013-05-06 00:13:47 eleanor3 systemd 1 - -  Started Forward Password Requests to Wall.
> <3.6> 2013-05-06 00:13:55 eleanor3 systemd 1 - -  last message repeated 2 times
> <3.6> 2013-05-06 00:13:55 eleanor3 systemd-cryptsetup 3332 - -  Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda7.
> <3.5> 2013-05-06 00:13:56 eleanor3 modprobe - - -  FATAL: Error inserting padlock_sha (/lib/modules/3.7.10-1.1-desktop/kernel/drivers/crypto/padlock-sha.ko): No such device
> <0.6> 2013-05-06 00:13:56 eleanor3 kernel - - -  2584.502406] bio: create slab <bio-1> at 1
> <0.6> 2013-05-06 00:13:56 eleanor3 kernel - - -  2584.705460] bio: create slab <bio-1> at 1
> <3.6> 2013-05-06 00:13:56 eleanor3 systemd 1 - -  Started Cryptography Setup for cr_data_cripta1.
> <3.6> 2013-05-06 00:13:56 eleanor3 systemd 1 - -  Found device /dev/mapper/cr_data_cripta1.
> <3.6> 2013-05-06 00:13:56 eleanor3 systemd 1 - -  Starting File System Check on /dev/mapper/cr_data_cripta1...
> <3.6> 2013-05-06 00:13:56 eleanor3 systemd-fsck 3375 - -  /dev/mapper/cr_data_cripta1: clean, 11/102000 files, 23388/406528 blocks
> <3.6> 2013-05-06 00:13:56 eleanor3 systemd 1 - -  Started File System Check on /dev/mapper/cr_data_cripta1.
> <3.6> 2013-05-06 00:13:56 eleanor3 systemd 1 - -  Mounting /data/cripta1...
> <0.6> 2013-05-06 00:13:57 eleanor3 kernel - - -  2584.897747] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr
> <3.6> 2013-05-06 00:13:57 eleanor3 systemd 1 - -  Mounted /data/cripta1.


That’s when I succeeded to mount the encrypted partition first.

At about 2:00 AM I reboot and try again, just after nrickert’s post. The
log is this:



> <3.6> 2013-05-06 02:04:52 eleanor3 systemd 1 - -  Startup finished in 3s 848ms 476us (kernel) + 49s 685ms 82us (userspace) = 53s 533ms 558us.
> <3.6> 2013-05-06 02:05:02 eleanor3 systemd 1 - -  Starting Stop Read-Ahead Data Collection...
> <3.6> 2013-05-06 02:05:02 eleanor3 systemd 1 - -  Started Stop Read-Ahead Data Collection.
> <10.6> 2013-05-06 02:05:03 eleanor3 login - - -  pam_unix(login:session): session opened for user root by LOGIN(uid=0)
> <10.3> 2013-05-06 02:05:03 eleanor3 login - - -  pam_apparmor(login:session): Unknown error occurred changing to root hat: Operation not permitted
> <0.4> 2013-05-06 02:05:03 eleanor3 kernel - - -    64.692192] audit_printk_skb: 60 callbacks suppressed
> <0.5> 2013-05-06 02:05:03 eleanor3 kernel - - -    64.692195] type=1400 audit(1367798703.405:32): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 pid=2803 c
> omm="login"
> <4.6> 2013-05-06 02:05:03 eleanor3 systemd-logind 650 - -  New session 1 of user root.
> <3.6> 2013-05-06 02:05:03 eleanor3 dbus-daemon 672 - -  dbus[672]: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service'
> <3.5> 2013-05-06 02:05:03 eleanor3 dbus 672 - -  [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service'
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Expecting device dev-mapper-cr_data_cripta1.device...
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Starting Cryptography Setup for cr_data_cripta1...
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Starting Console Manager...
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Started Forward Password Requests to Wall.
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Started Forward Password Requests to Wall.
> <3.6> 2013-05-06 02:05:03 eleanor3 dbus-daemon 672 - -  dbus[672]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
> <3.5> 2013-05-06 02:05:03 eleanor3 dbus 672 - -  [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Starting Authorization Manager...
> <3.6> 2013-05-06 02:05:03 eleanor3 polkitd 3101 - -  Started polkitd version 0.110
> <10.5> 2013-05-06 02:05:03 eleanor3 polkitd 3101 - -  Loading rules from directory /etc/polkit-1/rules.d
> <10.5> 2013-05-06 02:05:03 eleanor3 polkitd 3101 - -  Loading rules from directory /usr/share/polkit-1/rules.d
> <10.5> 2013-05-06 02:05:03 eleanor3 polkitd 3101 - -  Finished loading, compiling and executing 3 rules
> <3.6> 2013-05-06 02:05:03 eleanor3 dbus-daemon 672 - -  dbus[672]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
> <3.5> 2013-05-06 02:05:03 eleanor3 dbus 672 - -  [system] Successfully activated service 'org.freedesktop.PolicyKit1'
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Started Authorization Manager.
> <10.5> 2013-05-06 02:05:03 eleanor3 polkitd 3101 - -  Acquired the name org.freedesktop.PolicyKit1 on the system bus
> <3.6> 2013-05-06 02:05:03 eleanor3 dbus-daemon 672 - -  dbus[672]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
> <3.5> 2013-05-06 02:05:03 eleanor3 dbus 672 - -  [system] Successfully activated service 'org.freedesktop.ConsoleKit'
> <3.6> 2013-05-06 02:05:03 eleanor3 systemd 1 - -  Started Console Manager.
> <10.5> 2013-05-06 02:05:04 eleanor3 login - - -  ROOT LOGIN ON tty1
> <4.6> 2013-05-06 02:05:09 eleanor3 sshd 3156 - -  Postponed keyboard-interactive for root from 192.168.74.1 port 54690 ssh2 [preauth]
> <4.6> 2013-05-06 02:05:15 eleanor3 sshd 3156 - -  Postponed keyboard-interactive/pam for root from 192.168.74.1 port 54690 ssh2 [preauth]
> <4.6> 2013-05-06 02:05:15 eleanor3 sshd 3156 - -  Accepted keyboard-interactive/pam for root from 192.168.74.1 port 54690 ssh2
> <10.6> 2013-05-06 02:05:15 eleanor3 sshd 3156 - -  pam_unix(sshd:session): session opened for user root by (uid=0)
> <10.3> 2013-05-06 02:05:15 eleanor3 sshd 3156 - -  pam_apparmor(sshd:session): Unknown error occurred changing to root hat: Operation not permitted
> <0.5> 2013-05-06 02:05:15 eleanor3 kernel - - -    76.398305] type=1400 audit(1367798715.128:33): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 pid=3156 comm="sshd"
> <4.6> 2013-05-06 02:05:15 eleanor3 systemd-logind 650 - -  New session 2 of user root.
> <3.6> 2013-05-06 02:05:50 eleanor3 systemd-cryptsetup 3036 - -  Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda7.
> <0.6> 2013-05-06 02:05:51 eleanor3 kernel - - -   112.614497] bio: create slab <bio-1> at 1
> <0.6> 2013-05-06 02:05:51 eleanor3 kernel - - -   112.781315] bio: create slab <bio-1> at 1
> <3.6> 2013-05-06 02:05:51 eleanor3 systemd 1 - -  Started Cryptography Setup for cr_data_cripta1.
> <3.6> 2013-05-06 02:05:51 eleanor3 systemd 1 - -  Found device /dev/mapper/cr_data_cripta1.
> <3.6> 2013-05-06 02:05:51 eleanor3 systemd 1 - -  Starting File System Check on /dev/mapper/cr_data_cripta1...
> <3.6> 2013-05-06 02:05:51 eleanor3 systemd-fsck 3224 - -  /dev/mapper/cr_data_cripta1: clean, 11/102000 files, 23388/406528 blocks
> <3.6> 2013-05-06 02:05:51 eleanor3 systemd 1 - -  Started File System Check on /dev/mapper/cr_data_cripta1.
> <3.6> 2013-05-06 02:05:51 eleanor3 systemd 1 - -  Mounting /data/cripta1...
> <3.5> 2013-05-06 02:05:51 eleanor3 systemd 1 - -  data-cripta1.mount: Directory /data/cripta1 to mount over is not empty, mounting anyway. (To see the over-mounted files, please manually mount the underlying file system to a secondary location.)
> <0.6> 2013-05-06 02:05:51 eleanor3 kernel - - -   112.977643] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr
> <3.6> 2013-05-06 02:05:51 eleanor3 systemd 1 - -  Mounted /data/cripta1.
> <0.5> 2013-05-06 02:15:02 eleanor3 kernel - - -   662.462065] type=1400 audit(1367799302.004:34): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 pid=3273 comm="cron"


As you can see in my response to him, I used
“systemd-tty-ask-password-agent --query”.

I can repeat the testing in another manner, taking note of times, if you
tell me what to test exactly.

> --query is default, whether you believe it or not and I would be
> interested to understand the difference you describe.

Well, see above, the first post, it failed silently. And with --query,
it worked when I tried two hours later. Maybe there is a time interval
in which it works.

>> I can not replicate it again as I disabled the systemd-ask-password-wall
>> service above.
> Do not be confused. systemd-ask-password-wall has very little to do
> with systemd-tty-ask-password-agent and systemd-tty-ask-password-agent
> does not need systemd-ask-password-wall.

Ok. Good :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

What is “it”? I’m not sure I understand what you are trying to achieve.

Notice that, if you did not see it on the first post,

I did.

Well, see above, the first post, it failed silently. And with --query,
it worked when I tried two hours later.

This is misinterpretation. The first time command invocation without --query did nothing because service start already timed out and password request was cancelled. Invocation with --query would have done nothing as well. The second time invocation with --query succeeded because service was still activating. Invocation without --query would have succeeded as well.

Unless you demonstrate that two invocations (with and wihout --query) behave differently under the same conditions I do not see anything unusual.

On 2013-05-07 07:56, arvidjaar wrote:
>
> robin_listas;2554423 Wrote:
>>
>> So perhaps it would work if I left ‘noauto’ in ‘crypttab’, and ‘auto’
>> in
>> fstab :-?
> What is “it”? I’m not sure I understand what you are trying to achieve.

Activating and deactivating both partitions with the same commands.
Currently “systemctl start systemd-cryptsetup@cr_data_cripta2.service”
does not mount it (and maybe does not fsck it).

>> Well, see above, the first post, it failed silently. And with --query,
>> it worked when I tried two hours later.
>
> This is misinterpretation. The first time command invocation without
> --query did nothing because service start already timed out and password
> request was cancelled. Invocation with --query would have done nothing
> as well. The second time invocation with --query succeeded because
> service was still activating. Invocation without --query would have
> succeeded as well.

It may be possible.

I did another test. I reactivated the wall service (systemctl unmask
systemd-ask-password-wall) and rebooted. Did nothing for many minutes. I
did not get the wall message, though. Then I tried:



> eleanor3:~ # ps afxu | grep agent
> root      3145  0.0  0.1   7088   860 pts/0    S+   15:45   0:00          \_ grep --color=auto agent
> root      2811  0.0  0.1  12744   904 ?        Ss   15:19   0:00 /usr/bin/systemd-tty-ask-password-agent --wall
> eleanor3:~ # systemd-tty-ask-password-agent
> eleanor3:~ # systemd-tty-ask-password-agent --query
> eleanor3:~ # ps afxu | grep agent
> root      3149  0.0  0.1   7088   860 pts/0    S+   15:49   0:00          \_ grep --color=auto agent
> root      2811  0.0  0.1  12744   904 ?        Ss   15:19   0:00 /usr/bin/systemd-tty-ask-password-agent --wall
> eleanor3:~ #


So that command only works withing a time frame. You are right there.

Notice, however, that I do not get the “wall”, even after activating the
“wall” service and rebooting. Thus I can not test if using
“systemd-tty-ask-password-agent” just after seeing the wall works or not.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On 2013-05-07 17:03, Carlos E. R. wrote:
> On 2013-05-07 07:56, arvidjaar wrote:
>> >
>> > robin_listas;2554423 Wrote:
>>> >>
>>> >> So perhaps it would work if I left ‘noauto’ in ‘crypttab’, and ‘auto’
>>> >> in fstab :-?
>> > What is “it”? I’m not sure I understand what you are trying to achieve.
> Activating and deactivating both partitions with the same commands.
> Currently “systemctl start systemd-cryptsetup@cr_data_cripta2.service”
> does not mount it (and maybe does not fsck it).

Ok, I did this change:



> fstab:
>
> /dev/mapper/cr_data_cripta1     /data/cripta1   ext4            noatime,acl,user_xattr,nofail 0 3
> #/dev/mapper/cr_data_cripta2    /data/cripta2   ext4            noatime,noauto,acl,user_xattr,nofail 0 3
> /dev/mapper/cr_data_cripta2     /data/cripta2   ext4            noatime,acl,user_xattr,nofail 0 3
>
>
> /etc/crypttab
> cr_data_cripta1 /dev/sda7            none       none
> cr_data_cripta2 /dev/sda8            none       noauto


however:



> eleanor3:~ # systemd-tty-ask-password-agent
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta1) on /data/cripta1! ***********
> Please enter passphrase for disk VMware_Virtual_S (cr_data_cripta2) on /data/cripta2! ***********
> eleanor3:~ # ls /data/cripta2/
> lost+found
> eleanor3:~ #


Both are mounted. So I need “noauto” both in crypttab and fstab, and
live with the two different commands to activate them. And perhaps do
fsck manually on the second one.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Partition or mounted filesystem?

I do not think there universal way to do it using systemctl. You activate filesystem using “systemctl start foo.mount”, which in this case implicitly configures encrypted container, does fsck and mount filesystem. And if you want to completely tear down encrypted container you do it using “systemctl stop systemd-cryptsetup@container.service” which implicitly unmounts filesystem if it is currently mounted.

On 2013-05-07 17:56, arvidjaar wrote:
>
> robin_listas;2554644 Wrote:
>>
>> Activating and deactivating both partitions with the same commands.
>
> Partition or mounted filesystem?

In this case partition. The other case will come later, I have not tried
loop mounted encrypted filesystems yet.

> I do not think there universal way to do it using systemctl. You
> activate filesystem using “systemctl start foo.mount”, which in this
> case implicitly configures encrypted container, does fsck and mount
> filesystem. And if you want to completely tear down encrypted container
> you do it using “systemctl stop systemd-cryptsetup@container.service”
> which implicitly unmounts filesystem if it is currently mounted.

Yes, I was finding that out. Thanks for writing it out so nicely :slight_smile:

I might create my own script to do those commands on the partitions I
use frequently, easier to remember.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)