asn at samba.org
Thu Sep 1 01:56:15 MDT 2011
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
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.
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.
Andreas Schneider GPG-ID: F33E3FC6
Samba Team asn at samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 575 bytes
Desc: not available
More information about the samba-technical