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