Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #208009 > unrolled thread

How do I trace changes in configuration files?

Back to article view | Back to linux.debian.user

Contents

  How do I trace changes in configuration files? Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-05-01 11:40 +0200
    Re: How do I trace changes in configuration files? Jonas Smedegaard <jonas@jones.dk> - 2019-05-01 13:00 +0200
    Re: How do I trace changes in configuration files? Dan Purgert <dan@djph.net> - 2019-05-01 13:40 +0200
      Re: How do I trace changes in configuration files? Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-05-01 18:50 +0200
        Re: How do I trace changes in configuration files? Dan Purgert <dan@djph.net> - 2019-05-01 19:30 +0200
        Re: How do I trace changes in configuration files? Joe <joe@jretrading.com> - 2019-05-01 23:20 +0200
          Re: How do I trace changes in configuration files? Jude DaShiell <jdashiel@panix.com> - 2019-05-02 00:10 +0200
        Re: How do I trace changes in configuration files? David Wright <deblis@lionunicorn.co.uk> - 2019-05-02 05:30 +0200
          Re: How do I trace changes in configuration files? Dan Purgert <dan@djph.net> - 2019-05-02 13:10 +0200
          Re: How do I trace changes in configuration files? Lee <ler762@gmail.com> - 2019-05-02 18:20 +0200
            Re: How do I trace changes in configuration files? David Wright <deblis@lionunicorn.co.uk> - 2019-05-02 22:20 +0200
              Re: How do I trace changes in configuration files? Lee <ler762@gmail.com> - 2019-05-02 23:00 +0200
    Re: How do I trace changes in configuration files? Andy Smith <andy@strugglers.net> - 2019-05-02 12:10 +0200

#208009 — How do I trace changes in configuration files?

I'm trying to learn how to set up my two Teres laptops so that they are 
identical.

I have now repeated the [first steps] a couple of times so that I feel 
that I know what I am doing (I don't necessarily understand what I am 
doing though). I have two identical machines that run from two identical 
SD cards.

So I'm ready for the next step, configuring some of the programs that 
are installed (e.g. shotwell, thunderbird and xfce itself).


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?

The idea is then to just replace the default configuration files with 
the files where my preferences have been saved.


Thanks for taking time.

//Erik


[first steps] https://box.redpill.dk (I do box-add-gui, not box-add-tui )

[toc] | [next] | [standalone]

#208010

[Multipart message — attachments visible in raw view] — view raw

Quoting Erik Josefsson (2019-05-01 11:35:48)
> So, is there a way to trace/record/capture changes in all 
> configuration files?
> 
> The idea is then to just replace the default configuration files with 
> the files where my preferences have been saved.

Install package etckeeper to track files below /etc with git.

For tracking dot-file changes below your $HOME - and below /etc if you 
don't want/understand git - you can make a copy of the relevant folder 
before you start edit, and compare before and after e.g. with diif:

  diff --recursive --unified --new-file somedir.orig somedir


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#208011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

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 --

  #!/bin/bash
  # 'rvi' - "revision-controlled" vi wrapper
  # create a backup then edit the original file

  cp -p "$1" "$1".$(date +%y-%m-%d_%H%M%S)
  vi "$1"

  ALTERNATE

  #!/bin/bash
  #'rvi' - revision control vi wrapper
  # use the 'rcs' tool to checkout/checkin files

  co -l "$1"
  vi "$1"
  ci -u "$1"

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).

> 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.


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlzJgxsACgkQjhHd8xJ5
ooEKAwf/aUN+2DkbpzQKxEXkLWjCDXacI2MnvSUfpAOkxid4rcnNHZRqjuww2Kcj
caZj4D/T8P2Ah9HetitxRW8Cx22Z0cggM5WBIquEssAPT833mp8F5uCgFADVZ0O7
Z5xoZP9+DW3umcVnjdEfT844xFsL5dRmKmZ31HAQQlVSBbzvMxFwjjkowVE4zcTg
YYRm4uPPqW5JNPa9Q4j9lb5Cv3w54v31OVKS62QCYZs9Nenr4L2e7/J+lO9XKAcG
l6LR/9ay2A9ItlqmNnnEZSaoAOxKrScqIGnVwDe9HtKIpm4mBU0/m18ROOqhqO5c
dshWFqQ/o/6VPYf/JAVoG9obev9lOg==
=9ovY
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#208013

Den 2019-05-01 kl. 13:29, skrev Dan Purgert:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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.


Thanks Dan, I'll start with that method and maybe later I'll try Jonas' 
proposal with etckeeper and git.

But first, in which top level directories could files that change be 
located?

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.


