CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

On Mon, Jan 07, 2002 at 06:43:36PM -0800, Jeremy Allison wrote:
> On Tue, Jan 08, 2002 at 01:33:17PM +1100, Martin Pool wrote:
> 
> > It might be nice if the code to do dcerpc was less coupled to Samba,
> > so that it can be reused to help such good causes.  So Evolution can
> > link to libsambadce or whatever, and share code maintenance.  (In
> > fact, it looks like it would probably be a library plus code
> > generator, like most RPC systems.)
> > 
> > Once you've made that split, you could perhaps refactor Samba to use
> > the library from several different processes.  That seems like a
> > secondary point, and simply a matter of taste for Samba developers.
> 
> Martin,
> 
> 	You only need Samba code if you want to do DCE/RPC
> over named pipes. Luke makes a big thing about transport
> independence, indeed this is one of the strengths of DCE/RPC.
> 
> In which case in order to allow MS clients to connect to a UNIX
> DCE/RPC server you don't need Samba at all, 

no, that's not correct.

dce/rpc clients _choose_ the transport they wish to use.

the majority of dce/rpc clients choose to use _all_ transports.

not only that, but dce/rpc services may _also_ choose
the transports they wish to use [where the majority,
and this is again, an implementor-specific choice, choose
to bind to all transports].

however, a few critical services such as NT domain related
ones choose _specifically_ to only use "ncacn_np", at both
the client and server implementations.

this means that samba _is_ a mandatory requirement in the
equation [which is why i have been trying to get through 
to you for so long].




> as you only need
> to be running the DCE/RPC endpoint mapper (which listens on port
> 135 and acts like portmapper - maps arbitrary DCE service endpoints
> to strings so clients can find them) and tell your MS clients to use
> the TCP transport.
 
 ncacn_ip_tcp.

 the endpoint mapper service listens on ncacp_ip_tcp[135],
 ncadg_ip_tcp[135], ncadg_dds[12] (whatever _that_ is),
 ncacn_dnet_nsp[#69] (decnet?), and ncacn_np[epmapper].

 the last is microsoft: ncacn "named pipes" i.e. \PIPE\epmapper.

 the only recognised transport in samba is hard-coded implementations
 of "named pipes".

 unfortunately, samba dominates port 139, thereby terminating
 any possibility for other dce/rpc implementations to bind to
 ncacn_np on the same ip.

 [it also dominates ports 137 and 138, thereby terminating
 any possibility for other netbios services to run on the
 same ports, but that's another story that chris hertel
 is addressing.
 
 _oh_, and it also terminates any possibility to run
 dce/rpc over netbios - _yes_ microsoft added direct
 netbios (no smb involved) as a dce/rpc transport, too!]


 so, the endpoint mapper can inform a client that the only
 available transport is ncacn_np [for a given service]
 _even_ if the client contacted the endpoint mapper on
 tcp port 135, because the server has only specifically
 bound to the ncacn_np transport.



> The only time you need Samba code is if you wish to plug in
> named pipe backends into the SMB transport, which the plug-in
> API Andrew describes is ideally suited for the task.

 named pipe backends....

 ... great!  i have some hope for the future, after
 having been extremely disappointed for the last two
 and a half to three years.


> The code for the DCE/RPC system has been release (not as Open Source/
> Free Software though I believe) so it can be studied freely
> for an interoperable implementation.

it's a lot of code [extremely well-documented code], and yes,
you're right, it's there.  it works.

and it's been ported to linux.

it's called freedce.  it's available on dcerpc.net.  see the
cvs page http://dcerpc.net/cvs.

there are also a number of other projects being hosted
on dcerpc.net, such as osexchange - open source exchange.

all of these projects are critically dependent on a number
of key things happening, and this "named pipe backend" is
one of them.



> I'm afraid Samba is being used here as a convenient whipping post
> for Luke's other problems and past grudges. 

just a word of advice, jeremy: you know i'm brutally
blunt and don't hold back when i get started.  don't
push your luck by goading me.

i'm going to ignore this one, and ask that you
don't get involved, here, jeremy.

> That's a shame but
> it doesn't affect the technical arguments.

glad to hear it.

lkcl