[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/