Hi,<br><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 7:55 PM, karthik kumar <span dir="ltr">&lt;<a href="mailto:kumarkarthikn@gmail.com">kumarkarthikn@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>

<font face="arial, sans-serif"><span style="border-collapse: collapse;"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse: collapse;">1) I have master-master mode ldap but all the requests are sent to only one of the master. The other one is a mere replica. In this case will objectClass: glue get set?</span></font></div>

</blockquote><div><br>It depends by the grants you assign to the user used for the replication. If you have a replica mechanism active, you change grants on the master withdrawing permission to some object of the tree for the replica user used by the (in this context) slave. At some time the OL slave could revert to represent those entries with objectClass glue.<br>

This is the result of my experience, so I&#39;m ready to be <span id="result_box" class="short_text" lang="en"><span style="" title="">contradicted.</span></span><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



<div><font face="arial, sans-serif"><span style="border-collapse: collapse;">2) I m sure that in our application if we are deleting anything we delete all the children nodes, </span></font></div>

<div><font face="arial, sans-serif"><span style="border-collapse: collapse;"><br></span></font><div>      I mean, if web have a subtree like this one<div class="im"><br>      ou=a  --&gt; ou=b  --&gt; ou=c<br>

</div></div><div>      If we delete ou=b, then ou=c also gets deleted. So there shouldnt be any glued objects. </div><div><br></div><div>   I assumed that ou=b becoming unavailble may be due to replication I mean ...  ou=&gt;b may be in ldap1 and unavailable in ldap2 but tyring to update ou=&gt;c in ldap2. </div>



<div>     In that case will the original objectClass: (in ldap1) gets replaced by  objectClass: glue ?</div></div></blockquote><div><br>Are you sure of that?<br>I mean, as far as I know, a process of deletion of a subtree involves a delete of all objects under that  subtree. So you need to have grants to delete also the children objects.<br>

<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div> 3) Can you advice how did you ultimately removed all the glued objects and did you tweek anything in ACL so that it never happened again ? </div>

</div></blockquote><div><br>First of all I corrected my ACL. It depends strongly on the specific environment.<br>To do this you have to include the syncrepl user with every &quot;access to&quot; statement.<br><br>On top of my ACL I have a special one for the userPassword attribute:<br>

<span style="font-family: courier new,monospace;">access to attrs=userPassword</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">        by self write</span><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;">        by anonymous auth</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">        by dn.one=&quot;ou=utenze_tecniche_openldap,ou=Gestori,dc=lan,dc=<a href="http://mycorp.it">mycorp.it</a>&quot; read</span><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;">        by * none</span><br><br><span style="font-family: courier new,monospace;">ou=utenze_tecniche_openldap,ou=Gestori,dc=lan,dc=<a href="http://mycorp.it">mycorp.it</a></span> is a special &quot;container&quot; of syncrepl users which needs to have access to ALL my DIT.<br>

<br>Every other &quot;access to&quot; directive has a <i>line</i> like this one:<br><span style="font-family: courier new,monospace;">--&gt;   by dn.children=&quot;ou=Gestori,dc=lancse,dc=<a href="http://csebo.it">csebo.it</a>&quot; read</span><br>

<br>After this check, you could proceed with the sanitizing of your data.<br><br>On the first system of my MultiMaster deploy I had to re-slapadd my entire slapcat-ed database, obviously after correcting the LDIF by hand. I took the right info from my previous backups.<br>

On the other ones I simply stopped the OpenLDAP engine, deleted my entire db, restarted and let the db populate by the first system.<br><br>I done this because I could temporary stop my clients from accessing the other ldap servers. In my deploy I used iptables to not permitting the connection so they reverted to another one until the populating end.<br>

<br>Hope this helped.<br>Regards<br>Marco<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div>Thanks</div><div>Karthik. <font color="#888888"><br>

<br></font></div><div><div></div><div class="h5"><div><br></div><div><br><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 10:49 PM, Marco Pizzoli <span dir="ltr">&lt;<a href="mailto:marco.pizzoli@gmail.com" target="_blank">marco.pizzoli@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br>I had the same problem some times ago.<br><br>I could be corrected by someone, but the glue is the way by which the OL system revert to represent entries that are accessible directly.<br>



I mean, if you have a subtree like this one<br>

 ou=a  --&gt; ou=b  --&gt; ou=c<br><br>Assume that your ou=b entry is not available anymore for any reason. The system represent it wuth an entry ou=b of objectClass=glue.<br><br>The cause of my problem was related to bad ACLs. So when my n-way multi-master systems tried to replicate them selves reverted to represent the entry in that way.<br>





Suggestion: check with slapacl if your entry is accessible by clients (modifiers, master replicas, ecc...).<br><br>Marco<div><div></div><div><br><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 7:06 PM, karthik kumar <span dir="ltr">&lt;<a href="mailto:kumarkarthikn@gmail.com" target="_blank">kumarkarthikn@gmail.com</a>&gt;</span> wrote:<br>





<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">Hi .. <div>



<br></div><div>Few of my ldap entries got changed like this </div>

<div><span style="font-family: arial,sans-serif; line-height: 15px;"></span></div><div><br></div><div>objectClass: glue   </div><div>objectClass: top  </div><div>structuralObjectClass: glue</div><div><br></div><div>Those glued entries are not showing up in the ldapsearch. I took a dump and from the ldif file, realized the objectClass/ structuralObjectClass got changed.</div>







<div><br></div><div>I wanted to recover my ldap. So removed all those entries ( including the childnodes ). ldapadd  them back from a previous dump ( which wasnt glued). But after some time when I access those entries from application, they get glued. </div>







<div><br></div><div>Can you please advice how do I recover my ldap from this.</div><div><br></div></span>
</blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br>_________________________________________<br>Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.<br>                    Jim Morrison<br>




</font></blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>_________________________________________<br>Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.<br>                    Jim Morrison<br>