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 verysmall database (less than 100 entries).
(2) a META-backend for domain CS.EXAMPLE.COM that is configured torelay 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.