Archive for July, 2012

Excessive automation

Monday, July 23rd, 2012

In this line of work, automation is a Good Thing. There are so many things you can do to make your life easier with scripting it’s ridiculous. Just looking at doing new installs of linux machines, you can do pretty much anything you want to in the %post section of a kickstart. And I do mean anything – you could, if you wanted to, even blow away the linux you just finished installing and lay down a copy of Windows! Why you would want to do that remains a mystery, but it’s possible.

However, there does come a point where you’re over-automating, possibly because you’re trying to control too much. Two huge examples of what I consider over-automation: 1) fixing the position of kernel stanzas within the grub.conf file, and 2) munging files to conform to “preferred” presentations when there is no functional difference between what the system generates and the “preferred look”.

First, fixing stanza locations in grub.conf. Most of the time (most being 99.9%), grubby automatically puts new kernels at the beginning of the file, since they appear at the top of the list when you’re booting. That means it’s already at position 0. Munging a file like this by hand is HARD. The only people I’m aware of who are qualified to write a parser to ensure you always generate a correct file are the people interested in writing compilers, not one-off scripts to deal with grub.conf syntax. Don’t try to parse it yourself – you will get it wrong. You may get it right for the first 6 months, or even 5 years, but eventually, your script will be wrong, and by that time, you probably will have forgotten where the script is and forgotten what the heck you were doing inside it, and nobody will be able to fix it. Let the system manage the order of kernel stanzas for you – the default kernel doesn’t have to be the first listed, that’s why there’s a “default=” option. Besides, if you’re a linux admin, you should be able to look at the file and figure out the default kernel from the default= option when you’re blind stupid drunk and half asleep.

Similar reasoning tells you not to munge system-generated files for no other reason than a preferred presentation. Example? The kickstart creates an /etc/sysconfig/network file with HOSTNAME=<FQDN>. It’s functional. It’s system-generated. It will work just fine forever and ever amen. I know lots of people prefer to see HOSTNAME=<short name> and DOMAIN=<domain>. There’s no reason for that, they are functionally equivalent. Munging that file in that way will cause breakage as soon as the variable to specify the host name changes – granted, that may not happen until version five hundred thirty-three and seven tenths, but as soon as it does happen, *BOOM* your kickstart is broken. And you’re probably not sure where it’s broken, so you’re not sure how to fix it. If you’re even still at that job, which these days isn’t all that uncommon, so your inheritors are cursing your name and your father and your father’s father unto the seventh generation for inflicting them with a kickstart that is broken in a way they can’t figure out.

Like with beer, moderation is the key to automation. Automate what you can easily automate, automate what makes sense to automate, but don’t try to automate everything just for the sake of automation.