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. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
