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

Re: Index Usage

On 12/21/2010 07:26 AM, Quanah Gibson-Mount wrote:
--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.
Sorry, I may be being completely dense here. So those errors are because the wrong type of index is being specified in these lines in my config file? 

index           objectClass                     pres,eq
index           gidNumber                       eq
I assumed that "bdb_equality_candidates" would indicate "eq" indexing as being the type of search it's trying to do, is my assumption off the mark?
On the general subject of indexes, is there a way to identify in OpenLDAP/slapd which ones are actually being used? Beyond just basic pam/e-mail stuff I've got a number of java apps and the like not all done in house that could be querying the LDAP server in numerous ways. 




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.
I haven't even the faintest clue how to begin there. Googling is returning nothing useful (but I may be searching for the wrong things), nor is searching through the OpenLDAP documentation. What could be the root cause of such antics? Should I be particularly concerned by it? 


Paul

--
Paul Graydon
Senior Systems Administrator
Hawaii Information Consortium
Internet Portal Partner with the Aloha state
808-695-4619 office
808-695-4618 fax
paul@ehawaii.gov
*********************************************
CONFIDENTIALITY NOTICE:
This email and any attachments are confidential.  If you
are not the intended recipient, you do not have permission
to disclose, copy, distribute, or open any attachments.  If
you have received this email in error, please notify us
immediately by returning it to the sender and delete this
copy from your system.

Thank you.
Hawaii Information Consortium, LLC
**********************************************