Hi,

if i'm right, the indices are for cached for faster result on ldap-search. My slapd.conf looks like

# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,maildrop,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell                    eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry                            eq,pres,sub

## Note that using the session log requires searching on the entryUUID
#attribute. Setting an eq index on this attribute will greatly benefit the
#performance of the session log on the provider.
## http://www.openldap.org/doc/admin24/replication.html
index entryCSN,entryUUID                                        eq


If your SOGo-Login and Adressbook-search works like expected, you can simply ignore the log messages.

Best
Philipp


Philipp v. Strobl.-Albeg
- PILARKTO.NET -

Zellerstr. 19
70180 Stuttgart
Tel.  +49 711 1215 8269
Fax.  +49 711 6583 089
Mobil +49 151 27039 710


Am 02.10.2012 09:37, schrieb Adi Kriegisch:
Hi!

    i have some entries in my logs like:

  bdb_equality_candidates: (member) not indexed
  bdb_equality_candidates: (displayName) not indexed
  bdb_equality_candidates: (cn) not indexed
  bdb_equality_candidates: (displayName) not indexed
  bdb_equality_candidates: (cn) not indexed
  bdb_equality_candidates: (mail) not indexed
  bdb_equality_candidates: (member) not indexed

  how should i add them to ldap?

  eq, pres, approx, special or sub?
 From the source (servers/slapd/back-bdb/filterindex.c):
bdb_equality_candidates hints at "eq"; bdb_presence_canditates hint at
"pres"...
So "eq" it should be...

  What i know is:

  pres should be used if use [1]searches of the form 'objectclass=person' or 
'attribute=mail' will be used.

    approx MUST be used if use [2]searches of the form 'sn~=person' (a
    'sounds-like' search) will be used.

    eq should be used if [3]searches of the form 'sn=smith' will be used i.e
    no wildcards are included (uses the EQUALITY rule only).

    sub should be used if use [4]searches of the form 'sn=sm*' i.e wildcards
    are included (uses the SUBSTR rule). This rule may be enhanced by a
    using subinitial (optimised for 'sn=s*'), subany (optimised for 'sn=*n*')
    or subfinal(optimised for 'sn=*th'). One or more sub parameters may be
    included.
excellent summary btw.

-- Adi
--
users@sogo.nu
https://inverse.ca/sogo/lists

Reply via email to