Re: cn=config: sharing, conditionals

[Howard Chu <hyc@symas.com>]

Rein Tollevik wrote:
> Howard Chu wrote:
> > Howard Chu wrote:
> > > Since there is currently no support at all, I think it's important to get
> > > something usable first, and worry about those other cases later.
> >
> > The other alternative, which is much simpler to implement, is just to
> > add a suffixmassage/rewrite keyword to the syncrepl config, allowing it
> > to pull from a particular remote base and map it to the local base. Then
> > it's up to the sysadmin to create a complete cn=config hierarchy
> > somewhere else on the master server and let the slaves pick it up. That
> > would address all of the issues of differentiation, at the cost of a
> > little bit of redundancy on the master.
>
> I'm not too fond of the proposed olcServerMatch, it appears to me to
> create a cluttered config database that requires you to match these
> attribute values to see the currently active configuration.  Should it
> be added though, then I would prefer it to be defined as range(s) of
> serverIDs rather than a pattern to match.  Regexp matching of integer
> ranges is always awkward..

Yes, I agree, it would make things cluttered and the complexity could easily 
get out of hand. In retrospect I'm not so fond of the idea.

> So, I would definitely prefer this syncrepl solution, especially if
> syncrepl was also extended with a (list of?) locally evaluated ldap URLs
> that an entry must match (or not match?) for the syncrepl stanza to
> accept it.  Entries received from the producer, or found in the local
> database upon startup, should be ignored by the syncrepl stanza unless
> it do (not) match any of these URLs.

> This would allow a syncrepl stanza to maintain only parts of a local
> database, and one stanza could be used to pull in the specialized
> database configuration from one location, others to fetch common parts
> like the acl and schema configurations from other locations.

That sounds even more complex. I think you're also touching on ITS#5990, 
allowing a single entry to receive portions of its attributes from multiple 
providers. I'd like to add that feature at some point, but I don't think now 
is the right time. (Unless someone shows us a working patch already...)

> Hm, it might be sufficient with a syncrepl option that makes it match
> entries against its configured searchbase and filter, and ignore entries
> that fails to match.  But not equally flexible.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/