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.

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.

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

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