Extending LDB for Extended DNs
simo at samba.org
Wed Dec 3 02:21:45 GMT 2008
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, 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.
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 ?
Finally have you run the ldb speed tests with and without your patches?
Is there any difference ?
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>
More information about the samba-technical