Trying to understand epmapper registration

[Andrew Bartlett]

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. 

> > 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)?  

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

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.  

> > Anyway, let me know what you think, as I'm hoping to sort out the
> > endpoint registration as my next major task in progressing s3fs as our
> > file server solution.
> 
> This will probably not work cause s4 doesn't implement epm_Insert() and 
> epm_Delete().

As I said, I'm well aware of the limitations.  I intend to overcome
those limitations so that all our services are registered with a single
endpoint mapper.  To do this, I need to ensure only the right things are
registering. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org