I think there are three general strategies:

1. Take notes.
2. Configure everything through some utility that keeps track of it.
3. Learn the default state and diff the system vs. it.

Taking notes is self evident. This is a bit tedious, but taking notes about what you are doing is a good general habit for any adult, not just for Linux but life in general. So if you are already motivated to maintain this habit, you can simply be disciplined about always noting whatever changes you make. You can use something as simple as a paper notebook, or it may be easier to have a bunch of text files on your computer for the sake of copy/paste.

Useful things to note are:

• When you made the change
• If you were following a guide, links to it
• Versions of software you think may be relevant. It helps to learn some shell idioms for printing the version and sending it to the clipboard.
• If you changed a specific config file, the exact path to it and which line number you changed. You can get the path from realpath.
• If you changed it by clicking on things in a GUI, you can describe what exactly you clicked or save a screenshot

If this leads you to think that configuration files are superior to GUI utilities, because of how much easier changes are to record, you are right :)

Sometimes, it is useful to also save things like console output and logs if you feel like you might need it. It takes some time to learn how to judge whether this is overkill or not for a given change, so to start out I'd record as little as possible to avoid overwhelming yourself.

The "utility" method is nice because it can reduce the tedium of note taking by leveraging technology to do it. The common way is to use "dotfiles". This means that you use git to track changes to each config file as if it were a piece of code. Git will handle tracking paths, exact lines, reproducing the same change on a nother computer, annotations about why you did something (commit messages), chronology... But you will have the following challenges:

• Git is designed to track files inside a given "project" directory, but your config files will be all over the filesystem
• Many config files require admin privileges (sudo) to edit, which git normally doesn't have
• Some things are configured in a way that git cannot handle (exotic binary formats, mixing volatile state information with configs so that it looks like there's many changes even when you didn't change anything)

The first two have many nice solutions in the dotfiles community. The third is harder, you have to either avoid programs that can't be easily configured via dotfiles, or you have to automation write scripts that handle the configuration to avoid making git deal with the config state directly. Firefox and Chrome are a great example: They have a very messy config directory that doesn't separate user configuration from data like history that will always change under normal use. They also have a lot of obfuscated data, like things wrapped up in some binary database file instead of a simple text file. From this you see a third option - for exceptional cases like Firefox, use git only to take notes to manually configure them, while still doing the full dotfiles approach for the majority of other programs which have better design.

Doing diffs is IMO not practical as a general approach, because most desktop OSes acquire very complex state after a few years of normal use. This is more practical for:

• Things like servers that have a narrow usage
• Distros designed around it, like Guix or NixOS
• As a fallback in when you discover after the fact that you forgot to keep track of something

In Linux these days, configuration that applies to all users on that computer will be somewhere under /etc. Boot-time things maybe baked into the initial boot environment (under /boot) but they will still be controlled by configs under /etc (see GRUB and mkinitcpio). Configuration that applies to only one user should be somewhere under ~/.config.

These days, most Linux systems have only one human user, but usually there is a second, hidden "admin" user that doesn't share your user's config. When you do things with sudo you may notice your configuration reverts to default sometimes, the short answer is that sudo sometimes looks at /root/.config instead of /home/$USERNAME/.config.

The above are simply conventions and not every program is guaranteed to follow it. A developer may choose to put the configs in some random place just because. This is discouraged in the community because it makes it harder to find the configs, so you may find it useful to avoid the work of such developers. Also, in past years it was common to put configs in ~/.program_name instead of ~/.config/program_name and some older software may still do it.

Generally, I think trying to identify changes post-mortem is a case-by-case thing. So I won't aim to describe it fully in this answer. A better way would be to try some basic naive guesses based on the above, and if you can't find it, ask a new question about specifically that case on this site (or elsewhere).

posted 10 months ago

CC BY-SA 4.0

matthewsnyder‭

1851 reputation 124 77 292 110

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 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. 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
• the notebook which gives you a good place to write about configuration changes made
• a magical notebook that will check your work or even do some of it for you when you forget

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!
3. although the etckeeper vcs log shows apt operations and some others with useful information, there is a risk of a run uninformative "daily autocommit" entries.
   • Because the VCS is tracking not driving changes, you are at liberty to rewrite that Git history any way you like to provide better commit granularity and messages, but who has time for that?

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...

Immutable OS

Something like Fedora Silverblue or (related) rpm-ostree might be relevant.

The fundamental idea is that the base OS is immutable and atomically updated every few months; then I think other apps are brought in with flatpak / snap / etc.

It doesn't remove the mess of configuration files, but it should isolate their influence into much smaller zones of sprawl.

Gordian solution

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Alan Perlis

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

posted 4 days ago

CC BY-NC 4.0

2d ago

mcast‭

11 reputation 1 3 1 8