Plans for pdb_ads and auth_netlogond?

[Andrew Bartlett]

On Sun, 2012-06-17 at 01:52 +0200, Michael Adam wrote:
> simo wrote:
> > On Sat, 2012-06-16 at 07:33 +0200, Volker Lendecke wrote: 
> > > On Sat, Jun 16, 2012 at 02:56:43PM +1000, Andrew Bartlett wrote:
> > > > On Mon, 2012-06-11 at 12:08 +0200, Volker Lendecke wrote:
> > > > > Hi!
> > > > > 
> > > > > I don't think that I can give input that is deemed worth any
> > > > > consideration on this matter.
> > > > 
> > > > Sorry,
> > > > 
> > > > I'm not really sure what you mean by that.
> > > > 
> > > > Are you OK with the patch, or do you have plans to develop these into
> > > > something that we use?
> > > 
> > > They are still my preferred way to let smbd3 access the
> > > directory. You have decided that linking instead of ipc is
> > > the better way to integrate components. Your approach has
> > > more support in the community than mine,
> > 
> > I am not sure that is true. I made it clear earlier that I think the
> > linking approach is wrong, and I do prefer the forking and executing of
> > smbd.

Simo,

I'm rather confused:  Is this comment related to my patches, or just a general
concern following up the comments you made last week?  We currently fork() and 
exec() smbd, and after your clear feedback on the question, there are no current
proposals to change that.  

Inside that fork()'ed and exec()'ed smbd we do load 3 plugins (pdb_samba4, 
auth_samba4 and vfs_samba4), but it remains a fork()/exec() modal.  

In s3fs as in Franky, the common named pipe IPC mechanism is used to contact 
the s4 RPC servers. 

> > > and as I do not
> > > have the time to develop them against your efforts on my
> > > own, it is only logical to remove them.
> > 
> > I would rather keep them around, I want to discuss the File Server
> > approach later, perhaps at the SDC conference.
> 
> Hmmm, too late.
> 
> I am als not certain, why it was important to remove them.
> It is not that they are in the way and blocking process, right?

Michael,

As you may know, I have a number of concerns about pdb_ads and auth_netlogond.

- They is not tested in make test, and we know that untested code is broken code. 

- pdb_ads cannot operate 'offline', without a working and operating 'samba' binary.

- They produce incorrect results.  
  - pdb_ads does not query the Samba4 idmap 
    (so fails to give the same idmap as the samba4 winbindd).  Because ldap does not
    have transactions, pdb_ads operations are not protected by them and so the 
    /* TODO: Create machines etc */ in pdb_ads_create_user cannot be completed safely. 

  - auth_netlogond cannot handle kerberos (because it was written before those 
    extensions), and cannot query the correct lsa database for matching privileges. 

- At best, they duplicate the supported, working and tested solution. 

- We should not release, even as a developer feature, code which is duplicate, 
  untested and which we do not wish to support. 

Given that in the last year when we have largely solidified the
design of Samba 4.0, and that in that year there hasn't been any changes
(beyond those imposed by broader changes), or a way to automatically
test the code, it seemed reasonable to ask, and to act on the
affirmative response from the maintainer.

So, to ensure I'm understanding things correctly, can I just confirm that as
a team we want to keep these modules for the medium term, in both the
autoconf and waf build systems?  


Simo, 

We don't currently use this pdb_ads and auth_netlogond so I simply don't 
see the connection between these modules, and the fork()/exec() model, 
except that these modules and their replacements auth_samba4 and 
pdb_samba4 both operate in such a model. 

Perhaps you could clarify the connection for me, as I don't think I've understood
your objection clearly. 

I've been trying to seek the will and consensus of the team in sensitive
issues such as this, and would appreciate a clearer understanding of the objection here.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org