selftest: re-enable nss_winbind via nss_wrapper in the test-envs.

[Andrew Bartlett]

On Wed, 2015-02-18 at 23:37 +0100, Michael Adam wrote:
> On 2015-02-19 at 11:06 +1300, Andrew Bartlett wrote:
> > On Wed, 2015-02-18 at 11:21 +0100, Michael Adam wrote:
> > 
> > > My understanding is also that smbd is not
> > > functional without the ability to reach out into nss some time
> > > because it tries to do getpwnam at times. 
> > 
> > The only case I'm aware of is for the [homes].  The other cases are
> > handled because we go via pdb_samba_dsdb. 
> 
> There are more cases, mainly through auth. Example:
> 
> make_server_info_info3()
> -> check_account()
>    -> smb_getpwnam()
>       -> Get_Pwnam_alloc()
> 
> etc.
> 
> So I am really puzzled that you call this a supported config...

That code path is in auth_samba4, but as I mentioned in my other mail,
we always go via GENSEC and directly into the source4 auth stack, except
in winbindd (oh, the irony) so we don't call check_account().  

GENSEC calls the code path as originally used in the ntvfs SMB server,
and in the other services.  (This being one of the key points of the
merge approach I took, and hopefully the subject of an upcoming SambaXP
talk). 

> > > Maybe this is just
> > > not true with the way smbd is used in the DC environment, but
> > > I was not aware. That is the basis of my statement that I
> > > consider a DC setup without nss_winbind incomplete, or broken. :)
> > 
> > OK.  But given that isn't the case, you might now understand my concern
> > with your change.
> 
> Given the above, I'd still argue that the setup with nss_winbind
> is the one we should call supported, and even if there are
> special situations where one might get along without it, the the
> nss_winbindd setup is to be preferred. So if we were to test just
> one of the scenarios, I'd make a strong vote for the nss_winbind
> one.

We should test both.  We need to understand why they are different, and
we should not change the tests until we understand the tests.  The
difference may well be due to the different smb.conf files in use,
rather than anything more dramatic, when :local was added.  Can you
check?

> > > If you want to keep the test as it is, I propose to do a special
> > > environment for this test only that does not enable nss_winbindd
> > > for it. But for other envs / tests we do need it, so I would not
> > > want go back the whole way...
> > 
> > Please restore the test as-was, until you get time to investigate
> > further what is going on.  
> 
> I will probably not have the resources to deeply investigate in
> the very near future. As I said I hoped that someone with more
> stakes in the AD/DC and the test itself would assist... :-)

I wish I also had the time and resources.  I'm actually in the happy
position of being up to my eyeballs in upstream AD DC development!  If
you or anyone else wants to help, do let me know! :-)

> That being said I still think that we have become more realistic in
> testing the dc with nss_winbind, and we should not give that up
> because we know there is a problem hidden. And as I said above, I
> think it is more important to test with nss_winbindd than
> without.

An interesting quirk here is that while it may be reset at runtime, the
most important time for this routine to be called on sysvol ACLs is
during provision, when nss_winbind isn't likely installed, and certainly
isn't operable. 

> So the concession I would be happy to make is to add an environment
> for the plugin_s4_dc that does not use nss_winbindd and run the
> original test (with 6 instead of 7) against that.
> 
> OK for you? - Michael

Given the views rest of the thread, it seems important we run a few more
tests in both modes, as the next variation here is likely to be much
more trouble, and this has shown that both modes are widely used. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150220/75a7babc/attachment.pgp>