Re: aliased bases

[Will Ballantyne <Will.Ballantyne@gems1.gov.bc.ca>]

Hi Robert,  While the data could be stored in the backend, the behaviour of the
suffix is subtly different from what I would consider normal aliasing behaviour
for an entry.  Normally, I would consider an alias consisting of one entry
pointing to another.

The suffix applies to all entries and requires a change to a part of the DN rather
than an association between a given object and another.  That is, the suffix alias
applies to itself and objects other than itself.

For example, in what you suggest the alias would not apply in many expected cases
(of course this would depend on exactly how you define aliases, you could define
suffix aliases;).

Consider the scenario where the search base is deeper than the aliased suffix,
e.g. for a "real" suffix of  "o=my o, c=my c" lets suppose an alias of "dc=myo,
dc=myc".  Now, when searching with a search root of "ou=my ou, o=my o, c=my c" a
normal alias would not associate that with "ou=my ou, dc=myo, dc=myc" since only
the base is aliased and no internal reference is made to all the parents.
However, the suffix alias does the association.

The code for the suffix alias is quite small and the query part is distinct. If we
want to change it so the data is maintained in the backend as a special type of
record that applies to aliasing the suffix we can do that.  The reason I did not
do so is that it seemed to me to duplicate effort.  The aliased suffixes would
still need to be defined in the config file (so we can find the correct backend)
but now we would also have to create an entry in the directory for any of it to
work....

I am interested in general aliasing so if someone is working on that please let me
know...

Robert Streich wrote:

> > The changes consisted of changing the config code to read an arbitrary set of
> > suffixAlias specifications of the form suffixAlias <alias> <aliased base>
> > from the config file in the backend portion.  The information is stored in
> > the backend struct as an array of strings.
>
> Will,
>
> Maybe I'm missing something, but wouldn't this best be solved by just
> adding support for alias entries? Then all you'd need to do is add
> a new suffix line and create an entry for it that pointed to your
> "real" suffix. You could also put aliases in at arbitrary points in
> the DIT without having to modify the configuration file.
>
> I had asked on the list before about support for aliases, but got no
> response.
>
> bob
>
> Robert Streich                  streich@slb.com
> Schlumberger                    512-331-3318 (voice)
> Austin Research                 512-331-3760 (fax)

--
Will Ballantyne     GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca