Post History

> if I configure everything this way, it will turn into a mess, and after a few months I won't know what things I configured where

I agree, and would suggest that we are looking for a way to "manage the mess".

Other than taking notes as @matthewsnyder said, you can put copious comments with your reasons / initials / date in the files modified - when you are not using a GUI.

# Cattle vs pets

[First search hit](https://www.hava.io/blog/cattle-vs-pets-devops-explained) seems to describe what I'm talking about, TLDR there may be better ones.

The gaming rig, the personal laptop and the configured-over-years mail server are "pets" in this analogy. When they get old, you still love them but the vet bills are mounting up and there are hard choices to be made.

The DevOps way is to define how the thing should be, put the recipe in version control, test the recipe like any other software release, then run the provisioning tools to make it be that way. When it gets poorly (and it will) just update the recipe, test again, bring up a new one and shoot the old one.

(It's also a grim and sad comment on modern industrial animal farms)

The DevOps way does _assume_ that bringing up a new VM in a pool of hardware, and returning the previous resources to that pool, is a cheap and fast operation.
* Mail servers, microservices and replicated databases work well this way.
* Firefox profiles, laptops with large home directories and real animals... not so much?

# Tracking changes in `/etc`

For /etc **I highly recommend [`etckeeper`](https://etckeeper.branchable.com/)**. It doesn't change anything, it just commits (git, mercurial, brz or darcs) the whole of /etc into `/etc/.vcdir/` each time something happens, or daily.

The implementation is fairly easy and quick to inspect, by reading `dpkg -L etckeeper` or equivalent to see the few files contained, so you can be confident it won't cause problems.

What does it do for you? After only a few weeks of using it, and many years' not using it,

1. you have the record of exactly what changed and when, at least under /etc, with good precision and accuracy
2. it's better if you remember to `etckeeper commit -m "what I did and why"` after making changes, but if you don't the "daily autocommit" catches it
3. after taking care with permissions and remembering the whole VC history should be sufficiently private, you have the usual ways to ship a copy elsewhere
4. the immediately obvious benefits for me are
    1. `etckeeper vcs log { --name-status | -p -5 cloud/cloud.cfg.d/ | ... }` to look at what changes happened in the past
    2. `etckeeper vcs diff` to double-check what I'm about to modify and leave running
5. Yes, it does keep a record of the permissions on all files affected, and in a script form that looks easy and safe to re-apply
6. Yes, it ships with a bunch of `/etc/.gitignore` entries to reduce noise
7. **It looks very safe.** If you installed it, forgot about it and never used it... no harm done.
8. It is now #2 in my list of things to do on a fresh machine after that first `apt update`

Think of it as the right way to get older `diff -u /etc/aliases{~,}` versions!

Downsides,

1. it isn't really designed for rolling back to an old version or merging changes from another machine, but you could and the support is there.
2. running `git` manually as root, especially for networking stuff, is unnerving. Don't fight that, it should be unnerving!

# Changing `/etc` from a version control project

I'm making a little tool for doing the reverse, for the subset of files `/etc/aliases`, `/etc/exim/` and related, that I need to drive on a couple of machines. Currently this is at the toy project stage.

The plan,
1. ✅ copy the old dusty files into Git
2. ✅ write Python / Shell mess to do the important operations
   * paste those files back into /etc in a controlled way, setting permissions
   * freshen the VC copy from what's currently live in /etc
   * diff
3. ⏳ try it on another machine (and see what kind of mess needs clearing up after)
4. Profit! Or more likely GPL / abandonware.
5. ❌ Oh and test driven development. Whoops... I was in a hurry.

It might be classed as a kind of semi-DevOps?

# `~/`

I have yet to bring my `~/.dotfiles` under any kind of control. I have an inconveniently large number of different home directories for various purposes on laptop, servers, Raspberry Pis (plus SD cards swapped out).

I know there are projects to do it, but my previous attempts to put my home directory in version control were Not Pretty.

Advice welcome...

# Gordian solution

> Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- [Alan Perlis](https://www.brainyquote.com/quotes/alan_perlis_177188)

Remember that the configuration changes are not important and should not burden you, if the machine is powered off.