Home / server / Questions / 715938
Accepted
sa289
Asked: 2015-08-22 19:15:15 +0800 CST

yum updates - are .rpmnew files ever critical / important to act upon?

  • 772

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.

centos

2 Answers

  1. Best Answer

    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.

    • 10

  2. 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.

    • 1