[GE users] Help with qrsh, SSH, and LDAP

David Olbersen dolbersen at nextwave.com
Fri Nov 9 19:03:08 GMT 2007


Dan,

Let's just say I'm motivated. :)

So my debugging settings aside, I updated the config for the one host in
my target queue and made qlogin_daemon & rlogin_daemon `/usr/sbin/sshd
-i`.

That made all the difference in the world. :D

Is there a good way that I can make that kind of change on all my nodes
without popping open vi all the time? I've got 80 nodes and don't really
want to do this 80 times if I can help it.

I tried: qconf -mattr exechost qlogin_daemon "/usr/sbin/sshd -i" node-2

But that didn't do what I wanted, nor did some variations of -aattr,
etc. Looking at the man page for qconf I don't see any variation of
-mconf that takes a file as input or is in some other way scriptable.

Any ideas?

-- 
David Olbersen (x0623)
 

-----Original Message-----
From: Dan.Templeton at Sun.COM [mailto:Dan.Templeton at Sun.COM] 
Sent: Friday, November 09, 2007 10:15 AM
To: users at gridengine.sunsource.net
Cc: Chris Dollmont; Andrew Preece
Subject: Re: [GE users] Help with qrsh, SSH, and LDAP

Wow.  You've been busy. :)

The SGE_DEBUG_LEVEL variable is more easily set by sourcing the dl.[c]sh

script in the util directory and running "dl <n>", where n is a number 
between 1 and 10.  The setting you're using is equivalent to dl 1.  
Bigger n doesn't mean more data.  See my blog for more info:

http://blogs.sun.com/templedf/entry/using_debugging_output

The command and daemon settings can appear in two places.  If you set 
them in the global host config (qconf -mconf), they will be inherited by

all execution daemons, unless those daemons have their own settings.  To

set a value for an individual host, regardless of what the global config

is, edit the host config (qconf -mconf hostname).  By default, hosts 
override the qlogin and rlogin daemon settings.

The port thing is a red herring.  The way our qrsh works currently is 
that both the client and the server open ports.  The server then 
connects to the client's port to tell it where to find the server's 
port.  It's complicated.  That will change with 6.2.

Daniel

David Olbersen wrote:
> I've made a few experiments with very strange results.
>
> First I set SGE_DEBUG_LEVEL to "2 0 0 0 0 0 0 0" (googled from
> somewhere) which gives some interesting output (attached). The bits
that
> are interesting to me are (summarized):
>
> qlogin_daemon = /usr/sbin/in.telnetd
> qlogin_command = /usr/bin/ssh
> rsh_daemon = /usr/sbin/sshd
> rsh_command = /usr/bin/ssh
> rlogin_daemon = /usr/sbin/in.rlogind
> rlogin_command = /usr/bin/ssh -v
>
> That's interesting because `qconf -sconf | grep '_command\|_daemon'`
> shows:
> rsh_command                  /usr/bin/ssh
> rsh_daemon                   /usr/sbin/sshd
> rlogin_command               /usr/bin/ssh -v
> rlogin_daemon                /usr/sbin/sshd
> qlogin_command               /usr/bin/ssh
> qlogin_daemon                /usr/sbin/sshd
>
> So there's some configuration being ignored or overwritten somewhere.
> OK, fine. Maybe I'm missing some higher-level configuration settings
> somewhere. I believe the debug output to be the Final Answer and I can
> work with that.
>
> Since I don't have in.telnetd or in.rlogind in CentOS I made a short
> wrapper script and symlink'd to it:
>
> 	#!/bin/bash
>
> 	env >> /var/tmp/sshd-$$
> 	exec /usr/sbin/sshd -e >> /var/tmp/sshd-$$
>
> The interesting part about this is when I compare what I see on the
> client side:
>
> 	OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
> 	debug1: Reading configuration data /users/dolbersen/.ssh/config
> 	debug1: Applying options for *
> 	debug1: Reading configuration data /etc/ssh/ssh_config
> 	debug1: Applying options for *
> 	debug1: Connecting to node-2.skunkworks.eng.atg.nw.net
> [172.24.19.116] port 34139.
> 	(more output about SSH keys)
>
> To what I see on the server side (attached as well):
>
> QRSH_PORT=labmaster.skunkworks.eng.atg.nw.net:36910
>
> Client says port 34139, server says port 36910. Maybe I'm putting
things
> together that I shouldn't be, but that seems pretty strange.
>
> Am I heading down some horribly twisty and ultimately incorrect path?
> Are there a few fundamental things I should check first before pursing
> this further? If anybody has any import I would love to hear it!
>
>   
>
------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list