New configuration backends for Samba 3 SoC project

Ming mingwxia at gmail.com
Tue May 30 04:56:35 GMT 2006


2006/5/28, Gerald (Jerry) Carter <jerry at samba.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mingwang,
>
> This is probably one of the more interesting projects
> from my perspective (mostly because I've been whining
> about configuration bloat for a while).  First some
> background.
>
> I initially spoke with Avi about possibly using libelektra
> (http://www.libelektra.org/) but I never got a chance to
> try the work.  I know Avi started on some of it last month
> but then hit a few issues.
If we use libelektra,we need to implement a backend in libelektra
which probably named
libelektra-smb.so(http://www.libelektra.org/Library_Linkage_Architecture).It
should parse the smb.file and implement a set of interface used by
libelektra.so.Further more in order to maintain the other samba server
part changed as few as possible to use the new configuration backend,
We might wrap the libelektra.so interface to what smb team already
used.

> I think the first challenge is to abstract the interface
> used by Samba servers and tools to query values from
> the config backend.  To make any move towards a richer
> configuration backend, we will have to continue to
> support a "legacy" smb.conf file.  I'm not as worried
> about actually implementing this legacy support during
> SoC, just keeping the requirements in the back of our
> minds.  The advantage of using a library like libelektra
> is that it abstracts the query/set calls from the actual
> data storage.
Yes and I'm not clear how the other parts use the smb.conf backend(all
through lp_**?). Should we implement the new configuration backend as
a new set of get/set interface, that will bother the other server
part,I think.
> 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.
>
> 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.
In order to meet the speed requirement,heavily accessed option should
use in-ram hashes.Is it possible to implement an architecture as:
+---------------------------------------+
|parameter access interface |
+---------------------------------------+
                     |
+-----------------------+ +-----------+
|smb.conf parser |   | LDB     |
+-----------------------+ +-----------+
We define a set of new interface which text configuration and LDB
configuration modules should implement(other futhure one conform to it
too).

> Just some initial thoughts.
Also need discuss. :)
>
>
>
> cheers, jerry
> =====================================================================
> Samba                                    ------- http://www.samba.org
> Centeris                         -----------  http://www.centeris.com
> "What man is a man who does not make the world better?"      --Balian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iD8DBQFEeLKTIR7qMdg1EfYRAgavAJ9YqucpctC5N9SLOQtpqZNr0lNgcgCg4jii
> VVuqUyXLP6h42/6Ce8+jpBQ=
> =fbZm
> -----END PGP SIGNATURE-----
>


More information about the samba-technical mailing list