Mailinglist Archive: opensuse-features (39 mails)

< Previous Next >
[openFATE 310713] put /etc under (git) version control
Feature changed by: phanisvara das (phanisvara)
Feature #310713, revision 6
Title: put /etc under (git) version control

openSUSE-11.4: Unconfirmed
Requester: Important

Requested by: Christoph Obexer (cobexer)
Partner organization:

put /etc under (git) version control to track changes made to the
configuration, merge new configuration options coming from package
updates / security fixes an handle the case where RPM decides to create
a .rpmsave - where a administrator would need to migrate all changes
from the old version to the new one in order to not end up with an
unusable system upon reboot.
Integration in YaST would be very cool, you could have a look at what
an update changed in your system, and YaST could force you to migrate
changes to configuration files that are no longer in effect.
there are a fewsilly things in /etc (CUPS, alsa,, and the
bootsplash images i recall) that cause a lot of "fake" changes, but
they would be easy to "fix".
checking differences in configurations between multiple systems(to
diagnose problems...) would be easy too, simply clone them and diff
them, very efficient ;) . making backups of the system configuration
would be easy too (simply back up /etc/.git and restoring would be non
destructive in that you could check what changes will be restored)
(subversion would not work well, for example because of gconf IIRC)
-- edit:
since a related mail showed up on the opensuse-factory ml
the default fonfig files and the default system config should be put
into /usr/etc with a linear git history that tracks system updates.
when updates are done the new config should be auto merged to /etc and
conflict resolution should be done graphically by the admin (with
options to take default system config and such for inexperienced users
for example).
all tools that modify files in /etc should be updated to handle git
checkins and log messages there

Use Case:
there was a security update once concerning session entropy in PHP,
since the php.ini has been modified on the system in question the
update process created a .rpmnew file, a file i would have never found
it if I had not put /etc under git version control. With git however it
was easy to see the file, I moved it over the php.ini and had a look at
the changes, merged them in and committed the changes.
Another useful feature would be to show the modifications (done by the
admin) compared to the packaged config files.

#1: Rémy Marquis (spyhawk) (2010-10-17 17:43:04)
This looks as an übercomplexified solution. Wouldn't be easier to have
a script that detects .rpmnew file, runs diff over the original file
and then show the results to the (advanced) user?

#2: Christoph Obexer (cobexer) (2010-10-17 22:57:31)
and a normal user ends up with an insecure / broken system and needs to
reinstall(current situation)?
the "compare the files and look at the diff" script will already exist
for sure, but an improvement would be having that built right into the
package management.

#3: Christian Boltz (cboltz) (2012-05-13 20:35:11)
Ubuntu discussed a similar idea at their developer summit (UDS). See

( contains
a copy of the UDS session notes and a link to the audio recording.
Extremely shortened summary: Ubuntu will probably use etckeeper, which
can use various VCS as backend (bzr, git, ...) and additionally stores
file permissions and ownership.

+ #4: phanisvara das (phanisvara) (2012-05-13 20:53:15)
+ i've been doing this since i learned about git: keep sub-repos of
+ essential configurations like /etc/apache2, /etc/postfix, etc., under
+ one repo encompassng the whole of /etc., also /boot and some of the lib.
+ s.
+ this has proven quite useful, but it's comfortable only for someone who
+ is used to dealing with git. others need an intuitive GUI for dealing
+ with GIT, and apparently etckeeper is such a frontend.
+ unless there's something definitely wrong with etckeeper (which i
+ wouldn't know), why not use that?

openSUSE Feature:

< Previous Next >
This Thread