Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)

[clem.oudot@gmail.com]

--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:
>>
>> 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">&lt;<a href=3D"mailt=
o:ck@cksoft.de" target=3D"_blank">ck@cksoft.de</a>&gt;</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>
&lt;snipp/&gt;<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--