Howdy,
I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong.
I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listin...
The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container:
dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow)
An incoming add for user james looks like
dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow)
Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves.
Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow)
At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed
Any thoughts? -Will
On 14/04/09 5:37, Will Nowak wrote:
Howdy,
I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong.
I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listin...
The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container:
dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow)
An incoming add for user james looks like
dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member
add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com
delete: nisNetgroupTriple
add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow)
Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves.
Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member
add: member member: uid=bobby,ou=people,dc=example,dc=com
delete: nisNetgroupTriple
add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow)
At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed
Any thoughts?
Hi,
This looks the same as ITS 5781 (http://www.openldap.org/its/?findid=5781). As far as I can see the fix for that was indeed released in 2.4.13, though. Have you upgraded the slaves as well as the master? This fix applies to the consumer side.
On a related note, if you're upgrading, I do recommend you move to 2.4.16, which has a few more bug corrections, and is currently considered the best version available.
Regards, Jonathan
All servers in the loop have been upgraded to 2.4.13, then 2.4.15. I note that the container is somewhat nonstandard -- could that be related?
-Will
On Tue, Apr 14, 2009 at 12:15 AM, Jonathan Clarke jonathan@phillipoux.net wrote:
On 14/04/09 5:37, Will Nowak wrote:
Howdy,
I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong.
I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at
https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listin...
The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container:
dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow)
An incoming add for user james looks like
dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member
add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com
delete: nisNetgroupTriple
add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow)
Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves.
Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member
add: member member: uid=bobby,ou=people,dc=example,dc=com
delete: nisNetgroupTriple
add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow)
At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed
Any thoughts?
Hi,
This looks the same as ITS 5781 (http://www.openldap.org/its/?findid=5781). As far as I can see the fix for that was indeed released in 2.4.13, though. Have you upgraded the slaves as well as the master? This fix applies to the consumer side.
On a related note, if you're upgrading, I do recommend you move to 2.4.16, which has a few more bug corrections, and is currently considered the best version available.
Regards, Jonathan
Are you sure that your rules on your slaves are the same - and that there is not a contraint that is stopping your deletes from happing on the replication?
E.G. can you manually delete the entry w/o warning or error on the slaves? Do you have constraint enforcement enabled ?
Sellers
On Apr 14, 2009, at 11:04 AM, Will Nowak wrote:
add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow)
At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed
openldap-software@openldap.org
-
Chris G. Sellers -
Jonathan Clarke -
Will Nowak