--001636988beae98b80047830ba81 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
pitpalme@gmail.com wrote:
masarati@aero.polimi.it wrote:
pitpalme@gmail.com wrote:
I do see attributes reflecting state after "modify" (which changes
"sn" attribute). Where exactly should I expect to see a note about "glue state"? Is output from "-d Any" helpful to figure what's going on (or wrong)?
My understanding of your previous message was that you got a positive result from delete, but an "Already exists" from a subsequent add.
That=92s korrekt.
I inferred that you checked about the existence of the object and you go=
t
a negative result.
In my current test scenario I do not check. I assume a non-error on =84delete=93 in fact =84deletes=93, so I just che=
ck if
response code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91).
Apparently, my guess was wrong. In that case, you probably hit
*hmmm* Good idea, thanks. But after reading ITS description I don=92t think it=92s what troubles m=
e.
We don=92t actually neither have =84multi master mode=93, but =84mirror m=
ode=93 and
writes are done only on exactly one server, so there should not be a prob=
lem
with second server producing a concurrent write/modify. I=92d expect the delete to be correctly propagated, but I can=92t check i=
t is
is, simply because I have to little knowledge to read debug log correctly=
.
Follow up:
I modified my test Perl script to do a 'ldapSearch' after deleting and it returns zero as number of found entries. Sadly I have no idea, how to emulate '-MM' when using 'Net::LDAP' and it's search function, so I can't check for 'glue' entries this way. --=20 Regards, Peter
--001636988beae98b80047830ba81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><span dir=3D"ltr"><a href=3D"mailto:pitpalme@gma= il.com">pitpalme@gmail.com</a></span>=A0wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex;"><div class=3D"im"> <a href=3D"mailto:masarati@aero.polimi.it" target=3D"_blank">masarati@aero.= polimi.it</a> wrote:<br> <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <a href=3D"mailto:pitpalme@gmail.com" target=3D"_blank">pitpalme@gmail.com<= /a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do see attributes reflecting state after "modify" (which change= s<br> "sn" attribute).<br> Where exactly should I expect to see a note about "glue state"?<b= r> Is output from "-d Any" helpful to figure what's going on (or= wrong)?<br> </blockquote> <br> My understanding of your previous message was that you got a positive<br> result from delete, but an "Already exists" from a subsequent add= .<br> </blockquote> <br></div> That=92s korrekt.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I inferred that you checked about the existence of the object and you got<b= r> a negative result.<br> </blockquote> <br></div> In my current test scenario I do not check.<br> I assume a non-error on =84delete=93 in fact =84deletes=93, so I just check= if response<br> code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91= ).<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Apparently, my guess was wrong. =A0In that case, you probably hit<br> ITS#6097 <<a href=3D"http://www.openldap.org/its?findid=3D6097" target= =3D"_blank">http://www.openldap.org/its?findid=3D6097</a>>.<br> </blockquote> <br></div> *hmmm* Good idea, thanks.<br> But after reading ITS description I don=92t think it=92s =A0what troubles m= e.<br> We don=92t actually neither have =84multi master mode=93, but =84mirror mod= e=93 and writes are done only on exactly one server, so there should not be= a problem with second server producing a concurrent write/modify.<br> I=92d expect the delete to be correctly propagated, but I can=92t check it = is is, simply because I have to little knowledge to read debug log correctl= y.</blockquote></div><div><br></div>Follow up:<div><br></div><div>I modifie= d my test Perl script to do a 'ldapSearch' after deleting and it re= turns zero as number of found entries.</div> <div>Sadly I have no idea, how to emulate '-MM' when using 'Net= ::LDAP' and it's search function, so I can't check for 'glu= e' entries this way.</div><div>-- <br>Regards, <div>Peter</div></div>
--001636988beae98b80047830ba81--