-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Thursday, July 30, 2009 1:18 PM
To: Robert Hanson
Cc: openldap-technical@openldap.org
Subject: Re: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
Robert Hanson wrote:
What I need is to have the "glue" items returned as part of the search.
It looks to me like I can get nodes that are "glue" nodes to be part
of the results by commenting out these lines:
in src\servers\slapd\back-bdb\search.c, lilnes 908-91
if ( !manageDSAit&& is_entry_glue( e )) {
goto loop_continue;
}
If I comment out these lines, then I get the results I'm looking for.
If you send the manageDSAit control, you'll also get the results. Mucking with
the code is not a good idea.
Are there any other implications to the "glue" nodes? It looks like I'm
able to edit and delete these nodes as well. But there is code in
delete.c, modify.c, modrdn.c that worry about glue nodes.
Another option would be to redefine the is_entry_glue macro to always
return false. Is that a better approach?
No.
------------------------------------------------------------------------
*From:* Robert Hanson
*Sent:* Thursday, July 30, 2009 11:08 AM
*To:* 'openldap-technical@openldap.org'
*Subject:* entries exist in ldap (as glue entries), but are missing from
the tree (v2.4.16)
Is this bug ITS#4626?
Not likely since that was fixed 2-3 years ago...
Or is there a workaround?
====
Using a build of 2.4.16 on RedHat linux; in a multi-master environment
with 2 nodes. On both nodes, I have a tree that has a node "ou=Company,
o=MyCompanyName". Under that are several nodes that are "glue" nodes.
Following those is a actual data node.
Slapd 2.4.16, built from source, running on redhat linux)
I have seen this occur several times on various test systems with
similar configurations.
The data in these nodes is inserted, in the proper order, (parent then
children) using ldap client calls (ldap_add_s). Later, when I go to look
at the output of slapcat, I see that some nodes are replaced with "glue"
nodes.
Questions:
1) Why are these glue nodes created? Is there a known bug that will
cause existing nodes to be deleted without the children being deleted?
No.
Is this an issue in replication? (where syncrepl needs to create a node
where the parent does not exist). Is that why the glue nodes are created
later?
Possibly.
2) How can I change the "glue" to some other class? Can that be done
programmatically?
If those entries belong there, syncrepl will automatically replace them with
their correct values when those entries next get replicated. So performing a
modify on one of the entries on the master should cause it to replicate across.
3)
========
This is a dump of slapcat (with unnecessary nodes removed)
dn: o=MyCompanyName
objectClass: organization
o: MyCompanyName
structuralObjectClass: organization
entryUUID: feb5b352-2eb7-102d-8c1f-f1b463e2c47e
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20081015034921Z
entryCSN: 20081015034921.418938Z#000000#000#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20081015034921Z
contextCSN: 20090728202448.877262Z#000000#001#000000
contextCSN: 20090728202123.336320Z#000000#002#000000
dn: ou=Company,o=MyCompanyName
ou: Company
description: 3.0.0
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: feb7a41e-2eb7-102d-8c28-f1b463e2c47e
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20081015034921Z
entryCSN: 20081015034921.432024Z#000000#000#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20081015034921Z
dn: lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: 0136f8e0-0ff7-102e-8da5-59a5102cad9a
creatorsName: cn=Client,ou=People,o=MyCompanyName
createTimestamp: 20090728191715Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: ou=Servers,lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: 014e7632-0ff7-102e-8db3-59a5102cad9a
creatorsName: cn=Client,ou=People,o=MyCompanyName
createTimestamp: 20090728191715Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: ou=Application Data,lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: e5a152de-0fff-102e-923c-cf0948a0ceb1
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20090728202054Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: appName=Configurations,ou=Application Data,lcc=Call Center
1,ou=Company,o=
MyCompanyName
entryUUID: e5a299f0-0fff-102e-923d-cf0948a0ceb1
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20090728202054Z
structuralObjectClass: applicationUnit
appName: Configurations
objectClass: applicationUnit
entryCSN: 20090728202143.649526Z#000000#001#000000
modifiersName: cn=Client,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202143Z