4

The last CentOS upgrade from December 3, 2015 rpmsaved the /etc/yum/yum-cron.conf file and replaced it with the new one on bunch of the servers I manage, which had previously been configured with the following settings in the file:

update_messages = no
apply_updates = yes

to let all the systems auto-upgrade without sending notification messages. Unfortunately, both settings have been reversed by the last upgrade and my e-mail box is full of annoying notifications.

Now, before proceeding to set desired settings on all the servers once from anew again, I'd like to know how to prevent this kind of issues in the future. I don't mind the yum-cron.conf file to be upgraded if required, but with my custom settings preserved. So what is the best way of addressing this issue?

Nick
  • 205
  • 1
  • 9
  • See also http://unix.stackexchange.com/questions/252314/why-does-a-yum-package-update-replaces-my-yum-cron-config-files – maxschlepzig Dec 31 '15 at 09:42
  • Max, unfortunately I can't comment on that thread due to lack of reputation. The problem is that I don't have yum.spec file on my systems at all. So it is unclear how to apply the patch file suggested on https://bugzilla.redhat.com/show_bug.cgi?id=1293513 – Nick Jan 12 '16 at 01:59
  • Nick, the patch is for the package maintainer to integrate. The spec file is inside the yum rpm source package. You can unpack/change/patch it but then you need to rebuild the rpm binary package (also making sure that you change the version number in a proper way). Only worth it if you have a bunch of machines you want to push a yum-cron update to. – maxschlepzig Jan 12 '16 at 08:04
  • I see now it doesn't worth, however I wonder what is the best temporary way of addressing this issue until it's resolved by the upstream OS vendors. – Nick Jan 12 '16 at 08:29

1 Answers1

4

The best way, IMHO, would be to file a bug against RHEL 7 (from which CentOS is a simple rebuild), asking that this file be marked as a configuration file instead of a normal payload file. That is the best fix, but will probably also take longer than you care to wait.

The best workaround I can come up with is the set the immutable attribute on this file (chattr +i), and only unset it when you specifically want to edit the file. The only potential problem with this is that the update may fail because it can't write a payload file, so you'll end up not getting the yum update.

You could set up a configuration management environment that replaced this file with a file of your choosing when it noticed a change, but that might be overkill.

John
  • 9,070
  • 1
  • 29
  • 34
  • Bug report is the way to go. This should not have happened. Of course, it's always best to test updates on one or a few servers before rolling them out everywhere. – Michael Hampton Dec 21 '15 at 16:01
  • Thanks guys for your suggestions, however after quickly reading through https://utcc.utoronto.ca/~cks/space/blog/linux/CentOSBugReportProblem?showcomments#comments (Funnily one of them just got fixed some 3-4 years since I first submitted it...) I don't feel like filing anything. Using chattr command is also not viable solution in my case. So if there is no other ways then I am afraid I'll just setup a rule in my e-mail client to forward all notification from CentOS 7 anacron to autodeletion. – Nick Dec 22 '15 at 01:26
  • 1
    Changed my mind and took 5 minutes to quickly report the bug on https://bugzilla.redhat.com/show_bug.cgi?id=1293513 So let's see what happens. – Nick Dec 22 '15 at 01:39