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

Logged in as guest

Viewing Software Bugs/8800
Full headers

From: quanah@openldap.org
Subject: MMR: out of date master will ignore history of its own changes
Compose comment
Download message
State:
0 replies:
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 30 Jan 2018 21:04:12 +0000
From: quanah@openldap.org
To: openldap-its@OpenLDAP.org
Subject: MMR: out of date master will ignore history of its own changes
Full_Name: Quanah Gibson-Mount
Version: 2.4.45
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)


Did the following test:

4-way MMR setup, database populated from an initial DB that has history to it

Make several thousand MODs to serverID 1 only
Stop serverID 1
wipe its database
reload serverID 1 from the initial DB

Expected result:
serverID 1 REFRESHes from the other servers to sync up its database

Actual result:
serverID 1 updates its contextCSN to the last change op, but does not sync any
actual changes back, leaving it out of sync with the rest of the cluster.

Followup 1

Download message
Date: Tue, 30 Jan 2018 15:46:46 -0800
From: Quanah Gibson-Mount <quanah@symas.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8800) MMR: out of date master will ignore history of its
 own changes
--On Tuesday, January 30, 2018 9:04 PM +0000 quanah@openldap.org wrote:

> Full_Name: Quanah Gibson-Mount
> Version: 2.4.45
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (47.208.148.239)
>
>
> Did the following test:
>
> 4-way MMR setup, database populated from an initial DB that has history
> to it

Per Howard's suggestion, I commented out lines 2390-2396 in syncprov.c, 
which allows the master to get fed back its own operations on startup.

On the plus side, the database indeed get all the operations sent back. 
There were 1187 entries in the accesslog DBs of all 4 nodes.

On the minus side, while server IDs 2,3, and 4 all agreed on the final 
resulting contextCSN, serverID 1 did not.  Which then broke the ability for 
the nodes to communicate with each other (err=53)

Last entry on serverIDs 1/2/3/4:

dn: reqStart=20180130233019.000017Z,cn=accesslog
objectClass: auditModify
reqStart: 20180130233019.000017Z
reqEnd: 20180130233019.000018Z
reqType: modify
reqSession: 1
reqAuthzID: cn=ldaproot,dc=xxx,dc=yyy
reqDN: dc=xxx,dc=yyy
reqResult: 0
reqMod: contextCSN:= 20180130233019.035885Z#000000#001#000000
reqMod: contextCSN:= 20171130222521.056018Z#000000#002#000000
reqMod: contextCSN:= 20171130222318.939265Z#000000#003#000000
reqMod: contextCSN:= 20171203041258.811473Z#000000#004#000000
reqEntryUUID: 156eb8cc-18e9-1027-80e5-d3f2010890dc


contextCSNs on 2/3/4:
base
contextCSN: 20180130233019.035885Z#000000#001#000000
contextCSN: 20171130222521.056018Z#000000#002#000000
contextCSN: 20171130222318.939265Z#000000#003#000000
contextCSN: 20171203041258.811473Z#000000#004#000000
accesslog
contextCSN: 20180130233019.035885Z#000000#001#000000
contextCSN: 20171130222521.056018Z#000000#002#000000
contextCSN: 20171130222318.939265Z#000000#003#000000
contextCSN: 20171203041258.811473Z#000000#004#000000

contextCSNs on 1:
base
contextCSN: 20180130233019.035885Z#000000#001#000000
contextCSN: 20171130222521.056018Z#000000#002#000000
contextCSN: 20171130222318.939265Z#000000#003#000000
contextCSN: 20171203041258.811473Z#000000#004#000000
accesslog
contextCSN: 20180130233016.137867Z#000000#001#000000
contextCSN: 20171130222521.056018Z#000000#002#000000
contextCSN: 20171130222318.939265Z#000000#003#000000
contextCSN: 20171203041258.811473Z#000000#004#000000


Note that the contextCSN is correct on the database root, but incorrect in 
the accesslog entry.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>



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