ldbdump is a vaulable tool and should be retained.

simo idra at samba.org
Wed Oct 31 05:53:09 MDT 2012

On Wed, 2012-10-31 at 16:33 +1100, Andrew Tridgell wrote:
> Hi Simo,
> I don't think exposing ltdb_pack_data() was so terrible, but given you
> would prefer another approach Andrew and I have put one together in my
> ldbdump-review branch.
>   https://git.samba.org/?p=tridge/samba.git;a=shortlog;h=refs/heads/ldbdump-review
> It makes the patch quite a bit larger, but is more consistent with other
> calls, such as those in ldb_parse.c. There isn't really anything
> specific to ldb_tdb about the ldb_pack.c code, it was only in ldb_tdb/
> as there happened to be no other users. It could be used by any record
> based ldb backend.
> One disadvantage of this alternative approach is that it adds an
> assumption that TDB_DATA and struct ldb_val are the same shape, in the
> same way we currently assume that struct ldb_val and DATA_BLOB are the
> same shape. We could instead re-build the structures each time, but I
> don't think that is worthwhile.
> The ldbdump utility looks to be very useful for database recovery, and I
> don't think we can really build it without adding some linkage between
> the pack/unpack record oriented routines and outside tools. Given that
> ldbdump is a ldb internal tool doing that via including ldb_tdb.h was
> not unreasonable I think, but if you prefer the above approach instead
> then I'd be happy with either way.

to be honest I do not think this is the best solution, however at least
it does not violate layers so I could agree to it.

The solution I was thinking about was not going to move
ltdb_unpack_data, instead it would add a 'recover' operation to
ldb_module_ops, that takes a module and a ldb_dn argument (it doesn't
need to be an async op so I doesn't need to use struct ldb_request, but
it could if you are so inclined).

Then ldbdump would simply open a ldb file passing in the 'recover'
string into options and 'recover_emergency' (for the -e flag) at module
loading. This can be used to disable anything that we think should not
be done (like loading additional modules).

Finally ldbdump would simply call a new function named ldb_recover which
would call the new recover operation and that would basically do the
traverse or the rescue as necessary inside ldb_tdb.

The reason why an operation is better suited is that this way we have
the infrastructure ready should we experiment with another backend in
future, instead of having to start adding more complexity to ldbdump to
handle multiple backends later.

I was actually planning recently to experiment using the new mdb
datadabse that Howard built for Openldap as an ldb backend, as it looks
extremely promising and has a structure that closely fit the needs of
ldap servers. If I were to build that it wouldn't be hard to build a
'recover' function (even if it is just a stub initially), and we'd have
ldbdump automatically working on both.


Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>

More information about the samba-technical mailing list