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

reuti reuti at staff.uni-marburg.de
Wed Feb 3 18:20:13 GMT 2010

Am 03.02.2010 um 18:07 schrieb rumpelkeks:

> Hi,
> reuti wrote:
>> Am 03.02.2010 um 17:34 schrieb rumpelkeks:
>>> Right. I've reverted the config for my test node, and started over
>>> again. This is what I did / what happens; maybe I am doing it wrong
>>> and
>>> someone can tell me where.
>>> With no extra configuration, qlogin (and qrsh) work.
>>> Now I add the following configuration to the host:
>>> [kdf51254 at pc030 tmp]$ qconf -sconf cs04r-sc-com04-15
>>> #cs04r-sc-com04-15.diamond.ac.uk:
>>> xterm             /usr/bin/xterm
>>> qlogin_daemon     /usr/sbin/sshd -i
>>> rsh_daemon        /usr/sbin/sshd -i
>>> rlogin_daemon     /usr/sbin/sshd -i
>>> qlogin_command    /dls_sw/apps/sge/SGE6.2/DLS/common/qlogin_wrapper
>>> rsh_command       /usr/bin/ssh -X
>>> rlogin_command    /usr/bin/ssh -X
>> The qrsh_command from the issuing machine must match the qrsh_daemon
>> of the target machine. The "pc030" has also a local configuration or
>> is using the global one?
> Is using the global one, I believe - at least it tells me so if I  
> use a
> reverted-config-normal-working-qlogin:
> [kdf51254 at pc030 ~]$ qlogin -q test.q
> local configuration pc030.sc.diamond.ac.uk not defined - using global
> configuration

Then the global configuration needs also to be adjusted to use ssh as  
method (or define a local one for pc30).

> (Maybe I should add a note about our setup, though I'm not sure it's
> important here - we don't have a head node or something. All cluster
> nodes route, the SGE_ROOT is on a central NFS share, all  
> workstations we
> have are submit hosts. So this pc030 is simply my normal  
> workstation. Oh
> and the cluster nodes don't all sit on the same network, and it is
> always a different network from where the workstations are. That
> shouldn't be a problem though?)

When there is always a direct connection between the workstations and  
the nodes and also host resolution gives a proper address for each  
machine it should work.

> About the global/local configuration again, the node will of course  
> have
> a local configuration once I try to use ssh instead of builtin;  
> because
> I add one to define the qlogin_daemon etc. As I had understood this  
> this
> should work - I did not want all nodes in the queue to use the ssh  
> method.

This is not forseen. Everytime you want to use a different method for  
the communication you would have to adjust the local pc30  
configuration to match the one from the target node. The different  
entries for each node is not meant to switch between methods of  
communication per node, but to be used if the same method has to  
access a binary for the chosen method in a different path (mainly if  
you have a heterogenous cluster with a mix of Solaris, Irix,  
Linux, ...).

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

-- Reuti

> Tina
>>> <snip>
>>> Also, is it normal I seem to have to ssh into the node and restart
>>> sge_execd whenever I change the config (using qconf -mconf)? It  
>>> never
>>> seems to pick them up, and I thought it should?
>> I faced a similar effect:
>> http://gridengine.sunsource.net/issues/show_bug.cgi?id=2361
>> and it will take some seconds anyway when tampering the global
>> configuration.
>> -- Reuti
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do? 
>> dsForumId=38&dsMessageId=242958
>> 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=242962
> 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