on Samba 4.0 epmapper, and 'embedeed' RPC services
abartlet at samba.org
Mon Mar 26 05:00:48 MDT 2012
I wanted to get back to you about the status of a combined end point
mapper, and the embedded RPC services. In particular, I wanted to let
you know where this all fits in terms of Samba 4.0, and s3fs,
particularly as I've wondered off into the strange world of id mapping
in recent weeks.
Now that we have disabled the registration of the embdeded rpc services
(which are now only available on ncacn_np) with the epmapper, we have
removed what was filling the logs. As no clients consult the epmapper
for these services, we don't actually need to do anything more for Samba
4.0. That is, while it would be nice to have just one end point mapper,
it is no longer a blocking issue. The only service Samba 4.0 as an AD
DC has from the source3 codebase, that can listen on TCP, and therefore
could register is spoolss. It seems a reasonable compromised that on an
AD DC, that spoolss be available over named pipes only.
In the long term, my hope is that we might be able to develop a shim
layer, that allows Samba4's RPC server layer to load Samba3 rpc servers.
This would be done by using the fact that Samba3 RPC severs are
implemented in terms of a number of non-static functions, that could be
wrapped by the Samba4 generated RPC layer and some functions to fake up
Finally, I think some of the removal of the optional/disabled
functionality in my patches may have been based on a misunderstanding.
It seems that in fact, the event context is wiped in the per-client
child processes. This means that my feared multiple-process
re-registration or listener wouldn't happen, it would just happen in the
master process. (I still think doing real RPC processing in the master
process would be a bad idea).
Thank you very much for your assistance so far, and I look forward to
continuing to work together.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical