refactoring idmap code in smbd

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 10 Jul 2003, Andrew Bartlett wrote:

> 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.

ok.  Let's clarify things.  This thing you call SAM is nothing more than 
the next revision of passdb.  It will store only Windows attributes (not 
uid's).  So how do you handle a user in passdb and a user in /etc/passwd?
you have an nt_username field and a username (for the UNIX login name)?
Why can't you just continue to use this?  Why re-invent the wheel?

Re: deleting a user, suppose you delete a user from passdb and not 
/etc/passwd, how do you handle that now?

> 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?

I don't care if you want to code up a winbindd_passdb backend.  I don't 
care if you check it into the tree.  But it will not be the default 
behavior.  At least not initially.  And it better not be any more invasive 
to winbindd than the rpc_methds or ads_methods. 

But you don't need to do this.  I have a gut feeling that winbindd_passdb 
was based out of the assumption that you couldn't run winbindd on a Samba 
PDC as a domain member.  Since we know that is not the case, why
bother with passdb?  Why not just use the rpc functions already used as a 
member of any domain?  

And don't say performance.  If it is good enough for remote DC's, it 
should be good enough for loopback.  No extra code.  Same functionality.

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

See argument above.  This is a generic feature that a member server of 
any domain could benefit from.  Why paint yourself into a corner and limit 
it only to a local passdb.

> 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? 

Yes.  I mailed the team list and told you that we were about to refactor 
the code, what brought this on and what functionality the new code would 
provide.  Jeremy and I lived up to this (minus having to use 
winbindd_passdb).  Everything we said we would deliver, we did.

You had your chance.  I asked for 2 things in the 3.0 release. (1) a
distributed winbindd idmap, and (2) working trust relationships. You said
we need to get idmap in to the 3.0 code base to solve the problems.  So I
waited.  idmap got checked in and still neither feature worked.  So i
adapted the idmap_ldap patch someone contributed (metze?  simo?  you?  
aligori? I don't know) and got it working initially and checked in. Then I
said we need to get trust relationships working and all I heard was that
winbindd won't run on a Samba PDC.  We need something else.  In one
weekend with < 150 lines of code, i had winbindd running on a Samba PDC.

For three years Jeremy and I lived on 2.2. If 3.0 had been in a shippable
state when we moved over, then we wouldn't have had to make these hard
decisions.  And from my perspective (and experience with testing 3.0), we
were not getting there.

A manager has responsibilities.  If you want to call yourself "Manager
of Authentication Subsystems", then you better live up to it.  As I've 
said before, i like the auth and passdb code even if it is a little 
over engineered (but its workable).  I've had very few bugs to fix in it.
And they were specific scenarios.  Not general issues.

So this mail might seem rude, or hard.  The point is that i trusted you to 
deliver something.  You were heading up the effort so I waited.  Then you 
claimed to have done something important (idmap) but never delivered what 
I needed.  So forgive me if I'm a little distrusting of you in this one 
area.

> 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).

smbd calling into idmap was the wrong decision.  It is hard to articulate 
exactly what needs to be fixed until you get into it.  And I never said
"broken".  I said "troublesome in design and implementation".  Turns out
all I needed to do to get what I wanted was to wrap idmap in winbindd.
Which is what it should have been all along.

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

Right, but at least it is in a shippable state for 3.0.  

> 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?

passdb doesn't tell me anything about UNIX uids.  I need a uid.
So i allocate a uid via winbind_create_user() to augment a 
SAM_ACCOUNT structure.  How is this ignoring it?







cheers, jerry
 ----------------------------------------------------------------------
 Hewlett-Packard            ------------------------- http://www.hp.com
 SAMBA Team                 ---------------------- http://www.samba.org
 GnuPG Key                  ---- http://www.plainjoe.org/gpg_public.asc
 "You can never go home again, Oatman, but I guess you can shop there."  
                            --John Cusack - "Grosse Point Blank" (1997)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE/DX0rIR7qMdg1EfYRAslUAJwJ6rJkfY32dljzwkZlCIbU77clsACgmJCc
31kadoOakfd/Uf7wvhlEI8U=
=9TtE
-----END PGP SIGNATURE-----