Using Git And Etckeeper To Version Control Your Server Configuration
Keeping track of your server’s configuration is an important part of making sure that nothing breaks. Version control systems such as Git allow you to track changes to your files, when they were made, who made them and why they were made. This makes it much easier to identify why something has gone wrong, and also what the correct version should be. One way in which version control systems do fall down is that while they track the contents of the files, they don’t do well at tracking the file permissions, which is where Etckeeper comes in. This is a tool that works with Git in order to keep track of changes in your /etc directory, allowing you to track these changes whether you make them or they are made by your package manager updating the directory.
Something to note is that some of the files in the /etc directory need to be kept private for the security of your system. As such, if you are pushing the git data to a central repository for safe keeping you’ll want to be sure that you can trust the users that are able to access the data.
Installing Etckeeper
On Debian and Ubuntu systems the installation is pretty straightforward as Etckeeper is in the default repositories, and can be installed with the following commands:
sudo apt-get update
sudo apt-get install etckeeper git
For CentOS and Red Hat users you’ll first need to enable the Fedora EPEL (Extra Packages for Enterprise Linux) repositories:
sudo yum install epel-release
sudo yum install etckeeper
Configuring Etckeeper
Once installed, there is a configuration file for Etckeeper. /etc/etckeeper/etckeeper.conf has most of the settings you’ll need for configuring it. It starts with the choice of version control system (VCS) for which git should be selected by default. This is followed by any extra options you may wish to add to the various VCS option commits. Next are some options for changing when Etckeeper will automatically commit the files for you. You then have the options for setting the package managers your system uses. At the very end of the file is the option to set details of any remote repositories for the Etckeeper to push the commits to.
By default, Etckeeper will automatically commit any changes every night, and will also commit any changes prior to your package manager running to ensure it catches any changes prior to a package manager making a change in the /etc directory. If you don’t want those functions you’ll need to change the setting in the configuration file.
Etckeeper Monitoring
To start etckeeper monitoring your files you’ll need to initialize it.
cd /etc
sudo etckeeper init
This will create a directory called .git that contains the data that git will store about the change it tracks in the directory. It also creates a file called .gitignore that contains files that Etckeeper doesn’t need to monitor in the directory. You can also add other filenames that you don’t wish to monitor to that file.
So with everything now set up, you can now make your first commit of your /etc directory:
sudo etckeeper commit “Initial commit of /etc”
The screen will scroll with details of the files being added to the commit.
Next, we’ll look at making a change to a file:
sudo nano hosts
At the bottom of the file add:
127.0.0.1 example.com
Save the file and exit. Now we can re-commit to add the change.
sudo etckeeper commit “adding example.com to hosts”
This will then show some details of the changes added in this commit.
So finally, let’s look at how you can reverse a change. First, you can look at the history of the changes with the following command:
sudo git log –pretty=oneline
This will show you the list of the commit serial number and the text given with the commit when it was made. To roll back to an earlier commit you can use the following command:
sudo etckeeper vcs checkout e6586a /etc/hosts
In this command the “e6586a” is the start of the commit serial number. You only need to use as much text as needed to be unique. So this command is telling etckeeper to checkout the /etc/hosts file from the commit starting with “e6586a”, which in my case was the initial commit. If you try this and then look at your hosts file you will see that the change made was reverted.
Note here that if you don’t include a filename at the end of the command, all the files in the directory will be rolled back to how they were at the time of that commit.
If you revert changes using the checkout method, you’ll still need to commit the changes again, much the same as if you had manually changed the file to ensure that your most recent commit matches the current status of the directory.
With that, we are now done, and you should be able to successfully keep track of the changes to your /etc directory using Etckeeper.