Hi,

OpenLDAP 2.4.32 and also tried with latest RE24 BDB 4.8.30

My DB_CONFIG looks like this.

set_lk_detect DB_LOCK_DEFAULT set_flags DB_TXN_NOSYNC set_flags DB_LOG_AUTOREMOVE set_lg_max 10485760 set_cachesize 0 1073741824 1 set_lk_max_locks 4000 set_lk_max_lockers 4000 set_lk_max_objects 4000 set_lg_regionmax 262144 set_lg_bsize 20971520 set_lg_dir /var/lib/ldap2.4/ogilvy.com/bdb/

In our stage directory I noticed a range search is not returning anything on a specific attribute with generalizedTime syntax. On production it works fine.

Here is an example command. $ ldapsearch -x -H ldaps://ds71 -D cn=manager,dc=ogilvy,dc=com -w 'secret' -b ou=people,dc=ogilvy,dc=com -LLL '(&(lastchangeDate<=20111107235959Z)(lastchangeDate>=20111107151200Z))' dn lastchangedate $

I know my entry falls in that range. $ ldapsearch -x -H ldaps://ds71 -D cn=manager,dc=ogilvy,dc=com -w 'secret' -b ou=people,dc=ogilvy,dc=com -LLL '(uid=marco.schirrm*)' lastchangedate dn: uid=marco.schirrmeister@ogilvy.com,ou=people,dc=ogilvy,dc=com lastchangeDate: 20111107151301Z $

The attribute is indexed. index lastchangeDate eq

Schema has this. SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch

I tried recreating the index, but all that did not help. Same problem exists if I use bach-hdb.

I tried that same dataset with back-mdb and the search returned what I expected. So I thought it's maybe Berkeley DB bug.

I then tried bdb 5.3.15 some time ago and also the latest 5.3.21. I see the same issue with this versions.

I first thought it's the amount of entries that cause that issue. It's not really much, but stage has less the prod. So tried to create different test datasets to see if I can reproduce it. I was not able to reproduce it with the test datasets. The ldapsearch always returned what I wanted.

I'm now a little bit lost if my DB_CONFIG settings are maybe bad. Or if it is something in Berkeley DB or OpenLDAP.

Any ideas? I'm going to switch to mdb soon. But was wondering if that is something serious or not.

Here is the slapd.conf. I omitted all the schema includes and index lines.

include /etc/openldap2.4/slapd.access.ogilvy.conf pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib64/oldap24/openldap2.4 moduleload back_monitor.la moduleload accesslog.la moduleload syncprov.la moduleload auditlog.la TLSCertificateFile /etc/pki/tls/certs/ogilvy.com.crt TLSCertificateKeyFile /etc/pki/tls/private/ogilvy.com.rsa TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt loglevel stats sasl-secprops noplain,noanonymous,noactive serverID 40 ldaps://ds71.ogilvy.com database bdb suffix "dc=ogilvy,dc=com" rootdn "cn=manager,dc=ogilvy,dc=com" rootpw FooBarBaz directory /var/lib/ldap2.4/ogilvy.com limits dn.exact="cn=manager,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="uid=replicator,ou=admin,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits group/ogilvyGroup/uniqueMember="cn=svcgrp-unlimitedsearch,ou=groups,dc=ogilvy,dc=com" size.soft=unlimited size.hard=unlimited cachesize 150000 dirtyread sizelimit 90000 checkpoint 256 5 conn_max_pending_auth 2000 idlcachesize 450000 dncachesize 150000 monitoring on overlay syncprov syncprov-checkpoint 256 5 syncprov-sessionlog 5000

database config rootdn "cn=admin,cn=config" rootpw FooBarBaz include /etc/openldap2.4/slapd.access.config.conf

database monitor rootdn cn=monitor rootpw FooBarBaz

-- Marco