To release Samba 4.0 'as is'

[Jeremy Allison]

On Thu, Nov 24, 2011 at 09:15:15AM +1100, Andrew Tridgell wrote:
> 
> To get all of this logic into the s3 winbind would involve a massive
> change in that code and we'd end up with a daemon that is trying to do
> far too many things. The s3 winbind is basically a "cacheing slave". The
> equivalent service for an AD DC is quite different. Putting both in the
> same service would be a huge mess I think.

Wouldn't it be easy to just add a different backend into the
s3 winbindd cachine server, and let the AD-DC code handle the
complicated bits (the path lookups to the right DC etc. etc.) ?

After all, I think that's what Windows servers do (or something
similar). winbindd certainly isn't the right place for the
complexity you describe - but what you're describing isn't
really what we've previously described as winbindd. I think
you're describing a daemon with different functionality than
the current s3 winbindd code. Maybe it should either have a
different name or be a separate service inside the s4 'samba'
binary (as other functionality is implemented).

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.

Remember there are person-years of testing and production
use of that code, so I'd be loath to change out the code
completely for 4.0. 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).

Remember - Thanksgiving means I'll be not contributing
much until Monday (but I'm still very interested in the
discussion :-).

Jeremy.