Hi! Is it possible to add soemthing like: SSH_AGENT=" " if [ -f ${HOME}/.ssh/identity ]; then SSH_AGENT=" ssh-agent1 " fi if [ -f ${HOME}/.ssh2/identification ]; then SSH_AGENT=" ssh-agent $SSH_AGENT " fi and then replace each exec by exex $SSH_AGENT in order to have Xsession compliance with ssh/ssh2 ? TIA, Jacek
seems like a reasonable idea.
now that we support the /etc/X11/xinit/xinitrc.d directory in 6.2 (analogous to /etc/profile.d), we should have the person who maintains the ssh RPMs drop a script in there to do this. I suggest that you forward this information to the maintainer.
The new "/etc/X11/xinit/xinitrc.d" directory is a good place for drop-in additions. Unfortunately, it is not quite sufficient in this case. The "ssh-agent" process really wants to be the ancestor of the rest of your X session. That requires a changes to the Xsession script itself. For example, where the Xsession script currently has "exec gnome-session" you want "exec ssh-agent gnome-session". Same goes for all of the other "exec" lines near the end of the Xsession script. You cannot get the same effect just by dropping a script into "xinitrc.d". About all that such a script can do is run some commands and set some environment variables. But it cannot affect they way that "exec gnome-session" and the others get run once we are back in Xsession. Perhaps we can have a split approach. You could modify Xsession so that it uses commands like "exec $SESSION_WRAPPER gnome-session". Then the SSH package maintainers can put a script into xinitrc.d that sets $SESSION_WRAPPER to "ssh-agent". If SSH is not installed, then $SESSION_WRAPPER would evaporate and you would be back to the "exec gnome-session" behavior we have today. Hmm. Perhaps a more flexible idea would be to look for a file called "$HOME/.xsession-wrapper". If it exists, then run "exec $HOME/.xsession-wrapper gnome-session". Savy users can make that a symlink to ssh-agent, or they can make it a script that does whatever they like. That would be a very nice place to hook in all kinds of session-related functionality. (I've used gnome-session as the running example here. But obviously the same concerns apply to the commands that start KDE sessions, AnotherLevel sessions, and so on.)