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