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