Feature added by: Christoph Obexer (cobexer)
Feature #310713, revision 1 Title: put /etc under (git) version control
openSUSE-11.4: Unconfirmed Priority Requester: Important
Requested by: Christoph Obexer (cobexer)
Description: 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, ld.so.cache, 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)
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.
Feature changed by: Rémy Marquis (Spyhawk) Feature #310713, revision 2 Title: put /etc under (git) version control
openSUSE-11.4: Unconfirmed Priority Requester: Important
Requested by: Christoph Obexer (cobexer)
Description: 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, ld.so.cache, 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)
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.
+ Discussion: + #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?
Feature changed by: Christoph Obexer (cobexer) Feature #310713, revision 3 Title: put /etc under (git) version control
openSUSE-11.4: Unconfirmed Priority Requester: Important
Requested by: Christoph Obexer (cobexer)
Description: 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, ld.so.cache, 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)
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.
Discussion: #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.
Feature changed by: Christoph Obexer (cobexer) Feature #310713, revision 4 Title: put /etc under (git) version control
openSUSE-11.4: Unconfirmed Priority Requester: Important
Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org
Description: 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, ld.so.cache, 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.
Discussion: #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.
Feature changed by: Christian Boltz (cboltz) Feature #310713, revision 5 Title: put /etc under (git) version control
openSUSE-11.4: Unconfirmed Priority Requester: Important
Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org
Description: 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, ld.so.cache, 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.
Discussion: #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 http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con... + (http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con...) + http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html + (http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html) 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.
Feature changed by: phanisvara das (phanisvara) Feature #310713, revision 6 Title: put /etc under (git) version control
openSUSE-11.4: Unconfirmed Priority Requester: Important
Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org
Description: 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, ld.so.cache, 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.
Discussion: #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 http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con... (http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con...) http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html (http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html) 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?
Feature changed by: Karl Cheng (qantas94heavy) Feature #310713, revision 7 - Title: put /etc under (git) version control + Title: Put /etc under (git) version control
- openSUSE-11.4: Unconfirmed + openSUSE Distribution: New Priority - Requester: Important + Requester: Desirable
Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org
Description: 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, ld.so.cache, 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.
Discussion: #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 http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con... (http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con...) http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html (http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html) 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?
Feature changed by: Karl Cheng (qantas94heavy) Feature #310713, revision 8 Title: Put /etc under (git) version control
openSUSE Distribution: New Priority Requester: Desirable
Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org
Description: 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, ld.so.cache, 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
+ Relations: + - FUSE filesystem to keep /etc/ valid (feature/id: 318432)
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.
Discussion: #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 http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con... (http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con...) http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html (http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html) 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?
Feature changed by: Sarah Kriesch (AdaLovelace) Feature #310713, revision 9 Title: Put /etc under (git) version control
openSUSE Distribution: New Priority Requester: Desirable
Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org
Description: 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, ld.so.cache, 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
Relations: - FUSE filesystem to keep /etc/ valid (feature/id: 318432)
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.
Discussion: #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 http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con... (http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con...) http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html (http://lists.opensuse.org/opensuse-factory/2012-05/msg00281.html) 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?
+ #5: Sarah Kriesch (adalovelace) (2017-06-26 19:33:48) + We have got snapper with snapshots instead of git for saving + configuration changes. Does that do what you want to have?
-
fate_noreply＠suse.de