[GE users] qrsh and iptables

David S. dgs at gs.washington.edu
Fri Feb 25 03:11:13 GMT 2005


> 
> Has anyone worked out a particularly clever way to use qrsh without 
> having to have every exec host trust all tcp from every possible submit 
> host, and vice versa?
> 
> The process for getting an interactive login appears to involve 
> initiating the following tcp connections:
> 
> 1) submithost:X -> qmaster:536
> 2) qmaster:536 -> exechost (previously established connection)
> 3) exechost:(seemingly random) -> submithost:X+1
> 4) submithost:X+2 -> exechost:(wherever the daemon started)
> 
> Number 3 requires that your submit hosts allow connections from any 
> unprivledged port on any possible exec host to any local unprivledged port.
> 
> Number 4 requires that your exec hosts allow connections from any 
> unprivledged port on any submit host to any local unprivledged port.
> 
> In practice this means that exec hosts end up having to use a wide-open 
> iptables configuration, and that submit hosts need be wide-open to 
> anywhere that exec hosts might be. (Alternatively, you can never use 
> qrsh and just use qsub, if you can convince your users...)

That's just the 'rsh' protocol.  If you don't like it, see

	http://gridengine.sunsource.net/project/gridengine/howto/qrsh_ssh.html

David S.

> 
> It's #3 that actually bothers me the most, as it seems like it shouldn't 
> be neccessary.  Why does the exechost send the connection port directly 
> to the submithost instead of passing it through the qmaster? I don't 
> like that you need to un-firewall submithosts in order for qrsh to work.
> 
> Has anyone come up with any clever ways to configure this better?
> 
> I haven't hacked at the relevant code since 5.x, but the behavior hasn't 

---------------------------------------------------------------------
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