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

Re: backend relay with empty suffix



Pierangelo Masarati wrote:
Nikos Voutsinas wrote: 
My point here is that requests to ldap backend, defined with suffix
"ou=People", are also subject to suffix transformation rules defined in
relay backend, (i suspect because of the empty suffix "", and at least
while searching for attr=hasSubordinates).

Is this the expected behavior? 

No.  And I'm not seeing anything like that (with HEAD/re23 code, which
means after fixing the core dumps you initially reported).

Searches for "ou=People" see the suffix transformations defined for that
database, while searches for anything else see the transformations
defined for the relay database.

Just to make sure we talk about the same thing, I'm posting the relevant
portions of my second slapd.conf (the first one is that resulting from
running test003):

<slapd.conf>
database        bdb
suffix          "ou=Other,dc=example,dc=com"
# ...

database        ldap
suffix          "ou=People"
uri             "ldap://:9011";
overlay         rwm
rwm-suffixmassage       "dc=example,dc=com"

database        relay
suffix          ""
relay           "ou=Other,dc=example,dc=com" massage
</slapd.conf>

Note that the database rooted at "ou=Other,dc=example,dc=com" has been
populated by writing to slapd, so write operations succeeded as well.
As an example:

$ ldapsearch -x -H ldap://:9012 -b ou=People hasSubordinates=TRUE 1.1
dn: ou=People

dn: ou=People,ou=People

dn: ou=Groups,ou=People

dn: ou=Alumni Association,ou=People,ou=People

dn: ou=Information Technology Division,ou=People,ou=People

$ ldapsearch -x -H ldap://:9012 -LLL -b "" hasSubordinates=* 1.1
dn:

dn: cn=Ando

$ ldapsearch -x -H ldap://:9012 -LLL -b "ou=Other,dc=example,dc=com" \
	hasSubordinates=* 1.1
dn: ou=Other,dc=example,dc=com

dn: cn=Ando,ou=Other,dc=example,dc=com

$ ldapsearch -x -H ldap://:9012 -LLL -b "" -s base namingcontexts
dn:
namingContexts: ou=Other,dc=example,dc=com
namingContexts: ou=People
namingContexts:


Indeed, command line ldapsearch returns what is expected. It seems as a client specific fault and my initial estimation that the problem was related with the hasSubordinates attr seems to be wrong.

To help clear things up and to understand where the real problem might be, I am providing below the differences of the log files during the search operations launched from the cli ldapsearch and the other client. Please note that in both cases the same search operation is committed but in the second case slapd returns an error.

Here are the logs during the cli ldapseach:


daemon: read activity on 11
connection_get(11)
connection_get(11): got connid=0
connection_read(11): checking for input on id=0
daemon: select: listen=7 active_threads=0 tvp=NULL
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=*)
    attrs:
 hasSubordinates
 objectclass

conn=0 op=1 SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)"
conn=0 op=1 SRCH attr=hasSubordinates objectclass
=> bdb_search
bdb_dn2entry("dc=foo,dc=bar")
=> bdb_dn2id("dc=foo,dc=bar")
<= bdb_dn2id: got id=0x00000001
entry_decode: "dc=foo,dc=bar"






Here are the logs during the search with the other client:


daemon: read activity on 11
connection_get(11)
connection_get(11): got connid=0
connection_read(11): checking for input on id=0
daemon: select: listen=7 active_threads=0 tvp=NULL
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