[GE users] qlogin / ssh (ultimately, X forwarding)

reuti reuti at staff.uni-marburg.de
Thu Feb 4 22:24:53 GMT 2010


Am 04.02.2010 um 14:14 schrieb rumpelkeks:

> I was wanting to avoid ssh due to the integration/accounting/etc  
> issues,
> especially on the 'new' nodes.
> The issue about "Potential loss of control: in some unusual cases,
> killing the job might leave behind idle or busy processes, even if the
> job is seen as finished by Grid Engine." mentioned in the  
> disadvantages
> on the how to set it up page, how often would you say do you actually
> see that? That was one of my biggest gripes with it (regarding using
> that method on the faster nodes).

you can compile SGE on your own and build an sshd with tight SGE  
integration to get rid of these limitations. It's sufficient to build  
only a part of SGE for the libs and use the openssh source to get a  
new sshd which you access in your SGE configuration instead of the  
original sshd. Nothing from the SGE installation you have, needs to  
be exchanged at all.

There are some hints in http://www.sun.com/blueprints/ 
0607/820-1695.pdf page 13 but it's not actual as some declarations  
are missing.

It's also good to set "execd_params ENABLE_ADDGRP_KILL=TRUE" in SGE's  
configuration to have better control of killed jobs in general.

Let me know, if you need further directions in case you want to try  

> How far away is the builtin supporting X, actually?

Dunno. I only know it's an RFE: http://gridengine.sunsource.net/ 

-- Reuti

> Thanks a lot for your help,
> Tina
> reuti wrote:
>> Hi,
>> Am 04.02.2010 um 11:19 schrieb rumpelkeks:
>>> <snip>
>>> Okay. I didn't read it like that, again that's down to me not being
>>> good
>>> of putting the puzzle together.
>>> So there's definitely no way to only have part of the hosts in a  
>>> queue
>>> do that? Is there a way to only allow it on parts of a queue?
>> in long-term also the -builtin- method will support X11 forwarding  
>> IIRC.
>>> Basically, what I have is the - not unusual - case of having a
>>> group of
>>> more elderly hosts and new, fast nodes. On the new, fast nodes,  
>>> we run
>>> automatic fast data processing and such; the older ones aren't in  
>>> use
>>> for the fast processing jobs any more. So I don't see any harm in
>>> allowing people to run X applications on the older hosts; but I'd  
>>> like
>>> to keep the newer hosts used for fast processing free of them, if
>>> at all
>>> possible. I thought (hoped?) that I could set it up so that only the
>>> older hostgroup uses the ssh method (clearly, I was wrong). Is
>>> there any
>>> way you can see of doing this? I wouldn't really like to set up a
>>> different queue for it (I've got too many queues as it is, in my
>>> opinion).
>> I would suggest to use ssh for all nodes, but adjust /etc/ssh/
>> sshd_config to disallow X11 on certain machines (assuming that
>> interactive usage is allowed on all nodes besides this restriction).
>> If you don't want to tamper the original sshd_config, it's also
>> possible to supply a custom one for the SGE created sessions with the
>> -f option to sshd in SGE's qrsh setup or to append just the necessary
>> -oX11Forwarding=no in the local configuration for the disallowed
>> nodes to the qrsh_daemon entry.
>>>> What you can set up is to use ssh for the interactive qlogin/ 
>>>> rlogin,
>>>> and -builtin- for qrsh with command (i.e. the rsh_* entries).
>>> Or, I assume, qlogin with builtin and qrsh using the ssh method? (I
>>> want
>>> the ssh/X forwarding to be the exception rather than the norm).
>>> Could I
>>> then disallow qrsh on some host groups?
>> You could remove the keyword "INTERACTIVE" from the qtype entry in
>> the queue definition. But this will not disallow interactive use when
>> users find out to get an interactive slot with:
>> $ qrsh -now n
>> it will then run in a batch queue. "INTERACTIVE" in SGE terms is more
>> to be read as "IMMEDIATE" (and a `qsub -now y ..` will run in an
>> interactive queue).
>> In the sshd_config you can use one of the "AllowUsers" or
>> "AllowGroups" options to restrict access though.
>> -- Reuti
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do? 
>> dsForumId=38&dsMessageId=243197
>> To unsubscribe from this discussion, e-mail: [users- 
>> unsubscribe at gridengine.sunsource.net].
> -- 
> Tina Friedrich, Computer Systems Administrator, Diamond Light  
> Source Ltd
> Diamond House, Harwell Science and Innovation Campus - 01235 77 8442
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=243211
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].


To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

More information about the gridengine-users mailing list