To release Samba 4.0 'as is'

[Jeremy Allison]

On Fri, Nov 25, 2011 at 10:34:18AM +1100, Andrew Tridgell wrote:
> Hi Andreas,
> 
> > this stuff got a lot of love recently. With the endpoint mapper deamon and the 
> > LSA service daemon we improved the named pipe proxy handling and fixed 
> > remaining bugs. We also test this stuff in autobuild. spoolssd and lsasd are 
> > enabled in 'make test' to make sure we don't break anything here.
> > 
> > We still think this is best approch to get smbd as fileserver in S4.
> 
> It may work for a member server, but it has some real problems for S4 as
> an AD DC, as I think I have mentioned to you before.
> 
> Problems are:
> 
>  1) if you enable the epmd via smbd then all AD services stop working as
>  none of the S4 RPC services are plumbed into it. This is a pretty major
>  exception to "we don't break anything"
> 
>  2) it relies on forking from inside smbd. Why a endpoint mapper should
>  fork from a file services daemon I don't know, but even if it was valid
>  as an architectural decision then it will fail when smbd is not used
>  for file serving. For embedded devices the single process mode and
>  ntvfs/ file server code is what we are likely to use for some time, as
>  it uses far fewer resources. For intensive file serving using smbd
>  makes sense but I don't want to lose the ability to run in small
>  environments.

Hang on a minute. Volker tested the connected-but-not-active
resources of smbd at around 200k I think. With the waf build
producing smaller binaries I don't see any reason to keep
the ntvfs/ code in there at all.

Having a second file server embedded - used only in certain
cases and having differing semantics is a receipe for disaster,
and not a good idea for long term stability of this release.

That's a big sticking point for me. I though we'd decided
s4 fileserver was smbd code - end of story. The details
were how to do the integration.

Now I hear the ntvfs/ server is coming back from the dead.
I didn't sign on for that at all.

Jeremy.