status of rpc servers in s3, and which process should handle ncalcrpc and ncacn_ip_tcp?

[Andrew Bartlett]

I've been looking more closely at the rpc server setup, and I remain
quite confused by the current state.

In particular: Which process should handle ncaclrpc and ncacn_ip_tcp
connections for embedded RPC services?

Currently it looks like it would be a race between the parent smbd,
spoolssd, lsasd and any forked SMB-handling child, because the events
are added to the main event loop.

Moving the initialisation of embedded services below the forked deamons
is easy, but should we fork off a child to handle these?

Also, if I may, can I get a bit of background on the status and overall
architecture here?  There has clearly been a lot of work done here to
build a system that can allow lsa, netlogon, samr and spoolss
interactions to occour out-of-process, and likewise an end point mapper
has been built.

But all this seems to be disabled by default, and I couldn't find any
other relevant patches after this commit:

commit da2347379e04caf5b7bbd3a6704b03e03c8bf30a
Author: Andreas Schneider <[hidden email]>
Date:   Wed Aug 31 14:53:52 2011 +0200

    s3-rpc_server: Disable epmapper by default.
   
    We need more testing in the real world. We need to be sure that if a
    Windows client can access port 135 it doesn't require that a service
is
    available via ncacn_ip_tcp. If possible please enable it using the
    following smb.conf options for testing:
   
      rpc_daemon:epmd = fork
      rpc_server:epmapper = external
   
Was there a major problem that was found that I should know about?

What is the use case for ncaclrpc and ncacn_ip_tcp access (particularly
for the embedded services)?

Thanks,

Andrew Bartlett
--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

[Andreas Schneider-2]

On Saturday 03 March 2012 13:41:36 Andrew Bartlett wrote:
> I've been looking more closely at the rpc server setup, and I remain
> quite confused by the current state.
>
> In particular: Which process should handle ncaclrpc and ncacn_ip_tcp
> connections for embedded RPC services?

Hi Andrew,

> Currently it looks like it would be a race between the parent smbd,
> spoolssd, lsasd and any forked SMB-handling child, because the events
> are added to the main event loop.

it is turned off by default and you shouldn't activate it. smbd isn't able to
handle incoming ncalrpc or tcpip correctly. That's the reason why we have a
preforked spoolssd and lsasd.

> Moving the initialisation of embedded services below the forked deamons
> is easy, but should we fork off a child to handle these?

I don't know what you mean. Do you ask why we fork off a child to handle
preforked children in lsasd?

> Also, if I may, can I get a bit of background on the status and overall
> architecture here?  There has clearly been a lot of work done here to
> build a system that can allow lsa, netlogon, samr and spoolss
> interactions to occour out-of-process, and likewise an end point mapper
> has been built.

The FreeIPA requirement is that we need to be able to communitcate over
ncacn_np and ncacn_ip_tcp. For ncacn_ip_tcp you need the endpoint mapper so we
created that first. The next step was to get tcpip working, but the way smbd
works we're not able to simply setup tcpip listeners. It will not scale cause
only one process will probably handle it or a child already handling another
lcient connection. So we created a preforked model and decided to create lsasd
with the pipes we need to setup a trust.

> But all this seems to be disabled by default, and I couldn't find any
> other relevant patches after this commit:

You can enable epmapper by default it should work and smbd should register
it's named pipes. However windows never talks to epm over named pipes.

> commit da2347379e04caf5b7bbd3a6704b03e03c8bf30a
> Author: Andreas Schneider <[hidden email]>
> Date:   Wed Aug 31 14:53:52 2011 +0200
>
>     s3-rpc_server: Disable epmapper by default.
>
>     We need more testing in the real world. We need to be sure that if a
>     Windows client can access port 135 it doesn't require that a service
> is
>     available via ncacn_ip_tcp. If possible please enable it using the
>     following smb.conf options for testing:
>
>       rpc_daemon:epmd = fork
>       rpc_server:epmapper = external
>
> Was there a major problem that was found that I should know about?

I've enabled it by default but there were concerns running it by default.
However it isn't useful at the moment as smbd would only register named pipes
and windows never asks epm for named pipes. At the moment we only use epmd
together with lsasd in FreeIPA.

> What is the use case for ncaclrpc and ncacn_ip_tcp access (particularly
> for the embedded services)?

In S3 ncalrpc is only used to register endpoints at the endpoint mapper.

