On 3/25/06, Shane Stixrud <shane@xxxxxxxxxxxxx> wrote: > Greetings, > .... > I was recently tasked with standardizing/documenting our Linux server > build/configuration process and as part of this process began training > some of our Windows/Novell administrators to be able to carry out some of > these basic tasks. It was this second part of helping train people that > caused me to examine and re-examine the processes I used for this > standardization. > > My goal was simple in theory, I would use pxe+kickstart and enforce > standard configurations and policies via a series of post scripts while > attempting to keep readability, simplicity and supportability from a > "non-unix guru" perspective as my guiding light (A wise man once said: > Make it as simple as possible but no simpler). For those interested an > example of what I came up with it can be obtained here: > http://geeklords.org/~shane/kickstart > > The process turned out to be not quite as simple as the theory but very > educational none the less. To start with I had a number of ways I could > manipulate my fresh Linux install. > > 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. > I am completely missing the point of this letter I realize.. but doesnt your "The Right Way" also hide all the complex things too. It either does that or removes a lot of functionality that some admin needs to complete a job in a slightly different environment... which means enforcing that everyone's enviromental needs matches what you are laying out. I have to cover 8 different field environments and tasks that require that the same tools do something slightly different each time. Now I can build 8 versions of the same tool that reuses 90% of the same code or I can increase the complexity of the each tool to cover all cases. -- Stephen J Smoogen. CSIRT/Linux System Administrator -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
