[GE users] qrsh and iptables

Charu Chaubal Charu.Chaubal at Sun.COM
Fri Feb 25 03:32:49 GMT 2005


Hi,

On Feb 24, 2005, at 6:30 PM, Bevan C. Bennett wrote:

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

It depends what you need to run.  For what it's worth, "qsub -now y" 
will run the job in any queue marked "Interactive" and will fail if the 
job cannot be immediately scheduled (ie, just like the default behavior 
for qrsh).  If you need to only run an X-windows job, for example, you 
can qsub a wrapper script with the "-now y" option, and it will behave 
more or less like qrsh.

Regards,
	Charu

> 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 changed since then.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>
###############################################################
# Charu V. Chaubal				# Phone: (650) 786-7672 (x87672)
# Grid Computing Technologist	# Fax:   (650) 786-4591
# Sun Microsystems, Inc.			# Email: charu.chaubal at sun.com
###############################################################


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