Seems like it would be a good idea to define a new option "glue-peer" or somesuch that allows multiple peer-level DBs to be glued together.
http://www.openldap.org/lists/openldap-software/200802/msg00128.html
It wouldn't really be much work in backglue.c if the set of entries is disjoint.
In case of duplicate entries, we'd have to track them and either drop some of them or merge them.
Howard Chu wrote:
Seems like it would be a good idea to define a new option "glue-peer" or somesuch that allows multiple peer-level DBs to be glued together.
What exactly do you mean with peer-level DBs? I didn't get what the idea is for...
In case of duplicate entries, we'd have to track them and either drop some of them or merge them.
Hmm...how about bind requests?
I'm a very simple thinking guy. Therefore I'm not in favour of endorsing a setup which lets the slapd admins believe they don't have to think about schema and names spaces and consolidation of their data.
How should duplicates be detected (by DN, by filter?) and based on which criteria should they be dropped or merged. Even merging is messy: Merge all attribute values of same attributes of all merged entries? Or give some entries priority over others or I'm already totally confused now... ;-)
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Seems like it would be a good idea to define a new option "glue-peer" or somesuch that allows multiple peer-level DBs to be glued together.
What exactly do you mean with peer-level DBs? I didn't get what the idea is for...
Mainly for grafting OpenLDAP on top of an existing, poorly designed someone-else's DIT.
In case of duplicate entries, we'd have to track them and either drop some of them or merge them.
Hmm...how about bind requests?
Good question.
I'm a very simple thinking guy. Therefore I'm not in favour of endorsing a setup which lets the slapd admins believe they don't have to think about schema and names spaces and consolidation of their data.
Also a good point.
How should duplicates be detected (by DN, by filter?) and based on which criteria should they be dropped or merged. Even merging is messy: Merge all attribute values of same attributes of all merged entries? Or give some entries priority over others or I'm already totally confused now... ;-)
Yeah, good questions. Perhaps it is better addressed by enhancing slapo-translucent instead to allow local entries to exist independently of remote ones. At least in that case, there is a clearly defined precedence. (All local data overrides any remote data.)
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Seems like it would be a good idea to define a new option "glue-peer" or somesuch that allows multiple peer-level DBs to be glued together.
What exactly do you mean with peer-level DBs? I didn't get what the idea is for...
Mainly for grafting OpenLDAP on top of an existing, poorly designed someone-else's DIT.
Well, the reason why I'm nit-picking: Someone who isn't able to consolidate a poorly designed DIT could blame the functionality in OpenLDAP instead of rethinking his/her own approach if things doesn't work. The configuration of such a beast will get complex.
Yeah, good questions. Perhaps it is better addressed by enhancing slapo-translucent instead to allow local entries to exist independently of remote ones. At least in that case, there is a clearly defined precedence. (All local data overrides any remote data.)
And this clear precedence makes it usable. :-)
Ciao, Michael.
Maybe I'm understanding the requirements incorrectly, but what's wrong with http://www.openldap.org/lists/openldap-software/200802/msg00136.html? I agree with Dieter that I don't see how the referenced ITS applies.
For one project, I used:
database hdb subordinate suffix "ou=Local Users,dc=rutgers,dc=edu"
database ldap suffix "dc=rutgers,dc=edu"
in production for a couple years. It didn't work until 2.3.27 or so, when enhancements to back-ldap/meta made it possible. "Local Users" is politically guaranteed to be disjoint in this case. IIRC duplicates will indeed show up twice, with the local entry first.
I also recall the glue syntax changes of the 2.3.3-era. There were concerns over the amount of rope available there; make sure to keep those discussions in mind...
Aaron Richton wrote:
Maybe I'm understanding the requirements incorrectly, but what's wrong with http://www.openldap.org/lists/openldap-software/200802/msg00136.html?
That was of course my original suggestion in the ITS. It works for most situations because we patched nss_ldap to work with multiple service search descriptors. However the automounter he's using talks to LDAP directly, it doesn't go thru the name service switch, and it isn't smart enough to handle multiple SSDs. Thus the problem.
I agree with Dieter that I don't see how the referenced ITS applies.
For one project, I used:
database hdb subordinate suffix "ou=Local Users,dc=rutgers,dc=edu"
database ldap suffix "dc=rutgers,dc=edu"
in production for a couple years. It didn't work until 2.3.27 or so, when enhancements to back-ldap/meta made it possible. "Local Users" is politically guaranteed to be disjoint in this case. IIRC duplicates will indeed show up twice, with the local entry first.
I also recall the glue syntax changes of the 2.3.3-era. There were concerns over the amount of rope available there; make sure to keep those discussions in mind...
Howard Chu wrote:
Aaron Richton wrote:
Maybe I'm understanding the requirements incorrectly, but what's wrong with http://www.openldap.org/lists/openldap-software/200802/msg00136.html?
That was of course my original suggestion in the ITS. It works for most situations because we patched nss_ldap to work with multiple service search descriptors. However the automounter he's using talks to LDAP directly, it doesn't go thru the name service switch, and it isn't smart enough to handle multiple SSDs. Thus the problem.
On Linux, use the nss_ldap module for autofs (in doc/lookup_nssldap.c).
On Solaris, LD_PRELOAD nss_ldap.so with the Sun automounter.
Or are you using a different automounter?
-- Luke
-
Aaron Richton -
Howard Chu -
Luke Howard -
Michael Ströder