1:37 p.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:51 p.m.
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.
2:15 p.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:35 p.m.
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.
3:28 p.m.
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...
1:43 a.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:41 a.m.
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
5684
days inactive
5685
days old
6 comments
4 participants
participants (4)
-
Aaron Richton -
Howard Chu -
Luke Howard -
Michael Ströder