slapd won't start with nss_ldap.conf

[Jonathan McKeown]

On Friday 09 May 2008 23:09, Robert Fitzpatrick wrote:
> On Fri, 2008-05-09 at 22:44 +0200, Jonathan McKeown wrote:
> > On Friday 09 May 2008 14:36, Robert Fitzpatrick wrote:
> > > On a FreeBSD 6.1 with openldap-server-2.3.39, I have setup nss_ldap and
> > > pam_ldap, but cannot get slapd to start as long as I have nss_ldap.conf
> > > present, it just hangs and nothing in the messages or debug logs. I
> > > just copied ldap.conf to nss_ldap.conf, see contents below.
> >
> > So, to start slapd, the system needs the group info for user ldap - from
> > slapd. It times out and retries a few times, and eventually starts slapd
> > using the group information from /etc/passwd and /etc/group, but the
> > timeout and retry options by default take several minutes.
>
> Seems my core problem is something wrong with the openldap setup on that
> box. I had taken the slave ldap server up to 2.3.41 and it was not
> having this slapd/nss_ldap startup problem. I don't know if it is bad
> with a synrepl slave earlier version that the master, but I just didn't
> want to mess with the master until it proved OK and all seems perfectly
> great on the slave except my boot order issue....

It depends what else you upgraded while changing the openldap server. Earlier 
versions of nss_ldap had much shorter timeouts, I believe, which means the 
problem only manifested itself after a certain version of nss_ldap.

> Thanks for the response, and yes, the openldap list owner finally
> rejected my message and gave me the pointer to start slapd with the
> owner and group by id instead of name. After reading the start script to
> get the owner and group by id in the rc.conf file, I am now starting the
> process in that way. While doing that I realize that I can handle boot
> order by name of the file and gave it a prefix of 001.

Errr, not sure what you're talking about here: man rcorder will tell you the 
normal way to control startup order on a recent FreeBSD. I think you'd have 
to be doing something rather unusual to force the old behaviour you seem to 
be talking about... As far as starting up with a numeric id rather than a 
user name, I'm not sure that will stop the lookup of group information which 
is actually causing the problem.

Good luck.

Jonathan