Endpoint Mapper

[Andreas Schneider]

On Thursday 01 September 2011 13:25:21 you wrote:
> Hi Andreas,
> 
>  > The implementation of the Endpoint Mapper is complete. All functions
>  > needed by Windows clients are supported and fully implemented. In
>  > addition we support epm_Insert and epm_Delete over ncalrpc to be able
>  > to register and remove endpoints as the system user.
> 
> have you been able to confirm that the epm_Insert and epm_Delete
> functions are wire compatible with Windows clients/servers? I tried
> running the rpc.epmapper test against Windows and it fails with a RPC
> fault, which may indicate that the wire format is not correct. Note
> that our epmapper.idl doesn't use the same IDL form as the IDL in the
> OpenGroup spec, so its quite plausible that we are not wire
> compatible.

I think we have to modify the tests if you want to run them against Windows. 
epm_Insert and epm_Delete are not available on Windows. They are available in 
Samba so we test them.

See

http://msdn.microsoft.com/en-us/library/0beb2488-00a9-4bc4-b7c1-
a24793f99e97(v=PROT.13)

They raise an EPT_S_CANT_PERFORM_OP exception and we do the same if the 
connection is another than NCALRPC.

>  > The epmd can detect if a rpc service dies cause of the open
>  > connection. If the service dies and the connection is closed we
>  > delete the registered endpoints of the service form the database.
> 
> this is certainly a good idea
> 
>  > The goal should be to use the epmd implementation of Samba3 in the
>  > future. The Samba4 epmapper implementation is pretty simple and tied
>  > to S4. There is no easy way to register new endpoints from external.
> 
> I'm not convinced that adopting epmd as the normal approach for the
> Samba 4.0 release is the right way to go. The 'tied to s4' argument
> seems weak given we don't have any plans for another 3.x release.

I think the approach should be to have a common RPC insfrastructure, right? So 
there should be only one implementation of each RPC service.
 
> What about extracting the work you have done into a library, and then
> using that library in both the source4/rpc_server/epmapper/ service
> and the epmd service?

That would be a short term solution.

> 
> We certainly can't just drop the current source4/ epmapper, as that
> would make all of the current source4 RPC services unavailable. I also
> don't want to lose the ability to run the source4/ rpc services in
> single mode, using the task abstraction.

I didn't say that we should drop it, but we should use the code from the S3 
endpoint mapper which is complete.

> 
>  > The epm_Map and epm_Lookup function are incomplete.
> 
> can you tell me what calls made by Windows clients fail against the
> current source4/ epmapper? I know it doesn't allow for the
> registration of new services, which you need for IPA, but I am curious
> as to whether you have also found ways in which Windows clients
> interact with us that fail with the current code.

I haven't found any calls which fail against the Samba4 Endpoint Mapper cause 
I didn't test it and look at the tcpdump. In most cases the call from Windows 
is a simple epm_Map which is answered correctly from S4 (here is an uuid give 
me the port).

I've analyzed the traces between windows client and windows server and checked 
the RPC specification to write the some simple torture test. The suite doesn't 
do really complex tests. It is still on my todo list.

Maybe you want to try the attached patch.


Cheers,


	-- andreas

-- 
Andreas Schneider                   GPG-ID: F33E3FC6
Samba Team                             asn at samba.org
www.samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s4-epmapper.patch
Type: text/x-patch
Size: 575 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110901/62bda9a9/attachment.bin>