how to get a list of config files I altered?

I'd like to get a list of the config files I tweaked in the system.

Not just files in /etc but in other directories too, like /boot, /root, /usr/local/, and so on.

I wasn't always prudent to keep a backup so searching for *.bak will not get me everything. I can always go the long, hard way of checking all config files for changes, but before I do that, I'd like to know if there is an easier one.
 
This is why I keep my entire configuration in a Git repository.

Now, Git is an external program; FreeBSD is shipped with svnlite which is also an excellent way to set this up, maybe you'd like my guide about it here:

https://forums.freebsd.org/threads/managing-your-system-configuration-with-svnlite.68343/

An example:

Code:
peter@zefiris:/etc $ git status -s
 M make.conf
 M rc.conf
See? I recently modified both make.conf and rc.conf, hmm... I wonder what I did:
Code:
peter@zefiris:/etc $ git diff make.conf
diff --git a/make.conf b/make.conf
index 509fa6c..2524b3f 100644
--- a/make.conf
+++ b/make.conf
@@ -1,4 +1,4 @@
-DEFAULT_VERSIONS+=apache=2.4 bdb=5 perl5=5.26 pgsql=9.5 python=2.7 python2=2.7 samba=4.6 php=5.6 ruby=2.4 ssl=openssl
+DEFAULT_VERSIONS+=apache=2.4 bdb=5 perl5=5.26 pgsql=9.5 samba=4.6 php=5.6 ssl=openssl
 
 JAVA_VERSION=1.8
Aha! I removed the Python targets.

Seriously: putting your configuration under version control management is the best way to keep full control over your setup, all applied changes and the reason behind said changes:
Code:
peter@zefiris:/etc $ git log
commit a003a7e8dc8b0dfcf8fd8bd3836cde2923d85168 (HEAD -> etc, repo/etc)
Author: Zefiris admin <pl@intranet.lan>
Date:   Tue Dec 18 16:32:41 2018 +0100

    Changes due to Git upgrade.
    
    Signed-off-by: Zefiris admin <pl@intranet.lan>

commit 88bf3c694e21717a161ffb355bcd2c9665c26965
Author: Zefiris admin <pl@intranet.lan>
Date:   Tue Dec 18 09:48:18 2018 +0100

    Changes to factilitate a new kernel.

Notes:
    Spotted the typoe after commit: s/factilitate/facilitate/g ;)

commit 1dbaa219f390691909f82b77a41936d9c587e0b2
Author: Zefiris admin <pl@intranet.lan>
Date:   Tue Dec 18 09:47:23 2018 +0100

    (re)Activated the GPG keyserver.
    
    Signed-off-by: Zefiris admin <pl@intranet.lan>
---<CUT
The reason I use Git is because it allows me to construct a complete collection of "config repositories":
Code:
peter@zefiris:/root/etc/vps $ git log
commit 4a1f97e7632041b2645748ec4a1198d50ed2e438 (HEAD -> master, origin/master, origin/HEAD)
gpg: Signature made Mon Dec 17 20:08:18 2018 CET
gpg:                using RSA key B02F3C9BA677634D
gpg: Good signature from "Sysop (TransIP VPS) <root@(bleep)>"
Author: VPS administrator <root@(bleep)>
Date:   Mon Dec 17 20:08:18 2018 +0100

    Added root's bin directory to version control
    
    Signed-off-by: VPS administrator <root@(bleep)>

commit efa6035c815d6332bb307eff665371b487b77adf
gpg: Signature made Mon Dec 17 19:56:08 2018 CET
gpg:                using RSA key B02F3C9BA677634D
gpg: Good signature from "Sysop (TransIP VPS) <root@(bleep)>"
Author: VPS administrator <root@(bleep)>
Date:   Mon Dec 17 19:56:08 2018 +0100

    Added all branches.
    
    Signed-off-by: VPS administrator <root@(bleep)>
So: /root/etc is my main "config repository" whereas /root/etc/vps is a submodule (Git phrase) which is a clone of the "config repository" for my VPS server:
Code:
peter@zefiris:/root/etc $ git submodule status
 c93b9a5513c6839d22610dcb9ebbbee2106669ef breve (heads/master)
 a6b8d1f46227ee6a549120ea5415ff5b3c357696 feliner (heads/master)
 4a1f97e7632041b2645748ec4a1198d50ed2e438 vps (start-2-g4a1f97e)
Meaning? From this location I can 'control' my 2 servers (and one laptop) by simply using Git to request the specific configuration 'branch', applying changes, pushing them (this obviously doesn't always work for my laptop ;)) after which they'll become available on the remote servers again (my laptop works a bit different).

For me this is the ultimate way of controlling my servers configuration.
 
  1. Make a list of configuration directories and files.
  2. Use the installation media to generate a checksum for each of these files.
  3. Generate the checksum for these files on your live system.
  4. Use something like diff(1) to check a) which files exist on your system but not on the installation media, and b) which files exist on both, but were modified.

It's like your "long, hard way" but automated through scripting.
 
I wasn't always prudent to keep a backup so searching for *.bak will not get me everything. I can always go the long, hard way of checking all config files for changes, but before I do that, I'd like to know if there is an easier one.
Three words, document, document and document.
 
Back
Top