On Sat, 2006-03-25 at 15:37 -0800, Shane Stixrud wrote: > 1) I could create a custom RPM that had all of the changes imbedded in > config files and rpm scripts that merely overwrote the pre-existing ones. > Problem being this approach hides the complexity of what all was being > changed and why. > > 2) Use cfengine after the kickstart install. This of course has some > advantages over the rpm method but it also hides the same complexity and > adds some of its own. > > 3) Document on paper all of the steps required and how to perform them > from the console, taking advantage of the guis when available or command > line when required. I felt that was not only a big waste of time but left > far too much to human error. > > > 4) Create a series of simple scripts using basic OS applications/tools > (sed, echo, cp, mv, authtool, postconf etc...) to perform all of the > required modifications, documenting what and why along the way. 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. One of the goals of config mgmt systems like cfengine is to separate these two concerns. You are right though that cfengine is not entirely trivial to use. 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 > My conclusion having completed this process is that the number of > variables, complexity and dependencies that must be understood and taken > into account when modifying configuration files is much higher than it > needs to be. I think this should be clear when reading the example scripts > mentioned above. One of the reasons to separate the what from the how: there are complexities in both areas, and using a declarative approach to this problem lets you separate these two kinds of cpmplexities nicely. > It is my opinion that we as a community need to find a Better Way (tm) to > manage configuration changes for Linux subsystems and applications. I completely agree. > Everything should be a file, but that does not mean every configuration > file needs to be formatted and managed differently. While I agree in theory, the reality of config files with different formats makes it extremely hard to get there. One approach that is being pushed by a number of players to achieve uniform management of configs is CIM/WBEM, an enormous standard that IMHO too much tool-specific knowledge to see wide adoption. 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. David -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
