Hello, I got this weird behavior: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782212 Summary: # LDAPv3 # base <ou=wheezy,ou=debian,ou=fai,ou=configs,ou=systems,dc=mcmic,dc=test> with scope oneLevel # filter: objectClass=FAIbranch # requesting: ALL #
# wheezy, debian, fai, configs, systems, mcmic.test dn: ou=wheezy,ou=debian,ou=fai,ou=configs,ou=systems,dc=mcmic,dc=test
This dn should not be in the results as it’s the base and the scope is oneLevel. As I managed to build slapd from http://www.openldap.org/software/download/ and reproduce the problem I thought I should ask here if anyone already encountered this kind of problems. It only happens with MDB, with this particular base and filter (filter "ou=wheezy" for instance works correctly).
Any idea what the root of this problem could be?
--On Thursday, April 09, 2015 5:44 PM +0200 Côme BERNIGAUD come.bernigaud@opensides.be wrote:
Any idea what the root of this problem could be?
Already reported and fixed in OpenLDAP. It will be part of the OpenLDAP 2.4.41 release:
Fixed slapd-mdb one-level search (ITS#7975)
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Côme BERNIGAUD wrote:
Hello, I got this weird behavior: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782212 Summary: # LDAPv3 # base <ou=wheezy,ou=debian,ou=fai,ou=configs,ou=systems,dc=mcmic,dc=test> with scope oneLevel # filter: objectClass=FAIbranch # requesting: ALL #
# wheezy, debian, fai, configs, systems, mcmic.test dn: ou=wheezy,ou=debian,ou=fai,ou=configs,ou=systems,dc=mcmic,dc=test
This dn should not be in the results as it’s the base and the scope is oneLevel. As I managed to build slapd from http://www.openldap.org/software/download/ and reproduce the problem I thought I should ask here if anyone already encountered this kind of problems. It only happens with MDB, with this particular base and filter (filter "ou=wheezy" for instance works correctly).
Any idea what the root of this problem could be?
ITS#7975, fixed in RE24 for 2.4.41
openldap-technical@openldap.org
-
Côme BERNIGAUD -
Howard Chu -
Quanah Gibson-Mount