Re: How do I trace changes in configuration files?
- Date: Wed, 1 May 2019 22:18:43 -0500
- From: David Wright <deblis@xxxxxxxxxxxxxxxxx>
- Subject: Re: How do I trace changes in configuration files?
On Wed 01 May 2019 at 18:43:47 (+0200), Erik Josefsson wrote:
> Den 2019-05-01 kl. 13:29, skrev Dan Purgert:
> > Erik Josefsson wrote:
> > > I'm trying to learn how to set up my two Teres laptops so that they are
> > > identical.
> > >
> > > [...]
> > >
> > > I have tried to document my personal preferences before, but I have
> > > always ended up with unreadable handwritten notes.
> > >
> > > This time I thought I should do it in a more systematic way by somehow
> > > capture the difference between the default install and the result of my
> > > (often irrational) efforts to make my machines look and feel like I want
> > > it to.
> > >
> > > So, is there a way to trace/record/capture changes in all configuration
> > > files?
> > >
> > There are as many as people reading this channel :)
> > Probably the simplest (and, to some extent, most error prone) is to
> > simply make copies, edit only the copies. For example:
> > cp orig.conf orig.conf.$(date +%y-%m-%d_%H%M%S)
> > vi orig.conf
> > and then you'll end up with stuff like
> > orig.conf
> > orig.19-05-01_065356
> > orig.19-05-01_104022
> > (etc)
> > Then just use 'diff' against any two files to see what changed between
> > them.
I find it useful to have a set of modified files in one place,
as well as these copies left lying around. I make a set of
pseudo-home directories (so they're encrypted, and backed up)
such that they can be copied onto my working laptop and my
server for inspection, comparison, etc. whether the host is up or not.
The files' paths are mangled, replacing / with ¬, so that they're
all at one directory level, and a script like
# for j in * ; do (printf '%s\n' "$j" ; diff -u "$(bar2slash "$j")" "$j") ; done 2>&1 | less +/^¬
will check whether all the files are up-to-date when executed in
the pseudo-home directory on the appropriate host.
> Thanks Dan, I'll start with that method and maybe later I'll try
> Jonas' proposal with etckeeper and git.
I already run etckeeper, though I haven't read enough about it yet
to be able to use it for any benefit.
> But first, in which top level directories could files that change be
> There are quite a few to choose from: bin, boot, dev, etc, home, lib,
> lib64, lost+found, media, mnt, opt, proc, root, run, sbin, srv, sys,
> tmp, usr and var.
The top-level directories that make an appearance in my pseudo-home
files are /boot/grub, /etc/(the bulk, obviously), /lib/firmware
(non-Debian), and /root.
It might be worth your perusing the Filesystem Hierarchy Standard
which will fill you in on what all these directories are for.
> > Or you can use a revision tool. I ran across "rcs" a few years ago, and
> > while it's not something I always use, when I remember, it's pretty good
> > at what it does.
> > Either of these could be wrapped up in a little script --
> > Personally I like vi, but if you don't, replace it with whatever your
> > editor of choice is. The scripts probably have flaws that someone will
> > point out soon (like calling it with no file, or multiple files, etc).
This can more or less guarantee that you save changes made by editing
the configuration files themselves, but …
> > > The idea is then to just replace the default configuration files with
> > > the files where my preferences have been saved.
> > As far as actually propagating changes, that gets a little more
> > difficult -- but if all the config files are in $HOME/.config ... well,
> > just use a cronjob to sync daily or something.
> For now, I just want to see where (and if) my setup is stored (e.g.
> where does my wifi's SSID and passphrase end up? maybe in more than
> one place?).
… it fails to capture changes made on your behalf, like typing the
SSID and passphrase into, say, wicd (which puts them into
/etc/wicd/wireless-settings.conf). So it helps to have a dead simple
method for collecting this information, less you put it off and
then inevitably forget about doing it later.
As for finding where the information went, I sometimes use
# find /boot /etc /home /lib /lib64 /var -type f -mmin -1440 -print | less # one day
but changing 1440 to something more appropriate, like 10 (mins).
I also maintain a shell script that I run almost immediately after
installing Debian, that performs a load of administrivia like
adding me to groups, changing permissions, etc etc. It actually kicks
off by installing etckeeper and configuring git. I add more items
to it occasionally, and rerun it, so one or two items are protected
by conditionals preventing their getting repeated unnecessarily.
(But it's clunky and slow; for example there's a long list of
.debs to install, so it spews out "already installed' messages.)