dce/rpc "client" api

[Andrew Tridgell]

> how about... samrd.  grepping for extern, this uses global_sam_name,
> global_myname, global_sam_sid, global_builtin_sid.
> 
> wow, big deal.

There are a lot more variables that are affected than those you find
by grepping for extern. In many cases we hide variables behind little
set_foo() and get_foo() functions, with the variable itself declared
static in the module.

There are also all of the global and static variables used inside all
the Samba utility functions. Any of those may carry with them a
semantic dependency on the current architecture where we have a single
process per client.

You have already had to kludge your way around several of these in the
TNG code. For example you return the name of the DCE/RPC pipe for %m
in smb.conf macros when inside the msrpc daemon in the TNG branch,
whereas in all released versions of Samba %m has been the clients
netbios name. You do this because the netbios name of the client is
not available inside daemons like msrpcd. If someone is doing printer
accounting based on the netbios name of the client machine then this
will break with the TNG code, but only from NT workstations (from
Win9X it will keep working).

I can understand why you put in this quick hack, as it allowed you to
quickly get working code. Does it matter in this case? Not
particularly much - we could decide to deprecate the %m macro (and %I
etc) and document that it no longer is reliable. Alternatively we
could include the client netbios name and other variables in the setup
calls that smbd makes to the msrpcd daemon.

It isn't that the individual problems are really hard to
overcome. Every one of them is surely solvable with a little
effort. My point is that we would need to identify all of these little
semantic nuances and address them individually to prevent getting
nasty surprises when we release this onto millions of systems with a
myriad of weird configurations.

As far as I'm aware there has not yet been any serious effort to
identify these potential problems. As the only way to be sure of
finding them all is to _carefully_ inspect about 200k lines of source
code this is not surprising.

> the other question is, what do you do about %macro substitution variables
> [some of which are derived from global variables]. as i mentioned in other
> messages, the whole issue of implementing, regardless of implementation,
> dce/rpc services throws the whole %macro system into disarray.

I'm not prepared to throw away our %macro substition system. It is
extremely widely used and one of the most useful aspects of Samba
configuration. I also disagree that it must be thrown away with any
dre/rpc implementation, as most of the variables work fine with
in-process implementations and only start failing when we move to a
separate daemon.

In any case the %macro problem is only the tip of the iceberg. A
decade of coding with a process-per-client architecture has left us
with code where we just don't know where we now have subtle
dependencies on having only one process per client connection. To just
ignore this and assume everything will be all right is a bit too brave
for my liking.

Cheers, Tridge