[GE users] 6.2 beta qsh problem...

Alexandre Racine Alexandre.Racine at mhicc.org
Thu Jun 12 22:00:20 BST 2008


Hi,

> xhost +
[...]
> - you are on server1
> - ssh to server2 without X11 forwarding and do on this machine:
> - export DISPLAY=server1:0
> - xterm


Wow, that actually work pretty well! But you are right, and I have
tested that, my friend could open an xterm in my X11 session (with his
credential!). The combination of xhost with qsh works pretty well too,
as long that the DISPLAY variable is set correctly.

Now... how could this work without any user interventions? I know that
ROCK or OSCAR have their own authentification system (411 or something
like that)... but how could this work in a ldap environnement?


And as a side question, if I launch a qsh, can it be queue or does it
have to be possible to run right now?




Alexandre Racine
alexandre.racine at mhicc.org
514-461-1300 poste 3303


> -----Original Message-----
> From: Reuti [mailto:reuti at staff.uni-marburg.de]
> Sent: 12 juin 2008 13:32
> To: users at gridengine.sunsource.net
> Subject: Re: [GE users] 6.2 beta qsh problem...
> 
> Am 12.06.2008 um 18:52 schrieb Alexandre Racine:
> 
> > Hi,
> >
> >> If you switch of the firewall for
> >> internal connections in your cluster (i.e. between server1 and
> >> server2) and allow connections to X11 from the other server in your
> >> case (xhost +server2).
> >
> > I don't really understand this sentence. Those tests servers do not
> > have
> > firewalls but could you please elaborate a little more for the X11
> > part?
> > This will make qsh work in a transparent way?
> 
> You can try the following to simulate the process of SGE's working.
> 
> - you are on server1
> - ssh to server2 without X11 forwarding and do on this machine:
> - export DISPLAY=server1:0
> - xterm
> 
> This should open an xterm window on server1, while you issued the
> command on server2.
> 
> The xterm (a X11 client program) on server2 will establish a
> connection to the X11 server (running already) on server1. There is
> nothing to do on server1 at that time. X11 is working in the opposite
> way, then you would expect - a client (on the remote machine) is
> contacting the server (your local machine) to display the output
> instead.
> 
> When  this is working, also SGE's qsh should work. Maybe you need to
> issue "xhost +" (on server1), so that your local X11 server (on
> server1) accepts connections from everywhere or "xhost +server2" just
> from server2.
> 
> Inside a cluster you can do this. But a) the connection is
> unencrypted, and b) depending of your "xhost +" command, anyone may
> open a window on your machine - even a different user can do this.
> You start typing in a window on your local machine to connect to
> somewhere - and bingo: he got your password.
> 
> -- Reuti
> 
> 
> >> the problem is, that X11 is working in the other way: an xterm is
> >> started on a node and connects to the local machine (the submit
host
> >> - where a X11 server is supposed to be running already)  to show
you
> >> the output.
> >
> > Correct. I am on server1, run qsh and xterm is started on server2.
> > Then
> > xterm connect to server1... mmmm ok so here is the authentification
> > problem I guess.
> >
> >
> >> This was working fine in former times, when noone cared
> >> about firewalls and unencrypted connections - just ports 6000+ are
> >> used in such a configuration.
> >
> > This is related to my first question. Ok, I'll wait for your answer.
> >
> >
> > In the future, could SGE have it's own "qsh tunnel" in a transparent
> > way? (I know, this is putting all the work in your hands. Sorry for
> > that).
> >
> > Thanks.
> >
> >
> >
> >
> >
> > Alexandre Racine
> > alexandre.racine at mhicc.org
> > 514-461-1300 poste 3303
> >
> >
> >> -----Original Message-----
> >> From: Reuti [mailto:reuti at staff.uni-marburg.de]
> >> Sent: 12 juin 2008 06:43
> >> To: users at gridengine.sunsource.net
> >> Subject: Re: [GE users] 6.2 beta qsh problem...
> >>
> >> Hi,
> >>
> >> Am 11.06.2008 um 23:13 schrieb Alexandre Racine:
> >>
> >>> I never got to make qsh work with any version. I mean, it does
work
> >> in
> >>> some scenarios only. For example, if the xterm job get executed on
> >> the
> >>> same server where I am, that will work. Or if I am already logged
> >>> on the
> >>> server where the xterm will execute, that will work too. (In this
> >>> case,
> >>> I start qsh on server1, but I have another ssh session on server2,
> >> the
> >>> xterm starts on server2, and server1 receive the xterm.)
> >>>
> >>> The script below do not change anything. Should it be?
> >>>
> >>> Why SGE can't link, tunnel, forward a xterm session from one
server
> >> to
> >>> another?
> >>
> >> the problem is, that X11 is working in the other way: an xterm is
> >> started on a node and connects to the local machine (the submit
host
> >> - where a X11 server is supposed to be running already)  to show
you
> >> the output. This was working fine in former times, when noone cared
> >> about firewalls and unencrypted connections - just ports 6000+ are
> >> used in such a configuration. If you switch of the firewall for
> >> internal connections in your cluster (i.e. between server1 and
> >> server2) and allow connections to X11 from the other server in your
> >> case (xhost +server2).
> >>
> >> To use a tunnel, there are two options:
> >>
> >> - start a ssh connection from the submit machine to the node and
> >> therein xterm ("qrsh xterm" & setup ssh for SGE)
> >>
> >> - you are already connected to the machine and reuuse the already
> >> established ssh connection - this is what is already working for
> you.
> >>
> >>
> >> -- Reuti
> >>
> >>
--------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> >> For additional commands, e-mail:
users-help at gridengine.sunsource.net
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> > For additional commands, e-mail: users-help at gridengine.sunsource.net
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list