Extending LDB for Extended DNs
abartlet at samba.org
Wed Dec 3 02:38:05 GMT 2008
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.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20081203/8ae7e8c3/attachment.bin
More information about the samba-technical