I recently purchased an Eee PC 1000HE. This is a very nice machine, and aside from one weird bug, Linux support is great. However, I’ve run into a very annoying problem with Fedora 10, and at the root of that problem is gnome-keyring-manager.
Misconfiguration Most Foul
We begin our tale with NetworkManager. Since I connect to several wireless networks and a VPN, NetworkManager is a very useful thing to have working. Its initial setup was great; I loaded nm-applet in my fluxbox startup, it prompted me for a default keyring password, and we were off.
However, on my next boot I was not prompted for my keyring password; I had to enter my WEP key manually. After some exploration, I learned that gnome-keyring-daemon needs to be running. The paradox is that it WAS running.
A Red Herring
I found some rather old advice thas suggested I run gnome-keyring-daemon manually from ~/.fluxbox/startup, but this didn’t work; gnome-keyring-daemon starts automatically in Fedora 10, thanks to pam_gnome_keyring.so. I now had two copies of the daemon now running, neither of which worked.
What I eventually discovered was this: if I kill the automatically-started gnome-keyring-daemon (or remove auto_start from the pam_gnome_keyring options in /etc/pam.d/kdm), then start it manually with different options, it works every time. So, instead of:
gnome-keyring-daemon -d –loginwhich is the automatically provided command, I ran:
gnome-keyring-daemon -f -c keyringfrom my fluxbox startup file. This worked, but turned out to be unnecessary.
An Anwser
My next discovery: If I disable the daemon’s automatic starting (once again by taking the auto_start option out of /etc/pam.d/kdm) and remove my custom invocation from the startup file, it still starts automatically, but with different options than the auto_start version! In fact, it starts with the options work.
It turns out that nm-applet and gnome-screensaver both automatically start gnome-keyring-daemon if it isn’t running. Since nm-applet runs first, it starts up the daemon, and passes it a completely different set of options than the pam-invoked version. Thanks for the consistency, gnome!
A Problem
Starting gnome-keyring-daemon manually or allowing nm-applet to start it still poses a problem: the daemon doesn’t die when I log out! This means that, as I log in and out several times, useless instances of the daemon end up sitting around doing nothing. Since the apps that talk to the daemon use $GNOME_KEYRING_SOCKET to do so, everything keeps working; but it’s cruft I’d rather not have.
Elementary
After following this circuitous path, I finally stumbled into the answer: it’s a known bug. It is actually related to the lack of a proper $DISPLAY getting set for gnome-keyring-daemon; it isn’t related to the passed in options at all.
At this point, I’m forced to fall back on a hack. I’ve added the following to my ~/.fluxbox/startup, above the gnome-related apps:
killall gnome-keyring-daemonI’ve also removed the auto_start option from /etc/pam.d/kdm. Unfortunately, not launching the daemon with pam means that I can’t take advantage of the single sign-on feature provided by pam_gnome_keyring. But until the bug is fixed, I guess this will have to be good enough.
(As for why I don’t use gdm, see this post)
Update: a command explained
If you look at the –help output for gnome-keyring-daemon (or, if you’ve applied my hack below, gnome-keyring-daemon-bin), you’ll see this output:
Usage:
gnome-keyring-daemon [OPTION…] - The Gnome Keyring Daemon
Help Options:
-?, –help Show help options
Application Options:
-f, –foreground Run in the foreground
-d, –daemonize Run as a daemon
-l, –login Use login password from stdin
-c, –components=ssh,keyring,pkcs11 The components to runAnyone acquainted with Linux will understand the first two options, -f and -d, pretty intuitively. You’ll note in my post above that my ‘working’ option set included -f; this is because -f prints to standard out, allowing us to capture the GNOME_KEYRING_SOCKET and GNOME_KEYRING_PID variables that the daemon spits out. However, when run in -d, these variable seem to get set correctly anyway. Further, the -c option I used in my quest seems superfluous; the daemon defaults to using the keyring component. I wanted to explain this since it wasn’t clear in the original post exactly why I bounced between options. At the time, I was grasping at straws, and assigned a simple correlation (the different command-line options in use) to a causation (the daemon that started automatically, with the different options, failed to work correctly).
The option that had me baffled, though, was –login. The information in the help output is cryptic, but I finally worked out its purpose; it allows single sign-on. pam_gnome_keyring passes your login password to gnome-keyring-daemon, which uses it to unlock a special keyring called the login keyring. This keyring can then be used to store the passwords to your other keyrings, so that when you log in, everything unlocks automatically. Your system login doubles as your keyring authentication.
Further Update: Eureka! (or: building a better hack)
Based on a comment in the bugzilla entry for this problem, I have crafted a better (if more system-intrusive) hack. I simply perform the following:
mv /usr/bin/gnome-keyring-daemon /usr/bin/gnome-keyring-daemon-bin
touch /usr/bin/gnome-keyring-daemon
chmod 755 /usr/bin/gnome-keyring-daemon
cat > /usr/bin/gnome-keyring-daemon << EOF
#!/bin/sh
DISPLAY=":0.0" /usr/bin/gnome-keyring-daemon-bin "$@"
EOFThis hack creates a wrapper script that sets the $DISPLAY variable before running the keyring daemon. Until this kdm bug is worked out, this hack performs beautifully.