>
> 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 --
>
>    #!/bin/bash
>    # 'rvi' - "revision-controlled" vi wrapper
>    # create a backup then edit the original file
>
>    cp -p "$1" "$1".$(date +%y-%m-%d_%H%M%S)
>    vi "$1"
>
>    ALTERNATE
>
>    #!/bin/bash
>    #'rvi' - revision control vi wrapper
>    # use the 'rcs' tool to checkout/checkin files
>
>    co -l "$1"
>    vi "$1"
>    ci -u "$1"
>
> 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).
>
>> 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?).

Thanks for your help Dan!

//Erik

[toc] | [prev] | [next] | [standalone]

#208014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Erik Josefsson wrote:
> Den 2019-05-01 kl. 13:29, skrev Dan Purgert:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> 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.
>
>
> Thanks Dan, I'll start with that method and maybe later I'll try Jonas' 
> proposal with etckeeper and git.
>
> But first, in which top level directories could files that change be 
> located?

Config files live in /etc (global configs, e.g. for sshd or apache, and
so on), or a user's $HOME directory (personal configs, e.g. your
Thunderbird profile)

> [...]
> 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?).

Depends on what tool you're using, probably in a config file under /etc.
On a box I have here running Network Manager, it's

  /etc/NetworkManager/system-connections/${ssid_name}


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlzJ1BYACgkQjhHd8xJ5
ooFZwQgAkjl0t4+PX3eNNwBm3SXbjGSzckjNmuXQohld7HwJNjcSfeFj2Y57myVi
J/B2bPPh7KT8tMArJifaewWgUrLJ9qRdm3gbbTM+0RGnmd7WGG8/dm+wSygD5pMC
bf3S70Rz1vIFCarvwhsfruJfus6C0zHj2MJkEmbnUZ2Nk/m8t5Ct3dazh2YUm8Bk
MJXtvwUx/U5iog6ViKC5tfbIbV+T/6q/euRbreB3PwfFDDcPX+1qYNwtSWCZd9ai
tl3+gNj7ZXIK2nDdWVMWWKAHYWZUXufAGHMFQbS6yiMHELIhFlm9IKkP6S2g2VW3
KGQoan8jc2WW5Jt6AjatvfmTa752Fw==
=MIre
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#208020

On Wed, 1 May 2019 18:43:47 +0200
Erik Josefsson <erik.hjalmar.josefsson@gmail.com> wrote:

> Den 2019-05-01 kl. 13:29, skrev Dan Purgert:

<snip information>
> 
> 
> Thanks Dan, I'll start with that method and maybe later I'll try
> Jonas' proposal with etckeeper and git.
> 
> But first, in which top level directories could files that change be 
> located?
> 
> 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.
> 
In general, system-wide configurations go in /etc, individual user
configurations are in /home/<user>, either in directories beginning
with a . or as single files beginning with a dot for simple
configurations. If you use a GUI file manager, you may need to
configure it to show hidden files.

There are more complex applications, such as php and gschem, which look
for configuration files in many places. php in particular is tightly
tied to a web server, and may have different configurations for
different virtual web sites, so may have some configurations stored in
the web server's configuration directories. I have experienced the
usual php beginner's fury and frustration at changing a parameter in
about six different php.ini files, and *still* not having the change
work... Yes, most of the time I do remember to restart the web server.

The original configuration files for many applications are often stored
somewhere in /usr/lib, either being copied into /etc during
installation or being referred to in /usr/lib but with additional files
in /etc or /home overriding them if the user has made any changes.
Nothing under /usr should ever be written to other than during
installation, so no modified configuration files *ought* to exist here.

On the whole, /etc and the /home dotfiles should hold all of the
configurations which will interest you. If you are unable to find
something you *know* exists somewhere, then look at the list of
installed files for the application, using one of the apt tools.

It is increasingly common for the Debian packages of an application (I
don't know about other distributions) to use a basic configuration
file (e.g. app.conf) and a directory called something like app.conf.d as
well. The idea is that the basic file is not ever modified, because it
can be replaced during an upgrade and if it has been modified you then
get asked that multiple choice question about what you want to do about
it during the upgrade. User files placed in the app.conf.d directory
will be used to override the basic file, and will never be touched
during upgrades, so your configuration changes will (usually) persist
through an upgrade.

Debian also uses an /etc/default directory, which contains many
miscellaneous system configurations in a relatively user-friendly
format. Some of the more useful grub boot parameters live here.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#208021

One thing I like to do whenever using vim and vim-clones is to use the +1
parameter on the command line since when the file opens I'm in a
predictable location.



--

[toc] | [prev] | [next] | [standalone]

#208022

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)
named /home/system-<hostname>-<Debian-release>-<partition-label>,
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
> located?
> 
> 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 --

