New configuration backends for Samba 3 SoC project

[Avi Alkalay]

Some time ago I started to look inside Samba's source to see how to
inject the Elektra patch.

In general, programs use to deal with configurations this way:

1. Parse configurations from a conf file or other type of backend
2. Fill internal C structs with these configuration parameters
--- End of configuration-related code and affairs with configuration
files etc ---
3. Rest of the program accesses these C structs to define its "modus-operandi"

So to switch to a different configuration backend, something between
step 1 and 2 should be written for the transition time, and when
stabilized, move entirely to become step 1.

My impression (that could be wrong cause I didn't went very deep) was
that the configuration retrieval infrastructure is being called too
many times in too many places in Samba code. And I sent the following
message that time:

> I started to work on that and already have reimplemented
> param/param.c::pm_process(). That was easy. But couldn't find a clean
> way to inject the call to this patch in Samba code, because
> configuration loading is very spread and semantics are very
> file-oriented.
>
> dyn_CONFIGFILE is the variable that contains the configuration file name.
> It can contain a key tree configuration root instead. But the problem
> is this:
>
> $ cd samba-3.0.22/source
> $ find . -name "*.c" -o -name "*.h" | xargs grep dyn_CONFIGFILE
>
> Gives me more than 80 calls or manipulation points.
> I stuck because I'll loose control if I change all this points.
>
> Am I in the right path ?
> Is it the same on Samba 4 ?
> Any tip ?

This is what I mean when I say Samba has a spread configuration system.

I don't know why it is so spread and being recalled so many times. I
guess maybe because Samba's programs want to be aware of configuration
changes. If so, the Elektra way of doing that is to setup some
notifications with callbacks that will retrieve the modifications, and
modify the internal C structs.

I guess too that ldb is being used to store lots of data like long
list of user accounts etc. If so, why the API to access ldb is the
same to access smb.conf. Or I completely missunderstood the relation
between smb.conf, ldb and the API for them all.

Regards,
Avi

On 5/27/06, simo <idra at samba.org> wrote:
> On Sat, 2006-05-27 at 15:12 -0500, Gerald (Jerry) Carter wrote:
> > Most of the lp_XXX() functions can be wrapped around
> > a simple query call.  The main hurdles are smb.conf
> > variables and the include parameter.
>
> A careful analysis on lp_XXX() calls need to be made.
> In some places we call lp_XXX() quite much as we knew they were just
> references to in memory strings.
> We can't move to querying a db for each retrieval without suffering
> major performance issues.
>
> We may end up requiring a cache system to not destroy performances.
> (Think of how much lp_workgroup() is used (more than 200)).
>
> > In an ideal world we could have a virtual registry
> > for configuration that could be pulled from multiple
> > data sources: advanced options in a registry (I know
> > I'll get flamed for that comment) and the admin friendly
> > ones in the normal configuration file/backend.
> >
> > Even if we don't end up using libelektra, I'd like to
> > have an abstracted interface rather than hard coding
> > ldb calls.  And since ldb is still in flux some, it's
> > probably safer to localize the ldb calls as much as
> > possible.
>
> Jerry, the ldb api is not going to change that much and certainly not
> the ldb syntax (which is in the end the ldap syntax).
> Anyway, I think that for a registry style interface a simpler API make
> sense. You just need to get set very specific and wellknown values, no
> need for the powerful but complex ldap filter syntax or to fiddle with
> ldif style programming to change a value.
>
> Simo.
>
> --
> Simo Sorce
> Samba Team GPL Compliance Officer
> email: idra at samba.org
> http://samba.org
>
>