我们有两个独立托管的 Web 服务器。一个运行 CentOS 6.2，用作多个网站的生产环境。第二个运行 CentOS 6.4，托管一些内部应用程序，例如我们的 wiki、gitlab 和问题跟踪器。
我还想将第二个环境用作我们开发的站点的临时环境，以便在投入生产之前进行测试。理想情况下，两个环境在操作系统方面应具有相同的设置。
我的选择似乎是；
- 将实时盒子升级到 6.4 - 我们目前在那里有客户站点，所以这似乎有点冒险。
- 将辅助盒子降级到 6.2 - 我担心弄乱我们目前拥有的东西，我不想重新安装每天使用的开发工具。
- 忽略差异并希望这不是什么大问题。
选项 3 很诱人，但由于我真的找不到两个版本之间的区别，我不知道它是否明智，有人可以给出建议吗？
答案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 指出的那样，是人们认为可取的改进）移植到他们选择的版本。这意味着您将运行的软件的版本号表明它容易受到某些众所周知的漏洞攻击，但已对其进行了修补以避免这些漏洞（如果您需要权威参考，Red Hat 在这里用他们自己的话解释了这一点）令人惊讶的是，很多安全审计员都不理解这一点，有些人甚至在有人慢慢用简短的语言解释了之后，仍然不明白。
这个修补策略导致很多人向 SF 发帖询问如何在他们的 C6 机器上获取最新的 PHP，但它也影响了稳定性。
现在，版本控制：在某一天，Red Hat 有效地在 RHEL6 的当前补丁状态上画一条线，并将其声明为（比如说）RHEL6.4。他们制作了 ISO，但它并不是真正的 RHEL 6 版本，它只是 RHEL 6 在当天的补丁状态下。如果您想要一个完全最新的 RHEL 盒子，从 RHEL 6.4 ISO 和补丁安装比从 RHEL 6.0 ISO 和补丁安装更快，但无论哪种方式，你最终都会得到同样的东西-RHEL6.4。
CentOS 跟随上游的做法，也做了同样的事情。
这意味着，只要您没有安装任何不正常的东西（就其本身而言），并且您已安全备份所有配置文件，您就可以从 C6.2 升级到 C6.4 而不用担心任何问题。
此外，升级不仅不是一个坏主意，而且是一个非常好的主意。目前，C6.2 实际上已经过了使用寿命。它没有补丁，无法支持，而且不受支持，因为如果你将 C6.2 盒子升级到 C6.4，它就是 C6.4。没有办法运行完全打过补丁的 C6.2 盒子，除非它是 C6.41。
1这不完全正确；你可以竭尽全力不是升级redhat-release软件包，它控制着决定版本的文件，但你这样做的唯一原因是如果你正在运行一些疯狂的商业软件，坚持在 RHEL/CentOS 的特定版本上。如果您正在运行这样的程序，请将其删除。它不适合用途，并且是由白痴编写的（或更可能是营销的）。
答案2
关于 RHEL/CentOS 6.3，此更新主要带来了虚拟化方面的改进，例如为客户机提供更多 CPU 或内存，或用于将物理机迁移到虚拟机的 virt-p2v 工具。除此之外，我不知道有任何可能影响您安装的应用程序的重大更改。我只会预先检查服务器上安装的更新软件包和运行服务器所必需的更新内核驱动程序。一般来说，这些更新仅包括错误修复或安全修复。
关于 RHEL/CentOS 6.4，我知道一些重要的变化，包括完全支持并行 NFS 或更新驱动程序，以便更好地在 Hyper-V/ESXi 虚拟机管理程序上运行 RHEL6.4 客户机。否则，我会像 6.3 一样检查所有更新的软件包/内核驱动程序。
我认为，我会尝试将系统更新到最新版本 6.4。我不希望发生任何灾难……