Trying to understand epmapper registration

[Andreas Schneider]

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

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

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.

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


Cheers,


	-- andreas

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