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.
