Re: aliased bases

[Robert Streich <streich@austin.apc.slb.com>]

> > 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 spent some time looking over the code this weekend and it looks like it'd
be a fairly serious rewrite to put this above the back-end. The slapd code
just hands all of the search parameters over to the back-end code. You'd
have to rewrite the slapd search and all of the back-end searches. More
than I feel like taking on at the moment.

> > 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.

The v3 draft at least specifies that aliases are not dereferenced for
add, modify, and delete. That's better than the v2 spec, but it leaves
a lot of operations still undefined with respect to alias dereferencing.
The draft that Ludovic referenced is better at constraining this.

> > 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.

Well, uh, gee, guess I wasn't paying attention to that one.

bob

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