Hi Curtis,

Curtis Maurand via Dng writes:

> On 10/18/21 4:36 PM, Steve Litt wrote:
>> Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900
>>
>>
>>> I keep track of /etc with etckeeper which puts that directory under git
>>> version control. That means I can always track back changes to package
>>> updates or me mucking around there and see exactly what changed. That
>>> can be very helpful if an `apt upgrade` broke stuff, more so because I
>>> track "testing" ;-)
>> Nice!!!
> I run on a BTRFS file system and /etc is in it's on sub volume. I just
> take a snapshot of it. restoration is as easy as overwriting a file or
> folder from the snapshot. I store the snapshots both locally and
> externally. Works great. I handle /var/lib/mysql that way, too.

I really looked into snapshotting but the etckeeper commit messages also
list which packages changed, like so (after I "beautified" the logging a
bit to suit my taste and needs)

commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
Author: olaf <olaf@quark>
Date: Mon Oct 11 21:48:25 2021 +0900

      Committing changes in /etc after APT run

      Package changes:
      - debconf 1.5.71 all
      + debconf 1.5.71+deb10u1 all
      - libgssapi-krb5-2 1.17-3+deb10u2 amd64
      + libgssapi-krb5-2 1.17-3+deb10u3 amd64
      - libk5crypto3 1.17-3+deb10u2 amd64
      + libk5crypto3 1.17-3+deb10u3 amd64
      - libkrb5-3 1.17-3+deb10u2 amd64
      + libkrb5-3 1.17-3+deb10u3 amd64
      - libkrb5support0 1.17-3+deb10u2 amd64
      + libkrb5support0 1.17-3+deb10u3 amd64
      - libmariadb3 1:10.3.29-0+deb10u1 amd64
      + libmariadb3 1:10.3.31-0+deb10u1 amd64

which gives me a chance to pinpoint any culprits and submit bug reports
if necessary with detailed info on the changed packages.

When tracking "testing" and doing regular, say weekly or even more
frequent, updates (maybe even via unattended-upgrades), you don't always
notice issues rightaway. Being able to track things down to the upgrade
that introduced the issue retroactively in this kind of detail helps a
lot. The commit itself has the byte-by-byte changes that may point to
the root cause of the issue and the commit logs also let me check very
easily if I modified related files myself for some reason.

Yes, I know that /var/log/apt/ has some of this info but I find my
commit messages a bit easier to parse. Besides, they won't be rotated
into oblivion by logrotate ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join