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