Issue 6329 - memberof overlay doesn't update entryCSN
Summary: memberof overlay doesn't update entryCSN
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-13 14:04 UTC by msmith@cbnco.com
Modified: 2014-08-01 21:04 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description msmith@cbnco.com 2009-10-13 14:04:48 UTC
Full_Name: Michael Smith
Version: 2.4.18-55.1
OS: SLES11 (SUSE)
URL: 
Submission from: (NULL) (207.164.182.8)


Hi,

It looks like the memberof overlay doesn't update a user object's entryCSN when
a group object is changed. I believe this causes trouble with syncrepl, at least
in a multi-master configuration: if one node is down when the group object is
changed, it won't know it needs to update the user object when it comes back.

I'm a little confused because while the entryCSNs don't change on the server
where the group is updated, they do change on the other servers in the
replication group. For example, if I add a user to a group on node 2, the user's
entryCSN on node 2 might be "20091008032402.932100Z#000000#002#000000": old
timestamp, correct server ID. On node 1 the entryCSN might be
"20091008032142.915412Z#000000#002#000000": current timestamp, correct server
ID.

I'm using syncrepl with refreshAndPersist and syncprov. The memberof overlay is
using its default configuration. In the stacking order, memberof comes before
syncprov, but it behaved the same way in both orders. All nodes are configured
with memberof and syncprov. The servers' clocks are in sync (NTP).

There was a thread on openldap-software here:

http://thread.gmane.org/gmane.network.openldap.general/45790/focus=45808

This is what my configuration looks like on node 1:

dn: cn=config
# ...
olcServerID: 1

dn: olcDatabase={1}hdb,cn=config
# ...
olcAccess: {0}to attrs=userPassword by self write
    by dn.subtree="ou=service,dc=dom" read by * auth
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to attrs=userPKCS12 by self read by * none
olcAccess: {3}to * by * read
olcDbIndex: objectclass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcLimits: {0}dn.subtree="ou=service,dc=dom" time.soft=unlimited
    time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcSyncrepl: {0}rid=002 provider=ldap://ldap2.dom
    binddn="cn=repluser,ou=service,dc=dom" bindmethod=simple
    credentials=xxxxxx searchbase="dc=dom" attrs="*,+"
    type=refreshAndPersist schemachecking=off
    tls_cacert=/etc/openldap/ssl/ca.crt tls_reqcert=demand
    interval=00:00:05:00 retry="60 +"
olcMirrorMode: TRUE

dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
olcOverlay: {1}memberof

dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcSyncProvConfig
olcSpCheckpoint: 100 10
olcSpSessionlog: 1000
olcOverlay: {0}syncprov

Node 2 looks the same, but with olcServerID: 2 and provider=ldap://ldap1.dom.

Thanks,
Mike
Comment 1 ando@openldap.org 2009-10-14 18:35:57 UTC
> It looks like the memberof overlay doesn't update a user object's entryCSN
> when
> a group object is changed. I believe this causes trouble with syncrepl, at
> least
> in a multi-master configuration: if one node is down when the group object
> is
> changed, it won't know it needs to update the user object when it comes
> back.

Should be fixed in HEAD (one-line fix, see overlays/memberof.c 1.25 -> 1.26).

Please test.  Thanks, p.

Comment 2 ando@openldap.org 2009-10-14 18:36:58 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Bugs
Comment 3 msmith@cbnco.com 2009-10-15 04:23:57 UTC
On Wed, 14 Oct 2009, masarati@aero.polimi.it wrote:

> Should be fixed in HEAD (one-line fix, see overlays/memberof.c 1.25 -> 1.26).
> 
> Please test.  Thanks, p.

Thanks - I applied this to openldap 2.4.19 and the entryCSNs now match on 
all nodes, as long as they're all up when a group is modified.

I still get something strange if one node is down: if I remove a user from 
a group on the working node, then bring the failed node back, the failed 
node doesn't sync the modified group and user objects. For example, if I 
remove testuser3 from testgroup2 while node 2 is down, then bring node 2 
back, I get this on node 1:

dn: uid=testuser3,ou=people,dc=dom
memberOf: cn=testgroup1,ou=group,dc=dom
entryCSN: 20091015040419.455869Z#000000#001#000000

dn: cn=testgroup2,ou=group,dc=dom
member: uid=testuser2,ou=people,dc=dom
entryCSN: 20091015040419.455869Z#000000#001#000000

And this on node 2:

dn: uid=testuser3,ou=people,dc=dom
memberOf: cn=testgroup2,ou=group,dc=dom
memberOf: cn=testgroup1,ou=group,dc=dom
entryCSN: 20091015033445.046089Z#000000#002#000000

dn: cn=testgroup2,ou=group,dc=dom
member: uid=testuser2,ou=people,dc=dom
member: uid=testuser3,ou=people,dc=dom
entryCSN: 20091015033233.354687Z#000000#001#000000

I don't have this problem with changes that don't involve member/memberOf 
attributes. For example, I can add a description attr to the group object 
while node 2 is down, and when I bring it back up, it picks up the change.

On both nodes I've got the memberof and syncprov overlays turned on, in 
that order.

dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
olcOverlay: {0}memberof

dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcSyncProvConfig
olcSpCheckpoint: 100 10
olcSpSessionlog: 1000
olcOverlay: {1}syncprov


Thanks,

Mike

Comment 4 Quanah Gibson-Mount 2009-10-30 18:15:57 UTC
changed notes
changed state Test to Release
Comment 5 Howard Chu 2009-11-30 05:38:18 UTC
changed notes
changed state Release to Closed
Comment 6 OpenLDAP project 2014-08-01 21:04:25 UTC
fixed in HEAD
Fixed in RE24