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

tdk*_*2fe 21 security redhat yum

我最近负责了一个新的 RedHat EL5.6 服务器。很明显,在过去的 12 个月中,几乎没有关注任何类型的软件包更新。

通常我的心态是如果它没有坏掉 - 不要修复它。但是,在向 RHN 注册服务器并使用 yum-security 插件检查安全更新后,只有 1100 多个“安全”更新可用。

有没有人遇到过类似的情况?我不愿意只更新所有内容,因为我想知道正在更新的内容以及它是否有可能影响机器上运行的任何内容(这是一个生产服务器)。但是,看起来与这种做法保持一致还需要我逐行检查 1100 包勘误表。有没有更有效的解决方案?

Sco*_*ack 21

一般来说,安全更新被认为是有些安全的,特别是对于像 RedHat 这样的目标的发行版。他们的核心重点是创建一致的操作环境。因此,维护人员倾向于选择软件包的版本并长期坚持使用它们。要明白我的意思看这种封装类的版本kernelpythonperl,和httpd。他们还做的是从上游开发人员向后移植安全补丁。因此,如果发现 Apache httpd 2.2.x 的所有版本都存在安全漏洞,那么 Apache 基金会可能会发布带有修复程序的 2.2.40 版本,但 RedHat 将在本地滚动补丁并发布httpd-2.2.3-80该修复程序。

还请记住,您目前谈论的是 RHEL5.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。这往往会解决大多数潜在的订购问题。

这也可能是重新平台的好时机。我们已经使用 RHEL6 有一段时间了。根据此服务器的功能,在并行启动新实例时让此服务器按原样运行可能是有意义的。安装完成后,您可以复制所有数据、测试服务并执行切换。这也将使您有机会从头开始了解系统是标准化的、干净的、有据可查的以及所有爵士乐。

不管你做什么,我觉得让自己适应当前的系统是非常重要的。你只需要确保以一种让你信任你的工作和成品的方式来做。