directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Replication configuration : second thought
Date Mon, 16 Mar 2009 21:49:10 GMT
Howard Chu wrote:
> Emmanuel Lecharny wrote:
>> Based on the previous elements, let's define what can be the
>> configuration, assuming we have one replication subsystem.
>> consumer :
>> - replicaId, an int between [0,999] : identify uniquely this consumer
> Before you get too far, I should point out that replicaID is only 
> significant within a single server. It's just a means of labeling each 
> individual consumer config within one server. There is no requirement 
> for uniqueness across multiple servers.
> For OpenLDAP's MMR, we had to introduce the serverID parameter which 
> *is* required to be unique across all masters. This goes into the sid 
> field of the CSN, so it's a hex value [0-fff]. And also note that 0 is 
> only valid for single-master replication, for MMR the sid must be 
> non-zero.
>> - for each replication peer :
>>    o type, the replication type (RefreshAndPersist or ResfreshOnly).
>> Default to RefreshAndPersist.
>>    o interval, if type is ResfreshOnly : a hh/mm/ss interval between 
>> each
>> content polling
>>    o search base, the base DN to start the search on the producer
>>    o principal, the principal to use in order to connect on the producer
>>    o credential, the password to use to connect on the producer
> I don't know if your network layer already handles it, so you haven't 
> mentioned it here, but parameters for timeout / detecting a failed 
> network connection and scheduling retries are also necessary.
>> producer :
>> currently, I see no specific information to set, but it's really a
>> preliminary proposal
> One of the points to RFC4533 is that no producer-side configuration is 
> required, although some optimization is possible.
>> Regarding the principal/credential information, as the passwords are
>> stored crypted using a one-way algorithm, we have to store it in clear.
>> This is not very safe. We can think about a better algorithm, like
>> encrypting the password using a 2 ways algorithm, but that means we have
>> to store a key on the server, which is a breach too. There is no free
>> lunch ...
> Also provide the option of using SASL mechanisms. All of my production 
> syncrepl configs use TLS and certificate-based authentication. You 
> still get stuck needing the plaintext private key, but at least it's 
> not a text string that can be easily spotted and memorized in passing.
>> I'm going to implement this configuration on the replication branch.
>> feel free to comment, and don't really care about the breakage that can
>> introduce in the code I will commit  : it's just there as a starting
>> point, nothing more.
>> Thanks !
Thanks Howard for all the points.
- I think I was a bit confused about the rid/sid, because there are many 
documents all over the internet describing them as integer, or hex. 
After having checked, we already implemented it as a hex value
- We haven't yet added all the network timeout/failure. But we will :)
- The very same for SASL/SSL. In any case, as this is plain LDAP 
protocol, we will benefit from the existing stack.

cordialement, regards,
Emmanuel L├ęcharny

View raw message