Philipp Marek (@pmarek) on GitLab, 2018-11-09.
Scope
We'd like to have a way to follow configuration changes over time; like with source code that may help answer questions like "Why is this setting here wrong?"
Current status
A limited set of files is added to /etc/.git, and sometimes checked in.
Goal
Like with source code, changes in /etc should be documented; the perhaps easiest way is to commit them as soon as possible, with a log message giving a general idea of the change in one or two keywords in front. Examples: FSVS: set up repository., FSVS: add ignore patterns, exim: new TLD list, mailman3 migration: redirect list, part 1.
My reasoning is that (like programming) there'll typically be multiple changes that need to be done, and which have to be figured out over time. Having modified files lying around just raises the questions "why" and "what for", so I'd propose to commit changes at least upon logging out, and continuing work later on in new commits.
A caveat is that, because of using subversion, flattening commits (like git rebase does) later on is not that easy.
Proposal
As the author of FSVS I'm not impartial. That said, the current solution lacks a few things that FSVS could enhance on:
- metadata versioning - owner, group, mode, mtime
- not enough data kept in repository, eg. because of sensitiveness
The latter point could be solved by setting an attribute on the specific files (https://doc.fsvs-software.org/doxygen-gif/group__s__p__n.html#ga2d334147103fe5343ebed845cea712c7) that makes a commit pipe the file's contents through some command line before pushing the content into the repository (the local data is unchanged, of course). That allows eg. to remove the password (hash) from /etc/shadow, so sensitive data can be pruned before it arrives at the repository.
The important thing is that by keeping eg. the user list intact the evolution documentation is much more complete, and recovery becomes much easier -- just undo one commit, and the complete change is removed.
I'm aware that recovery isn't really the goal here - that's what we have filesystem snapshots for.
Dave Cooper (@dcooper) on GitLab, 2026-10-01.
/etc on the server is versioned with etckeeper, in git: it commits daily on its own, and automatically before and after every package installation or upgrade, so each change carries the apt command that made it. File ownership and permissions are recorded in .etckeeper with each commit, and the repository stays on the host, readable by root alone. That covers the goal of this issue. Closing.
Sign in to comment.