I hope this helps.


        -- andreas

--
Andreas Schneider                   GPG-ID: F33E3FC6
www.cryptomilk.org                [hidden email]

[Andrew Bartlett]

On Tue, 2012-03-06 at 10:30 +0100, Andreas Schneider wrote:

> On Saturday 03 March 2012 13:41:36 Andrew Bartlett wrote:
> > I've been looking more closely at the rpc server setup, and I remain
> > quite confused by the current state.
> >
> > In particular: Which process should handle ncaclrpc and ncacn_ip_tcp
> > connections for embedded RPC services?
>
> Hi Andrew,
>
> > Currently it looks like it would be a race between the parent smbd,
> > spoolssd, lsasd and any forked SMB-handling child, because the events
> > are added to the main event loop.
>
> it is turned off by default and you shouldn't activate it. smbd isn't able to
> handle incoming ncalrpc or tcpip correctly. That's the reason why we have a
> preforked spoolssd and lsasd.

On that basis, I have prepared the attached patches.  Currently, having
an endpoint mapper implementation causes ncalrpc pipes and TCP sockets
to be created for embedded services, but as you say, this isn't going to
work.

If we want to make any of these services support ncalrpc and TCP, we
will need to move them to a child, like lsasd.

What do you think?

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

[Andrew Bartlett]

On Wed, 2012-03-07 at 14:05 +1100, Andrew Bartlett wrote:

> On Tue, 2012-03-06 at 10:30 +0100, Andreas Schneider wrote:
> > On Saturday 03 March 2012 13:41:36 Andrew Bartlett wrote:
> > > I've been looking more closely at the rpc server setup, and I remain
> > > quite confused by the current state.
> > >
> > > In particular: Which process should handle ncaclrpc and ncacn_ip_tcp
> > > connections for embedded RPC services?
> >
> > Hi Andrew,
> >
> > > Currently it looks like it would be a race between the parent smbd,
> > > spoolssd, lsasd and any forked SMB-handling child, because the events
> > > are added to the main event loop.
> >
> > it is turned off by default and you shouldn't activate it. smbd isn't able to
> > handle incoming ncalrpc or tcpip correctly. That's the reason why we have a
> > preforked spoolssd and lsasd.
>
> On that basis, I have prepared the attached patches.  Currently, having
> an endpoint mapper implementation causes ncalrpc pipes and TCP sockets
> to be created for embedded services, but as you say, this isn't going to
> work.
>
> If we want to make any of these services support ncalrpc and TCP, we
> will need to move them to a child, like lsasd.

Updated patches (currently under test) are in my s3-rpc_server branch.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

[Andreas Schneider-2]

On Wednesday 07 March 2012 16:18:14 you wrote:

> On Wed, 2012-03-07 at 14:05 +1100, Andrew Bartlett wrote:
> > On Tue, 2012-03-06 at 10:30 +0100, Andreas Schneider wrote:
> > > On Saturday 03 March 2012 13:41:36 Andrew Bartlett wrote:
> > > > I've been looking more closely at the rpc server setup, and I remain
> > > > quite confused by the current state.
> > > >
> > > > In particular: Which process should handle ncaclrpc and ncacn_ip_tcp
> > > > connections for embedded RPC services?
> > >
> > > Hi Andrew,
> > >
> > > > Currently it looks like it would be a race between the parent smbd,
> > > > spoolssd, lsasd and any forked SMB-handling child, because the events
> > > > are added to the main event loop.
> > >
> > > it is turned off by default and you shouldn't activate it. smbd isn't
> > > able to handle incoming ncalrpc or tcpip correctly. That's the reason
> > > why we have a preforked spoolssd and lsasd.
> >
> > On that basis, I have prepared the attached patches.  Currently, having
> > an endpoint mapper implementation causes ncalrpc pipes and TCP sockets
> > to be created for embedded services, but as you say, this isn't going to
> > work.
> >
> > If we want to make any of these services support ncalrpc and TCP, we
> > will need to move them to a child, like lsasd.
>
> Updated patches (currently under test) are in my s3-rpc_server branch.

If they pass make test I'm fine with it. The lsa tests are run over tcp and
ncalrpc too.

Do you want me to sign and push the patches?
 

        -- andreas

--
Andreas Schneider                   GPG-ID: F33E3FC6
www.cryptomilk.org                [hidden email]