The Strengths and Weakness of Fedora/RHEL OS management

[Shane Stixrud]

On Tue, 28 Mar 2006, David Lutterkort wrote:

> The problem with (4) is that you mix describing what you want to be done
> with how it is done, which has a number of disadvantages.

I agree, the biggest disadvantages with 4) IMO are:

1) Overhead of keeping the build scripts up to date
2) Determining what should be scripted vs done manually
3) Roll back / change revision is very difficult.
4) This approach can easily cause confusion on "objective" vs 
"implementation" for a 3rd party.

It is my opinion that in an ideal world the OS/configuration engine would 
be able to largely eliminate these disadvantages by tracking the history 
of all configuration changes from inital system build to current state, 
independent of how the change was made (scripted, distributed, manually at 
the console, etc...).  It seems to me this would be trivial if every 
configuration element was easily identifiable by path (filesystem), 
key name (filename) and it's value (content). Obviously there are 
practical considerations that make this difficult, performance, number of 
files, what should be a directory vs a file vs content etc...

> I have been using another config mgmt system, puppet,
> (http://reductivelabs.com/projects/puppet) I wrote up an example of how
> a config mgmt tool could help in solving the kind of problem you are
> looking at: http://people.redhat.com/dlutter/puppet-app.html

Puppet looks like a very promising centralized change distribution system. 
As you mentioned this separates the "how" changes are applied from the 
"what" is actually changing.  If you combine the change re-visioning 
concept mentioned above with a puppet like centralized distribution system 
that can detect client changes we now have something quite impressive.  In 
fact it resembles very much what I have with my Cisco equipment + 
management software.

> A lighter-weight approach seems more promising: encapsulate most of the
> config-file specific knowledge in simple script wrappers that can be
> controlled by a declarative description of the configuration you want to
> achieve and the logical interdependencies between them. This is what
> puppet does, and why I find it very attractive.

I mostly agree, although very elegant compared to what exists today I 
would still classify it as a work-around.

Cheers,
Shane