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

rumpelkeks tina.friedrich at diamond.ac.uk
Thu Feb 4 14:27:24 GMT 2010

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


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


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

More information about the gridengine-users mailing list