Trying to understand epmapper registration

[Andreas Schneider]

On Saturday 03 March 2012 09:21:14 Andrew Bartlett wrote:
> On Fri, 2012-03-02 at 15:23 +0100, Andreas Schneider wrote:
> > On Friday 02 March 2012 17:36:33 Andrew Bartlett wrote:
> > > Andreas,
> > 
> > Andrew,
> > 
> > > I've been trying to understand the endpoint mapper registration,
> > > starting with the errors we currently get in the plugin_s4_dc
> > > environment.
> > 
> > are you trying to register s3 endpoints on s4? This will not work cause s4
> > doesn't implement epm_Insert().
> 
> No, I'm not trying to do that yet.  I am well aware of the endpoint
> registration mechanism, and I'm hoping to either support epm_Insert()
> one way or the other, to permit registration to a common endpoint
> mapper.
> 
> > > /data/samba-2/bin/smbd: Failed to register endpoint 'dssetup'!
> > > /data/samba-2/bin/smbd: ../source3/rpc_client/cli_pipe.c:461: Bind NACK
> > > received from host obed!
> > > /data/samba-2/bin/smbd: Failed to register endpoint 'wkssvc'!
> > > /data/samba-2/bin/smbd: ../source3/rpc_client/cli_pipe.c:461: Bind NACK
> > > received from host obed!
> > > /data/samba-2/bin/smbd: Failed to register endpoint 'svcctl'!
> > > /data/samba-2/bin/smbd: ../source3/rpc_client/cli_pipe.c:461: Bind NACK
> > > received from host obed!
> > > /data/samba-2/bin/smbd: Failed to register endpoint 'ntsvcs'!
> > > /data/samba-2/bin/smbd: ../source3/rpc_client/cli_pipe.c:461: Bind NACK
> > > received from host obed!
> > > /data/samba-2/bin/smbd: Failed to register endpoint 'eventlog'!
> > > /data/samba-2/bin/smbd: ../source3/rpc_client/cli_pipe.c:461: Bind NACK
> > > received from host obed!
> > > /data/samba-2/bin/smbd: Failed to register endpoint 'initshutdown'!
> > > 
> > > I've knocked up two patches, attached, which simplify the setup and
> > > registration of the embedded rpc servers, but I would appreciate your
> > > comment and direction.  I'm confused as to why this process is not
> > > totally driven by the endpoint declarations in the IDL, as it appears to
> > > be strongly influenced by it.
> > 
> > Why do you mean not driver by the endpoint decleration in the IDL? The
> > client (smbd) registers the enpointer over ncalrpc calling epm_Insert()
> > on the server (epmd). As epm_Insert() are only internal functions we
> > extended the logic a bit. The client opens a ncalrpc connection and call
> > epm_Insert() then it leave the connection open to sends something like
> > keepalive. If epmd crashes or gets restarted it detects it and will
> > reregister the endpoint.
> 
> What I mean is that the IDL declares the endpoints that a particular
> service is available on.  The C code I was modifying appears to encode
> in C the same information that is in the IDL file, that is should a
> particular service be registered on ncalrpc, ncacn_ip_tcp or ncacn_np.
> Indeed, the IDL is consulted to determine the named pipes to register,
> but not for the other details.

Do you mean the table with the GUID, endpoint names, and on which endpoints it 
should be available? I don't really get what you're talking about and what the 
problem is :)

> 
> > > The fundamental bug here is that the registration didn't consider that
> > > services might be marked 'external', as they are in the plugin_s4_dc
> > > environment.  The second patch addresses that.
> > 
> > The first patch is looks correct. The second patch is completely wrong. We
> > considered that processes can be external like spoolss. You still need to
> > register them in smbd to that smbd know that we are serving this pipe.
> 
> So, part of this happened because the configuration of plugin_s4_dc
> changed while s3fs was still in a separate branch, and so it only
> follows the outdated instructions on
> https://wiki.samba.org/index.php/Franky so the rpc_daemon directives
> were not set.
> 
> > Example:
> > 
> > rpc_server:spoolss = external
> > rpc_daemon:spoolssd = fork
> > 
> > This means we have a spoolssd running, so the pipe is served external. The
> > smbd needs to register spoolss internal.
> > 
> > A spools client connects so first smbd check if the serve a spoolss
> > client.
> > Then it checks in which mode spoolss is set up. If it is external it will
> > forward it over the named pipe proxy to the daemon providing the
> > /var/lib/samba/ncalrpc/np/spoolss unix socket.
> 
> I've looked at the registration, and one of the confusing things is that
> the registration appears to be made in the wrong process!  For the
> example you give above:
> 
> main() calls:	dcesrv_ep_setup(ev_ctx, msg_ctx))
> 
> This then calls rpc_spoolss_init() regardless of if spoolss is to be run
> in a forked child or not.  Shouldn't the registration happen only in the
> child running the process?  If not, how could we support unknown
> endpoints (dnsserver/drsupai/backupkey for example)?

We need(ed) to call rpc_spoolss_init() or if you connect over a named pipe to 
smbd, then smbd will tell the client that it doesn't know the rpc protocol and 
drop the connection. This registration is (was) needed to accept the 
connection and forward it over the named pipe proxy to the correct service, 
spoolssd.

Maybe this has changed and isn't needed anymore. It was needed by the time I 
was doing the work. I think we need to try it and maybe make sure it isn't 
requried anymore.

> Given the support for automatically removing registrations when
> processes shut down, I imagined it would need to be registred from the
> same process.

Do you talk about registered endpoints in smbd or rpc_<rpc>_init() now?

> 
> The other problem is that even if the main daemon processes are
> disabled, dcesrv_ep_setup() will still register "dssetup" (and a number
> of other embedded services) unconditionally.  The problem is, dssetup is
> declared to be "external" so that it can be forwarded across the named
> pipes, and must be provided by Samba4's AD code, and so should not be
> registered here.

We should differentiate between registering the process on epmd or make smbd 
aware of handling the connection for dssetup and forwarding it. If you mean 
the letter than we need to make sure that this will work.


	-- andreas

-- 
Andreas Schneider                   GPG-ID: F33E3FC6
www.cryptomilk.org                asn at cryptomilk.org