问更新以前未维护的服务器的最佳实践RHEL5.7 5.7

EN

一般来说，安全更新被认为是安全的，特别是对于目标像RedHat这样的发行版。他们的核心重点是创造一个一致的操作环境。因此，维护人员倾向于选择包的版本，并长期使用它们。要了解我的意思，请查看这些包的版本，如kernel、python、perl和httpd。他们还做的是来自上游开发人员的backport安全补丁。因此，如果在Apachehttpd2.2.x的所有版本中都发现了安全漏洞，那么Apache基金会可能会发布2.2.40版本的补丁，但是RedHat会在本地滚动修补程序并发布httpd-2.2.3-80。

还请记住，您目前正在谈论的是RHEL5.7 5.7系统，当前的版本是5.9。一些软件供应商只支持某些子版本。例如，我最近遇到了一款软件，供应商说它只在5.4上工作。这并不意味着它不会运行在5.9，但它可能意味着，如果不工作，他们将不会提供任何支持。

对于一个已经很长时间没有修补过的系统进行大规模更新也引起了人们的关注。我遇到的最大的一个问题实际上是一个配置管理问题，这个问题只会因为大的更新而加剧。有时，配置文件会被更改，但管理员永远不会重新启动服务。这意味着磁盘上的配置从未被测试过，并且正在运行的配置可能不再存在。因此，如果服务重新启动(一旦应用内核更新就会发生)，它可能实际上不会重新启动。或者，一旦它重新启动，它的行为可能会有所不同。

我的建议是，做更新，但要聪明。

• 在维护窗口中计划出来。如果服务器不需要重新启动，那么已经有了许多内核更新，您必须重新启动才能应用它们。
• 在做任何事情之前，一定要做一个完整的备份。这可能是快照，如果这是一个VM，触发对任何您的工具的完全备份，将/ (转到另一个系统)，获取驱动器的dd图像等等。只要它是你可以恢复的东西。
• 计划如何应用更新。你不想就这么丢了一个yum update -y就走了。对于yum所做的所有好事情，当它根据依赖项应用更新时，它不会排序。这在过去造成了一些问题。我总是运行yum clean all && yum update -y yum && yum update -y glibc && yum update。这往往解决了大部分潜在的排序问题。

这也可能是一个重新平台的好时机。我们已经有很长一段时间了。根据服务器所做的事情，当您并行地打开一个新实例时，让这个服务器按原样运行可能是有意义的。然后，一旦安装完毕，您就可以复制所有数据，测试服务，并执行剪切操作。这也会让你有机会从底层了解这个系统是标准化的，干净的，有很好的文档记录，以及所有的爵士乐。

不管你做什么，我都觉得你要适应当前的体制是非常重要的。你只需要确保这样做的方式，让你相信你的工作和成品。

根据我的经验，RHEL不会破坏相同版本更新中的向后兼容性。

然而，这将不会扩展到任何已经安装到外部的rpm。

您可以使用rpm -qf查找您怀疑是外部编译的文件，如果它返回“不属于任何包”，则在升级过程中可能会出现问题。

我会拍下服务器的图片并进行升级，但我比大多数人更关心魔鬼。