refactoring idmap code in smbd

[Andrew Bartlett]

On Wed, Jul 09, 2003 at 05:28:25PM +0000, Jeremy Allison wrote:
> On Wed, Jul 09, 2003 at 10:30:11AM -0700, Richard Sharpe wrote:
> > On Wed, 9 Jul 2003, Jeremy Allison wrote:
> > 
> > > On Wed, Jul 09, 2003 at 05:06:11PM +0000, Jeremy Allison wrote:
> > > > 
> > > > How do we do this ? The new concept is that winbindd can
> > > > be a source of accounts
> > > 
> > > By "accounts" here btw. I mean UNIX accounts only - not
> > > SAM entries with all the extra stuff. Pure and simple
> > > UNIX uids and groups.
> > 
> > This is an amazingly simple and effective concept ...
> 
> As we store them as the same strings that are in /etc/passwd
> and /etc/group it means you could back up the winbindd local
> db into a passwd or group file by doing a tdb traverse and
> printing out the strings. Likewise to import a passwd or
> group file into it. It's really easy and clean ! I really
> love this design (but I'm biased :-).

If it was just unix uid and groups then I would be quite happy with it - but
now we have duplication of information - both the SAM and winbind have 
independent ideas of what a user's unix username is, and what their full name
is.  When a user is added or deleted from the SAM, winbind might not be told 
(pdbedit with winbind shut down, for example), and there appears to be no
way to keep the other details (full name etc) in sync.

What I loved most about the winbind design prevously was that the only thing
it stored was the id mapping table - the rest was always as dynamic as 
possible from the NT PDC.  This is what I was hoping to achive with 
winbind_passdb - if we can read an Active Directory LDAP server 'directly',
why can't we do that to our own - or a MySQL server, or a TDB?

As to 'why do we care about login hours etc' - I would actually like to 
have winbind provide those for the 'shadow' nsswitch table.  

What concerns me most however is the way this has all been presented as 'this
will be the solution - live with it'.  Would have posting the patch for 
discussion really have cost that much?  Would have detailing what was actually
broken about the previous code have cost that much?  (The changes have added
features, but the whole thing was premised on 'idmap is too broken', yet
those most involved in it were not given the most basic idea what the 'problems'
where).

And we still don't seem to have a fix for the group mapping/id mapping
duplication, but instead have further embedded it.

Don't get me wrong - I like the simplicity of the group solution - given we
do not have a good groups database - but given the existance of a well 
developed user database, why do we need to take such lengths to ignore it?

Andrew Bartlett