[Date Prev][Date Next]
Re: (ITS#5354) slapd repeatedly hangs and stops reponding
> firstname.lastname@example.org wrote:
>> --On Thursday, February 07, 2008 6:56 PM -0500 Oren Laadan
>> <email@example.com> wrote:
>>> More threads, less threads -- it still happens :(
>>> Attached is the last part of the log before it stopped responding
>>> (you can see towards the end the time gap).
>>> Also attached is the backtrace of all threads (thanks to gdb).
>> Your backtrace is fairly useless. You need to do a make install STRIP=""
>> so it doesn't strip the binaries on installation. Or copy over the slapd
>> from your build area, as that is pre-stripping. Additionally, I'd add the
>> patch from ITS#5341 to your build.
>> Reading symbols from /usr/local/opt/ldap-2.4.7/libexec/slapd...(no
>> debugging symbols found)...done.
> It shows enough; back-meta is hanging waiting for responses from some other
> LDAP server. This is a pretty bad configuration; you should not use back-meta
> (or back-ldap) to redirect queries back into the same slapd. You should use
> back-relay instead.
I'm not quite sure why having the server query itself is such a bad idea.
Can you please explain ?
Let me repeat how my setup works:
* there exists an LDAP server "ldap.cs.example.com" for domain CS.EXAMPLE.COM
* I need to build a server that extends the contents of that server, for
the same domain; but I don't have access to the DB of that server.
* My clients will use my server, with the domain CS.EXAMPLE.COM (instead of
querying the original server)
* So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that serves two
(1) a BDB-backend for domain MINE.CS.EXAMPLE.COM that holds a very small
database (less than 100 entries).
(2) a META-backend for domain CS.EXAMPLE.COM that is configured to relay
to both the original server (ldap.cs.example.com) and also relay to the
local (other) server (ldap.mine.cs.example.com); the second relay is done
with "suffixmassage" to convert from CS.EXAMPLE.COM to MINE.CS.EXAMPLE.COM
So, yes, my server/2nd-DB effectively relays queries to the my server/1st-DB
The questions are:
(1) why is this such a bad idea ?
(2) how would I use back-ldap in place ?
Note that the reason to originally select the meta-ldap backend was because
it was the only one that I could find in the docs that automagically merges
two separate databases and presents them as a single database the client.