To release Samba 4.0 'as is'
jra at samba.org
Thu Nov 24 22:25:58 MST 2011
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
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.
More information about the samba-technical