Hi, I had the same problem some times ago. 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. I mean, if you have a subtree like this one ou=a --> ou=b --> ou=c 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. 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. Suggestion: check with slapacl if your entry is accessible by clients (modifiers, master replicas, ecc...). Marco On Wed, Sep 29, 2010 at 7:06 PM, karthik kumar <kumarkarthikn(a)gmail.com&gt;wrote: -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

Hi, On Wed, Sep 29, 2010 at 7:55 PM, karthik kumar <kumarkarthikn(a)gmail.com&gt;wrote: 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. This is the result of my experience, so I'm ready to be contradicted. Are you sure of that? 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. 3) Can you advice how did you ultimately removed all the glued objects and First of all I corrected my ACL. It depends strongly on the specific environment. To do this you have to include the syncrepl user with every "access to" statement. On top of my ACL I have a special one for the userPassword attribute: access to attrs=userPassword by self write by anonymous auth by dn.one="ou=utenze_tecniche_openldap,ou=Gestori,dc=lan,dc= mycorp.it" read by * none ou=utenze_tecniche_openldap,ou=Gestori,dc=lan,dc=mycorp.it is a special "container" of syncrepl users which needs to have access to ALL my DIT. Every other "access to" directive has a *line* like this one: --> by dn.children="ou=Gestori,dc=lancse,dc=csebo.it" read After this check, you could proceed with the sanitizing of your data. 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. On the other ones I simply stopped the OpenLDAP engine, deleted my entire db, restarted and let the db populate by the first system. 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. Hope this helped. Regards Marco Thanks -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison