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.