To release Samba 4.0 'as is'

Jeremy Allison jra at samba.org
Thu Nov 24 22:19:49 MST 2011


On Fri, Nov 25, 2011 at 09:32:12AM +1100, Andrew Tridgell wrote:
> 
> > After all, I think that's what Windows servers do (or something
> > similar)
> 
> I'm not sure what you mean here. What part of windows is like winbindd?

The parts that do the offline auth, name lookups and all the
other things that the current s3 winbindd does.

> it is already a separate service inside the samba daemon, and has been
> for years. The service is still called 'winbind', because it inherited
> the winbind socket protocol to nss clients and to wbinfo. This is what
> all of the current deployments of AD have been using.

Ok, that's a relief. Why is it providing services to nss clients
and a wbinfo interface ? I don't get that. Seems like it should be
internal to the AD code only. What am I missing here ? Is it just
naming confusion ?

> > For stability I'd suggest we leave the s3 caching winbindd
> > functionality alone so the codepaths from smbd just call into the
> > existing winbindd as they currently do.
> 
> sure, I was proposing not to change this. I'm proposing to build on what
> we've been doing for years, which is to use the internal winbind service
> inside bin/samba when we are an AD DC, and use the external s3 winbind
> service when a member server.

Problem is when smbd is a server on an AD DC if the winbindd
RPCs are implemented internally (and differently to the caching
winbindd) then it's a host of different codepaths for smbd.

That's why I'm wondering if having both installed, smbd calling
s3 winbindd and s3 winbindd talking via a different backend to
the equivalent functionality inside the AD DC might make a
better server. 

> > Can't we end up with both running on a box functioning as an AD-DC ?
> > nsswitch can definitely handle that (if indeed the new functionality
> > needs to be plumbed into nsswitch).
> 
> We can have both installed, but I don't think running both at the same
> time makes any sense. The s3 winbind code just doesn't do anything
> useful on a DC. 

If it's not running I'd like smbd to act as though it were
on a standalone server then - I'm nervous about a second
implementation answering smbd for the same s3 winbindd RPC
calls and would rather avoid that. Can that be done ?

Jeremy.


More information about the samba-technical mailing list