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