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

一般来说，安全更新被认为是有些安全的，特别是像RedHat这样的目标的分发。 他们的核心重点是创造一致的运营环境。 因此，维护人员倾向于select软件包的版本，并坚持使用它们。 看看我的意思是看看像kernel ， python ， perl和httpd这样的软件包的版本。 他们还做的是从上游开发人员的backport安全补丁。 因此，如果在所有版本的Apache httpd 2.2.x中发现安全漏洞，那么Apache基金会可能会发布修正版本2.2.40，但是RedHat将在本地滚动修补程序并释放带有修复程序的httpd-2.2.3-80 。

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

还有一个问题，那就是对这个系统进行大量的更新，而这个系统在这么长的一段时间还没有被修补。 我遇到的最大的问题实际上更多的是一个configurationpipe理问题，这个问题可能会被大的更新所加剧。 有时configuration文件被更改，但pipe理员从不重新启动服务。 这意味着磁盘上的configuration从未经过testing，并且正在运行的configuration可能不再存在。 因此，如果服务重新启动，一旦您应用内核更新将发生，它可能不会重新启动。 或者它重新启动后可能会有所不同。

我的build议是做更新，但要聪明一点。

• 在维护窗口中进行规划。 如果没有别的服务器将需要重新启动，已经有一些内核更新，你将不得不重新启动应用它们。
• 确保在做任何事情之前进行完整备份。 这可能是快照，如果这是一个虚拟机，无论你的工具是什么，触发一个完整的备份，tar / （到另一个系统），采取驱动器的dd映像，无论如何。 只要这是你可以恢复的东西。
• 计划如何应用更新。 你不想只是抛出一个yum update -y ，然后走开。 对于yum所做的所有好事情，它根据依赖关系应用更新时不会进行sorting。 这在过去引起了一些问题。 我总是运行yum clean all && yum update -y yum && yum update -y glibc && yum update 。 这倾向于处理大多数潜在的订购问题。

这也许是重build平台的好时机。 我们已经有了RHEL6一段时间了。 根据这个服务器的作用，在并行启动一个新的实例的时候，让这个服务器运行就可以了。 然后，一旦安装，您可以复制所有的数据，testing服务，并执行切换。 这也将使您有机会从头开始了解，该系统是标准化的，清洁的，有据可查的，以及所有的爵士乐。

不pipe你做什么，我都觉得让自己适应现在的系统是非常重要的。 你只需要确保这样做，让你相信你的工作和成品。

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

但是，不会扩展到任何外部安装的rpm。

您可以使用rpm -qf来查找您怀疑编译的文件是外部文件，如果它返回“不属于任何软件包”，那么您可能在升级时遇到问题。

我会拍摄服务器的图像并进行升级，但是我比其他大多数人更关心恶意软件。