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>