On 30/07/2009 20:33, Robert Hanson wrote:
Thanks Howard. How do I send the manageDSAit control using the C functions?
This looks like it is a workaround to the underlying problem, where some nodes that are created as regular (non-glue) nodes become glue nodes. According to the ldap administration guide (http://www.openldap.org/doc/admin24/referrals.html#The%20ManageDsaIT%20Contr...) it should not be used when managing regular entries, which these are supposed to be.
Why do I get these "glue" items anyway?
I recall getting some similar glue entries when trying out multimaster replication a while back. Unfortunately I don't recall exactly why.
However, if you take a look at the output from "loglevel stats sync", as of starting the replication, there may be an indication there. If you post your config and some logs here we could take a look.
-----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:
- 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.
- 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.
========
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