Comments on: Don’t script it, just make it so http://www.cmdln.org/2009/07/18/dont-script-it-just-make-it-so/ a system administrators mutterings Sun, 28 Feb 2010 09:28:06 -0600 http://wordpress.org/?v=2.9.2 hourly 1 By: Nick Anderson http://www.cmdln.org/2009/07/18/dont-script-it-just-make-it-so/comment-page-1/#comment-937 Nick Anderson Wed, 12 Aug 2009 14:13:45 +0000 http://www.cmdln.org/?p=416#comment-937 Indeed, I never do OS upgrades on anything (as long as I have a say). I always do a fresh install and drop the needed data in place. The configuration management tools like puppet make it very consistent and easy to either stand up a new server or to push a firewall change either to a specific node or to a group of nodes. I also agree it would be almost pointless to not store your configuration managements tool outside of version control. You would never have a record of what has changed over time or why. Both of those aspects are very important especially when looking at configurations you have not touched in a while. Indeed, I never do OS upgrades on anything (as long as I have a say). I always do a fresh install and drop the needed data in place. The configuration management tools like puppet make it very consistent and easy to either stand up a new server or to push a firewall change either to a specific node or to a group of nodes.
I also agree it would be almost pointless to not store your configuration managements tool outside of version control. You would never have a record of what has changed over time or why. Both of those aspects are very important especially when looking at configurations you have not touched in a while.

]]> By: Michael Janke http://www.cmdln.org/2009/07/18/dont-script-it-just-make-it-so/comment-page-1/#comment-936 Michael Janke Wed, 12 Aug 2009 13:05:56 +0000 http://www.cmdln.org/?p=416#comment-936 A configuration management tool certainly would qualify as a 'script', not a 'click' in my world, and if it's a decent tool, would have the additional properties of handling version control and maybe even configuration auditing. I also like the idea of storing the configuration of the configuration tool in version control. And 'config creep' is a problem on any system. One of the simplest ways that we've battled it (on Solaris) is to manage the apps in a way that permits re-installation from scratch easily and consistently. When we upgraded from Solaris 10 u4 to Solaris 10 u6, we re-installed each server OS from a golden image, re-applied any per-server customizations and re-installed the apps from a master copy in an SVN repository (the data is untouched, on separate LUN's). We did not do any in-place upgrades. That method is faster and more consistent than an in-place upgrade. Can't do that with Windows though. A configuration management tool certainly would qualify as a ’script’, not a ‘click’ in my world, and if it’s a decent tool, would have the additional properties of handling version control and maybe even configuration auditing.

I also like the idea of storing the configuration of the configuration tool in version control.

And ‘config creep’ is a problem on any system. One of the simplest ways that we’ve battled it (on Solaris) is to manage the apps in a way that permits re-installation from scratch easily and consistently. When we upgraded from Solaris 10 u4 to Solaris 10 u6, we re-installed each server OS from a golden image, re-applied any per-server customizations and re-installed the apps from a master copy in an SVN repository (the data is untouched, on separate LUN’s). We did not do any in-place upgrades. That method is faster and more consistent than an in-place upgrade.

Can’t do that with Windows though.

]]> By: Sol Jerome http://www.cmdln.org/2009/07/18/dont-script-it-just-make-it-so/comment-page-1/#comment-934 Sol Jerome Tue, 11 Aug 2009 18:16:23 +0000 http://www.cmdln.org/?p=416#comment-934 Nick, The xml configuration in bcfg2 isn't as bad as it seems. Most of the xml present in your configuration can be generated using tools which are shipped with Bcfg2. There are also advantages to using xml. You are able to easily verify your configuration using xmllint (which is nice since you don't end up having to maintain your configuration checker). Also, having the configuration in xml means you can transport it seamlessly via the most popular transport protocol (http). IMO, the benefits far outweigh the fact that xml is used for the configuration. Nick,

The xml configuration in bcfg2 isn’t as bad as it seems. Most of the xml present in your configuration can be generated using tools which are shipped with Bcfg2. There are also advantages to using xml. You are able to easily verify your configuration using xmllint (which is nice since you don’t end up having to maintain your configuration checker). Also, having the configuration in xml means you can transport it seamlessly via the most popular transport protocol (http). IMO, the benefits far outweigh the fact that xml is used for the configuration.

]]> By: Nick Anderson http://www.cmdln.org/2009/07/18/dont-script-it-just-make-it-so/comment-page-1/#comment-902 Nick Anderson Sun, 19 Jul 2009 02:08:36 +0000 http://www.cmdln.org/?p=416#comment-902 I did look bcfg2 and cfengine. I didn't like cfengine because it didn't seem to provide the abstraction that puppet provided. bcfg2 I liked but I found the xml configs a bit obtuse. That combined with a few installation issues kind of turned me off of bcfg2. I really like that its python as opposed to ruby though. How large of an infrastructure are you managing with bcfg? Also this was not meant to be as much of a props for puppet as a general methodology. I think the most important thing is that you version your configs. It makes the most sense to store them and manage them centrally. There are a few systems that allow you to do this and I just find puppet to be the right fit for me? What did you like about bcfg compared to puppet? I did look bcfg2 and cfengine. I didn’t like cfengine because it didn’t seem to provide the abstraction that puppet provided. bcfg2 I liked but I found the xml configs a bit obtuse. That combined with a few installation issues kind of turned me off of bcfg2. I really like that its python as opposed to ruby though. How large of an infrastructure are you managing with bcfg? Also this was not meant to be as much of a props for puppet as a general methodology. I think the most important thing is that you version your configs. It makes the most sense to store them and manage them centrally. There are a few systems that allow you to do this and I just find puppet to be the right fit for me? What did you like about bcfg compared to puppet?

]]> By: PB http://www.cmdln.org/2009/07/18/dont-script-it-just-make-it-so/comment-page-1/#comment-901 PB Sun, 19 Jul 2009 01:55:18 +0000 http://www.cmdln.org/?p=416#comment-901 Did you happen to take a look at anything other than puppet? It's not clicking for me like bcfg did when I took a look at that. I think that some big players are looking at puppet and it's always important to at least consider that when making a long term decision. Did you happen to take a look at anything other than puppet? It’s not clicking for me like bcfg did when I took a look at that.

I think that some big players are looking at puppet and it’s always important to at least consider that when making a long term decision.

]]>