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
www.iktek.com
directory.apache.org
