RE: aliases (was: "Allow backup" extended operation)

["Howard Chu" <hyc@highlandsun.com>]

I've just checked in an implementation for BDB_ALIASES. It has one major
shortcoming at the moment, which I'm still working out. It generates a
correct list of candidates, fully dereferences all aliases in a subtree
search, and never returns the same entry multiple times. The only problem is
that it won't return deref'd entries outside of the original search scope
back to the client, because the alias processing code doesn't propagate the
new scope info back up to the main search function. The entries are in the
candidate list, but fail the scope check and so get pruned out... Building an
explicit scope list should fix this.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Friday, December 06, 2002 10:00 AM
> To: Howard Chu
> Cc: 'Hallvard B Furuseth'; openldap-devel@OpenLDAP.org
> Subject: aliases (was: "Allow backup" extended operation)
>
>
> Just to summarize, the current LDBM alias implementation is
> flawed in that it:
>         a) doesn't recurse (as needed for subtree searches)
>         b) may return same entry multiple times (when alias
>                 points to entry which is candidate).
>
> To fix this, one needs to rework the code to separately
> alias dereferencing from candidate evaluation.
>
> On starts with a baseObject, finds all subordinate aliases
> within scope.  Then, for each alias, deref (noting target),
> and find all subordinate aliases.  Repeat.  At the end of
> this step, one has a set of baseObjects.  One note here,
> when derefing an alias, the target may be subordinate or
> superior to an existing member of the set.  If subordinate,
> no further work is needed.  If superior, the target replaces
> all subordinates before attempting to find additional
> subordinate aliases.
>
> Then one determines which entries are candidates using
> something like: (&(|(scope=DN1)(scope=DN2)...)(user-filter)).
>
> Then one enters the normal test filter loop... where, using
> the above filter, the candidate is checked not only against
> the user-presented filter but that the entry is subordinate
> to the baseObjects in the set determined in first step.
>
> This should solve both of the problems noted above.
>
> At 08:05 AM 2002-12-06, Howard Chu wrote:
> >> -----Original Message-----
> >> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
> >
> >> Except...we need ldbm here, becuase it supports aliases:-(
> >> I don't know the alias code... why is is it enclosed in
> >> '#ifdef BDB_ALIASES'?  Would it be much work to fix it?
> >> Or should it be thrown out and rewritten from scratch?
> >
> >Kurt sent out a note about this a couple weeks ago. Here's
> the main point:
> >>>>>
> >So, instead of a candidate filter of:
> >     (&(scope=DN)(|(objectClass=alias)(user-filter))
> >
> >we need to have:
> >     (&(|(scope=DN1)(scope=DN2)...)(user-filter))
> >
> >where the DNs of the scope part are determined by a prior
> >recursive algorithm doing:
> >     (&(scope=DN)(objectClass=alias))
> >
> >where this algorithm is sensitive to subordinate/superior
> >relationships between DNs.
> ><<<<
> >So basically in search_candidates we need to call a
> recursive function
> >"alias_candidates" that builds the list of aliased scope DNs.
> >
> >  -- Howard Chu
> >  Chief Architect, Symas Corp.       Director, Highland Sun
> >  http://www.symas.com               http://highlandsun.com/hyc
> >  Symas: Premier OpenSource Development and Support
>