Separate default configurations and my own changes with a layered FS : /Data/etc/ upper layer in RO and /etc/ lower layer in RW?

I wish to separate the default packages configuration files (/etc/), and the configuration files I edited e.g. in /Data/etc/ (normally should be /usr/local/etc/, but let assume /Data/etc/).

This to enable me to easily see the modifications I made, to easily back it up, etc.

Therefore, I was wondering it was possible to mount /etc/ as :

upper layer FS in RO : /Data/etc/
lower layer FS in RW : itself (/etc/).

The package manager would make its changes in /etc/ like normal.
But when I add a file in /Data/etc/, e.g. /Data/etc/foo, I wish to then have a /etc/foo file in RO that will shadow any existing /etc/foo.

Note:

physical links aren’t possible as /Data and /etc will be in different FS.
symbolic links would be troublesome : e.g. if a symlink is deleted when updating a package, requires to automatically create a symlink for each files in /Data/etc/, etc.
mount –bind would be troublesome for the same reason.
some packages does look at /usr/local/etc/ for extra-configuration files, but unfortunately, not all.

However, I failed to see how to do so with UnionFS/AuFS/OverlayFS/etc.
I am also open to alternative solutions/ideas.

Asked By: Denis Migdal

Source

Something like what you’re after is coming in systemd v256, systemd-confext. However that might not be usable for you for a while yet.

Looking at the broader issue of tracking configuration changes (and identifying their origin as a subset of that), perhaps you could use a tool such as etckeeper. This is available in most distributions, and will integrate with the package manager to record changes made to /etc as separate commits. You can then record your own changes as separate commits — this can serve as a journal too, since you’ll have room in the commit messages to record the reasons for each change.

Changing a couple of configuration settings will improve your experience with etckeeper, in etckeeper.conf:

assuming you’re using the git backend, GIT_COMMIT_OPTIONS can be used to specify options used with git when run by etckeeper; you might be able to use this for example to set the commit authorship to distinct values;
AVOID_DAILY_AUTOCOMMITS=1 disables daily autocommits; this ensures that any manual changes that haven’t been committed yet don’t end up included in an automatic commit;
AVOID_COMMIT_BEFORE_INSTALL=1 disables automatic commits before installation; this serves a similar purpose to the previous setting, but prior to package installations rather than as part of daily processing.

With the above, changes you make will be readily apparent in git logs and blames, and if you forget to commit a change, package manager operations will be aborted instead of being allowed to make further changes.

etckeeper is available in most distributions, and distribution packages of etckeeper configure it to integrate with the distribution’s package manager.

Answered By: Stephen Kitt