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

range search on Generalized Time attribute


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_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.
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
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