|| ||Andrew Tridgell <tridge-AT-samba.org> |
|| ||Andreas Schneider <asn-AT-samba.org>, samba-technical-AT-lists.samba.org |
|| ||Re: To release Samba 4.0 'as is' |
|| ||Fri, 25 Nov 2011 10:34:18 +1100|
|| ||Article, Thread
> 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.
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
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.
to post comments)