[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: aliased bases



> Hi Robert,  I have not seen any RFC specifications for aliases in LDAP.  Maybe you can
> let me know which RFCs they are.

They get a brief mention in a few places in the v2 and v3 RFCs, but the
alias objectclass is described in RFC-2256. I haven't seen the '96
version of X.521, but the '93 version gave the alias objectclass an
attribute of aliasedEntryName, which is also the name in Alvestrand's
OID database. The RFC, however, uses aliasedObjectName.

>   The way the DNs are composed and looked at in the openLDAP source is quite primitive
> and does not currently involve looking at all the components in the parentage of the
> DN.  That is, there is no traversal up the DIT to see if any of the parents is an
> alias.  Without that you cannot use one entry to alias another for the suffix.
> 
>   Doing the walk up the DIT should not be too bad although that might cause havoc with
> some of the backends.  I know that some of them do not define all the entries that
> would be required for the DIT, they emulate them using attributes from the children, so
> what happens if it hits a blank?  The suffix alias solution still seems like a good one
> to me although I may look into doing the DIT walk.

I think that the dereferencing might best be done in the backend code
rather than in the next level up. I took a few minutes to look at the
code tonight and it looks like the best place to add it for the ldbm
backend is where there is a test to see if dn2entry() fails. dn2entry()
walks up the DIT to see what portion of the DN it can match and writes
it into a buffer that gets passed in the call. If you added a function
to test if the "returned" DN was an alias, you could continue by swapping
out the value of aliasedObjectName with the "alias" portion of the
original DN.

I need to have aliases in my DIT, so I'm going to give this a try.
Unfortunately, the v2 RFC only specifies how aliases are to be
dealt with when searching and modifying. It doesn't mention anything
in add, delete, etc. Any ideas?

As a general question: Is the openLDAP source headed towards v3? Should
I just be looking at the v3 RFCs?

If you're interested in continuing this thread, I suppose we ought to
move it to the "devel" list, eh? Feedback would be nice, expecially
from anyone who has dug into this code before.

bob


Robert Streich			streich@slb.com
Schlumberger			512-331-3318 (voice)
Austin Research			512-331-3760 (fax)