Please keep replies on the list.
Nikos Voutsinas wrote:
Indeed, a plain command line ldapseach with objectclass=*, works for me too.
Only with LDAP_Studio (an ldap browser written in java) I get this type of behavior, and I would normally ignore it, but it still troubles me because of the segfaults I am getting when ever I am trying to browse the real naming context with this client. This makes me think that sth goes wrong either with my config or slapd.
If the problem only appears with a specific client, I suggest you try to single out what that client is doing differently from command-line tools, starting from the server logs at "stats" level to check the sequence of operations (if they're meaningless to you, you can post them to the list). Please restrict logs to what's strictly required. Only if nothing relevant appears, you might need to make the logs more verbose, e.g. by adding "args" and "trace".
Please note, that it is the slapd which segfaults and not the client. This shouldn't have happened no matter what the client is doing.
With the relay,massage combination, slapd ends up looking for a non-existent db key (only when searching is done through the real naming context) and with the overlay,suffixmassage combination slapd seagfaults.
So, if the usage of "overlay,suffixmassage", instead of the "relay <> massage", is "legal" and if there isnt anything obviously wrong in the rest of the configuration, I might even start with debugging the segmentation fault on slapd
Thanks, Nikos
Nikos Voutsinas wrote:
Please note, that it is the slapd which segfaults and not the client.
This is how I understood the issue.
This shouldn't have happened no matter what the client is doing.
I agree, that's why I'm trying to help you. Nothing personal, but slapd crashing concerns me more that the issue you're having with some client.
With the relay,massage combination, slapd ends up looking for a non-existent db key (only when searching is done through the real naming context)
What does this mean? If the virtual naming context is "" and you search using the real naming context, the virtual database shouldn't come into play at all.
and with the overlay,suffixmassage combination slapd seagfaults.
So, if the usage of "overlay,suffixmassage", instead of the "relay <> massage", is "legal" and if there isnt anything obviously wrong in the rest of the configuration, I might even start with debugging the segmentation fault on slapd
Back to your initial questions:
Questions:
- What is the status with the usage of empty suffixes? Is this the cause of the problem here?
Should be just fine.
- How the relay,massage pair differs from overlay,suffixmassage in relay database?
They should not differ; back-relay automatically instantiates slapo-rwm when the "relay" directive is used. The only difference is that if "relay" is used with a DN, the database to relay for is selected once for all, otherwise it gets selected for each operation.
- Could slapo-rwm be used as a workaround to this problem?
Well, I'd say no, but there might be details I'm overlooking. Explicitly instantiating slapo-rwm makes sense if you want to do more than just suffix massaging while relaying.
BTW: slapd segfaults when I replace the relay,massage pair with overlay,suffixmassage.
It's a bug: it tries to lookup a database to relay for when unbinding, but unbind has no DN, so a strcmp on NULL is performed. This does not happen when using the "relay" directive because relay database selection does not occur for each operation. Please file an ITS for this issue.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
With the relay,massage combination, slapd ends up looking for a non-existent db key (only when searching is done through the real naming context)
What does this mean? If the virtual naming context is "" and you search using the real naming context, the virtual database shouldn't come into play at all.
I think I've tracked down the problem to this one:
When search is done against the real naming context, asking for hasSubordinates, slapd rewrites the searchDN/key to look for in BDB in very odd (and obviously wrong) way. (see logs below)
Note that there is no problem when searches are done through the virtual naming context and when searches are done in the real naming context with the relay database in slapd.conf commented out.
I can't be sure if this is another side effect of the empty suffix in the virtual naming context, a new issue totally unrelated with the relay backend, or just a result of a faulty configuration (e.g. ACLs)
SRCH "ou=People,dc=contacts,dc=uoa,dc=gr" 0 0 1 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=2 SRCH base="ou=People,dc=contacts,dc=uoa,dc=gr" scope=0 deref=0 filter="(objectClass=*)" conn=0 op=2 SRCH attr=hasSubordinates objectClass slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> limits_get: conn=0 op=2 dn="uid=nvoutsin,ou=people,dc=contacts,dc=uoa,dc=gr" [rw] searchDN: "ou=People,dc=contacts,dc=uoa,dc=gr" -> "ou=People,dc=contacts,dc=uoa,dc=gr,ou=People,dc=contacts,dc=uoa,dc=gr"
dnPrettyNormal:
<ou=People,dc=contacts,dc=uoa,dc=gr,ou=People,dc=contacts,dc=uoa,dc=gr> <<< dnPrettyNormal: <ou=People,dc=contacts,dc=uoa,dc=gr,ou=People,dc=contacts,dc=uoa,dc=gr>, <ou=people,dc=contacts,dc=uoa,dc=gr,ou=people, dc=contacts,dc=uoa,dc=gr> str2filter "(objectClass=*)" begin get_filter PRESENT end get_filter 0 => bdb_search
bdb_dn2entry("ou=people,dc=contacts,dc=uoa,dc=gr,ou=people,dc=contacts,dc=uoa,dc=gr") => bdb_dn2id("dc=gr,ou=people,dc=contacts,dc=uoa,dc=gr") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) entry_decode: "ou=People,dc=contacts,dc=uoa,dc=gr"
Nikos Voutsinas wrote:
Pierangelo Masarati wrote:
With the relay,massage combination, slapd ends up looking for a non-existent db key (only when searching is done through the real naming context)
What does this mean? If the virtual naming context is "" and you search using the real naming context, the virtual database shouldn't come into play at all.
I think I've tracked down the problem to this one:
When search is done against the real naming context, asking for hasSubordinates, slapd rewrites the searchDN/key to look for in BDB in very odd (and obviously wrong) way. (see logs below)
Note that there is no problem when searches are done through the virtual naming context and when searches are done in the real naming context with the relay database in slapd.conf commented out.
I can't be sure if this is another side effect of the empty suffix in the virtual naming context, a new issue totally unrelated with the relay backend, or just a result of a faulty configuration (e.g. ACLs)
Should related to the same problem. I've fixed it in HEAD code, and I'm about to backport part of the fix to 2.3. I didn't check stuff like asking for hasSubordinates, but it appears to work as expected in HEAD (after the fix, I mean).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Should related to the same problem. I've fixed it in HEAD code, and I'm about to backport part of the fix to 2.3. I didn't check stuff like asking for hasSubordinates, but it appears to work as expected in HEAD (after the fix, I mean).
Thanks, for the help.
Nikos
Let me refer to the following case, hoping that this will help to spot all possible side effects resulted from the usage of empty suffixes.
Using a configuration like the one below, searches for attr=hasSubordinates against the ldap backend as 'uid=<uid>,ou=People', fail because searchDN is rewritten to:
[rw] searchDN: "ou=People" -> "ou=People,dc=contacts,dc=uoa,dc=gr"
database bdb suffix "dc=contacts,dc=foo,dc=bar" ..... ..... database ldap suffix "ou=People" overlay rwm rwm-suffixmassage "ou=People,dc=foo,dc=bar" uri "ldap://server.foo.bar" ...... ...... database relay suffix "" relay "dc=contacts,dc=foo,dc=bar" massage
Nikos
Nikos Voutsinas wrote:
Let me refer to the following case, hoping that this will help to spot all possible side effects resulted from the usage of empty suffixes.
Using a configuration like the one below, searches for attr=hasSubordinates against the ldap backend as 'uid=<uid>,ou=People', fail because searchDN is rewritten to:
[rw] searchDN: "ou=People" -> "ou=People,dc=contacts,dc=uoa,dc=gr"
database bdb suffix "dc=contacts,dc=foo,dc=bar" ..... ..... database ldap suffix "ou=People" overlay rwm rwm-suffixmassage "ou=People,dc=foo,dc=bar" uri "ldap://server.foo.bar" ...... ...... database relay suffix "" relay "dc=contacts,dc=foo,dc=bar" massage
Either I didn't get what you're trying to do, or you didn't explain it clearly enough. All I can do right now is try to explain what the above configuration is supposed to do.
The above configuration serves 3 naming contexts:
1) "dc=contacts,dc=foo,dc=bar" is directly served by the local bdb
2) "ou=People" is directly served by the ldap proxy, by redirecting requests whose DN ends in "ou=People" to the remote server "server.foo.bar" after appending them the suffix "dc=foo,dc=bar"
3) any other request is served by the relay database, which appends to the request DN the suffix "dc=contacts,dc=foo,dc=bar"; so any request is actually mapped on the naming context of the local bdb.
I've tried the above configuration with HEAD code and with re23 code (with those small fixes I had to introduce to avoid the core dump when selecting a NULL dn; those have not been committed yet, sorry), and it behaves as I explained (binds, searches, writes), so there appears to be no bug.
Of course, if this is not the behavior you expect, you should try to clarify it a bit further, so that better directions about configuring slapd appropriately can follow.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati writes:
- any other request is served by the relay database,
Hopefully except requests to read entries local to the server: - the root DSE: Search with DN "", scope=base (other scopes should go to the relay database), - cn=Subschema.
Is there a way to get the other ldap server's version of these? Or this LDAP server's, if the above are not exceptions from (3:-)?
Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
- any other request is served by the relay database,
Hopefully except requests to read entries local to the server:
- the root DSE: Search with DN "", scope=base (other scopes should go to the relay database),
- cn=Subschema.
In this case, yes: the local rootDSE and cn=subschema are accessed as usual; it's the scope == base that allows the frontend to intercept them.
Is there a way to get the other ldap server's version of these? Or this LDAP server's, if the above are not exceptions from (3:-)?
You should configure a proxy like this
database ldap suffix "cn=remote" uri "ldap://remote" overlay rwm rwm-suffixmassage ""
so that anything rooted at "cn=remote" is rewritten stripping the trailing "cn=remote"; requests for
"cn=remote", scope == base
will return the remote server's rootDSE; requests for
"cn=subschema,cn=remote", scope == base
will return the remote server's subschema.
Note that in principle custom code could intercept requests for the local rootDSE and subschema by means of a global overlay, so that such requests are handled by the overlay before the frontend gets a chance to handle them. This is yet another side-effect of global overlays that should be documented. For example, slapo-rwm(5), if configured as global so that it always adds a trailing DN to each request, something like
overlay rwm rwm-suffixmassage "" "dc=extra"
would prevent rootDSE and subschema from being accessed... maybe this should be documented.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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?
PS: I will try the fix you mentioned and let you know of the results.
Nikos
Pierangelo Masarati wrote:
Nikos Voutsinas wrote:
Let me refer to the following case, hoping that this will help to spot all possible side effects resulted from the usage of empty suffixes.
Using a configuration like the one below, searches for attr=hasSubordinates against the ldap backend as 'uid=<uid>,ou=People', fail because searchDN is rewritten to:
[rw] searchDN: "ou=People" -> "ou=People,dc=contacts,dc=uoa,dc=gr"
database bdb suffix "dc=contacts,dc=foo,dc=bar" ..... ..... database ldap suffix "ou=People" overlay rwm rwm-suffixmassage "ou=People,dc=foo,dc=bar" uri "ldap://server.foo.bar" ...... ...... database relay suffix "" relay "dc=contacts,dc=foo,dc=bar" massage
Either I didn't get what you're trying to do, or you didn't explain it clearly enough. All I can do right now is try to explain what the above configuration is supposed to do.
The above configuration serves 3 naming contexts:
"dc=contacts,dc=foo,dc=bar" is directly served by the local bdb
"ou=People" is directly served by the ldap proxy, by redirecting
requests whose DN ends in "ou=People" to the remote server "server.foo.bar" after appending them the suffix "dc=foo,dc=bar"
- any other request is served by the relay database, which appends to
the request DN the suffix "dc=contacts,dc=foo,dc=bar"; so any request is actually mapped on the naming context of the local bdb.
I've tried the above configuration with HEAD code and with re23 code (with those small fixes I had to introduce to avoid the core dump when selecting a NULL dn; those have not been committed yet, sorry), and it behaves as I explained (binds, searches, writes), so there appears to be no bug.
Of course, if this is not the behavior you expect, you should try to clarify it a bit further, so that better directions about configuring slapd appropriately can follow.
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:
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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
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.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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
Nikos Voutsinas wrote:
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?
Yes, please.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org
-
Hallvard B Furuseth -
Nikos Voutsinas -
Pierangelo Masarati