Re: (ITS#5354) slapd repeatedly hangs and stops reponding

[orenl@cs.columbia.edu]

Hi,

Howard Chu wrote:
> Oren Laadan wrote:
>>> 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 ?
> 
> Any request then occupies a minimum of two slapd threads - one for 
> back-meta itself, and one for the extra inbound query. If you 
> misconfigure the meta URIs then you get into an infinite loop, which 
> consumes all of the available slapd threads.

The URIs are configured as following (see my original ITS post
for the full config file):

database        meta
lastmod         off
suffix          "dc=CS,dc=EXAMPLE,dc=COM"

uri             "ldaps://ldap.cs.example.com/dc=CS,dc=EXAMPLE,dc=COM"
uri             "ldaps:///dc=CS,dc=EXAMPLE,dc=COM"
suffixmassage   "dc=CS,dc=EXAMPLE,dc=COM" "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM"

> 
>> 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.
> 
> See slapo-translucent, which was written specifically for this reason.

I see. Am trying to build a new config using this overlay now.

> 
>> * My clients will use my server, with the domain CS.EXAMPLE.COM 
>> (instead of
>>     querying the original server)
> 
> Please stop using the "domain" terminology. LDAP uses Distinguished 
> Names, not domains. Tell us the distinguished names of the server 
> contexts you're dealing with. Tell us the actual DNs of the entries 
> you're dealing with.

Yes are correct. I confuse the two terms because the DNs follow the
convention of the network domains. So --

the original server servers "dc=CS,dc=EXAMPLE,dc=COM"
my server serves the same DNs for the clients; however the "extra"
local DB that I created is set for "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM"

> 
>> * So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that 
>> serves two
>>     databases:
>>
>>     (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
>>     and back.
>>
>> 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 ?
> 
> See above.
> 
>> (2) how would I use back-ldap in place ?
> 
> I would use back-ldap to contact the remote server and subordinate glue 
> for the local bdb database.
> 
>> 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.
> 
> I think you should be able to construct your DIT without needing to do 
> any suffix massaging.
> 

The reason I needed the suffix massaging in my setup is because I had
two servers coexisting on the same machine: one that is used by the
clients, and one that is used by the server itself through ldap-meta;

since the one visible to the clients was already "dc=CS,dc=EXAMPLE,dc=COM"
I had to make the other one do a different DN, hence the addition of
the "dc=MINE" at the beginning, and the suffix massaging

I hope that overlay translucent works, and that it does away with this
ugly trick that I had to put there.

I'm now re-doing the config to try it out. Many thanks to everybody
for the help so far.

Oren.