To release Samba 4.0 'as is'

[simo]

On Fri, 2011-11-25 at 10:34 +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"

The proxy pipe can be used quite easily, if anything does not work that
way it would be pretty easy to fix, that said I haven't seen a proposal
to enable smbd's epmd by default, so I do not understand this remark.

> 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.

And how is this different from the service forking from within bin/samba
exactly ? I am really baffled by this comment.

> 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.

Ok so all the planning the agreeing about converging etc... in the last
2 years have been worthless ... good to know.

> 3) the existing endpoint mapping module in bin/samba has worked
>  extremely well for us for years. I am not aware of any reports of
>  problems with S4 due to endpoint mapping bugs. I thus am skeptical of
>  claims that it is broken and must be replaced. The additional calls
>  that your EPMD code implements are not available remotely against
>  windows servers and as far as I know are not needed for an AD DC.

They are needed if you want to allow third party code to add additional
pipes.

> I
>  don't mind at all supporting these calls, but I'd rather see the
>  support come via a patch to the existing code rather than a complete
>  replacement with new code that has never been demonstrated to work on
>  an AD DC.

Besides the fact nobody proposed to necessarily substitute that code,
why would it be a problem ?

> 4) as far as I can tell, the primary motivation for this new endpoint
>  mapper is to support the architecture you have chosen for
>  FreeIPA. That's fine for you, but it can't come at the cost of losing
>  existing features in Samba4.

No. The primary motivation was to make a flexible EPM that would allow
plugging in from any third party. The Franky approach was the initial
driver. Things like openchange could use the EPM for example w/o forcing
them to depend on internal samba code for building. The bill for
developing it was partially footed by the FreeIPA project because it
just happened to be useful for it too. 

> Much the same argument is true of the LSA serice daemon. We have years
> of experience running the LSA module inside bin/samba for an AD DC. As
> far as I know, you have not attempted to test the LSA service code you
> are proposing when Samba is an AD DC. It certainly has not been tested
> by any of our users.

Exactly and that's because *nobody* has proposed running the smbd's LSA
daemon in the AD-DC scenario. The idea is to proxy all connections to
the bin/samba LSA daemon for AD-DC services. It's the Franky approach.

I wonder if you ever bothered to understand how the Franky architecture
was supposed to work, your comments here seem to indicate you didn't, a
pity.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>