[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: entryUUID

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