directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: Replication configuration : second thought
Date Mon, 16 Mar 2009 20:34:21 GMT
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 !

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

View raw message