winbindd_idmap.tdb recovery

[Michael Steffens]

Tim Potter wrote:
> 
> On Thu, Feb 07, 2002 at 12:18:55AM +0100, Jean Francois Micouleau wrote:
> 
> > > > IIRD, Peter Samuelson wrote some code a year ago to do that.
> > >
> > > I thought there were some byte ordering problems with it?
> >
> > dunno. tdbtool will export {name, data blob} tuple.
> > yep, the export will be endian dependant. Is that a big problem ?
> 
> It's a serious gotcha.  I would prefer something that spat out a more
> human readable format.
> 
> If you had a type attached to every tdb entry and a description of the
> type (field list, field names) you could write a tdbtool that didn't
> need to know anything about the semantics of the data, kind of like
> the registry editor.

I was considering a dedicated tool for the idmap tdb, only using
tdbtool as a starting point. It should be as simple and flexible as
possible (not aimed to regular use, but to desaster recovery), but
care for the special properties of this database. As every ID entry
being ASCII and having its reversed complement, and for "USER HWM"
and "GROUP HWM".

The format of dump lines could be

 UID <uid>:<domain>/<rid>:<NT-name>

and

 GID <gid>:<domain>/<rid>:<NT-name>

where the last field would be optional (it's not covered by idmap tdb),
and discarded on importing. Its purpose would be to help the poor guy
doing recovery and investigating what had happened when conflicts
occur. Winbindd, when logging new mappings, would have this information
and could fill it in. It would also be possible to complete the <NT-name>
entries of a dump by a postprocessing with winbindd running. If not,
the poor guy needs to live with numerical RIDs.

What happens when winbindd_idmap.tdb got simply trashed, but without
new mapping being created after that? In this case the last dump and
the log entries by winbindd would just need to be concatenated and
imported.

Another scenario would be new mappings created after the crash in
an inconsistent way. Imagine a different administrator who didn't
know what he was doing (or was *very* much in a hurry of getting
Winbind up again). He just restarted winbindd after winbindd_idmap.tdb
was gone...

In this case recovery will always be tedious. Implies that the poor
guy has to dig into what has been written since then, resolving
conflicts, chown'ing in the filesystem, and fix mappings accordingly.
How exactly this is done depends on the situation and will rarely
be easy. Might also imply phoning up users. I can't imagine a general
automated solution, but I want it to be at least possible.

Maybe I'm finding time to produce a draft version of such an
idmap recovery tool this weekend. But I can't promise that. :-)

Cheers!
Michael