s3-rpc_server: Only support static build.

[Stefan (metze) Metzmacher]

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.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101221/2a56ef48/attachment.pgp>