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

[orenl@cs.columbia.edu]

So, I followed your suggestion and set up the following config using
overlay translucent:

...
modulepath      /opt/ldap/lib/
moduleload      back_ldap
moduleload      back_bdb
moduleload      translucent
...
backend         bdb
...
database        bdb
suffix          "dc=CS,dc=EXAMPLE,dc=COM"
readonly        on
directory       "/var/lib/ldap"
...
overlay         translucent
uri             "ldaps://ORIG_SERVER_IP/"
lastmod         off
translucent_no_glue
...

The good news: it runs. The bad news: it doesn't do what I want :(

"ldapsearch -x" dumps the full contents of the original (remote)
server. But it doesn't give any of the entries in the local DB.
If I take out the translucent directives, then "ldapsearch -x"
does dump the contents of the local DB.

 >>> * 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.

Re-reading the man page - it says:
"Entries retrieved from a remote LDAP server may have some or all
attributes overridden, or new attributes added, by entries in the
local database before being presented to the client."

However my local DB _extends_ the original server, that is: it adds
_new entries_, as opposed to overriding attributes of existing entries.
Again, this is why I selected the ldap-meta is the first place.

Either that, or something has gone wrong with the configuration ?

 >> I would use back-ldap to contact the remote server and subordinate glue
 >> for the local bdb database.

How would I go about the "subordinate glue" ?

Oren.

orenl@cs.columbia.edu wrote:
> 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.
> 
>