The Usual Tech Ramblings

Configuration Management (Part I): Introduction

I’ve been asked to write a post on configuration management, and version control by a friend, Steven Klassen. Instead of a single post, I’m going to break this into several posts as some parts might be unimportant to some, and they can easily skip a whole post. I’ll be posting this over a few days, so stay tuned. If you’re not subscribed to my RSS feed, now would be a great time.

The Request

Earlier today, Steven asked if I used any form of version control. It was a leading question, straight into “dev only or system files”? His questions were targeted, he was searching for guidance1. Another question or two later, and it boils down to this:

  • Do you use version control for system files?
  • Files like domain zone files?
  • What about multi-user environments?
  • Can you write it up?

My take away on the questions boils down to two things; configuration management, and backups. Anybody that has managed any type of system has, at some point, messed up the configuration file, and forgotten what they did to get there in the first place. Those who have been at it a while will usually do a quick copy before they do any modifications. But, as Steven found out in the past, best laid plans can be foiled by a simple typo.

Version Control

This is what version control is all about. It acts as a backup, whilst keeping a running history of what you did between changes. Version control, or revision control as it’s also known, is big business. Anywhere you find a big name development company, you’ll find they’ve probably developed a revision control system to go with whatever they’re offering. Take a look at this Wikipedia entry comparing just a handful of them.

Configuration Management and Version Control

You don’t have to be a genius to figure out how useful version control can be for configuration management, but in case your brain often goes off to lala land like mine, here is a run down on a few reasons you should really consider using it…

  • What did I just change again? And why is that service not starting any more? Oh hell…
  • 6 months down the road, can you figure out why you changed that line to Apache to start 10 daemons instead of 5? No? Most version control systems allow you to add comments to your commits.
  • As above, but why did Fred in your team change that entry back down to 7 a week later?
  • In the words of Homer… Doh!! I wasn’t supposed to delete/overwrite that file!

So, there are 4 obvious cases as to why you’d want to use version control.

The Breakdown

As I said at the beginning, I’ll be breaking this down into several parts. I expect them to be something along these lines:

  • Introduction
  • Setting up SVN and the base repository
  • Using your repository
  • Educating your team members
  • Maintenance and monitoring
  • Conclusion, and follow-up ideas.

If you’re interested, keep an eye open for the rest of the series. If not, send me something you’d like to see me write about. I’m open to suggestions, and will probably butcher anything you can throw at me.

  1. At least that’s how I perceived it