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

reuti reuti at staff.uni-marburg.de
Thu Feb 4 21:18:45 GMT 2010


Am 04.02.2010 um 18:27 schrieb rumpelkeks:

> Sorry. Use Head. MPI uses qrsh, not qlogin, doesn't it? So changing  
> the
> qlogin but leaving the qrsh alone is indeed the way forward, I guess.

Yep.

-- Reuti


> Again, thanks a lot.
>
> Tina
>
> rumpelkeks wrote:
>> Another thing.
>>
>> Doesn't MPI tight integration use qlogin? So would setting the qlogin
>> method to ssh globally break that, possibly?
>>
>> Sorry for being a bother :)
>>
>> Tina
>>
>> rumpelkeks wrote:
>>> Hi,
>>>
>>> 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).
>>>
>>> How far away is the builtin supporting X, actually?
>>>
>>> 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=243281
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=243325

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



More information about the gridengine-users mailing list