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

rumpelkeks tina.friedrich at diamond.ac.uk
Fri Feb 5 10:00:43 GMT 2010


Hi,

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

Thanks for that. I might look into that, actually. On the whole, still, 
ssh is just a tiny little bit more inconvenient (suddenly I need 
authentication set up on the nodes, which is a pain to do, that sort of 
thing. No host based auth isn't an option.).

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

That is a good point; I'll do that I think. Provided there are no 
drawbacks with it? (Which bit of the documentation is that switch hidden 
in, can't find it at the moment. I'm sure I've seen it somewhere!)

> Let me know, if you need further directions in case you want to try  
> this.
> 
> 
>> How far away is the builtin supporting X, actually?
> 
> Dunno. I only know it's an RFE: http://gridengine.sunsource.net/ 
> issues/show_bug.cgi?id=3093

Hope it happens soon. It'd be far more convenient. Oh well.

I'll shout if I need help with the ssh tight integration stuff. We've 
compiled MPI of course, but never ssh.

Tina

> 
> -- 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].
> 
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=243342
> 
> 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=243449

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



More information about the gridengine-users mailing list