Apache, APR, TNG, a somewhat bigger picture

[Sander Striker <st...@samba-tng.org>]

Hi all,

For those who are interested, here is what I had in mind
regarding the reimplementation of samba tng.

To begin with we would like to make full use of apr
and the apache server framework to keep things simple and
portable, and to avoid code duplication. In this process
we will likely stumble across things that might be usefull
outside tng, in which case code can be migrated to apr.

Tng is a large project and help from any developers on the
apache team is very welcome. We want to develop under the
Apache license this time, instead of the GPL, so this will
remove a hurdle for many of you.  Possibly as an ASF project
if accepted. Second, we are going to try and split the
development up in graspable (and sensible) modules so noone
has to dive into an enormous codebase at any point in time.
This will also keep the codebase maintainable.

The first two modules to be developed are mod_smb and
mod_nbt. mod_nbt will implement netbios over tcp/ip,
mod_smb will implement smb over tcp/ip (probably we
need a filter that implements smb, that is fed from
tcp/ip, mod_nbt or other transports). I think it is
very sensible to start with smb directly over tcp/ip
(port 445, supported by windows 2000).

mod_smb. What does it do? Well, everyone seems to know about
the file sharing stuff, so yes, that has to be in there.
There is more though :). There is an smb print interface (I
don't like it much and I would like to shift this to the
backburner). And, most importantly, there are named pipes.
A service can open a named pipe and 'listen' for connections
on it. This is all over smb.

Example (simplified):

 client does an smb session setup to the server
 client connects to smb named pipe
 client does transactions over named pipe
 server responds
 named pipe connection is torn down.
 smb connection is torn down.

Now if you closely inspect the above you'll see that there
are in fact two network layers. The server framework could
listen on port 445 and pass the connections to the smb
filter. Then in an ideal world we could also have the
server framework listen for connections on the named pipe
and pass the connections to the associated filter.

I envision modules implementing the services behind named
pipes to do register themselves with mod_smb. For example
the netlogon service could do this (pseudo code) on startup:

    tng_named_pipe_register("netlogon", filter_netlogon);

Or something like that *). How the communication for the pipe
registration is to be done is not defined yet, this needs
some careful thought (keeping security in mind). A filter
approach is also very convenient when we decide we want to
reroute the request to another machine over a secure transport
(maybe to handle all authentication centrally).

Anyhow, the smb layer itself needs to do authentication...
It typically does this by calling the authentication services.
[which are behind the named pipes].

For reference take a look at:
http://www.samba-tng.org/docs/tng-arch/tng-arch.html
Keep in mind that this was written up before we came up with
the idea to start from scratch. Most of the document is
still valid and usefull reading for developers who wish
to take part in this effort. Other document pointers will
be posted at request.


Sander


*) Actually we need a better abstraction which involves
   registering endpoints with dcerpc. We would need something
   like dcerpc_endpoint_register("ncacn_np:.\\pipe\netlogon",
   filter_netlogon); This in turn calls the before mentioned
   tng_named_pipe_register(). We asume that we can at a certain
   point in time make use of the dcerpc code which does this.
   More on this later.