Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#18930 - [network-manager-applet] Unable to access secrets service

Attached to Project: Arch Linux
Opened by Byron Clark (byronc) - Friday, 02 April 2010, 14:27 GMT
Last edited by Ionut Biru (wonder) - Sunday, 02 May 2010, 17:24 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Whenever I try to use nm-applet to connect to a VPN or a wireless network that requires a passphrase, I see this error in .xsession-errors:
** Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files


Additional info:
* package version(s)
network-manager-applet 0.8-2
gnome-keyring 2.30.0-1
libgnome-keyring 2.30.0-1
This task depends upon

Closed by  Ionut Biru (wonder)
Sunday, 02 May 2010, 17:24 GMT
Reason for closing:  Implemented
Additional comments about closing:  2.30.1-2
Comment by Byron Clark (byronc) - Friday, 02 April 2010, 14:29 GMT
I see that network-manager-applet 0.8-3 is sitting in the repositories, I rebuilt locally with the versioned dep change (gnome-keyring 2.28.0 -> 2.30.0) and am still seeing the same issue.

I can connect to the network after entering the key, but the key is never being saved and I need to enter it on each connection.
Comment by Byron Clark (byronc) - Friday, 02 April 2010, 14:46 GMT
I should note that I am using slim as a login manager instead of gdm, but I do have these entries in /etc/pam.d/slim:
auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start
Comment by Byron Clark (byronc) - Friday, 02 April 2010, 15:39 GMT
Adding this line to ~/.xinitrc fixes the problem and is probably the most correct solution:

eval $(gnome-keyring-daemon -s --components=pkcs11,secrets,ssh)

gdm appears to run similar commands automatically.
Comment by Ionut Biru (wonder) - Friday, 02 April 2010, 15:49 GMT Comment by Alphazo (alphazo) - Saturday, 03 April 2010, 09:18 GMT
Sorry for bugging you but the recommended fix doesn't work for me.

I've added:

eval $(gnome-keyring-daemon -s --components=pkcs11,secrets,ssh)

to ~/.xinitrc (before the exec command)

and also

auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start

to /etc/pam.d/slim (didn't have those lines) as suggested in the bug report but password are not remembered.

I have to go back to the less elegant way by modifying /usr/share/dbus-1/services/org.gnome.keyring.service.
This fix doesn't work for me. At that point I'm going back to the un-preferred way
Comment by Byron Clark (byronc) - Saturday, 03 April 2010, 12:54 GMT
@alphazo One more thing to try: you may want to change login_cmd in /etc/slim.conf to be something like this:

login_cmd exec ck-launch-session dbus-launch /bin/bash -login ~/.xinitrc %session >~/.xsession-errors 2>&1
Comment by Alphazo (alphazo) - Saturday, 03 April 2010, 18:00 GMT
@byronc Does this have to be applied in combination with the two above modifications (.xinitrc & /etc/pam.d/slim) ?

Should this be seen as a temporary of permanent fix?

Thanks
Alphazo
Comment by Byron Clark (byronc) - Saturday, 03 April 2010, 20:29 GMT
Adding the lines to ~/.xinitrc and /etc/pam.d/slim and the modification to /etc/slim.conf serve to make sure you have a dbus session (/etc/slim.conf), the default keyring gets unlocked (/etc/pam.d/slim), and that the secrets interface gets started (~/.xinitrc). If you used gdm, it would take care of starting the dbus session and then running everything in /etc/xdg/autostart for your desktop environment, which would include starting the secrets service if you were running gnome. The only reason that the secrets service has to be started from ~/.xinitrc (or /etc/xdg/autostart) is that network-manager now looks for org.freedesktop.secrets instead of org.gnome.keyring.
Comment by Alphazo (alphazo) - Saturday, 03 April 2010, 20:59 GMT
I will give your suggestion a try. In the meantime, please forgive my ignorance but I find that modifying three files is more intrusive than the alternative quick fix that involves only one file (/usr/share/dbus-1/services/org.gnome.keyring.service) and one replacement (Name=org.gnome.keyring by Name=org.freedesktop.secrets).
Comment by Byron Clark (byronc) - Saturday, 03 April 2010, 21:14 GMT
I agree that it's more work to set this up, but none of these files will be replaced on a package upgrade (without leaving a .pacnew). As for changing /usr/share/dbus-1/services/org.gnome.keyring.service, that works fine for a single user system or a system where everyone will use gnome-keyring for the secrets service. I think the upstream goal is to allow either gnome-keyring or kwallet to provide org.freedesktop.secrets so the correct service would need to be started at desktop start. My only goal here was to get the secrets service working as close to how gdm and gnome start it now. Any change to /usr/share/dbus-1/services/org.gnome.keyring.service will need to come from upstream.
Comment by Allan McRae (Allan) - Sunday, 04 April 2010, 08:41 GMT
> eval $(gnome-keyring-daemon -s --components=pkcs11,secrets,ssh)

You really do not need the "eval $( )" around that command.
Comment by Alphazo (alphazo) - Sunday, 04 April 2010, 09:06 GMT
@byronc Thank you. This is exactly the kind of information I was looking for. Should this fix be added to the Wiki for people installing ArchLinux with Slim and latest nm-applet? I'm in a process of converting a friend of mine to Arch but if he gets stuck with this he will probably give up so having it in the Wiki would prevent such (over)reaction. Cheers
Comment by Byron Clark (byronc) - Sunday, 04 April 2010, 14:34 GMT
@Allan the eval $() is necessary because I start the ssh component. Unless there is another way to get the SSH_AUTH_SOCK variable set using the output of the command.

% gnome-keyring-daemon -s --components=pkcs11,secrets,ssh
GNOME_KEYRING_CONTROL=/tmp/keyring-PQzMAK
SSH_AUTH_SOCK=/tmp/keyring-PQzMAK/ssh
Comment by Byron Clark (byronc) - Sunday, 04 April 2010, 20:36 GMT
export $() works even better if ssh-agent hasn't been started previously.
Comment by Allan McRae (Allan) - Monday, 05 April 2010, 00:57 GMT
I was fairly certain that the output was informational and the values were already set. But I do not use the ssh component so could be wrong.
Comment by Byron Clark (byronc) - Monday, 05 April 2010, 03:03 GMT
The GNOME_KEYRING_CONTROL is informational as that variable is set by the gnome-keyring pam module on login. The eval/export is needed to set SSH_AUTH_SOCK only if using the ssh component. So, yes, you are correct. As long as the ssh component of gnome-keyring is not used, the eval/export is unnecessary.
Comment by Karl Ljungkvist (havresylt) - Wednesday, 14 April 2010, 16:13 GMT
This solves the issue for me as well. I agree that this info should be going into the wiki somewhere, if no package update will fix it.
Comment by Frank Phillips (fphillips) - Sunday, 02 May 2010, 16:45 GMT
If it wasn't a bug, why did they fix it upstream?

https://bugzilla.gnome.org/show_bug.cgi?id=611002

http://git.gnome.org/browse/gnome-keyring/commit/?id=b36d6beeb2fa430210c8a2aa19f772bd75325e42
http://git.gnome.org/browse/gnome-keyring/commit/?id=d6bb94e9c05072fc791fb5045f5b1ab22d11d916

I just want to make it known in our bug report that there is a proper fix from upstream and that any workaround doesn't need to be permanent.

Loading...