ldb for 3.0.24?

[simo]

On Wed, 2006-11-29 at 13:22 +0100, Stefan (metze) Metzmacher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Volker Lendecke schrieb:
> > BTW, on irc metze told me that it is better to wait until
> > 3.0.25 to include ldb. Stefan, do you have any further input
> > on this? Should I pull ldb from the 3.0.24 branch and
> > re-install the old group mapping code?
> 
> Hi Volker,
> 
> it mostly depends on when 3.0.24 will be released.
> 
> The problems I see are:
> 
> We use hardcoded attribute_name to attribute_handler mappings.
> The problem with it is that if we change them in the code,
> the records for indexes are created under different DN's
> if the attribute handler changes. We hit this problem in samba4
> last week, we're the attribute handler for the 'member' attribute
> was changed to use the ldb_canonicalise_dn() function instead of
> ldb_default_copy(), the result was that the index record
> for the member attribute changed from:
>   "DN=@INDEX:MEMBER:CN=Administrator,CN=Users,DC=sernoxdom4,DC=mx,DC=base"
> to
> "DN=@INDEX:MEMBER:CN=ADMINISTRATOR,CN=USERS,DC=SERNOXDOM4,DC=MX,DC=BASE"
> 
> And the ldb searches to find the group memberships of the
> administrator account, didn't detect the administrator is member of
> the administrators group, so the the kludge_acl module deniesd the
> write access to the administrator.
> 
> In the end fixing the problem was easy, just remove the attributes of
> the @INDEXLIST object and readd them, in other words the indexes are
> regenerated.
> 
> But I think we need to fix this! I think we should just have attribute
> syntaxes hardcoded in the code, and have the attribute_name ->
> attribute_syntax mappings in the @ATTRIBUTES object only,
> so that it doesn't depend on the version of ldbtools which are used if
> you can access the ldb file correctly.

I am not so sure that putting the attribute syntaxes in @ATTRIBUTES is
necessarily a good idea, the member case was obviously a bug in the
former code, and as you said it was fixed by just regenerating the
indexes. I don't expect syntaxes to change at all in the code, unless
there is a clear bug, and then we can always make sure we handle that on
upgrade. If we put the syntaxes in @ATTRIBUTES we will still need to
handle the case when we change them, if we do.

> And I think if we ship the current code with samba3, it will may hit
> a lot of people as the group_mapping.ldb uses indexed records.
> 
> And in the current implementation the LOCAL-DBSPEED test says that
> tdb is 10 times faster than ldb.

That is not going to change much. I increased ldb speed 40%, but in any
case ldb is more complex then tdb and that's why it is slower. We can
probably achieve some more improvements, but I don't expect to get that
much more speed.

> So I think that it would be good to wait untill the problems in ldb
> are fixed and will not cause problems to people, when they install a
> newer samba version. Also we should try to make the LOCAL-DBSPEED
> faster for the ldb case.
> 
> So depending on when 3.0.24 will come, it would be better to wait with
> it for 3.0.25.

I think Jerry will always have the last say, personally I am confident
that ldb can do its job very well, and there no major problems in the
code. The use cases we can have in samba 3 are much simpler than what we
have in samba 4 and I don;t expect to see ldb used in any other more
complex way any soon.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org