Samba 3 Design

Volker Lendecke Volker.Lendecke at SerNet.DE
Tue May 30 07:17:52 GMT 2000


-----BEGIN PGP SIGNED MESSAGE-----

Hi!

At the SNIA Interop Lab in Santa Clara there was a little Samba design
session, where plans for Samba 3.0 were discussed. Here's a little
summary of this session.

Conversion path to samba 3.0:

The Samba RPC subsystem is to be redesigned. Currently the rpc packets
are decoded and endcoded by hand. This is going to be moved to an
automatic conversion via an IDL compiler generating function stubs.

Along with this conversion the plan is to take out the rpc functions
into separate modules that are called by smbd.

When a pipe, say NETLOGON, is opened on IPC$, smbd does not handle
this directly. Instead, it looks for a shared object called
/usr/local/samba/pipes/pipe_netlogon.so, loads it and calls
dlsym("pipe_init") then pipe_init(pipe_name). This returns a structure
with function pointers, one of these should be the rpc handler that
expects and returns the raw rpc data stream. The shared object is
responsible to do the right thing for the RPC opcode it is given.

A rpc handler might need access to data "private" to other rpc
handlers. There are at least three ways to access that data:

- - As a shared library it has access to all internal data structures
  of smbd directly. This path is available as a first step. To make
  this method reasonable we will slowly move all internal data
  structures (open files, connections etc etc) into tdb databases.

- - When a rpc handler has to access data normally available via other rpc
  calls, it can access them directly, but it eventually should issue
  these rpc calls to the other pipe_whatever.so. To do this, it can
  use a local communication mechanism to the second rpc handler.

- - The third way is to use the rpc client library and access the second
  rpc handler as if it had accessed it via the network. This is
  probably the most inefficent way, but for a first implementation this
  way should be used so that the network rpc path is beaten as hard as
  possible.

Breaking it up this way has several advantages:

- - It is possible to unload the shared object for debugging purposes on
  SIGHUP.

- - It should be possible to convert rpc handlers into separate
  processes with only stubs loaded as shared objects. This should make a
  proprietary rpc handler at least possible. pipe_cascade.so or
  pipe_exchange.so might come to mind.

- - To ease administration, it is possible to statically link the shared
  objects, giving the user the impression of having a single smbd as
  he is used to.

A very distant idea might be to put all the data into a distributed
database, making it possible to really cluster samba.

Volker

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface

iQCVAwUBOTNrDD/9BWnmOc5FAQGLqAP/dwjCDFLYhJcMY4wNIE3hRKPymOMTHik/
cDnok6NwzQg6kXnwGkV/3KXQygv6e8Rz65RgiHSuBOgnIGVaW2MGmdifjeLi28EO
513ur09Hjt+g79+7G2P9RMBoazpAqCHab7cXK8doyCYLDskNgMlEf0BIk0GLnBQP
Wyb7jr0VKLM=
=CRK6
-----END PGP SIGNATURE-----


More information about the samba-technical mailing list