feat: add etckeeper

[GarciaLnk]

this installs etckeeper and enables a timer that commits daily the changes done to /etc

fixes #524

[tulilirockz]

I believe this might not be the right approach. This kind of stuff, as far as I know, needs to be enabled on a host-by-host basis, enabiling it on the build I think wont get to the users properly. Currently we have similar functionality to what we wanted to implement at that time with the ujust check-local-overrides.

I just want someone else to see this first before closing it outright. But thank you so much for your contribution!

[GarciaLnk]

etckeeper works at root level, so the .git dir is created in /etc and reaches the host machine just fine. I think there's value in having both etckeeper and ujust check-local-overrides, since the latter doesn't provide a log (but it will only show the changes done by the user).

etckeeper could be activated with a systemd service if that seems cleaner, I'm open to feedback.

[bsherman]

I have never used nor heard of etckeeper before I saw this PR.

I'll defer to others (@castrojo @m2Giles) on validity of including the package. I think it may be valuable if we have users wanting it, but I feel pretty strongly this should not be auto-enabled unless we have a strong understanding of how it works and how Bluefin itself makes use of it.

At a glance though, I'm not confident that using etckeeper init within our build will do anything useful... in fact, it may be harmful to users who actually wish to use the tool.

[bsherman]

In addition to my comment above, this comment on the issue requesting the package seems to indicate that etckeeper, as packaged in Fedora today, likely still does not support rpm-ostree/bootc.

#524 (comment)

[GarciaLnk]

In addition to my comment above, this comment on the issue requesting the package seems to indicate that etckeeper, as packaged in Fedora today, likely still does not support rpm-ostree/bootc.

#524 (comment)

etckeeper in F40 had dnf as a requirement for etckeeper's dnf plugin (which triggers a commit on dnf install/remove) to work, this was dropped before F41 in preparation for dnf5

[castrojo]

Yeah I'm confused on the use case here, why do we need etckeeper talking dnf at all? Most of our configs have moved to /usr/etc haven't we?

[p5]

Yeah I'm confused on the use case here, why do we need etckeeper talking dnf at all? Most of our configs have moved to /usr/etc haven't we?

/usr/etc should no longer be used (it actually should never have been used, since it was for internal only rpm-ostree use), and we've moved away from it almost everywhere.

I also don't understand the dnf integration, but see the value in running etckeeper

[GarciaLnk]

Just to clarify things, the dnf integration doesn't matter here, and currently it doesn't even work on regular fedora due to dnf5 changes; but in the past (see #524) it was what blocked installing etckeeper on atomic distros due to how it was being packaged.

[m2Giles]

There a reason to have it enabled by default?

I believe we had an ancient issue for etckeeper but didn't implement back then.

My struggle is over what changes will etckeeper capture that is actually meaningful. I guess if you are editing system level configs (ssh, systemd, sysconfig) it could be nice to have that but I wonder how it will handle the 3 way diff that ostree does. On boot /etc is changing.

[bsherman]

There a reason to have it enabled by default?

I believe we had an ancient issue for etckeeper but didn't implement back then.

My struggle is over what changes will etckeeper capture that is actually meaningful. I guess if you are editing system level configs (ssh, systemd, sysconfig) it could be nice to have that but I wonder how it will handle the 3 way diff that ostree does. On boot /etc is changing.

This is exactly what I was getting at in my comment above...

I feel pretty strongly this should not be auto-enabled unless we have a strong understanding of how it works and how Bluefin itself makes use of it.

At a glance though, I'm not confident that using etckeeper init within our build will do anything useful... in fact, it may be harmful to users who actually wish to use the tool.

[GarciaLnk]

Honestly, I enabled it by default because that's what I do on my custom image, but I can see how that's too opinionated, so I'm reverting that.

[castrojo]

Ok I have an idea. Whatever we do should match this: https://containers.github.io/bootc/filesystem.html?highlight=etc#etc

I'm tired and need to read through all this again but worse case we can ask the bootc team what the intended experience for /etc management is supposed to be and then we'll just do that.

I mention this because bootc will be having regular community meetings and we should just feel free to discuss things like this. This issue is old and so many things have changed and if this is all supposed to be magically handled by the native bootc tools then maybe the fix is better user documentation on this.

[drewmoseley]

FWIW, I would l love to see some means of version control on changes in /etc. I regularly use etckeeper on my Ubuntu systems and the integration directly with apt postinstall stuff makes it nice to see the history of changes as packages are installed and/or removed. I took a peek at one point and there was definitely no support in the upstream sources for rpm-ostree and it was not immediately obvious how to add such. I'll definitely review the bootc docs because if there's a better way I'm all for it. Having the history of changes (esp the manually created ones) is what I am looking for.