[Bug 804851] New: Updating clobbers modified systemd control files without generating rpmsave
https://bugzilla.novell.com/show_bug.cgi?id=804851 https://bugzilla.novell.com/show_bug.cgi?id=804851#c0 Summary: Updating clobbers modified systemd control files without generating rpmsave Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: geoff@cs.hmc.edu QAContact: jsrain@suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 When the update process (both major-version updates and online updates) makes changes to systemd control files in /lib/systemd/system, the old versions are replaced without giving the user any chance to preserve the original contents. Reproducible: Always Steps to Reproduce: 1. Edit a systemd control file (e.g., add a comment) that's included in an online update 2. Do an online update 3. Actual Results: The old contents of the control file are lost. Expected Results: The new contents should have been installed as an "rpmnew" (unless the change is critical to stability or security, in which case the old file should be preserved as an "rpmsave"). My understanding is that this is a simple configuration change. However, I feel obligated to point out that there is a deeper underlying issue here. I reported a similar bug long ago, when files in /etc/init.d were getting clobbered. The general rule for ANY configuration file should be that if the user changed it, she probably had a good reason and the results of those changes should not be discarded. In fact, usually the bias should be toward preserving those changes (i.e., the rpmnew approach) rather than discarding them even temporarily (rpmsave). The rpmsave approach often risks introducing security holes of various sorts, so it should be reserved for exceptional circumstances. Meanwhile, I'm often stuck restoring config files from backups--which is problematic in itself because first I have to discover that they got clobbered, which may be non-obvious. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=804851 https://bugzilla.novell.com/show_bug.cgi?id=804851#c1 Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |suse-beta@cboltz.de Resolution| |INVALID --- Comment #1 from Christian Boltz <suse-beta@cboltz.de> 2013-02-24 00:09:24 CET --- General rule of thumb: If you need to edit a file in /lib or /usr, you should a) read the documentation - do you really need to edit the file in this location? b) if yes, open a bugreport because config files should be in /etc. For systemd, the recommended (and documented) method is: copy the file you want to edit to /etc/systemd/system (or the matching subdirectory) and edit it there (don't change the filename). With this method you ensure that it won't be overwritten on updates. systemd will use the files in /etc/systemd/ instead of the files in /lib. This also means the main part of your bugreport is invalid. If you notice that files in /etc are overwritten on updates without creating a .rpmsave or .rpmnew, please open a bugreport about the specific case. (A general note that "some" files were overwritten doesn't really help in getting things fixed ;-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=804851 https://bugzilla.novell.com/show_bug.cgi?id=804851#c2 --- Comment #2 from Geoff Kuenning <geoff@cs.hmc.edu> 2013-02-25 02:35:43 UTC --- What an appallingly bad design. Now we have configuration files in multiple places, and to understand the configuration a human has to look in all those places and dig through bad documentation to figure out which one is actually being used. And why exactly aren't the CONFIGURATION files for systemd sitting in /etc in the first place? Is it any wonder that experienced Unix experts see systemd as a disaster? General rule of thumb: don't make things unnecessarily complex, and don't force sysadmins to spend hours reading documentation before making a simple change. I'm going to leave this closed because it's hopeless to argue. But it wouldn't earn a passing grade in one of my classes. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=804851 https://bugzilla.novell.com/show_bug.cgi?id=804851#c3 --- Comment #3 from Christian Boltz <suse-beta@cboltz.de> 2013-02-25 13:17:36 CET --- (In reply to comment #2)
What an appallingly bad design. Now we have configuration files in multiple places, and to understand the configuration a human has to look in all those places and dig through bad documentation to figure out which one is actually being used. And why exactly aren't the CONFIGURATION files for systemd sitting in /etc in the first place?
Well, it depends on the POV - personally I like the new design. A file in /etc means I modified something (and I still have the original file in /lib for comparison), and a file in /lib means it's the default file as shipped with the distribution. The "traditional" way with everything in /etc means I have to use rpm -V to detect changes, and usually don't have a copy of the original file around. (And BTW, I'm not the biggest fan of systemd, but I like this detail.)
I'm going to leave this closed because it's hopeless to argue. But it wouldn't earn a passing grade in one of my classes.
;-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com