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. [EMAIL PROTECTED] 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. > >
