Hello,

We're having a LSF HPC cluster on Linux RH Enterprise 4 64B running.
When I login to a login server I can open an xterm with command 'xterm' and with a bsub command using LSF.
When I ssh to another login server, my display variable will be forwarded thanks to a ssh setting. (xforwarding=yes in sshd.conf).
I still can use the command 'xterm' to open an xterm windows on the other loginserver.
When I now want to submit an xterm to a queue with bsub, xterm will not be displayed because of it's $DISPLAY variable. It says:
xterm Xt error: Can't open display: saq1l008:12.0

It seems that bsub will not use the Xforwarding origin from ssh.

We want this to be global, and not for one or two persons. Otherwise it was easy to add an entry in a wrapperscript which controlled the display variable or edit xauth.
We also want it to be as transparant as possible without letting the users to manually set their display variable after they ssh to the new loginserver.

It may be a dump question why we want to ssh to another loginserver and from there start an xterm or other application using X11, but users do silly things ;-)

I'm out of ideas and maybe can help me with this issue.

Thanks in advance.

The reason why it doesn't work is because there is authentication on the pseudo display on the ssh tunnel'd display, so only systems with the correct X authentication (usually a MIT-MAGIC-COOKIE or the like) can connect to it.

Try this:

$ xhost +
$ bsub ...

If they are local to the lsf farm (ie on the same network) then you probably shouldn't be messing around with tunneled displays. You should do this:

myhost$ xhost +
myhost$ ssh launchhost
launchhost$ export DISPLAY=myhost:0.0
launchhost$ bsub ...

...and have the job display direct back to the user's computer rather than displaying unencrypted to the launch host, then tunnelling that back to the user.

If you really need to do it (ie the user is ssh'd in from a system firewalled from the internet, and the lsf node can't get directly back to it) then you need to get the xauth information into the environment, then write a "launcher" that extracts the xauth information from the shell environment, performs the xauth operation, THEN runs your xterm or whatever.

Try this:

On your local machine do

xauth list $DISPLAY

and you get a reply:

mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1 37cb47264b485cd2e24ef9421def2a83

Then, on your remote machine do:

xauth add mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1 37cb47264b485cd2e24ef9421def2a83

That's all. Now you can set the display on your remote system, and processes started from that shell can display back to your originating machine. Unencrypted, of course, but it means that arbitrary people on the remote system can't interact with your display (the downside of xhost +).

Your key shouldn't change that often, but when it does, just issue on the
remote machine:

xauth remove mymachine.mydomain.com:0

before you add the new key.

The above is, in a nutshell, what your bsub wrapper has to do.

Here's what happens when I try the above

nonemagreen@magreen_fc9.hq.tensilica.com:~ 101$ xauth list $DISPLAY
magreen_fc9.hq.tensilica.com/unix:0 MIT-MAGIC-COOKIE-1 4713d325a2c39b515bf443457cdcdd3d
nonemagreen@magreen_fc9.hq.tensilica.com:~ 102$ ssh naos
magreen@naos's password:
Last login: Fri May 8 09:06:31 2009 from magreen_fc9.hq.tensilica.com
nonemagreen@naos:~ 101> xauth add magreen_fc9.hq.tensilica.com/unix:0 MIT-MAGIC-COOKIE-1 4713d325a2c39b515bf443457cdcdd3d
nonemagreen@naos:~ 102> bsub -q pr -Ip "xterm"
Job <807121> is submitted to queue <pr>.
<<Waiting for dispatch ...>>
<<Starting on alma>>
nonemagreen@naos:~ 103> bjobs
No unfinished job found
nonemagreen@naos:~ 104> bsub -q pr -W 300 -c 300 -R "select[type==RHEL4_64 || type==RHEL5_64]" -Ip "xterm"
Job <807122> is submitted to queue <pr>.
<<Waiting for dispatch ...>>
<<Starting on orion>>
xterm Xt error: Can't open display:
nonemagreen@naos:~ 105> setenv DISPLAY magreen_fc9.hq.tensilica.com/unix:0
nonemagreen@naos:~ 106> bsub -q pr -W 300 -c 300 -R "select[type==RHEL4_64 || type==RHEL5_64]" -Ip "xterm"
Job <807123> is submitted to queue <pr>.
<<Waiting for dispatch ...>>
<<Starting on orion>>
xterm Xt error: Can't open display: magreen_fc9.hq.tensilica.com/unix:0

What am I doing wrong?

The reason why that doesn't work is because when you do the

xauth add

...you are adding the details for your workstation to the computer you are ssh'd in to, not to the farm nodes. xauth information isn't stored in the environment anywhere.

Short of doing xhost + you'll have to add the xauth information to your environment, then teach your bsub'd command to do the xauth add before running any commands. Sort of like:

export MY_XAUTH=`xauth list $DISPLAY`

then do a

$bsub MyXterm

where MyXterm does this:

xauth add $MY_XAUTH
xterm

That's just off the top of my head though.