s3-rpc_server: Only support static build.

[simo]

On Tue, 2010-12-21 at 17:44 +0100, Stefan (metze) Metzmacher wrote:
> Am 21.12.2010 17:14, schrieb Volker Lendecke:
> > On Tue, Dec 21, 2010 at 02:32:21PM +0100, Andreas Schneider wrote:
> >> this is the short time solution. In the long term wie should only use modules.
> > 
> > If we can agree on this aspect, then I'm with you.
> 
> +1 for removing support for rpc modules in 3.6.x.
> 
> > In the past I have already put quite some thought into the
> > whole RPC server infrastructure. One wall I have hit is the
> > fundamental assumption of DCERPC that RPC serves are active
> > entities that register themselves with the epmapper and
> > provide services. This has the obvious problem that the
> > epmapper is not actively notified when the daemon crashes,
> > but this could be fixed I think.
> > 
> > This problem manifests itself in the S3 routine
> > is_known_pipename: We have to reply to the ntcreate&x
> > \\pipe\samr differently than to \\pipe\foobar. I have played
> > with an epmapper that walks a subdirectory with .so's,
> > briefly loading them and looking what services they provide.
> > That worked for me, but it would nail us to this particular
> > solution. An alternative that I briefly touched was a real
> > epmapper that depended on a tng (DCERPC?) style model of
> > daemons registering themselves.
> > 
> > How does Samba4 intend to handle this issue?
> > 
> > To me this is an important architectural question that I
> > don't have a definitive answer to yet.
> 
> May work on unifying our 4 dcerpc systems into 1
> (see http://wiki.samba.org/index.php/DCERPC) will provide
> helper functions to run rpc services as active servers.
> 
> The idea is this:
> 
> - create a dcerpc server context,
> - setup the credentials for the server (for krb5 and ntlmssp server)
> - specify endpoints to listen on (tcp ports, named pipes)
> - register dcerpc interfaces with their function tables
>   (this will allow more than one implementation of an interface,
>    without relying on magic function names).
> - start to listen for connections and register with the endpoint mapper
>   The ncalrpc connection to the endpoint mapper should be kept open,
>   so that we automatically re-register if the endpoint mapper was restarted.
>   My plan was that the endpoint mapper would also actively monitor the
> registered
>   servers.
> 
> I think that would give us a nice infrastructure to run services within
> samba
> or external as openchange.

Full ack, I was envisioning a very similar architecture myself.

Simo.

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