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

Logged in as guest

Viewing Software Bugs/6329
Full headers

From: msmith@cbnco.com
Subject: memberof overlay doesn't update entryCSN
Compose comment
Download message
State:
0 replies:
2 followups: 1 2

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 13 Oct 2009 14:04:48 +0000
From: msmith@cbnco.com
To: openldap-its@OpenLDAP.org
Subject: memberof overlay doesn't update entryCSN
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

Followup 1

Download message
Date: Wed, 14 Oct 2009 20:35:57 +0200 (CEST)
Subject: Re: (ITS#6329) memberof overlay doesn't update entryCSN
From: masarati@aero.polimi.it
To: msmith@cbnco.com
Cc: openldap-its@openldap.org
> 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.



Followup 2

Download message
Date: Thu, 15 Oct 2009 00:23:57 -0400 (EDT)
From: Michael Smith <msmith@cbnco.com>
To: masarati@aero.polimi.it
cc: openldap-its@openldap.org
Subject: Re: (ITS#6329) memberof overlay doesn't update entryCSN
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


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