[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    range search on Generalized Time attribute
From:       Marco Schirrmeister <marco () schirrmeister ! net>
Date:       2012-09-28 15:48:30
Message-ID: 43E8A4E5-EDE5-4ABE-A120-5DC5DD5270A5 () schirrmeister ! net
[Download RAW message or body]


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(a)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



[prev in list] [next in list] [prev in thread] [next in thread]