当yum安装更新有时，它会给一些消息，如：
warning: /etc/ssh/sshd_config created as /etc/ssh/sshd_config.rpmnew 我的想法是，这是明智的做法，因为也许偶尔会有一些configuration文件的调整是重要的是出于安全原因执行; 然而，我想知道我是否过于谨慎，这只是一个理论问题，在实践中并不是真正的问题。
我想我问的是任何人都知道在过去几年任何情况下，没有在.rpmnew文件中合并会有一些值得注意的不受欢迎的暗示 – 特别是安全明智，但其他angular度，如稳定性或configuration的愿望可能值得一提。
对默认configuration进行更改对于安全或稳定性的影响是非常罕见的。 然而，“非常罕见”并不是“从不”，对所有.rpmnew文件进行检查并仔细检查是否包含重要更改，然后将其删除，这是一个很好的系统卫生实践。
作为一个双重检查，您还应该安排接收安全通知和所有可用更新的信息 – 阅读更新日志和公告可以让您很好地了解正在解决的问题的性质。
我会build议在更新后对* .rpmnew和* .rpmsave文件执行操作。 这些文件的创build通常表明以下三件事之一：
你不小心（或没有其他的方法），并修改了包pipe理下的configuration文件。 通常情况下，如果一个软件包提供了一个configuration代码片段的目录（例如/etc/<package>.d/，就像在/etc/php.d/中用于PHP），那么你应该放弃你的本地修改，不要被包提供了configuration更改。
一个打包者不小心，并改变了规格文件中相应文件条目的定义（例如，他们忘记将特定文件标记为％config或将修饰符更改为％config（）macros。
有什么可疑的事情发生，有问题的configuration文件被篡改。
在任何情况下，如果更新生成* .rpmnew或* .rpmsave，
使用diff -uw old_file new_file在旧文件和新文件之间做差异（-w选项将忽略空白量的变化）;
如果没有区别（空白除外），并且正在研究* .rpmnew文件的创build，请使用mv config_file.rpmnew config_filereplace原始文件* .rpmnew。 这将确保包集元数据被保留（例如时间戳，文件许可和可能的function）
如果存在差异，则对包中提供的文件重新进行更改（例如，如果您正在使用* .rpmnew-将该* .rpmnew文件复制到临时名称下，并将其调整为与原始configuration文件中所需的更改相匹配;如果您使用* .rpmsave – 将更改应用到提供的包的configuration文件）。 这将确保进一步更新会更容易，如果引入新的configuration文件格式，您正在使用它
当你解决这个“冲突”时，由于它们不被包pipe理所追踪，删除相应的* .rpmnew或* .rpmsave文件。
这将给你一个干净，漂亮的系统，并确保你与configuration文件的最新变化联系在一起。