OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/5973
Full headers

From: rein@openldap.org
Subject: Syncrepl can update more than one csn value
Compose comment
Download message
State:
0 replies:
3 followups: 1 2 3

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 24 Feb 2009 18:56:15 +0000
From: rein@openldap.org
To: openldap-its@OpenLDAP.org
Subject: Syncrepl can update more than one csn value
Full_Name: Rein Tollevik
Version: CVS HEAD
OS: irrelevant
URL: 
Submission from: (NULL) (81.93.160.250)
Submitted by: rein


Syncrepl can update more than one csn value in one operation, but only one can
be passed to syncprov in the csn queue.  Syncprov should instead pick the
updated values from the modify operation.

A patch that fixes this is coming.  This patch depends on the ITS#5972 patch,
and is required for the new test058 to succeed.

Rein Tollevik
Basefarm AS

Followup 1

Download message
Date: Thu, 12 Mar 2009 06:14:42 -0700
From: Howard Chu <hyc@symas.com>
To: rein@OpenLDAP.org
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#5973) Syncrepl can update more than one csn value
rein@OpenLDAP.org wrote:
> Full_Name: Rein Tollevik
> Version: CVS HEAD
> OS: irrelevant
> URL:
> Submission from: (NULL) (81.93.160.250)
> Submitted by: rein
>
>
> Syncrepl can update more than one csn value in one operation, but only one
can
> be passed to syncprov in the csn queue.  Syncprov should instead pick the
> updated values from the modify operation.

The syncrepl patch broke the CSN queue, which has caused out-of-order updates 
in test050. I have reverted it. Every write operation begins with a queued CSN 
and ends by graduating a CSN. You removed the enqueueing step, and so the 
queue contents were invalid.

> A patch that fixes this is coming.  This patch depends on the ITS#5972
patch,
> and is required for the new test058 to succeed.

test058 has the same number of errors with or without the syncrepl patch, so I 
don't think it was relevant to the issues you were addressing.

I'm still skeptical about the syncprov half of the patch. The two patches were 
actually unrelated, the syncprov patch takes effect regardless of the syncrepl 
patch.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
Date: Thu, 12 Mar 2009 06:31:11 -0700
From: Howard Chu <hyc@symas.com>
To: rein@OpenLDAP.org
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#5973) Syncrepl can update more than one csn value
rein@OpenLDAP.org wrote:
> Full_Name: Rein Tollevik
> Version: CVS HEAD
> OS: irrelevant
> URL:
> Submission from: (NULL) (81.93.160.250)
> Submitted by: rein
>
>
> Syncrepl can update more than one csn value in one operation,

False. An operation can only affect one entry. An entry has only one CSN 
(entryCSN is single-valued). Multiple changes may have occurred to an entry 
before a consumer sees it, but the consumer will only see the final result and 
only the last entryCSN.

On the other hand, multiple CSNs may have changed in the cookie that is 
transmitted to the consumer. That's a separate issue...

> but only one can
> be passed to syncprov in the csn queue.

> Syncprov should instead pick the
> updated values from the modify operation.
>
> A patch that fixes this is coming.  This patch depends on the ITS#5972
patch,
> and is required for the new test058 to succeed.
>
> Rein Tollevik
> Basefarm AS
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 3

Download message
Date: Fri, 13 Mar 2009 15:46:37 +0100
From: Rein Tollevik <rein@OpenLDAP.org>
To: hyc@symas.com
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#5973) Syncrepl can update more than one csn value
hyc@symas.com wrote:
> rein@OpenLDAP.org wrote:
>> Syncrepl can update more than one csn value in one operation, but only
one can
>> be passed to syncprov in the csn queue.  Syncprov should instead pick
the
>> updated values from the modify operation.

> The syncrepl patch broke the CSN queue, which has caused out-of-order
updates 
> in test050. I have reverted it. Every write operation begins with a queued
CSN 
> and ends by graduating a CSN. You removed the enqueueing step, and so the 
> queue contents were invalid.

I removed the queuing and graduating of the CSN syncrepl_updateCookie() 
would update, as that only sent one of the (possibly) many values that 
could be updated by that operation.  With the syncprov half of the patch 
the queued patch should never be looked at, meaning that this queuing 
should be unnecessary here.

The ordinary queue/graduation of the CSN received with an updated entry 
is still in place, and should continue to be so.

>> A patch that fixes this is coming.  This patch depends on the ITS#5972
patch,
>> and is required for the new test058 to succeed.
> 
> test058 has the same number of errors with or without the syncrepl patch,
so I 
> don't think it was relevant to the issues you were addressing.

It was only the syncprov half of ITS#5793 patch that was relevant for 
test058.  The syncrepl half of the patch only removes code that should 
be unnecessary..

> I'm still skeptical about the syncprov half of the patch. The two patches
were 
> actually unrelated, the syncprov patch takes effect regardless of the
syncrepl 
> patch.

Yes, the syncprov part of the patch doesn't need the syncrepl half, but 
I found it correct to clean up code that should be made unnecessary by 
that patch.

All updates received during the persistent phase should include an 
updated CSN value, and should already have been transmitted to syncprov 
by the commit/graduate queue and have caused it to update its own csn 
set.  I.e, the syncrepl_updateCookie() replace operation should only 
have caused syncprov to updated its cookie and thereby send NEW_COOKIE 
messages when syncrepl updated the CSN set at the end of the refresh 
phase.  Apparently, there is something that causes this to break.  More 
on that in another message on -devel.

Rein


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org