On 3/25/06, Shane Stixrud shane@geeklords.org 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.
- 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.
- 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