Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jan 2006 09:42:15 -0600
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Dominique Goncalves <dominique.goncalves@gmail.com>
Cc:        freebsd-stable@freebsd.org, vsevolod@freebsd.org
Subject:   Re: Using [Open]LDAP for authentication
Message-ID:  <20060120154215.GA54284@dan.emsphone.com>
In-Reply-To: <7daacbbe0601192341p32673972j8f309dff1df543aa@mail.gmail.com>
References:  <200601201130.18872.doconnor@gsoft.com.au> <7daacbbe0601192341p32673972j8f309dff1df543aa@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jan 20), Dominique Goncalves said:
> On 1/20/06, Daniel O'Connor <doconnor@gsoft.com.au> wrote:
> > I use OpenLDAP for authentication in conjunction with nss_ldap and
> > pam_ldap (and samba). I use the RCORDER port option so it put the
> > startup file in /etc/rc.d.
> >
> > In 5.4 this worked fine - it started up correctly and in the right
> > place. However I upgraded to 6.0-STABLE (11/12/05) and when I ran
> > mergemaster I accidentally told it to delete the rc.d file (doh..)
> > I then upgraded to a slightly later version of openldap (a newer
> > version of openldap23-server).
> >
> > The problem now is that OpenLDAP appears to start very late, since
> > lots of things need to do nss_ldap lookups it means bootup is very
> > glacial as they timeout.
> 
> I've reported recently a problem with the same symptoms [1] but I use
> this order in my nsswitch.conf "files ldap".
> 
> All exemples I found on internet use this order. And if I understand
> correctly, this order means, if a user is not found in files then it
> tries on ldap?
> 
> [1] http://lists.freebsd.org/pipermail/freebsd-questions/2006-January/110581.html

For the username lookup itself this is true, but to determine which
groups that user is a member of, it needs to fetch the entire group
list. That's probably the cause of your hang.  Compare "id -u root"
(just looks up userid) with "id root" (looks up userid and group
memberships).

In any case, I can't think of any reason why ldap queries would timeout
or hang, though.  Either nss_ldap can connect to the remote ldap
service, or it can't, and if it can't it should realize this
immediately (unless your routes are messed up).  Unfortunately, truss
doesn't tell you what syscall a process is waiting on when you ^C it;
try ktrace or strace and see if it gives you any more info.

-- 
	Dan Nelson
	dnelson@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060120154215.GA54284>