[snipped]

> > 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.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#208029

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

David Wright wrote:
> On Wed 01 May 2019 at 18:43:47 (+0200), Erik Josefsson wrote:
>> Den 2019-05-01 kl. 13:29, skrev Dan Purgert:
>>> [...]
>> > 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 --
>
> [snipped]
>
>> > 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 …
> [...]
> … 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.

I rarely use GUIs to do the work for me -- but yes, good point that
there are config files hidden behind graphical programs too. :)

I don't wifi very much -- just the one laptop leaves the house, but it
doesn't matter if/when it has different things, because none of the
other wireless devices will see those networks.

>
> 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).

NICE!  I always forget about the 'time' options in find. 

>
> 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.)

Haha, yeah, I have one of those myself.  Looking at picking up an
ansible or puppet reference and getting started with that "soon(tm)".


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlzKzHQACgkQjhHd8xJ5
ooH8Hgf9FCmDoNafDD9zMZPee+v4qrSMJLqn/AxSGoM353xeEy/cS9cy3o8gdb5l
7QQcs0rxSYyBaEwGZUuhYaJFqxKveIRu93f/6aRwoU8Yn8w82FbtmuZXtINvqnjZ
2Sm+pmEmhdQXmn9hKVhncnlXIV1U22UVY/KqnC8iT6gCjOstqnRdzciVQ0UWnz45
lJXDjAZcaZPTnlKJRWQeVrAzV35+Afy8s9j/v0WbtjpCTtskFW7rF6+coDmRZoCV
ZYMYTESdw9ynP1wvFYGFR6tmU4Fa8xIBuPlvJ5EgMlVH+akfR7VeLLXF+iqbti1T
4gtG297auYlPf5BwXy2ZitHAIo52pg==
=dvdw
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#208047

On 5/1/19, David Wright wrote:
>
> 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).

You can use "find -newer" and not have to guess/remember how long ago

$ cat makets
#!/bin/sh
# create a timestamp file
#
# useful for finding files created after the timestamp
# eg. find files created/modified after timestamp
#   find  ${HOME} -newer /tmp/timestamp
# find all files created/modified after timestamp
#   find  /cygdrive/c -newer /tmp/timestamp

TS=`date +%Y%m%d-%H%M`
#   20160225-0734

touch /tmp/timestamp /tmp/timestamp-${TS}


Regards,
Lee

[toc] | [prev] | [next] | [standalone]

#208054

On Thu 02 May 2019 at 12:12:19 (-0400), Lee wrote:
> On 5/1/19, David Wright wrote:
> >
> > 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).
> 
> You can use "find -newer" and not have to guess/remember how long ago

Sure, but most people can think, "I did this since having lunch,
so I know it was in the last 2 hours" ⇨ -mmin -150

> $ cat makets
> #!/bin/sh
> # create a timestamp file
> #
> # useful for finding files created after the timestamp
> # eg. find files created/modified after timestamp
> #   find  ${HOME} -newer /tmp/timestamp
> # find all files created/modified after timestamp
> #   find  /cygdrive/c -newer /tmp/timestamp
> 
> TS=`date +%Y%m%d-%H%M`
> #   20160225-0734
> 
> touch /tmp/timestamp /tmp/timestamp-${TS}

I prefer to have both bounds available:

find-between () 
{ 
    [ -z "$3" ] && printf '%s\n' "Usage:        $FUNCNAME timedate timedate top-of-trees...
        finds files under top-of-trees with modification timestamps between
        the two timedates given (free format, in any order). The output is
        piped through ls -l -t into less." 1>&2 && return 1;
    local Timea="$(date --rfc-3339=seconds --date "$1")";
    [ -z "$Timea" ] && return 2;
    local Timeb="$(date --rfc-3339=seconds --date "$2")";
    [ -z "$Timeb" ] && return 2;
    shift 2;
    [ "$Timea" = "$Timeb" ] && printf '%s\n' "Times are the same (one minute resolution)" && return;
    [ "$Timea" \> "$Timeb" ] && local Swap="$Timea" && Timea="$Timeb" && Timeb="$Swap";
    printf '%s\n' "From $Timea to $Timeb";
    local Unique="$(mktemp ${Uniquetrash:-/tmp}/$FUNCNAME-"$(date +%s)"-XXXX)";
    local UniqueA="$(mktemp ${Uniquetrash:-/tmp}/$FUNCNAME-"$(date +%s)"-XXXX)";
    local UniqueB="$(mktemp ${Uniquetrash:-/tmp}/$FUNCNAME-"$(date +%s)"-XXXX)";
    touch -d "$Timea" "$UniqueA";
    touch -d "$Timeb" "$UniqueB";
    find "$@" -newer "$UniqueA" -a -not -newer "$UniqueB" -type f -print0 >> "$Unique";
    [ -s "$Unique" ] && xargs -0 ls -l -t < "$Unique" | less;
    rm "$UniqueA" "$UniqueB" "$Unique"
}

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#208056

