ldb for 3.0.24?

[Stefan (metze) Metzmacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tridge,

> This is really a very minor issue. You could quite happily use the ldb
> code currently in Samba3 and not have a panic situation on your hands.

This problem was very hard to debug...
And the group mapping code uses the "member" attribute for storing
a SID string.

where the changes that cause the index trouble in samba4,
were caused by changing the attribute handler of the "member" attribute.

so the current samba4 code would try to interpret the SID string from
samba3 as DN string, and would break!

> The indexing fields in ldb are not the users data. The user data
> format has not changed. The indexing fields get completely regenerated
> on any attribute change to the database, and on any indexing
> change. They are like a cache inside the database and can be deleted
> and regenerated at any time.

as the cache is for the current database, it should only rely on
configurations in the database and not on hardcoded values in the
application.

> The obvious thing to do is add another index regeneration trigger (on
> top of the ones we have already) that triggers on application version
> string. That would make ldb auto-regenerate its indexes when anyone
> upgrades (or downgrades). We haven't had to do anything like that
> before as it hasn't been needed, but its a simple change to make. It's
> also not needed for the initial Samba3 release - and it doesn't matter
> if you release with the current ldb code in Samba3 or the code Simo
> will be working on - we won't be in trouble in either case.

I think using a application version string for triggering a index
regeneration is a very bad idea, because you would not be able to run
samba3 and use samba4's ldbedit.

I think the way to handle this is to make sure the attribute handler of
an attribute can only be changed by changing the @ATTRIBUTES object,
and this change will force the index regeneration.

Otherwise attribute names are forced to have the datatype used in active
directory, and I think that would be a bad limitation.

(for the ldap backends, we should still load the hardcoded attribute
handlers, for the ldif handling)

metze
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFbp1sm70gjA5TCD8RAuamAKC87fdPwgkYS6XR895ODO+ZMvm1xACgjwNd
wRJHPC99tec4Ha3djex1RZk=
=Piau
-----END PGP SIGNATURE-----