You set up a single Linux machine and it is working fine. Now and then you need to adjust different things to accommodate new requirements. This is a single host, so you decided not to install Puppet, Ansible or any other configuration management system to let the system manage itself (or use a cloud-based management system).
But definitely, it is more than helpful to keep track of all the changes to the central files which define the behavior of the system. And keeping track of changes in DevOps terms is a synonym for versioning. And you should do your very best to automate that. When versioning configuration file changes, it is not so interesting to document the justification for the changes; that is a job for ticket systems like OTRS or JIRA.
But the change itself is interesting.
If you also configured unattended upgrades you end up with a whole bunch of regular changes and in case something doesn't work as expected it will help a lot if you can see what has changed to spot the possible cause.
To start, install etckeeper with your local package manager:
apt install etckeeper
On a Debian or Ubuntu system, this not only installs the tool but also initializes the directory /etc as a git repository (thus you will find a directory /etc/.git when the installation was successful). If not (because your package maintainer has left this out) you need to init etckeeper first:
There are two more things created in the background:
- a package hook
- a daily cronjob
The package hook takes care of all package-related tasks as installation, removal or upgrade. etckeeper needs to know which package system is used. On a Debian or Ubuntu system the configuration file contains these entries:
(On a RedHat system or its derivatives and ancistors it would read "yum" and "rpm", Archlinux both would be set to "pacman").
The cronjob is for the rest of the tasks where direct changes to the configuration files are made. It runs once a day, which should be enough for normal cases; it is not intended to be used as an auditing system as it has no knowledge of who did the change. That also means that intermediary changes until the next run looks like one.
One thing to think about is the possibility to have the changes also pushed to a remote git repository. This has the benefit that you have a versioned copy of your configuration data and that you can for example easily replicate configurations or parts of it to other hosts or projects (don't get me wrong: Ansible and Puppet are great tools but do you always need their complexity? Nope.).
For that, you need to tell your local git repo where its remote origin is. You should start with a freshly created uninitialized repo.
git remote add origin git://mygithoster.dev/myrepo.git git push --set-upstream origin master
Now is a good time to set some defaults if you want, such as a different identity as "root@machine" for commit log messages.
To do so issue this command:
git config --global --edit
After that you should try to see if you can push to origin:
git push origin
If all went well the only thing left to do is to tell etckeeper to make that happen on every occasion when it gets activated. Add such a line to the etckeeper.conf:
For my home server I set up a private github repo, created a proper ed25519 ssh key with
ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "firstname.lastname@example.org"
add this key to github and added the repo as ssh remote as origin:
git add origin email@example.com:username/secret.git
Happy hacking ;-)
The project etckeeper lives here
P.P.S.: etckeeper does not track which packages are installed. If the packages doesn't provide or alter configuration files then you need another way to keep track of it.