--001a11c36ad2fcb4a204ede39c11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/12/19 Christian Kratzer ck@cksoft.de
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:
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:
- 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)
- 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:ck@cksoft.de" target=3D"_blank">ck@cksoft.de</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--