From clem.oudot@gmail.com Thu Dec 19 14:03:18 2013
From: clem.oudot@gmail.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#7766) Account unlocked in slave after two modifications on a
 master (overlay ppolicy)
Date: Thu, 19 Dec 2013 14:03:17 +0000
Message-ID: <201312191403.rBJE3HN6074275@boole.openldap.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7627459839500314297=="

--===============7627459839500314297==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

--001a11c36ad2fcb4a204ede39c11
Content-Type: text/plain; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable

2013/12/19 Christian Kratzer <ck(a)cksoft.de>

> Hi,
>
> On Wed, 18 Dec 2013, Cl=3DE9ment 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=3D
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=3DE9ment.

--001a11c36ad2fcb4a204ede39c11
Content-Type: text/html; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D3D"ltr"><br><div class=3D3D"gmail_extra"><br><br><div class=3D3D"g=
mail=3D
_quote">2013/12/19 Christian Kratzer <span dir=3D3D"ltr">&lt;<a href=3D3D"mai=
lt=3D
o:ck(a)cksoft.de" target=3D3D"_blank">ck(a)cksoft.de</a>&gt;</span><br><block=
quot=3D
e class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
ol=3D
id;padding-left:1ex">
<div class=3D3D"im">Hi,<br>
<br>
On Wed, 18 Dec 2013, Cl=3DE9ment OUDOT wrote:<br>
&lt;snipp/&gt;<br>
</div><blockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border=
-l=3D
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 =3D
class=3D3D"im"><br>
configuration and test result:<br>
<br>
<a href=3D3D"http://pastebin.com/earKiHnH" target=3D3D"_blank">http://pastebi=
n.=3D
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=3D
><div>=3DA0<br></div><blockquote class=3D3D"gmail_quote" style=3D3D"margin:0 =
0 0 =3D
.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><=3D
/div><div>If you take time to read all I sent, you will see that a first mo=3D
dification on the master DO NOT modifiy ppolicy attributes on the slave, th=3D
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=3D
t, you will see that pwdAccountLockedTime and some other attributes SHOULD =3D
NOT be replicated on read-only replicas.<br></div><div><br>=3DA0</div><blockq=
=3D
uote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #cc=
c =3D
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=3D
r><br><br></div><div>=3DA0</div><blockquote class=3D3D"gmail_quote" style=3D3=
D"ma=3D
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. =3DA0configure referrals and chaining so password locks etc... on the slav=
=3D
e<br>
=3DA0 =3DA0 get forwarded to the masters and replicated back to the slave.<br>
<br>
=3DA0 =3DA0 This means that you need to configure lcPPolicyForwardUpdates: TR=
UE=3D
<br>
=3DA0 =3DA0 and chaining on your slave.<br></blockquote><div><br><br></div><d=
iv=3D
>I tested it with success (almost, see ITS#7767 and ITS#7768)<br></div><div=3D
>=3DA0</div><blockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;=
bord=3D
er-left:1px #ccc solid;padding-left:1ex">

<br>
2. =3DA0configure multimaster replication so password locks get replicated<br=
=3D
>
=3DA0 =3DA0 to your master.<br>
<br></blockquote><div><br><br></div><div>I did not test if the bug occurs i=3D
n multimaster, but I think not.<br><br>=3DA0<br></div><blockquote class=3D3D"=
gm=3D
ail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
=3D
ft:1ex">

You should close this ITS and we can discuss anything further on the<br>
regular mailing lists.<div class=3D3D"HOEnZb"><div class=3D3D"h5"><br></div><=
/d=3D
iv></blockquote><div><br><br><br><br></div><div>As said above, I am pretty =3D
sure there is a bug. Maybe an OpenLDAP developer should give its opinion on=3D
 this ITS.<br>
<br><br>Cl=3DE9ment.<br></div></div></div></div>

--001a11c36ad2fcb4a204ede39c11--



--===============7627459839500314297==--