idmap recovery tool

[Esh, Andrew]

I don't count as a team member, but it looks fine to me. I'd use it.

-----Original Message-----
From: Michael Steffens [mailto:michael_steffens at hp.com]
Sent: Wednesday, February 13, 2002 6:02 AM
To: samba-technical at samba.org
Subject: Re: idmap recovery tool


Hmmm, no comment from any Samba team member, yet.

Do you like it? Is it fine, rubbish, or just the wrong way?

Would you consider taking this into the main Samba distribution
(and CVS)?

If so I would start hacking some sgml docs. (At least try to,
never done so, before :-)

Cheers!
Michael

Michael Steffens wrote:
> 
> Hi,
> 
> 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
> helpful.
> 
> 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
> overlap.
> 
> 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.
> 
> Cheers!
> Michael
-------------- next part --------------
HTML attachment scrubbed and removed