Hallvard B Furuseth wrote:
No, that text is about the alias entry, not the entry which the alias
points at.
This sounds like an OpenLDAP bug. Look a few paragraphs above in the
models draft:
"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."
Note that replacement is not just done when the name itself is an alias,
but also with aliases within the name.
Hm, looks like you're right. This can easily be fixed in back-bdb,
someone should file an ITS.
The other issue is, that it also doesn't seem possible to resolve
aliases pointing at entries in a different backend
...and that's an old limitation in OpenLDAP, which if I understand
correctly it would be quite a bit of work to fix.
It is not a limitation per se, but a conscious design choice. Alias
behavior in LDAP (as specified in RFC2251) adopts the definition in
X.501. Accordingly, the aliasedObjectName attrbiute may only contain a
DN. The DN does not have to point to an object that exists, but if it is
to be dereferenced successfully it obviously must point to an entry
within the DIT. Since there is no URI info attached, (unlike a referral)
it obviously cannot point to an entry stored in some other DIT on some
other server; it must point to a location within the same naming context
as the alias entry itself.
Note that by default, slapd treats separate backends as separate DSAs
with totally independent DITs. (This is the design choice I was
referring to.) Therefore, since those DITs are independent, aliases may
only be resolved within the same backend.
Once again - not enough information has been presented re: why this
particular approach is needed. Most sites should only need a single DIT,
and thus a single backend. And sites that need to isolate data into
separate DITs generally don't need to transparently refer to one DIT
from another.
Now, if I'd want to implement this, i.e. to a) transparently handle
aliases
It would be a mistake to implement (a) since you'll have no way to
specify when you want to Modify the alias entry itself, vs what the
alias points to.
No need, since "subordinates of aliases" are not needed, just aliases
pointing at non-leaf entries.
Well, this particular discussion is moot, since dereferencing is only
defined for Search operations. E.g., see RFC2251 section 4.6, Modify
Operation:
Parameters of the Modify Request are:
- object: The object to be modified. The value of this field contains
the DN of the entry to be modified. The server will not perform
any alias dereferencing in determining the object to be modified.
So implementing this feature would be a direct violation of the LDAP
specification.
and b) support references to other backends.
It would be a mistake to implement (b); that is already the purpose of
referrals.
It might be a mistake because of the mess I described above, but as far
as I can tell not because of referrals.
draft-ietf-ldapbis-protocol-xx.txt defines referrals to be for
references to _other_ servers. A server referring to itself seems to
be abuse of referrals, at least as far as the standard is concerned.
No, you're just using sloppy terminology. Referrals point to information
in other DSAs. Each backend in slapd is its own DSA, so referrals are
precisely the correct feature needed to implement these references.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
