Re: Index Usage

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Monday, December 20, 2010 12:44 PM -1000 Paul <paul@ehawaii.gov> wrote:



> I'm also seeing odd entries in the ldap logs:
>
> Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates:
> (objectClass) index_param failed (18)
> Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates:
> (objectClass) index_param failed (18)
> Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates:
> (gidNumber) index_param failed (18)

This means those entries are being searched on with a search other than the 
way they are indexed.  No amount of re-running slapindex is going to change 
those messages.

> On a separate note I've found the slapcat doesn't produce an LDIF file
> that slapadd will use, even keeping to the same version of software
> (2.3.37), or importing into newer (2.3.43).
> It always errors after the first entry because it seems to be trying to
> add a user to an ou that doesn't exist yet, which disturbs me slightly
> because the backup infrastructure has been relying on that mechanism for
> recovery.  To create another ldap slave I ended up having to use Apache
> Directory Studio to create the LDIF for import, which slapadd was
> perfectly happy to work with.  I'm not sure if that may be a known bug
> that I'm running up against.  I see a few entries in archives relating to
> it but not much by way of response other than suggests it should work.

It may be producing an out-of-order LDIF file.  You probably need to find 
out why and permanently re-order it.  OpenLDAP 2.4 handles that situation 
correctly.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration