refactoring idmap code in smbd

[Gerald (Jerry) Carter]

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

On Thu, 10 Jul 2003, Steve Langasek wrote:

> This particular constraint is inherent to a username-based map.  It was
> not present in the previous idmap design.

I think my previous messages that crossed in passing address this.

> > But lest you be worried about.  an rpc call to delete a user 
> > will also be able to delete the user from winbindd's account tdb.  
> > I just have to code up the winbindd_delete_user() and 
> > winbindd_delete_group() calls today.
> 
> But we can't *use* winbindd's account tdb.  We need LDAP.  I've read
> preceding comments as saying there will be no idmap solution that uses
> LDAP as a backend.  

no.  idmap backend hasn't changed.  

winbindd's acccount tdb is just a way to avoid 'add 
user script', etc... if you can use it, then define and 
'add user script'.  But this is not really what you are 
concerned about.  You want 'idmap backend = ldap' which 
still works.

We're dealing with two different issues here.  The idmap 
code was only half the solution we needed for 3.0.  
winbindd_passdb (the other half was missing).  So 
in order to get a complete working solution, the parts
of idmap that were plugged into smbd were removed.

See previous message about competing solutions.

It is pointless to discuss this if we are trying to figure
out which solution will be used in 3.0.  That's a done deal.
Beyond 3.0 and the 'perfect' way to do things will be decided 
post 3.0.



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/DZhUIR7qMdg1EfYRAuBHAKCpmZ/nlHhZpjYK271vs3e3uTkq8QCePj8U
bvGJ/j84A9ofm0HHprgsQFc=
=JyHq
-----END PGP SIGNATURE-----