Fwd: The Strengths and Weakness of Fedora/RHEL OS management

[Toshio Kuratomi]

On Fri, 2006-03-31 at 13:33 -0300, Avi Alkalay wrote:
> On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> > I'd argue that as the number of subnets and special case workstations
> > goes up, the ability of a system administrator to read and understand
> > the flat file is going to be markedly harder than for the admin to read
> > the custom-crafted dhcp-config syntax.
> >
> > So if the end-goal is to keep the system-administrator's poor brain from
> > exploding while manually editing the files, I'd say custom-crafted
> > config files can be a win versus the generic one-size-fits-all approach.
> 
> 
> 
> Thats not the end-goal.
> 
You came into the thread late.  It's not Elektra's end-goal, it is the
end goal of some of the posters to whom I was replying.

> See, the end goal is to standarize configurations in such a way that
> one program with proper permissions can directly interact with another
> program's configurations. So in your DHCP server problem, an LDAP
> helper can easily change DHCP's configuration to add/remove/change
> some host's fixed IP address, for example, without having to ask the
> sysadmin (a human being) to edit it manualy, and without having to
> regenerate the entire config file again.
> 
So Elektra's end goal is a common on-disk format?  And libelektra is a
"reference implementation" providing an API that the developers think is
sane?  Which clears up the following areas:

* GConf as a backend was not a real long term direction for the
software.
* Making Elektra a backend to GConf/KConfig/etc is providing an
additional API rather than the canonical one.  It doesn't compromise the
core goal of a common on-disk format.

Please further clarify if necessary.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060331/30b60df3/attachment.sig>