| |||||||||||||
GNOME != FedoraGNOME != FedoraPosted Nov 4, 2011 23:33 UTC (Fri) by rqosa (subscriber, #24136)In reply to: GNOME != Fedora by jmorris42 Parent article: Rawhide gets GNOME Shell for all display types
> If they can't at least get […] the SSH Key Agent working right Have you tried putting eval `ssh-agent`into .xsession or .xinitrc?
(Log in to post comments)
GNOME != Fedora Posted Nov 9, 2011 3:12 UTC (Wed) by jmorris42 (subscriber, #2203) [Link]
> Have you tried putting...
Nah, it is far stranger than that. I'm the sorta dweeb who has the O'Reilly SSH book three feet away; I already tried the easy stuff. XFCE kinda sorta ties into the cool plumbing GNOME uses. So when I login it will load up the agent by itself without a separate password. Except it doesn't work... except when it does.
Open a terminal and type ssh hostname and that works as expected. Put a shortcut on the desktop that opens an ssh session in a terminal window and it will prompt for the keyring password. Open a terminal window first and then click on the shortcut and it will work. Put a more complex ssh invocation in a shortcut that invokes a remote X11 app (that works fine on GNOME2) and it won't work at all (doesn't invoke the graphical password gadget) unless you already have a manually opened window running AND you take the option to run it in a terminal. You get an extraneous empty xterm that way but it does work without prompting for a password.
Then some things in shortcuts just silently fail (no logs anywhere I can find) even if they only invoke curses apps in a terminal window. Things I would kinda like to have in a shortcut, like ipmiconsole. But if I open a terminal and manually type the command it works perfectly.
All I can conclude is something subtle is horked up after switching desktops and it might require nuking huge swaths of my dot files or a full reload of the OS to solve.
GNOME != Fedora Posted Nov 9, 2011 4:05 UTC (Wed) by raven667 (subscriber, #5198) [Link]
My only suggestion is to follow what is in the environment in all those cases, what is inherited from the desktop session and what is coming from .profile/.bashrc. What scripts get sourced for environment variables is different for interactive vs. non-interactive shells which might explain some of the weirdness You should be able to see the env for your desktop processes in /proc
GNOME != Fedora Posted Nov 9, 2011 16:13 UTC (Wed) by jmorris42 (subscriber, #2203) [Link]
Oh yea, SSH_AGENT isn't defined in the cases when it doesn't work. Good luck tracing the guts of a modern desktop to find out why though. And ssh-agent is correctly at the very apex of the process tree for a session so variables are being culled from the environment for some reason that isn't documented anywhere. I still haven't found a way to reliably launch a .desktop file from a command line so debugging options are limited. xdg-open is what Google turns up and it almost works but the failure modes on it differ so much that it obviously isn't what is at the base of either GNOME or XFCE's launch action.
Hmm. Now that ya have me looking again at the guts of the thing, I think the clue is in /etc/xdg/xfce4/xinitrc. Looks like it wants to use gpg-agent to do everything. And I have both it and ssh-agent running so bad things are almost certain to be happening. Will have to go slowly over it until it makes sense and figure out how to kill one of them off.
|
|||||||||||||