[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#4030) BDB: Alias resolving in base dn incomplete
Full_Name: Michael Reiher
Version: 2.3.7
OS: Linux (Debian Sarge)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (213.54.219.18)
Resolving of base dns, which contain aliases, in searches doesn't work as
expected in the BDB backend.
Suppose you have a tree like:
dc=de
|
|-- ou=entry1
| |
| '-- ou=alias -> ou=entry3,dc=de
|
'-- ou=entry3
|
'-- ou=entry2
Now if you use the folling dns as base for a search (with deref == finding)
Example 1: dn: ou=alias,ou=entry1,dc=de
Resolving of this dn works as expected, as the alias is the last part of the dn.
This is the only place where aliases are resoved currently, at the moment.
Example 2: dn: ou=entry2,ou=alias,ou=entry1,dc=de
#> ldapsearch ... -a always -b "ou=entry2,ou=alias,ou=entry1,dc=de"
Gives:
No such object (32)
Matched DN: ou=alias,ou=entry1,dc=de
It just looks up the full dn in the DB, which fails of course. But no action is
taken from there. i.e. resolve the matching part, retry, and so on...
_All_ aliases appearing anywhere in the base dn should be dereferenced, and I
guess also aliases in dns resolved from the initial aliases, and so on...until a
completly alias free dn is reached.
The relevant part of the models draft someone quoted on the list would be:
"The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of
the corresponding 'aliasedObjectName' attribute. The process may
require the examination of more than one alias entry."