dce/rpc "client" api

[Luke Kenneth Casson Leighton]

On 24 Aug 2000, Todd Sabin wrote:

> Luke Kenneth Casson Leighton <lkcl at samba.org> writes:
> > 
> > - client_addr()
> > 
> > - client_name()
> > 
> > - remote_machine (calling NetBIOS name)
> > 
> > - local_machine (called NetBIOS name)
> > [...]
> > so, these i believe to be the _only_ four significant pieces of
> > information that must be transferred across the unix domain socket when a
> > pipe connection is initiated 
> 
> Are you saying you need to make these available at the dce/rpc level,
> or somewhere else?

somewhere else.

>  If it's at the dce/rpc level, I'm curious why you
> need them.  I didn't think they were available to the rpc server.

no, they are not.

what typically happens, and i missed this out, is that after the NBT
session request and also after the SMBsesssetupX, reload_services() is
called in smbd [and also in the code in msrpc/msrpc*.c which is the basis
of the msrpc daemons, with a function table for the service-specific
bits].

if you have this as your smb.conf file:

[global]

include = smb.conf.%m

then you create a per-remote-machine smb.conf.remote-machine smb.conf
file, and smbd reconfigures itself on a _per_ machine basis.

this is what andrew was referring to when he said, "deprecate %m" and
"deprecate %I" etc. as not being useable.

someone has to do a code-walk-through / analysis and come up with any
other variables that will be needed, and at the moment i think that
the critical ones are:

%L for local_machine

%m for remote_machine

%I for client_addr()

%M for client_name()

possibly %a for remote_arch, and %R for remote_proto - basically
everything that is in standard_sub_basic() that changes as each of the
aforementioned connection requests come in.

and it cannot be me that does this, because from past experience, my word
is not good enough.

lukes