Hi,
Le Ven 29 mai 2009 16:11, Howard Chu a écrit :
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.
Wouldn't it be possible to simply extend the attribute name to make it match a server? Eg: olcAccess;server1: ... olcAccess;server2: ...
That would be IMHO more clear than any related regexp-attribute.
Regards, Raphaël Ouazana.
Raphaël Ouazana-Sustowski wrote:
Hi,
Le Ven 29 mai 2009 16:11, Howard Chu a écrit :
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.
Wouldn't it be possible to simply extend the attribute name to make it match a server? Eg: olcAccess;server1: ... olcAccess;server2: ...
That would be IMHO more clear than any related regexp-attribute.
Yes, but it's clumsy, particularly if you want one value to apply to multiple servers.
-
Howard Chu -
Raphaël Ouazana-Sustowski