Thoughts on the importance of automated installs
January 3, 2012
I’m currently in the middle of a little bit of freelance work for my old company. Not long after I left, there was another round of funding that led to them getting significant amounts of money to purchase new hardware. Figures, right?
Anyway, they’ve got a lot of stuff going on, so my old boss asked me if I’d be able to set up a couple of servers to perform automated installations, to which I agreed. This means that I’m playing with kickstart and Cobbler again…but while I’m walking through this, I do have to wonder…why put much effort into setting the initial configuration?
I mentioned Cobbler on twitter not too long ago, and the responses varied from “I really need to use that” to “We barely even use that anymore”, which reflects the general spectrum of system administration across the board pretty well.
My thoughts are that if you’re going to be using “best practices”, then you’re going to have a configuration management solution in place, be it puppet, cfengine, chef, etc. Why duplicate all the work you’ve put into your configuration management solution by doing it again in a kickstart file? It doesn’t make much sense to me.
If a simplified lifecycle of a server looks like this:
Why would we insist on making it look like this?
Anyway, food for thought, I suppose. I didn’t manage to get the puppet infrastructure completed before I left, and the new administrator isn’t sure which solution he’s going with, and has asked me to leave off puppet from these images.
What are you currently doing in regards to automated system builds? Do you still lay out the full machine config in the kickstart file (or its equivalent), or do you throw down a bare bones generic install that then is enforced to policy via config management?
Posted in General
Email me
content rss
January 3rd, 2012 at 10:56 am
I thought it was just obvious now that the point of kickstart would be to get the minimum packages installed and get Puppet running, then let Puppet do the rest.
January 3rd, 2012 at 12:07 pm
I’m a big fan of the ‘minimal install just to get Puppet running” setup. However, Cobbler still has its uses, as I still haven’t figured out how to make The One True Kickstart that correctly handles various RAID setups based on hostname pattern.
January 3rd, 2012 at 12:31 pm
We ended up intentionally doing the latter because there was some things that turned out to be too difficult to do in puppet, because we need to support the same feature set across many OSes (solaris, RHEL, centos, opensuse. Yes, all are needed for specific apps). We decided, after much experimentation, that application-level configuration belonged in puppet, while (most) system-level configurations had too many edge cases to be done easily in puppet: the time spent writing the switch statements and handling those edge cases far exceeded the time saved by automation. This problem was greatly mitigated by moving to virtual systems, though; we simply create a VM template that has all the right system-level stuff configured and then let puppet manage the applications.
January 3rd, 2012 at 12:36 pm
I love using Cobbler for VM installation. Mostly it’s just a way of getting the disk layout the way I like it and then firing off Cfengine. Our hardware purchases come in bursts, w/years between them, so the last batch was Kickstart + Cfengine. Next time, I’ll probably use Cobbler because it’s just so dang simple.
(And happy new year!)
January 3rd, 2012 at 1:38 pm
I “live the Debian world,” so haven’t had any use for Kickstart; I’m afraid that overall distribution dependency management isn’t something I’ve used CFengine for very much, however.
I certainly have taken the approach of getting a minimal install going that included CFengine, and then used CFengine to get things into the “grander state.”
Bootstrapping into something somewhat minimal that is capable of then Properly Managing Configuration sure seems like the right answer.
January 3rd, 2012 at 3:22 pm
Christopher: Have a look at FAI, if you haven’t already; it’s quite nice.
January 3rd, 2012 at 6:19 pm
I suspect you’re speaking explicitly about spending too much time configuring the *package list* in Kickstart profiles. To that point, yes, I agree that there’s not a lot of point to it … except speed: Local controlled modern ISO repository in NFS vs. ‘yum install’ from the internet.
Why try to install 200 things from the net when they’re sitting 5ms away at GigE speed?
January 3rd, 2012 at 11:34 pm
At my current position I haven’t had time to set up proper config management but in my last place, we used Kickstart/Cobbler to do the OS install (RAID setup/partitioning) and package selection depending upon type of system being used, then Puppet to perform more of the application-level configuration. Stuff like driver RPM’s would go into Cobbler for initial installation and just be maintained/updated via Puppet. I agree with your point there’s no point in duplicating effort, but I can see specific instances where some configuration mgmt items may belong better in one place rather then the other.
January 5th, 2012 at 6:03 am
PXE install with kickstart (RHEL/CentOS) or preseed (Debian/Ubuntu) for a minimal install and then Puppet for everything here.
Trying to do more than the absolute minimum in the PXE install ends up being more work than doing the same in the Puppet config, as well as being more painful to keep track of for updates, in my experience.
January 7th, 2012 at 2:36 pm
I know we have a base install, and based off the PC name it will pull a different set of packages from the altiris servers. The name consists of the asset tag, campus location code, usage code and position. So it looks like #####AAABB#### This is a decent setup and seems to work with a few exceptions. 1) warehouse seems to think asset tags shouldn’t be a unique field. Also, when re-imaging a machine, you need to pull the old name out of the AD profile or altiris won’t see it as a new device on the network.
January 7th, 2012 at 6:51 pm
FAI (debian) or kickstart (rhel or derivates) to bootstrap cfengine :-)