[Date Prev][Date Next]
Re: aliased bases
> 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.
I may be wrong since I don't have an implementation of aliases and they are
very poorly described in the RFCs, but my impression was that an alias should
act similarly to a symbolic link on a file system. That is in the example you
give, the alias should in fact work.
Just to make sure that I understand your example, given a DIT like this where
the "dc=myo,dc=myc" entry is an alias to "o=my o,c=my c":
o=my o,c=my c <---- dc=myo,dc=myc
ou=my ou ou=his ou
I would expect "dc=myo,dc=myc,ou=my ou" and "dc=myo,dc=myc,ou=his ou" to be valid
RDNs. Likewise, a search of "(objectclass=*)" under "dc=myo,dc=myc" whould return
all the children of "o=my o,c=my c".
Have I misinterpreted what I read in the X.5xx docs?
> I am interested in general aliasing so if someone is working on that please let me
Make that two of us.
Robert Streich email@example.com
Schlumberger 512-331-3318 (voice)
Austin Research 512-331-3760 (fax)