[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4820) More issues with modify opattrs in syncrepl
ando@sys-net.it wrote:
> Full_Name: Pierangelo Masarati
> Version: HEAD (re23?)
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (87.28.220.33)
> Submitted by: ando
>
>
> I've modified syncrepl tests so that producer/consumer comparison includes all
> operational attributes as well. This yields some surprises. For example, after
> a modify, the modifiersName is changed into the consumer's rootdn. This occurs
> because the modified entry returned by syncprov contains the same modifiersName
> as the consumer's copy, so no modifiersName gets appended to the list of
> modifications that's passed to the underlying database. At this point, the
> underlying database adds the missing modify opattrs, thus breaking consistency.
> I've modified syncrepl as to always check if the modify opattrs are present,
> and, if absent, pull them off the entry sent by syncprov. However, in this
> case, it's likely that the order of th attributes breaks between the producer
> and the consumer, thus causing issues at the next check. Maybe a better fix
> would be to allow syncrepl to instruct the database not to create the missing
> modify opattrs. Comments?
I guess we could just set DBFLAG_NOLASTMOD on the db. We really only need to
make sure a structuralObjectClass and entryUUID gets set for an Add operation.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/