Fw: Patch for accessing smbconf via registry rpc interface

Volker Lendecke Volker.Lendecke at SerNet.DE
Thu Aug 10 07:06:09 GMT 2006

Hi, Chetan!

On Thu, Aug 10, 2006 at 11:20:31AM +0530, Chetan D Shringarpure wrote:
> 1. The code does not read the parameters from the smb.conf. This is so 
> because it avoids the need of revalidation for the parameters and values. 
> It simply gets the details from the loaded services.

In the past weeks I've started to get rid of the notion that
the loaded services are organized as an array. In you patch
I find for example

+               num_services = lp_numservices();
+               for (i=0 ; i < num_services-1 ; i++ ){

(BTW, why "num_services-1"...? ;-))

This is where it shows through that loadparm.c organizes the
loaded services as an array, and this in big ways restricts
the possibilities to be more flexible.

In transition to a more flexible scheme I've created a
struct share_params:

struct share_params {
        int service;

Right now it is only a wrapper around the "int snum" that is
everywhere in the code. But having a struct here makes it
possible to later on change the representation in one place.

What I would like to do step by step is to change all the
lp_ functions for share params to not take an snum as the
first parameter but a struct share_params. If that
transition is done, loadparm.c does not longer export the
fact that it organizes the loaded shares as an array.

To get such a struct you use "get_share_params()" which
converts a share name to a share param struct. Right now
this is equivalent to a find_service(), but it might as well
in the future to out to ldap, libelektra or wherever.

To enumerate all shares you use another struct:

struct share_iterator {
        int next_id;

For a use example of this please look at srv_srvsvc_nt.c,
function "init_srv_share_info_ctr".

I'd like to see your patch not reference the share num

> 2. The same problem is bit more complex when it comes to writing it back. 
> Moreso because there are included smb.conf. I don't see a clean way to 
> "know" and writeback.

I think there is just no way. We've been discussing this a
couple of weeks ago, include files just can't be handled in
a sane way with any kind of automatic writing to the
smb.conf. See the mail archives ;-)

> 3. There is definitely a possibility to avoid the need of included 
> smb.conf altogether by adding access levels and control thanks to the 
> reg_access hooks available in registry. This however is something I would 
> need a considerable discussion and thought. This is cleanly possible if a 
> switch is made to some different richer storage backend like xml, binary 
> (most contentious).

This sounds like an interesting idea, however this will
probably not be a full replacement of all the tricks you can
play with include files and macro expansions. Ask Mathias
about the things the OESV has done to smb.conf :-)

> 4. An api can be written to deal with smb.conf more sanely. However thats 
> almost similar to creating libelektra allover again.

Yep. So I would not do it :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060810/c45e316a/attachment.bin

More information about the samba-technical mailing list