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

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

To: Howard Chu <hyc@symas.com>
Subject: RE: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
From: Robert Hanson <Robert.Hanson@Calabrio.com>
Date: Thu, 30 Jul 2009 13:33:16 -0500
Accept-language: en-US
Acceptlanguage: en-US
Cc: "openldap-technical@openldap.org" <openldap-technical@openldap.org>
Content-language: en-US
In-reply-to: <4A71E3BA.4080708@symas.com>
References: <7A4A1C3056D0EB46BD030FF762B77BFA12B7F51518@calex01.Calabrio.ld> <4A71E3BA.4080708@symas.com>
Thread-index: AcoRQgWg/WGwG7nBQxSSlLhzA1EKsgAADlfw
Thread-topic: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)

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?



-----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
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Follow-Ups:
- Re: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
  - From: Jonathan Clarke <jonathan@phillipoux.net>

References:
- RE: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
  - From: Robert Hanson <Robert.Hanson@Calabrio.com>
- Re: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
  - From: Howard Chu <hyc@symas.com>

Prev by Date: Re: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
Next by Date: Re: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
Index(es):
- Chronological
- Thread