winbindd_idmap.tdb recovery

[MCCALL,DON (HP-USA,ex1)]

Ok, 
I know, I know - the problem is being able to map from a billion number
space (the number of potential rids that a win2k domain has to draw on) to
an arbitrarily small uid space.  GIVEN that the number of actual IN-USE rids
in the win2k space is not allowed to exceed the max number of uids in the
UID-SPACE.
I didn't say it would be easy....

-----Original Message-----
From: MCCALL,DON (HP-USA,ex1) 
Sent: Friday, February 08, 2002 2:57 PM
To: STEFFENS,MICHAEL (HP-Germany,ex1); Tim Potter
Cc: MCCALL,DON (HP-USA,ex1); samba-technical at samba.org
Subject: RE: winbindd_idmap.tdb recovery


Hi Michael,Tim, et al;
I've been thinking (I know - I shouldn't do that...).
All of the things we are trying to address with this additional
functionality/tool
are needed because we are assigning uid/gid's on a first come first serve
basis.
So if something screws up the database, we are pretty sure that when it gets
rebuilt
the uid-rid mapping will change.  In addition, this almost guarantees that
the uid-rid
mapping will be different on different samba servers in the SAME domain, as
users will
access them in a different order.

What we REALLY want is to guarantee is that ANY Samba server using winbindd
in the 
SAME WIN2k/NT domain, would map the same domain user to the same unix uid,
and the 
same domain group to the same group id.

What this suggests to me is a hashing algorythm that would take the SID/rid
of the 
domain group/user, and map that uniquely and consistently into the uid/gid
space that 
we define with winbindd uid and winbindd gid...

Just a quick thought - if you all can point out the problems/shortcomings of
a scheme
like this, I'll either look into it, or run away - run away (to misquote
Monty Python)...

Thanks,
Don


-----Original Message-----
From: Michael Steffens [mailto:michael_steffens at hp.com]
Sent: Wednesday, February 06, 2002 5:06 AM
To: Tim Potter
Cc: MCCALL,DON (HP-USA,ex1); samba-technical at samba.org
Subject: Re: winbindd_idmap.tdb recovery


Hi Tim,

Tim Potter wrote:
> I can always add a --export-idmap and --import-idmap arguments to
> be info that will do the trick.

as Don already said: great idea!

I think the --import-idmap functionality should be able to
cope with the cases

 - re-create idmap, i.e drop existing entries.

 - merge into existing idmap, discard new entries in case of
   conflicts with existing ones.

 - merge into existing idmap, overwrite existing entries in
   case of conflicts with new ones.

Maybe an interactive mode, prompting when coming across
conflicts, would also be helpful.

Would yo do that "online" via winbindd, or "offline" by directly
accessing winbindd_idmap.tdb?

I already thought about deriving an offline tool from tdbtool.

Cheers!
Michael