Hi,
Has anyone tried using the memberof overlay with syncrepl?
I'm using openldap 2.4.12-7.18.1 on SLES11. I'd like to do multi-master replication for availability. Most user/group updates will happen only on one node, but password changes could happen anywhere.
A couple of our apps like to see the memberOf attributes. My first thought was that I'd probably only need to run the overlay on one master. Does that sound about right?
At first glance it seems that when memberof modifies user entries, it doesn't update the entryCSN. I'm not sure but I think this might cause some grief for syncrepl.
If I add "testuser1" and "testgroup1" on ldap1, with testuser1 as a member of testgroup1, this is what I get on ldap1:
------- dn: dc=dom entryCSN: 20091005145613.859492Z#000000#000#000000 contextCSN: 20091005184427.691751Z#000000#000#000000 contextCSN: 20091006133430.568898Z#000000#001#000000 contextCSN: 20091005194750.632855Z#000000#002#000000
dn: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.564578Z#000000#001#000000 memberOf: cn=testgroup1,ou=group,dc=dom
dn: cn=testgroup1,ou=group,dc=dom member: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.568898Z#000000#001#000000 -------
testuser1's entryCSN is earlier than testgroup1's, but memberof would have modified testuser1 AFTER testgroup1. This is what shows up on ldap2:
------- dn: dc=dom entryCSN: 20091005145613.859492Z#000000#000#000000 contextCSN: 20091006133430.568898Z#000000#001#000000
dn: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.564578Z#000000#001#000000
dn: cn=testgroup1,ou=group,dc=dom member: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.568898Z#000000#001#000000 -------
Configuration of ldap1:
------- 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}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {0}syncprov
dn: olcOverlay={1}memberof,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}memberof -------
Configuration of ldap2:
------- dn: cn=config # ... olcServerID: 2
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=001 provider=ldap://ldap1.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}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {0}syncprov -------
Here's the log from ldap1. I have the loglevel set to "stats sync":
------- conn=23 op=11 ADD dn="uid=testuser1,ou=people,dc=dom" slap_queue_csn: queing 0x7f4d125ec2c0 20091006133430.564578Z#000000#001#000000 conn=23 op=11 RESULT tag=105 err=0 text= syncprov_sendresp: cookie=rid=001,sid=002,csn=20091006133430.564578Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7f4d1bca6b60 20091006133430.564578Z#000000#001#000000 conn=23 op=12 ADD dn="cn=testgroup1,ou=group,dc=dom" slap_queue_csn: queing 0x7f4d13dee2c0 20091006133430.568898Z#000000#001#000000 syncprov_sendresp: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7f4d1be955b0 20091006133430.568898Z#000000#001#000000 conn=23 op=12 RESULT tag=105 err=0 text= syncprov_sendresp: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 do_syncrep2: cookie=rid=002,sid=001 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) dn_callback : entries have identical CSN cn=testgroup1,ou=group,dc=dom 20091006133430.568898Z#000000#001#000000 syncrepl_entry: rid=002 be_search (0) syncrepl_entry: rid=002 cn=testgroup1,ou=group,dc=dom syncrepl_entry: rid=002 entry unchanged, ignored (cn=testgroup1,ou=group,dc=dom) conn=23 op=13 UNBIND conn=23 fd=29 closed -------
And here's the log on ldap2. There's a "CSN too old" error at the bottom.
------- do_syncrep2: cookie=rid=001,sid=002,csn=20091006133430.564578Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 uid=testuser1,ou=people,dc=dom slap_queue_csn: queing 0x7fece57d0860 20091006133430.564578Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7fece57d2480 20091006133430.564578Z#000000#001#000000 syncrepl_entry: rid=001 be_add (0) slap_queue_csn: queing 0x7fece57d0860 20091006133430.564578Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7fece57d4460 20091006133430.564578Z#000000#001#000000 do_syncrep2: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 cn=testgroup1,ou=group,dc=dom slap_queue_csn: queing 0x7fece57d2480 20091006133430.568898Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7fece57d0850 20091006133430.568898Z#000000#001#000000 syncrepl_entry: rid=001 be_add (0) slap_queue_csn: queing 0x7fece57d2480 20091006133430.568898Z#000000#001#000000 syncprov_sendresp: cookie=rid=002,sid=001 slap_graduate_commit_csn: removing 0x7fece57cea20 20091006133430.568898Z#000000#001#000000 do_syncrep2: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 do_syncrep2: rid=001 CSN too old, ignoring 20091006133430.568898Z#000000#001#000000 -------
Thanks, Mike
Michael Smith msmith@cbnco.com writes:
Hi,
Has anyone tried using the memberof overlay with syncrepl?
I'm using openldap 2.4.12-7.18.1 on SLES11. I'd like to do multi-master replication for availability. Most user/group updates will happen only on one node, but password changes could happen anywhere.
[...] There have been made many fixes since 2.4.12, in particular to syncrepl. I would suggest to update to the last available version (which is as of today 2.4.18) from: http://download.opensuse.org/repositories/network:/ldap:/OpenLDAP:/RE24/SLE_...
If you still experience some errors you should come back.
-Dieter
On Wed, 7 Oct 2009, Dieter Kluenter wrote:
Michael Smith msmith@cbnco.com writes:
Has anyone tried using the memberof overlay with syncrepl?
There have been made many fixes since 2.4.12, in particular to syncrepl. I would suggest to update to the last available version (which is as of today 2.4.18) from: http://download.opensuse.org/repositories/network:/ldap:/OpenLDAP:/RE24/SLE_...
If you still experience some errors you should come back.
Thanks, this is very helpful.
2.4.18 seems to work as long as I run the memberof overlay on both nodes. The stacking order of the overlays (memberof, syncprov) doesn't make a difference as far as I can tell. Does that make sense?
The entryCSNs tend not to match between nodes. For example, if I add testuser5 to a group on node 2, I might get:
node 1: entryCSN: 20091008032142.915412Z#000000#002#000000 node 2: entryCSN: 20091008032402.932100Z#000000#002#000000
Sometimes even the server IDs in the CSNs don't match:
node 1: entryCSN: 20091008031908.047245Z#000000#001#000000 node 2: entryCSN: 20091008032301.666362Z#000000#002#000000
But the other attributes always seems to match. I'm just a bit uneasy about the entryCSNs; I assume they're supposed to be the same across all nodes, right?
Thanks, Mike
On Wed, 7 Oct 2009, Michael Smith wrote:
2.4.18 seems to work as long as I run the memberof overlay on both nodes.
The entryCSNs tend not to match between nodes. For example, if I add testuser5 to a group on node 2, I might get:
node 1: entryCSN: 20091008032142.915412Z#000000#002#000000 node 2: entryCSN: 20091008032402.932100Z#000000#002#000000
This causes problems if one node is down and a group is modified (e.g. remove user) on the other: when the first node comes back, it won't see the change to either the group or the member object.
Mike
openldap-software@openldap.org
-
Dieter Kluenter -
Michael Smith