On 5/2/19, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Thu 02 May 2019 at 12:12:19 (-0400), Lee wrote:
>> On 5/1/19, David Wright wrote:
>> >
>> > 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).
>>
>> You can use "find -newer" and not have to guess/remember how long ago
>
> Sure, but most people can think, "I did this since having lunch,
> so I know it was in the last 2 hours" ⇨ -mmin -150

^shrug^ whatever floats your boat.
  makets
  # do something
  find  ${HOME} -newer /tmp/timestamp
has been good enuf for my purposes.  ... well, almost enough.
Occasionally I'll use meld  (https://packages.debian.org/stretch/meld)
to take a quick look at what all changed between current & backed up
files.

cool script for finding files modified between certain times tho -
thanks for sharing!
Maybe someday I'll get up to that level :)

Lee

>> $ cat makets
>> #!/bin/sh
>> # create a timestamp file
>> #
>> # useful for finding files created after the timestamp
>> # eg. find files created/modified after timestamp
>> #   find  ${HOME} -newer /tmp/timestamp
>> # find all files created/modified after timestamp
>> #   find  /cygdrive/c -newer /tmp/timestamp
>>
>> TS=`date +%Y%m%d-%H%M`
>> #   20160225-0734
>>
>> touch /tmp/timestamp /tmp/timestamp-${TS}
>
> I prefer to have both bounds available:
>
> find-between ()
> {
>     [ -z "$3" ] && printf '%s\n' "Usage:        $FUNCNAME timedate timedate
> top-of-trees...
>         finds files under top-of-trees with modification timestamps between
>         the two timedates given (free format, in any order). The output is
>         piped through ls -l -t into less." 1>&2 && return 1;
>     local Timea="$(date --rfc-3339=seconds --date "$1")";
>     [ -z "$Timea" ] && return 2;
>     local Timeb="$(date --rfc-3339=seconds --date "$2")";
>     [ -z "$Timeb" ] && return 2;
>     shift 2;
>     [ "$Timea" = "$Timeb" ] && printf '%s\n' "Times are the same (one minute
> resolution)" && return;
>     [ "$Timea" \> "$Timeb" ] && local Swap="$Timea" && Timea="$Timeb" &&
> Timeb="$Swap";
>     printf '%s\n' "From $Timea to $Timeb";
>     local Unique="$(mktemp ${Uniquetrash:-/tmp}/$FUNCNAME-"$(date
> +%s)"-XXXX)";
>     local UniqueA="$(mktemp ${Uniquetrash:-/tmp}/$FUNCNAME-"$(date
> +%s)"-XXXX)";
>     local UniqueB="$(mktemp ${Uniquetrash:-/tmp}/$FUNCNAME-"$(date
> +%s)"-XXXX)";
>     touch -d "$Timea" "$UniqueA";
>     touch -d "$Timeb" "$UniqueB";
>     find "$@" -newer "$UniqueA" -a -not -newer "$UniqueB" -type f -print0 >>
> "$Unique";
>     [ -s "$Unique" ] && xargs -0 ls -l -t < "$Unique" | less;
>     rm "$UniqueA" "$UniqueB" "$Unique"
> }
>
> Cheers,
> David.

[toc] | [prev] | [next] | [standalone]

#208028

[Multipart message — attachments visible in raw view] — view raw

Hi Erik,

On Wed, May 01, 2019 at 11:35:48AM +0200, Erik Josefsson wrote:
> 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?

I like to invert the problem by not making any changes to
configurations except through a config management system like
Ansible, Chef, Puppet, etc.

That enforces treating the configuration of the system like a
software project, so changes are recorded in a version control
system like git; what you did is automatically documented just
by the act of doing it, so forgetting to document is less of a
problem. Running through the config management again should bring
the new machine into the same state.

(Of course, documenting WHY you made a change or any more detail
than what the change was, is still on you!)

I don't find it overkill even for just one or two machines, though
it does of course come into its own with much larger numbers of
machines. Just from the documentation and reproduction angles I find
it worth it.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web