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 <[email protected]> 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/+listing-archive-extra >> >> 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 >
