Samba Management

[Gautier, B (Bob)]

> -----Original Message-----
> From: 
> samba-technical-bounces+bob.gautier=rabobank.com at lists.samba.o
rg [mailto:samba-technical->
bounces+bob.gautier=rabobank.com at lists.samba.org] On Behalf 
> Of Volker Lendecke
> Sent: 22 June 2006 11:11
> To: Chetan D Shringarpure
> Cc: Frank Kolb; samba-technical at samba.org
> Subject: Re: Samba Management
> 
> Hi, Chetan!
> 
> Taking this to samba-technical, this is of broader interest I think.
> 
> On Thu, Jun 22, 2006 at 02:56:36PM +0530, Chetan D Shringarpure wrote:
> > I have been following the libelektra development on samba-technical 
> > and I would think that storing of smb.conf in binary format 
> has been 
> > and will be shot down whenever it is brought up.  Its 
> invariably tough 
> > to prove it to *nix people that anything not editable by vi 
> is a good idea.
> 
> Putting conf data into binary files is a bit hard to swallow, 
> true. But as the requirement to machine-edit that data grows 
> we probably have to do it somehow.
> 
> The idea is the following:
> 
> We convert Samba to look up its config data via libelektra 
> (or some derivative).
> 
> The first config that is asked is the binary one that is 
> fully editable via msrpc.
> 
> We enable "include =" in libelektra, this should then include 
> the classic smb.conf. Probably libelektra needs to be adapted 
> to our smb.conf specialities.
> 
> When presenting the classic smb.conf retrieved via include, 
> libelektra refuses changes to this part of the configuration.
> 
> We ship with a default binary file that only does "include = 
> /etc/samba/smb.conf"
> (or /usr/local/samba/lib/smb.conf)...
> 
> This would give compatibility with existing setups. It is the 
> the admin's choice to go with the hand-written smb.conf that 
> is read-only via the fancy API and the editable part that is 
> stored in some obscure format.
> 
> Something else that needs to be done is to convert an 
> existing smb.conf into the internal format for an admin to 
> change his preference.
> 
> I think this might be a possible compromise that satisfies everybody.
> 

I like the idea of keeping an smb.conf around, or at least preserving
the simple text file as a way of configuring Samba.

But I would do it the other way up: leave the traditional smb.conf as
the primary configuration method, and allow a new config method to be
configured in there (e.g. "include = plugin:elektra").

That way there is no impact at all for users that want to carry on using
smb.conf, and those that want to change can write a simple minimal
smb.conf that simply says 'look over there for your configuration'.  It
also means there will still be an smb.conf, a standard, local file, that
will point sysadmins and consultants in the right direction for the way
a given samba is configured.

To promote adoption of the new mechanism, you can ship with a default
smb.conf that does nothing but import some binary configuration source
that is maintainable via msrpc.

Bob Gautier

_____________________________________________________________

This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat.
_____________________________________________________________