Need help merging LDB into common lib/

Michael Adam obnox at
Tue Apr 14 11:44:53 GMT 2009

Hi Andrew,

Andrew Bartlett wrote:
> On Mon, 2009-04-13 at 09:25 +0200, Volker Lendecke wrote:
> > On Mon, Apr 13, 2009 at 03:49:24PM +1000, Andrew Bartlett wrote:
> > > I've tried the simple approach, and made Samba4 build, but I'm at a bit
> > > of a loss as to the Samba3 build system.  Perhaps someone with
> > > experience in the Samba3 build system can help me fix up the branch at:
> > > 
> > > git:// ldb-common
> > >;a=shortlog;h=refs/heads/ldb-common
> > > 
> > > (Once this is done, I'll be in a position to test, and then propose my
> > > libcli-auth-merge3 branch)
> > 
> > As told on irc, I don't see a point in further use of ldb in
> > Samba3, because we will have to maintain two code-bases in
> > Samba3 then: The clustered version that uses direct tdb (see
> > group_mapping.tdb) and the non-clustered version that does
> > ldb.
> > 
> > Because the existing ldb use in Samba3 already increases our
> > maintenance effort, please *first* fix ldb (either version,
> > the s3 *or* the s4 one, I don't care) to be used in a
> > cluster.
> I'm sorry, but I don't follow the logic here.  Samba3 already uses LDB,
> and nobody is proposing to remove this at this stage (due to existing
> deployed use cases).

Currently the only user of ldb in Samba3 is the group mapping
database. Since this is also essential for clustered setups we
have introduced a groupdb:backend = {tdb|ldb} switch that can
be used to re-enable the tdb backend in clustered setups.

For this reason, it was in fact suggested that removing ldb
from s3 again might be a good idea. (Which would of course pose
some migration problems for existing installations.)

> I'm just suggesting that it would be good to only
> have one copy to maintain.

For me at this stage it would be perfectly fine to have a
common ldb code for s4 and the non-clustered s3 group mapping db.
I will also gladly have a look at the s3 build in your branch.

But as I told you on IRC already, the current s3 copy is not
maintained at all: I was frozen at a point and not developed
any further. So the argument of reduced effort is not a very
powerful one.

For the S3-side, a major argument for using a common (and current)
copy of ldb would be the intention to add more users of ldb to
Samba 3.  But I think this is exactly where Volker's concern
comes into play: This would mean that we would need more
special switches for the increasingly important clustered
scenario. It would also enlarge the gap between the clustered
and the non-clustered samba code.

There is also the concern that once ldb is common, more users
of ldb may sneak into s3 when more components (that rely on ldb)
are merged. These additional users  of ldb would break cluster
setups until we come up with yet another ugly workaround.

So to my humble understanding, these are the concerns
(there may be more), and I think they are valid and need
to be taken care of.

> I realise that a 'merge veto' is your only leverage to attempt to have
> this already common code improved, but I do not think it is appropriate
> in these circumstances, and I am in no position to act on your hopes for
> a clustered LDB.  
> All I'm asking is for this common library to be made common.  We can
> discuss use cases (such as avoiding the mymachinepw script in franky, or
> accepting or rejecting my auth merge) at a separate stage. 

I agree. I personally don't see evil in the plain act of using
a common ldb library.  Others may think differently though.  :-)
I will give the s3 build in your branch a try.

Cheers - Michael

Michael Adam <ma at>  <obnox at>
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url :

More information about the samba-technical mailing list