[Date Prev][Date Next]
Re: (ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
- From: firstname.lastname@example.org
- Date: Wed, 17 Sep 2014 01:25:04 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
--On Wednesday, September 17, 2014 3:08 AM +0100 Howard Chu <email@example.com>
> firstname.lastname@example.org wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.4.39
>> OS: Linux 3.11
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (184.108.40.206)
>> Found this at a customer site. They loaded an LDIF file that had the
>> child of an entry, but not the entry itself. slapadd then created a
>> glue entry to account for this, however there some significant problems
>> with this process
>> a) The glue entry is not syntactically correct. There is no RDN value.
>> b) It is impossible to use a filter with ldapsearch to find the entry.
>> It appears the objectClass index is utterly broken.
> Works as designed. Closing this ITS.
Even with -M, it appears impossible to find a specific glued entry, which
is problematic when attempting to find if it indeed exists or not outside
of a slapcat, or trying to parse (in this case) the 306 broken glued
entries that exist in the DB. It would be useful to be able (with -M) to
actually search for and find the specific entry so that the account
management client can then proceed accordingly. Right now, a search for
the specific entry results in error code 32, so then the account management
software attempts to create it, which results in error code 68. The
software then has no way to find the entry and decide if it needs
modification or deletion.
OTOH, it is entirely the clients fault for providing bad input, so I'm not
sure how hard we should chase it. :P
Zimbra :: the leader in open source messaging and collaboration