Extending LDB for Extended DNs

[Andrew Bartlett]

On Tue, 2008-12-02 at 21:21 -0500, simo wrote:
> On Wed, 2008-12-03 at 11:35 +1100, Andrew Bartlett wrote:
> > On Fri, 2008-11-21 at 18:28 +1100, Andrew Bartlett wrote:
> > > On Fri, 2008-11-14 at 18:23 +1100, Andrew Bartlett wrote:
> > > > On Wed, 2008-11-05 at 22:33 +1100, Andrew Bartlett wrote:
> > > > > Great.  I've been working on this hard for the past week or so.  See
> > > > > http://gitweb.samba.org/?p=abartlet/samba.git/.git;a=shortlog for the
> > > > > current work in progress.
> > > > > 
> > > > > I'm currently working on the comprehensive testsuite for DN behaviours,
> > > > > particularly with the extended DNs.
> > > > > 
> > > > > I would appreciate any comments or feedback,
> > > > 
> > > > This work has taken far, far longer than I ever expected, but it seems
> > > > that a SID or a GUID is just as valid as a DN in *every* area where it
> > > > is used.  As such, a fairly major rework has been required to translate
> > > > these into a 'normal' DN.
> > > > 
> > > > I've not yet got a working 'store the full DN' module working, but I
> > > > have largely got the input side working, and make test passing (broken
> > > > again as I test more, but what was there passes).  I've updated my GIT
> > > > tree again. 
> > > > 
> > > > This looks like taking another week to finish, after which I hope to
> > > > publish another Samba4 alpha. 
> > > 
> > > I've updated my git branch again.  I'm almost finished - I just need to
> > > figure out why subtree renames are no longer updating the linked
> > > attributes. 
> > > 
> > > Next steps are to hook this in to metze's DRS translation layer and to
> > > hook into OpenLDAP's 'dereference control'.
> > > 
> > > Once this is in and tested, we should be in a good position to make the
> > > long-awaited alpha6 release, which will then, I hope, support Samba3 as
> > > a member server.
> > 
> > I've now completed the work - it passes 'make test' (albeit without the
> > LDAP backend).  Is there any objection to me merging the work, as seen
> > in the branch above?
> > 
> > (And no, I'm not willing to rebase it - sorry.  It would remove a lot of
> > the context of the changes and make a bisect harder). 
> 
> A merge would probably be horrible,

Why?  I know it isn't the preferred development method for some
developers, but why would it be horrible?

>  a rebase is highly preferable and
> will allow for a final check on the patchset before we put it in.
> 
> If git rebase does not work for you diff+patch is good as well.

I fear both would loose too much of the history of the patch
development.  (For example fixes matched with the torture suite that
proves they are needed).

> Anyway I would not put it in if it is going to break the LDAP backend,
> we should have it working for.
> I have gone through great pain myself to make sure my stuff did work
> with LDAP with the async patches, is there a reason to apply a different
> standard in this case ?

No, there isn't, and you are right to hold me to that standard.  I'm
working on the changes to allow this to work with OpenLDAP's dereference
control right now.  

> Finally have you run the ldb speed tests with and without your patches?
> Is there any difference ?

Running the DBSPEED test I found a very small drop (< 1%) probably
incurred because the DN parsing is more complex. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20081203/8ae7e8c3/attachment.bin