[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)



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%20Control) 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:

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





--
--------------------------------------------------------------
Jonathan Clarke - jonathan@phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------