ldb for 3.0.24?
Stefan (metze) Metzmacher
metze at samba.org
Thu Nov 30 10:36:15 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
tridge at samba.org schrieb:
> > 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.
> ok, then I'd like to propose a different alternative. We can have a
> LDB_INDEX_VERSION define in ldb.h. This can be stored by ldb and
> checked at connect - if its not what is stored an index regenerate is
ok, then I think we should have such a version per attribute syntax
and store this version in the database, and trigger a reindex if the
> Maybe we won't need it for the current issue being dealt with about
> memberOf (I think there is a good chance we can avoid that without
> resorting to such mechanisms), but someday we are sure to run across a
> case where we do need to change a canonicalisation function, and will
> need a way to trigger a reindex.
> I know that such a forced reindex is not without its problems (the
> most obvious being the problem of two ldb libs of different versions
> being attached at the same time), but I still think the mechanism
> could prove to be extremely useful in some cases.
yes, but only in some cases, which happen once in month,
> > 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.
> To be LDAP and AD compliant, some of our canonicalisation handlers
> (which are used as the basis for indexing) must have very specific
> forms. If when we write those ones we never put any bugs in then
> everything is of course OK, but I think that relying on us never
> having a bug is a bit tricky!
that's a different problem, that we can track via the per attribute
but for me it makes no sense to limit the attribute_name ->
attribute_syntax mapping to what active directory needs.
I'll descripe that a bit more in my next mail.
> > (for the ldap backends, we should still load the hardcoded attribute
> > handlers, for the ldif handling)
> I'm not sure what you mean by "load" in this case?
by load I mean what ldb_register_samba_handlers() do
you first intoduced the attribute handlers just for display
attribute values nicely in ldbsearch and ldbedit
and what I mean is that we need to keep the static mapping of
names to syntax in the ldap/ildap backends, as they don't have
@ATTRIBUTES, at INDEXLIST... objects.
Because it's really nice to use ldbedit against windows and see
objectGUID and objectSID as strings...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the samba-technical