Is this bug ITS#4626? 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? 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?
2) How can I change the "glue" to some other class? Can that be done
programmatically?
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