Fw: Patch for accessing smbconf via registry rpc interface

[Chetan D Shringarpure]

Hi Volker,

Volker Lendecke <vlendec at SerNet.DE> wrote on 08/10/2006 12:36:09 PM:

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

I just wanted the share names. It looked cooler sans the IPC$. :) 
Moreso I wanted it to closely resemble smb.conf sections.


> 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.

> To enumerate all shares you use another struct:
> 
> struct share_iterator {
>         int next_id;
> };

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

I would like to do so too. Its ideal case where I refer to a share name 
and get every possible detail about it.
I was almost happy while writing the patch, when I came across the 
transitional scheme you've explained. Until I saw that all it had was 
snum. I can change my patch to use your scheme. I agree new scheme is far 
more cleaner and OO to look at, however imho its only a change in access 
semantics.
Besides it was a proof of concept. :)


> > 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 ;-)

A -1 for current smb.conf. +1 for anything that handles it. More ideas 
below.


> > 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 :-)

The idea becomes even more interesting and more complete replacement with 
a xml backend and reg_access_check allowing a peaceful compromise between 
vi loving sys-admins and binary backing developers.

The parameter data remains in human readable form. Access details, keys, 
passwords remain in tdb. XML tags would allow specifying how to deal with 
the data and using a binary storage for Just Right (tm) purposes.

IMHO limiting to just libelektra is not necessary if xml and libxml can 
fulfil what we want.
However am sure, I might be missing some problems which someone might have 
noticed before with xml. I would like to know those.



thanks and best regards,

Chetan Shringarpure
IBM India Pvt. Ltd.