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..
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.
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.