[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: aliased bases
Robert Streich wrote:
> 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.
Thanks for the pointers, I will peruse them as well as Ludovic's pointer to the draft.
Looking over RFC-2256 I can't say the behaviour is clearly defined there.
> 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.
That's a good idea, but I wanted the code to work well with all the different back-ends. We
are currently using an ldap to ph back-end since I implemented a ph server a few years ago
and using the back-end let us avoid duplicating the data or worrying about sync. It should
be possible to implement aliasing before the back-end and have it work with the various
back-ends but it may be trickier.
> 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?
I think the tricky part would be the delete. There should be a mechanism for alias deletion
on deletion of the aliased object or you will get a lot of dangling aliases. I should read
through the draft before commenting further as these things may be covered.
> As a general question: Is the openLDAP source headed towards v3? Should
> I just be looking at the v3 RFCs?
I am pretty sure the idea is to go to LDAP v3 by openldap v2
> 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.
This is in the devel list.
--
Will Ballantyne GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca