8

When yum installs updates sometimes, it will give some message like:

warning: /etc/ssh/sshd_config created as /etc/ssh/sshd_config.rpmnew

My thought is that it would be wise to act upon these because perhaps occasionally there's some tweak to a config file that is important to be performed for security reasons; however, I'm wondering if I'm just being too cautious and that's just a theoretical concern that isn't really an issue in practice.

I guess what I'm asking is anyone aware of any case in the past few years where not merging in a .rpmnew file would have had some noteworthy undesirable implication - especially security-wise, but other angles like stability or desirability of configuration may be worth mentioning.

sa289
  • 1,318
  • 2
  • 18
  • 44

2 Answers2

10

It's very rare for changes to the default configuration to have security or stability implications. However, "very rare" is not "never", and it's a good system hygiene practice to review all .rpmnew files and double-check that they don't contain important changes, and then delete them.

As a double-check, you should also arrange to receive security notices and information on all updates available to apply -- reading over the changelogs and bulletins will give you a good idea of the nature of the problems that are being fixed.

womble
  • 96,255
  • 29
  • 175
  • 230
  • Do you have any personal experience or are you aware of a specific example when an rpmnew file was important? I share your theoretical concerns, but I'd like to have a real world case to validate the concern. Thanks – sa289 Aug 22 '15 at 14:21
  • I've had configuration file formats change. That's always an amusing thing to debug. – womble Aug 22 '15 at 20:45
  • Wow, that's an unpleasant surprise. Was that when staying within the same major version (i.e. 6.x to 6.x) on RHEL / a derivative distro, or was that on some other distro or moving up major versions via an in-place upgrade? – sa289 Aug 23 '15 at 21:19
  • @sa289 Typically that happens with major releases, but something _can_ be upgraded on a minor release if there's a compelling reason to do so. In the RHEL world, that's very rare though. – Michael Hampton Aug 26 '15 at 23:56
  • 1
    I just saw ssl.conf.rpmnew contain a change in SSLCipherSuite from `ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW` to `DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES` which I imagine has security implications. – sa289 Oct 31 '15 at 04:36
  • Yeah, that could be a rather... surprising change. – womble Oct 31 '15 at 07:07
1

I would recommend to act on both *.rpmnew and *.rpmsave files after updates. The creation of these files generally indicates one of the following three things:

  1. you were not careful (or there was no other way to do it) and modified a configuration file that is under the package management. Usually, if a package provides a directory for configuration snippets (e.g. /etc/<package>.d/ like in /etc/php.d/ for PHP) you are supposed to drop your local changes there and not to be affected by the package provided configuration changes.

  2. a packager was not careful and changed a definition of the corresponding file entry in the spec file (e.g. they forgot to mark a particular file as %config or changed modifiers to the %config() macro.

  3. there is something fishy going on and the configuration file in question was tampered with.

In any case it's good to do the following if an update produced either *.rpmnew or *.rpmsave:

  1. do a diff between the old file and the new one with diff -uw old_file new_file (the -w option will ignore changes in the amount of whitespace);

  2. if there are no differences (except for the white space) and you are investigating the creation of the *.rpmnew file replace the original file with *.rpmnew one using mv config_file.rpmnew config_file. This will ensure that the package set metadata is preserved (e.g. timestamps, file permissions, and possibly capabilities)

  3. if there are differences then rebase your changes upon the file provided by the package (i.e. if you are working with *.rpmnew - copy that *.rpmnew file under a temporary name and adjust it to match the desired changes from the original configuration file; if you work with *.rpmsave - apply changes to the configuration file the package provided). This will ensure that further updates would be easier and if a new configuration file format was introduced that you are utilising it

  4. when you resolved that "conflict" remove the corresponding *.rpmnew or *.rpmsave file since they are untracked by the package management.

This will give you a clean and nice system to work with and also ensures that you are in touch with the latest changes to the configuration files.

galaxy
  • 2,089
  • 2
  • 15
  • 15
  • In my most recent example, on CentOS 7, I ran yum update and ended up with /etc/ssh/sshd_config.rpmnew. Is there a config file I should be modifying instead of /etc/ssh/sshd_config? Have you personally seen any important changes when merging in .rpmnew files that you're glad you didn't miss? – sa289 Sep 01 '15 at 14:53
  • Perhaps I worded it poorly in the answer, but the idea is that you need both files at the time of merging changes (to double-check things). So, in your case I'd do "cp -a /etc/ssh/sshd_config.{rpmnew,temp}", then will do the diff between /etc/ssh/sshd_config and /etc/ssh/sshd_config.rpmnew, apply changes to /etc/sshd/sshd_config.temp, double-check that the new file contains all you wanted, then "mv /etc/ssh/sshd_config{.temp,}" - this will atomically replace the current configuration file, restart sshd, and finally remove /etc/ssh/sshd_config.rpmnew. – galaxy Sep 03 '15 at 05:17
  • 1
    And, yes, I have seen such changes and that CentOS 7's change to sshd_config one of such changes I'm glad that I didn't miss since for some reason they decided to relax sshd security considerably by enabling stuff that was not enabled for ages :). – galaxy Sep 03 '15 at 05:19
  • Were those changes when you went from 6.x to 7.x or was it during a minor / patch release? – sa289 Sep 03 '15 at 16:20
  • It was between minors, approximately 3 months ago, IIRC. – galaxy Sep 03 '15 at 21:38