Pierangelo Masarati wrote:
Nikos Voutsinas wrote:
do_search
dnPrettyNormal: <dc=foo,dc=bar>
<<< dnPrettyNormal: <dc=foo,dc=bar>, <dc=foo,dc=bar> SRCH "dc=foo,dc=bar" 1 0 0 0 0 begin get_filter PRESENT end get_filter 0 filter: (objectClass=*) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: hasSubordinates objectClass
conn=0 op=5 SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" conn=0 op=5 SRCH attr=hasSubordinates objectClass slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> limits_get: conn=0 op=5 dn="uid=manager,dc=foo,dc=bar" [rw] searchDN: "dc=foo,dc=bar" -> "dc=foo,dc=bar,dc=foo,dc=bar"
dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>
<<< dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>, <dc=foo,dc=bar,dc=foo,dc=bar> str2filter "(objectClass=*)" begin get_filter PRESENT end get_filter 0 => bdb_search bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar") => bdb_dn2id("dc=bar,dc=foo,dc=bar") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
The manageDSAit control (2.16.840.1.113730.3.4.2) seems to be the key to the issue you're facing; in fact, when selecting the appropriate database, if a request is done with the local suffix select_backend() fails when manageDSAit is set. I don't quite understand this, but it results in selecting the only remaining database that matches the request DN, namely the "" database. The offending code is
if( manageDSAit && len == dnlen && !SLAP_GLUE_SUBORDINATE( be ) ) { continue; }in backend.c; to me, it looks a bit obscure.
This one sounds quite different from #4958 and rather irrelevant. Would you like me to file another ITS for this?
Nikos