To release Samba 4.0 'as is'

[Andrew Tridgell]

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.

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

 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.

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.

Cheers, Tridge