Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-14 Thread Olaf Meeuwissen via Dng
Hi Martin,

Martin Steigerwald writes:

> Olaf Meeuwissen via Dng - 13.12.20, 03:48:23 CET:
>> Hi Hendrik,
>>
>> Hendrik Boom writes:
>> > I wish everything user-configurable under /etc was under revision
>> > control. then we might even be able to have a vendor branch and a
>> > local branch.
>> Have a look at etckeeper.
>>
>> I've been using that for several years now on a variety of machines.
>> The log for the machine I'm writing this on goes back all the way to
>> its initial install on 2017-01-11 of Devuan's Jessie Official Beta2
>> :-)
>>
>> You may want to keep your sensitive /etc/ files out of the repository
>> though, depending on your level of paranoia.
>
> I still do not use etckeeper, cause I prefer to just add the files to the
> repository that I actually change. This way, whenever I like to
> replicate the config onto another machine or even just look at what I
> changed, I can just clone the repository and have exactly a tree of
> those files that I adapted.

Actually, I have been *thinking* about using vcsh to track those parts
of /etc/ that I tinker with myself and that are amenable to sharing
between (subsets of) my machines.  I've been using vcsh to selectively
manage the dot-files I care about and a small collection of snippets and
scripts and that works quite well, for me at least.  Still need to roll
up my sleeves and see if I can get something like that to work for /etc/
or even / (so I can track /usr/local/ bits too).

> Of course, Ansible would be also an
> alternative. I am just not completely sure whether it makes sense with
> just a few machines. I may start to use it with hosted virtual machines
> as it eases moving to a different provider if need be.
>
> I do not care about all the automatic changes by package upgrades.

That's you ;-)  I do care, so I use etckeeper.
Hendrik asked about stuffing /etc/ in git, so I suggested etckeeper.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-14 Thread Olaf Meeuwissen via Dng
Hi Dimitris,

Dimitris T. via Dng writes:

> Olaf Meeuwissen via Dng wrote:
>>
>> Have a look at etckeeper.
>
> was using it for years, but not anymore..
> too much disk i/o, too many files, `git gc` never ran (only by hand),
> and it never really came handy during those years...
>
> maybe storing etckeeper repo it in a different backup disk makes more
> sense, but anyway..., backups, backups, backups. :)

Backups really serve another use case.  I'm primarily using etckeeper to
find out what may have caused something from behaving the way it did in
the face of (ir)regular (unattended) upgrades.  Even went so far as to
allow empty commits because stuff under /var/log/apt/ is rotated away
into oblivion, eventually.

I also occasionally use it to find out when I upgraded to a particular
version of a package.

I haven't experienced any issues with disk IO or too many files.  Most
server machines run unattended-upgrades nightly and my laptops are only
upgraded (manually) every one or two weeks.

If running `sudo etckeeper vcs gc` by hand is too much trouble ;-), tag
it on to the list of DPkg::Post-Invoke commands or stick it into a cron
job.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-13 Thread Martin Steigerwald
Martin Steigerwald - 13.12.20, 16:07:10 CET:
> Hendrik Boom - 13.12.20, 15:52:31 CET:
> > On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote:
> > > I do not care about all the automatic changes by package upgrades.
> > 
> > I care about the automatic changes by package upgrades when they
> > conflict with my own.
> 
> Well, dpkg warns me about these.

And I forgot: I also see them with bzr / git diff.

-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-13 Thread Martin Steigerwald
Hendrik Boom - 13.12.20, 15:52:31 CET:
> On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote:
> > I do not care about all the automatic changes by package upgrades.
> 
> I care about the automatic changes by package upgrades when they
> conflict with my own.

Well, dpkg warns me about these.

-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-13 Thread Hendrik Boom
On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote:
> 
> I do not care about all the automatic changes by package upgrades.

I care about the automatic changes by package upgrades when they 
conflict with my own.

It would also be useful to have a tool that compares a the configuration 
files to the ones provided by the current release, to find
  * discrepancies that have crept in unawares
  * discrepancies that indicate proper, deliberate changes.
A kind of audit, I suppose, that would still have to be checed 
manually..

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-13 Thread Martin Steigerwald
Martin Steigerwald - 13.12.20, 09:29:26 CET:
> The history on this laptop dates back till May 2011. And I have older
> machines where I used it. It may be that for this laptop I just cloned
> the bzr branch of the older laptop, then did a diff to see which
> files to adapt and continued with the bzr branch of the older laptop.
> I still love to use brz – cause I prefer it usability wise -, but I
> probably will switch to git for new machines. On the other hand, it
> does not really matter.

Lol, now I just read the first changelog entry. And no, I did not copy 
over the repo, at this time I decided to start from scratch.

-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-13 Thread Martin Steigerwald
Olaf Meeuwissen via Dng - 13.12.20, 03:48:23 CET:
> Hi Hendrik,
> 
> Hendrik Boom writes:
> > I wish everything user-configurable under /etc was under revision
> > control. then we might even be able to have a vendor branch and a
> > local branch.
> Have a look at etckeeper.
> 
> I've been using that for several years now on a variety of machines.
> The log for the machine I'm writing this on goes back all the way to
> its initial install on 2017-01-11 of Devuan's Jessie Official Beta2
> :-)
> 
> You may want to keep your sensitive /etc/ files out of the repository
> though, depending on your level of paranoia.

I still do not use etckeeper, cause I prefer to just add the files to the 
repository that I actually change. This way, whenever I like to 
replicate the config onto another machine or even just look at what I 
changed, I can just clone the repository and have exactly a tree of 
those files that I adapted. Of course, Ansible would be also an 
alternative. I am just not completely sure whether it makes sense with 
just a few machines. I may start to use it with hosted virtual machines 
as it eases moving to a different provider if need be.

I do not care about all the automatic changes by package upgrades.

The history on this laptop dates back till May 2011. And I have older 
machines where I used it. It may be that for this laptop I just cloned 
the bzr branch of the older laptop, then did a diff to see which files to 
adapt and continued with the bzr branch of the older laptop. I still 
love to use brz – cause I prefer it usability wise -, but I probably 
will switch to git for new machines. On the other hand, it does not 
really matter.

Thanks,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-13 Thread Dimitris T. via Dng
Olaf Meeuwissen via Dng wrote:
> 
> Have a look at etckeeper.
> 

was using it for years, but not anymore..
too much disk i/o, too many files, `git gc` never ran (only by hand),
and it never really came handy during those years...

maybe storing etckeeper repo it in a different backup disk makes more
sense, but anyway..., backups, backups, backups. :)


d.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[DNG] Version control /etc (was Re: Ethernet names revisited)

2020-12-12 Thread Olaf Meeuwissen via Dng
Hi Hendrik,

Hendrik Boom writes:

> I wish everything user-configurable under /etc was under revision control.
> then we might even be able to have a vendor branch and a local branch.

Have a look at etckeeper.

I've been using that for several years now on a variety of machines.
The log for the machine I'm writing this on goes back all the way to its
initial install on 2017-01-11 of Devuan's Jessie Official Beta2 :-)

You may want to keep your sensitive /etc/ files out of the repository
though, depending on your level of paranoia.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng