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

reuti reuti at staff.uni-marburg.de
Wed Feb 3 16:38:05 GMT 2010


Hi,

Am 03.02.2010 um 15:31 schrieb rumpelkeks:

> Hi,
>
> <snip>
>> Are you running SELinux on the nodes?
>
> Nope. Running Lustre, SELinux disabled everywhere. But yes other than
> that that would've been my first guess as well, and I actually went  
> and
> double checked :)
>
>> Normal qsub is working?
>
> Oh yes! qlogin using builtin working fine, as well.
>
>>>>> <snip>
>>> Sorry, might've gotten confusing here. In this first instance I'd be
>>> quite happy to get a login. My problem is that it doesn't work at  
>>> all.
>>> (I mean even if the X forwarding fails, I should just get a
>>> shell/prompt/something like that, or not?)
>>
>> Yep.
>
> Which is what I don't get (I guess you guessed). I did try to enable
> debug output in ssh, but I don't even get that far. I mean usually job
> get's schedules and you get 'establishing builtin session' - I  
> never get
> the 'establish session'.
>
> Also, on the node (watching netstat), I never get more than TIME_WAIT
> for any connection status on the port that the job reports.
>
> (Oh, and when I've got a 'normal' ssh open into the node, a qsh - 
> display
> :10.0 works; so the 'connection command' works I guess. To me, it  
> looks
> a lot as if there's never any sshd process started when I try to  
> connect.)

is there any local configuration defined for the nodes, which has a  
different setting from the global one and leads to a mismatch of used  
methods?

-- Reuti


>>>>> <snip>
>>> I know what process SGE runs as. I want to know what it would try to
>>> start the ssh process as. The user that wants to login, the user  
>>> that
>>> SGE runs as; does it have setuid on something...? (This could very
>>> well
>>> be the user running SGE (sgeadmin) not being allowed to start sshd
>>> process.) Also, when trying this directly, I cannot run "sshd - 
>>> i"; is
>>> this required to work, or can it be used without being run from  
>>> inetd?
>>
>> It's not run from inetd:
>>
>> sgeadmin root     /usr/sge/bin/lx24-x86/sge_execd
>> sgeadmin root      \_ sge_shepherd-409 -bg
>> root     root          \_ sshd: reuti [priv]
>> reuti    reuti             \_ sshd: reuti at pts/0
>> reuti    reuti                 \_ -bash
>> reuti    reuti                     \_ ps -e f -o user,ruser,command
>
> Okay. So it IS running sshd as root, even though the execd runs as
> sgeadmin (I also have group sgeadmin, I think - that should not be a
> problem?)
>
> I've gone back to builtin and I'll do all the steps again, maybe I can
> find some more info on what's going wrong were.
>
> Tina
>
>>
>> -- Reuti
>>
>>
>>> Tina
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?
>>> dsForumId=38&dsMessageId=242659
>>>
>>> To unsubscribe from this discussion, e-mail: [users-
>>> unsubscribe at gridengine.sunsource.net].
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do? 
>> dsForumId=38&dsMessageId=242913
>>
>> 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=242929
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].

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

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



More information about the gridengine-users mailing list