Re: (ITS#5065) out of order ctxcsn from old entryCSN

[hyc@symas.com]

donn@u.washington.edu wrote:
> Full_Name: Donn Cave
> Version: 2.4.4
> OS: RH Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (128.95.135.150)
> 
> 
> Old entryCSN values imported into the data from another server, can crash
> replicas.
> 
> In loop at top of syncrepl_updateCookie, replica encounters a syncCookie whose
> value is less than its matching si_cookieState->cs_val.  This breaks out of the
> inner loop, and the outer loop, without copying anything into `first', so
> slap_queue_csn crashes on the null csn.  Both are element 0 of their respective
> arrays.  I assume it is no surprise that syncCookie takes its value from an
> entryCSN attribute.
> 
> To duplicate, add an entry with an explicit entryCSN, with value less than the
> current contextCSN.  In my case, the entryCSN is of the format without the
> `decimal fraction' field, but I doubt that matters.
> 
> I don't want to say OpenLDAP needs to support this, but maybe it would be better
> to catch the problem in the master, than crash the replicas.

You didn't mention how your syncrepl is configured but it seems that this can 
only occur for refreshAndPersist mode, with old entries being ldapadd'd to the 
running master. As you say, this is not a supported mode of operation. New data 
in the server should always have a new entryCSN as well. In fact, since 
entryCSN is NO-USER-MODIFICATION it shouldn't even be possible to add entries 
this way to a running server. Before we can "catch the problem in the master" 
we need more information on how the problem was caused.

As for crashing the replicas - the only sure solution is to patch the code in 
the replicas - "catching the problem in the master" isn't really a proper 
solution anyway.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/