idmap recovery tool

Michael Steffens michael_steffens at
Mon Feb 11 07:59:08 GMT 2002


did some weekend hacking and produced a basic tool
helpful for winbindd_idmap.tdb recovery. Basic at least
with respect to its user interface. Here it is, I proudly
present wbidmap! :-)

It links with the same library objects as wbinfo does,
so I just added a corresponding line to Makefile for
building it. Other than planned, it has very little
relationships to tdbtool, which was primarily used for
initially examining and getting the idea of the TDB file.
Close looks to winbindd_idmap.c of course were also quite

Usage: wbidmap [-f file] [-p] -d | -c | -m[o]
   -f file       use file as mapping TDB (default ...) 
   -p            preview, do not change TDB
   -d            dump TDB mappings to stdout
   -c            create new mapping TDB from stdin
   -m            merge stdin into mapping TDB
   -o            overwrite conflicting mappings in TDB on merge

wbidmap does a pretty extensive consistency check of the TDB
when dumping, by attempting reverse lookups for all ID mappings
found, and by checking the HWM values.

Duplicate mappings are allowed in the input stream on create and
merge, as long as they don't conflict. An admistrator doing
recovery can thus just concatenate all dump fragments (or log
fragments, as soon as we have them), regardless whether they

The "-p" mode for preventing changes of the TDB on merge is
pretty dumb, however, since it doesn't remember changes it
would have done itself, before. So for checking the input for
self-consistency, one should rather try to create a test TDB file
somewhere else and watch out for errors.

I did not spend much effort on locking. winbindd itself doesn't
seem to, so it looks wise to me not to run wbidmap on the real
TDB when winbindd is running.

The checks for valid field syntax could be improved. In particular
I don't know the rules for domain names valid for winbindd_idmap.tdb.
The checking function is_domainname() is thus a wild guess.

Of course, many things can be improved, anyway. :-)

What is missing for being able to do full recovery at any time
now is to have winbindd logging newly created mappings into a
dedicated log file. This log should not be truncated. If logging
was enabled since the first mapping, we even don't ever need to
dump with wbidmap, because all we need is there! In case of
desaster just replay the log with "wbidmap -m < logfile".

wbidmap's dumping would then be useful for creating an initial
log file, in case that has been damaged. As long as the log file
and winbindd_idmap.tdb are never trashed simultanously, the
rebuild should be quite easy in either way.

Comments are welcome! I think something like this would be
very useful in a production environment, as long as there is
no other method available for reproducing the ID mappings.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wbidmap.c
Type: text/x-csrc
Size: 21050 bytes
Desc: not available
Url :

More information about the samba-technical mailing list