CVS update: tng/source/passdb
Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Tue Jan 8 02:13:03 GMT 2002
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.
> 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.
the endpoint mapper service listens on ncacp_ip_tcp,
ncadg_ip_tcp, ncadg_dds (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
_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.
More information about the samba-technical