Kurt D. Zeilenga wrote:
We can certainly use internally either a CSN or a timestamp which has
sufficient resolution such that no two changes ever have the same
stamp, but we'll always have the issue that the party were
LDAPsync'ing with uses the other, or something else. So, we need to
support conversion as well, or something standard.
I choose CSN because, at the time, timestamps in most implementations
didn't have the resolution necessary, and there was some effort to
standardize CSNs. Today, well, timestamps with many implementations
still don't have the resolution necessary, and efforts to standardize
CSNs are, though not completely stalled, certainly not moving
quickly.
Right.
Well, my view was that the introduction of LDAPsync was not going to
be compatible with older releases. However, LDAPsync aside, it would
have been nice to support (slurpd) replication between minor
releases. But slurpd makes that hard to do. With LDAPsync, the
consumer is in control, so it should not be easier to make future
releases more easily support being consumers of current releases, and
vice versa.
Well, "the consumer is in control" is only a benefit for newly written
consumers. For synching with existing servers, we still need a
push-based model where the target slave server doesn't have any
knowledge of the new controls and extensions. Allowing a single provider
to service an arbitrary number of consumers without pre-set
configuration may be an advantage in some service environments where
consumers come and go at random. But in environments where a fixed pool
of servers is operating, it makes more sense to centralize all of the
replication agreements in one place - on the master.
Just to note some of my findings in using syncrepl against Microsoft AD:
using a custom overlay on top of back-ldap makes most of it transparent.
The OL 2.3 approach of storing the contextCSN in the context entry
doesn't really work. Instead, it has to go into a child entry (much like
the 2.2 consumer implementation). To avoid a requirement on extending
the AD schema, I use the applicationEntity objectclass, and store the
contextCSN value in the supportedApplicationContext attribute. Also the
entryUUID attribute is mapped to the MS objectGUID attribute (which is
stored in binary format, just like our normalized entryUUID). Since all
we care about on the consumer side is the contextCSN, we don't need to
have CSNs stored in every replicated entry, so the entryCSN attribute is
just stripped. This approach allows AD to be kept in sync using either
RefreshOnly or RefreshAndPersist mode, although there are (many) other
schema incompatibilities that need to be addressed (like 'cn' being
single-valued in MS's schema).
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
