On Wed, Sep 29, 2010 at 7:55 PM, karthik kumar <kumarkarthikn(a)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
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
To do this you have to include the syncrepl user with every "access to"
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 * 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.
On Wed, Sep 29, 2010 at 10:49 PM, Marco Pizzoli <marco.pizzoli(a)gmail.com>wrote:
> 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...).
> On Wed, Sep 29, 2010 at 7:06 PM, karthik kumar <kumarkarthikn(a)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
>> 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
>> 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
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.