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

David Olbersen dolbersen at nextwave.com
Fri Nov 9 00:08:35 GMT 2007


I've CC'd Chris & Andrew as their both LDAP & SGE people in our
organization. If you could reply to them as well I'd really appreciate

I can submit jobs through qsub; submitting interactive jobs through qsh
works as well.

finger & getent work just fine. We do have some rather large groups;
could that be a problem?

nsswitch.conf has "files ldap" for passwd, shadow, and group.

I'd like to point out that this is enterprise wide LDAP that -does- work
on hundreds of machines. It works just fine in every case -except- qrsh.

We're using Fedora DS. The anonymous binds work just fine for every
other system on our machines.

We have the indexes in place that you mention. I've tried trimming the
search down by modifying /etc/ldap.conf as you mention but it just
breaks lookups. The old way (without any nss_base lines) may be slower,
but it gives the right answers.

Like I said before, given that LDAP works right on every other system I
really have a hard time seeing it not being SGE. I suppose it could be
SGE being sensitive to problems that other services quietly ignore,

Thanks for taking the time to help!

David Olbersen (x0623)

-----Original Message-----
From: Darin Perusich [mailto:Darin.Perusich at cognigencorp.com] 
Sent: Thursday, November 08, 2007 6:20 AM
To: users at gridengine.sunsource.net
Subject: Re: [GE users] Help with qrsh, SSH, and LDAP


The errors that you're see are related to pam_ldap/nss_ldap not SGE. Are

you able to submit jobs using qsub? What happens if you query the 
directory using other system commands like finger, or getent? Are there 
nsswitch.conf entries for shadow and group?

 From looking at your ldap.conf it's clear that you're binding to your 
directory anonymously which could be the problem. Have you setup a proxy

account for non-anonymous binds? I don't know which ldap server you're 
using but Sun Directory will create an entry with an rdn like 
cn=proxyagent,ou=profile,dc=domain,dc=com for just this purpose. 
Additionally pam_ldap is having to search your whole directory tree to 
locate entries for passwd, shadow, and group. Setting 
nss_base_{passwd,shadow,group) in ldap.conf will really increase the 
efficiency of those lookups, as will creating indexes for them on the 

/etc/ldap.conf with examples mentioned above.

host    sunds1.domain.com sunds2.domain.com
base    dc=domain,dc=com
ldap_version    3
binddn  cn=proxyagent,ou=profile,dc=domain,dc=com
bindpw  password
ssl     start_tls
nss_map_attribute       uniqueMember member
pam_filter      objectclass=posixAccount
nss_base_passwd ou=people,dc=domain,dc=com?one
nss_base_shadow ou=people,dc=domain,dc=com?one
nss_base_group  ou=group,dc=domain,dc=com?one
tls_checkpeer   yes
tls_cacertfile  /etc/ssl/certs/cacert.pem

David Olbersen wrote:
> Darin,
> Thank you for taking the time to help! :)
> I don't really see how this could be an OS issue since I can SSH
> the boxes just fine (using passwords or keys). It's only when SGE is
> involved that trouble starts.
> I don't see any nss_ldap errors that aren't SGE related.
> nscd isn't running on the clients, so that's not it. Interestingly, if
> turn on nscd the errors go away but the connection still fails.
> /etc/nsswitch.conf is set to "files ldap", changing order makes no
> difference.
> /etc/ldap.conf only has a few lines that aren't commented out:
> host directory.eng.atg.nw.net
> base dc=eng,dc=atg,dc=nw,dc=net
> timelimit 120
> bind_timelimit 120
> idle_timelimit 3600
> ssl no
> tls_cacertdir /etc/openldap/cacerts
> pam_password md5
> /etc/openldap/ldap.conf is short as well:
> HOST directory.eng.atg.nw.net
> BASE dc=eng,dc=atg,dc=nw,dc=net
> TLS_CACERTDIR /etc/openldap/cacerts

Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

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