CentOS 6.4 和 6.2 之间有很大区别，我应该升级/降级吗？

Question

我们有两个独立的托管 Web 服务器。一个运行 CentOS 6.2 并用作许多站点的生产环境。第二个运行 CentOS 6.4，并托管一些内部应用程序，例如我们的 wiki、gitlab 和问题跟踪器。

我还想将次要站点用作我们开发的站点的暂存环境，以便在它们投入生产之前进行测试。理想情况下，两种环境在操作系统方面应该具有相同的设置。

我的选择似乎是；

1. 将 live box 升级到 6.4 - 我们目前在那里有客户站点，所以这似乎有点冒险。
2. 将辅助框降级到 6.2 - 我担心弄乱我们目前在那里的东西，我不想重新安装每天使用的开发工具。
3. 忽略差异并希望这不是什么大问题。

选项 3 很诱人，但由于我无法真正找到两个版本之间的差异，我不知道它是否明智，有人可以建议吗？

Answer 1

这一定是关于 RHEL/CentOS 最容易被误解的事情之一（就本文而言，两者实际上可以互换）。

CentOS 是一个操作系统。CentOS 6 是该操作系统的一个版本；它与 CentOS 5 非常不同。CentOS 6.1 不是操作系统版本，它只是 CentOS 6 的补丁级别。要了解这一点，您必须了解 Red Hat 的打包和补丁策略。

Red Hat 会选择他们在启动 RHEL 版本时将使用的任何给定工具的版本。对于 RHEL 6，这包括 Apache 2.2.15、2.6.32 内核、php 5.3.3 等。在 RHEL6 的剩余生命周期中，这些将不会升级；Red Hat 会将任何必要的补丁（有时，正如 dsumsky 指出的，认为是可取的改进）向后移植到他们选择的版本。这意味着您将运行的软件的版本号表明它容易受到某些众所周知的漏洞的攻击，但已经修补以避免这些漏洞（如果您需要权威参考，红帽在这里用他们自己的话解释这一点） . 令人惊讶的是，有多少安全审计员不理解这一点，其中一些甚至在理解之后”

这个补丁策略导致很多人向 SF 发帖询问他们如何在他们的 C6 机器上获得最新的 PHP，但它也带来了很大的稳定性。

现在，版本控制：在某一天，Red Hat 有效地通过 RHEL6 的当前补丁状态划了一条线，并声明它是（比如说）RHEL6.4。他们制作了它的 ISO，但它并不是真正的 RHEL 6 版本，它只是当天补丁状态下的 RHEL 6。如果你想要一个完全最新的 RHEL 盒子，从 RHEL 6.4 ISO 和补丁安装比从 RHEL 6.0 ISO 和补丁安装要快，但无论哪种方式，你最终都会得到同样的东西- RHEL 6.4.

CentOS 跟上游一样，也做同样的事情。

这意味着，如果您没有在滑雪道外安装任何东西（实际上是这样），并且您已经安全地备份了所有配置文件，您就可以从 C6.2 升级到 C6.4，而无需担心。

此外，升级不仅不是一个坏主意，而且是一个非常好的主意。在这一点上，C6.2 实际上已经结束了生命周期。它没有补丁，它不受支持，不受支持，因为如果您将 C6.2 盒子升级到补丁，它就是 C6.4。如果没有 C6.4 1 ，就无法运行完全修补的 C6.2 盒子。

1这并不完全正确；你可以向后弯腰不升级redhat-release包，它控制着决定版本的文件，但你这样做的唯一原因是如果你正在运行一些疯狂的商业软件，它坚持特定的 RHEL 版本/CentOS。如果你正在运行这样的东西，摆脱它。它不适合目的，并且由白痴编写（或者更有可能是营销）。