--001a11c36ad2fcb4a204ede39c11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/12/19 Christian Kratzer <[email protected]> > Hi, > > On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote: > <snipp/> > >> I sent it by mail but I think it is too big and queued. So here is all >> >> configuration and test result: >> >> http://pastebin.com/earKiHnH >> > > I have not worked trhough all your examples and configs yet as I am > travelling at the moment but things seem quite clear to me. > > > The password lock from you slaves never arrives on your master as you > have not configured referrals or any other kind of replication of state > from your slave to your master. > > That means the data on the masters and the slaves is inconsistent. > > As syncrepl as you use it always replaces the entire entry any changes > from the master will complelete overrite anything on the slaves. > > There is no merging of data in syncrepl. > If you take time to read all I sent, you will see that a first modification on the master DO NOT modifiy ppolicy attributes on the slave, the second modification do. Whatever you think, there is a bug here. If you read with caution the ppolicy draft, you will see that pwdAccountLockedTime and some other attributes SHOULD NOT be replicated on read-only replicas. > > This is working as designed and is not a bug by my understanding. > > We disagree a lot on this point. > You have at least following two options from what I see: > > 1. configure referrals and chaining so password locks etc... on the slav= e > get forwarded to the masters and replicated back to the slave. > > This means that you need to configure lcPPolicyForwardUpdates: TRUE > and chaining on your slave. > I tested it with success (almost, see ITS#7767 and ITS#7768) > > 2. configure multimaster replication so password locks get replicated > to your master. > > I did not test if the bug occurs in multimaster, but I think not. > You should close this ITS and we can discuss anything further on the > regular mailing lists. > > As said above, I am pretty sure there is a bug. Maybe an OpenLDAP developer should give its opinion on this ITS. Cl=E9ment. --001a11c36ad2fcb4a204ede39c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/19 Christian Kratzer <span dir=3D"ltr"><<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>></span><br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"im">Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> I sent it by mail but I think it is too big and queued. So here is all<div = class=3D"im"><br> configuration and test result:<br> <br> <a href=3D"http://pastebin.com/earKiHnH"; target=3D"_blank">http://pastebin.= com/earKiHnH</a><br> </div></blockquote> <br> I have not worked trhough all your examples and configs yet as I am<br> travelling at the moment but things seem quite clear to me.<br></blockquote= ><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The password lock from you slaves never arrives on your master as you<br> have not configured referrals or any other kind of replication of state<br> from your slave to your master.<br> <br> That means the data on the masters and the slaves is inconsistent.<br> <br> As syncrepl as you use it always replaces the entire entry any changes<br> from the master will complelete overrite anything on the slaves.<br> <br> There is no merging of data in syncrepl.<br></blockquote><div><br><br><br><= /div><div>If you take time to read all I sent, you will see that a first mo= dification on the master DO NOT modifiy ppolicy attributes on the slave, th= e second modification do. Whatever you think, there is a bug here.<br> </div><div><br><br><br></div><div>If you read with caution the ppolicy draf= t, you will see that pwdAccountLockedTime and some other attributes SHOULD = NOT be replicated on read-only replicas.<br></div><div><br>=A0</div><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <br> This is working as designed and is not a bug by my understanding.<br> <br></blockquote><div><br><br></div><div>We disagree a lot on this point.<b= r><br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You have at least following two options from what I see:<br> <br> 1. =A0configure referrals and chaining so password locks etc... on the slav= e<br> =A0 =A0 get forwarded to the masters and replicated back to the slave.<br> <br> =A0 =A0 This means that you need to configure lcPPolicyForwardUpdates: TRUE= <br> =A0 =A0 and chaining on your slave.<br></blockquote><div><br><br></div><div= >I tested it with success (almost, see ITS#7767 and ITS#7768)<br></div><div= >=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <br> 2. =A0configure multimaster replication so password locks get replicated<br= > =A0 =A0 to your master.<br> <br></blockquote><div><br><br></div><div>I did not test if the bug occurs i= n multimaster, but I think not.<br><br>=A0<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> You should close this ITS and we can discuss anything further on the<br> regular mailing lists.<div class=3D"HOEnZb"><div class=3D"h5"><br></div></d= iv></blockquote><div><br><br><br><br></div><div>As said above, I am pretty = sure there is a bug. Maybe an OpenLDAP developer should give its opinion on= this ITS.<br> <br><br>Cl=E9ment.<br></div></div></div></div> --001a11c36ad2fcb4a204ede39c11--
