On Wed, Sep 29, 2010 at 7:55 PM, karthik kumar
<kumarkarthikn@gmail.com> wrote:
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?
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.
2) I m sure that in our application if we are deleting anything we delete all the children nodes,
I mean, if web have a subtree like this one
ou=a --> ou=b --> ou=c
If we delete ou=b, then ou=c also gets deleted. So there shouldnt be any glued objects.
I assumed that ou=b becoming unavailble may be due to replication I mean ... ou=>b may be in ldap1 and unavailable in ldap2 but tyring to update ou=>c in ldap2.
In that case will the original objectClass: (in ldap1) gets replaced by objectClass: glue ?
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 did you tweek anything in ACL so that it never happened again ?
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. href="">mycorp.it" read
by * noneou=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
Karthik.
On Wed, Sep 29, 2010 at 10:49 PM, Marco Pizzoli
<marco.pizzoli@gmail.com> wrote:
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...).
MarcoOn Wed, Sep 29, 2010 at 7:06 PM, karthik kumar
<kumarkarthikn@gmail.com> wrote:
Hi ..
Few of my ldap entries got changed like this
objectClass: glue
objectClass: top
structuralObjectClass: glue
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.
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.
Can you please advice how do I recover my ldap from this.
_________________________________________
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison