Arch Linux

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.

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

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.

maybe add this information to http://wiki.archlinux.org/index.php/Gnome_2.30_Changes

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

@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

@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

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.

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).

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.

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

You really do not need the "eval $( )" around that command.

@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

@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

export $() works even better if ssh-agent hasn't been started previously.

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.

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.

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.

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.