Some elements of response :
- there is a RFC draft (an old one) describing how Alias should behave :
http://www.opensource.apple.com/source/OpenLDAP/OpenLDAP-15/OpenLDAP/doc/drafts/draft-byrne-ldap-alias-xx.txt
(so far still a draft)
- Alias is described in section 2.6 of RFC 4512
- If an alias does not dereference to an existing entry, you'll get an
AliasProblem result code
Now, how do we best handle this ?
The main two issues are :
- alias dereferencing must be fast
- we must be able to find cycle
We can detect cycle when modifying the base, and reject such a
modification (can be costly though if doing a MODDN), or we can detect
it when searching for a entry (can also be costly, and need extra
storage to 'remember' whch entry we have gone through).
Another option of course is to not support Alias at all ;)
More inline...
On 5/13/10 3:29 PM, Stefan Seelmann wrote:
Hi
I'd like to fix the various issues we have with alias handling [1]-[4].
Right now we are using indices for alias handling. When using indices it
is essential that they are of integrity. It is important that the target
of an alias entry (referenced by aliasedObjectName) exists. We check
this when adding an alias entry. However when deleting, moving or
renaming the target entry we have issues: the alias entry points to an
non-existing target and the alias indices are not updated.
Which is not necessarily a problem.
I'd like to discuss whether to keep those aliases or to use an
alternative approach for alias dereferencing.
Here are the pros and cons of alias indices from my POV:
Pros:
- very efficient alias dereferencing at search time using alias indices
and cursors
yop
- no duplicate search results, i.e. elimination of duplicates is built-in
- no loops can occur, i.e. loops are detected on write time
yop.
Cons:
- cross-partition aliases are not supported atm (can be fixed)
Complicated, but yes.
- alias chaining is not supported
It should ! If it's not supported, then the current index are ot wll used.
- indices must be maintained on write time
yop, but it's best to do that at write time, as you will have many read
for one single write
- target entries must exist before adding alias entries for them, makes
LDIF export/import more difficult
yes, and that's a problem. i'm not sure we should enforce that.
- alias dereferencing must be implemented for each partition
yes.
If we keep the alias indices we need to fix the issues I described
above, possible solutions are:
1. Reject delete/rename/move operations of an entry, if any alias points
to this entry.
No way. It's legal.
2. Automatically update alias entries and indices:
2.1 When deleting an entry we need to delete all alias entries that
point to that entry.
No. Still legal to have aliases pointing to nothing.
2.2. When moving/renaming an entry we need to update the
aliasedObjectName value of all alias entries that point to the entry.
No. Its legal.
In fact, if we delete the entry whch is dereferenced, then the aliases
will point to nothing, but that's not the server problem, it's the user
problem.
We could though offer an extended operation that find all the bad
aliases, so that the base can be fixed...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
