Endpoint Mapper

[simo]

On Thu, 2011-09-01 at 09:56 +0200, Andreas Schneider wrote:
> 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.

Can't really do that, a member server or a NT4 domain server are
completely different from an AD DC server as samba4. That's one of the
reasons we still have different services for lsasd for example.

The samba4 lsa services are 100% tied to samba4's Ldap database and
schema and are not pluggable at all.
So service implementations will need to be different to account for the
different uses cases (member server) even after 4.0 is released.

But I agree we should try to have a common RPC infrastucture (if we can
prevent having nested event loops).

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

I think also that being able to use the single mode is a nice to have
feature but shouldn't prevent us from using code that works.
Not having single mode can make some ways of debugging code slightly
more difficult, but if the price is making the overall code more complex
or more fragile (like when nested event loops are used) I don't thing
debugging features should trump code robustness.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>