“我们可以将现有的生产EL5服务器升级到EL6吗？”
来自两个完全不同环境的客户提出的一个简单的要求促使我回答“是的，但需要协调重build所有系统 ”。
这两个客户都觉得，对系统进行彻底的重build对于停机和资源的原因来说是不可接受的select。当被问及为什么有必要完全重装系统时，我没有一个好的答案，“这就是……”
我并不是想引起关于configurationpipe理的反应（“木偶一切 ” 并不总是适用 ），或者客户应该如何计划好。 这是一个现实世界的例子，在生产能力上已经发展壮大，但是没有看到转向下一个版本操作系统的干净path。
环境A：
拥有40台Red Hat Enterprise Linux 5.4和5.5 Web，数据库服务器和邮件服务器的非营利组织，运行Java Web应用程序堆栈，软件负载平衡器和Postgres数据库。 所有系统都在不同位置的两个VMWare vSphere群集上虚拟化，每个群集都有HA，DRS等。
环境B：
拥有200个CentOS 5.x系统的高频金融交易公司，在多个同地点设施中进行生产交易操作，支持内部开发和后台function。 交易服务器在裸机商品服务器硬件上运行。 他们有许多sysctl.conf ， rtctl ，中断绑定和驱动程序调整，以降低邮件延迟。 一些有定制和/或实时内核。 开发者工作站也运行类似的CentOS版本。
在这两种情况下，环境运行良好。 升级的愿望来自对EL6中新的应用程序或function的需求。
如果不彻底改变操作系统 ，两者都不能轻易打包或更新。
作为系统工程师，我很欣赏红帽build议在主要版本之间移动时进行完整的重build。 一个干净的开始迫使你重构并注意一路上的configuration。
对于客户的业务需求敏感，我想知道为什么这需要这么艰巨的任务 。 RPM打包系统不仅能处理就地升级，而且还有一点点细节让你： /boot需要更多的空间，新的默认文件系统，RPM可能会打破升级中，不推荐使用和不使用的软件包。
这里的答案是什么？ 其他发行版（基于.deb，Arch和Gentoo）似乎具有这种能力或更好的path。 比方说，我们find了以正确的方式完成这项任务的停机时间：
我想有configurationpipe理的angular度，但是我所看到的大多数Puppet安装并不能很好地转化为具有高度自定义的应用程序服务器的环境 （ 环境B可能有一个服务器，其ifconfig输出如下所示 ）。 不过，我很乐意听到关于如何使用configurationpipe理来帮助组织跨越RHEL主要版本的build议。
（作者注意：这个答案指的是RHEL 6和以前的版本，RHEL 7现在有一个从RHEL 6完全支持的升级path，详细信息在最后）。
首先，我应该注意到有两种方法可以进行就地升级：
linux upgradeany 。 redhat-release RPM，运行yum distro-sync （稍微简化一下）然后重启。 方法1仅仅是不受支持的。 方法2适用于真牛仔。 除了推荐的全新安装，我已经完成了这两个…
支持在我们的世界中有两个互补的含义。 首先是产品有一个特定的function（例如“Postfix支持SMTP”）。 第二个是供应商会和你谈谈。 从上下文来看，哪个定义并不总是很清楚。
要完成一项任务，显然需要第一个意义上的支持。 供应商支持来帮助您解决问题，并向供应商反馈哪些function需要存在或得到改进。 许多网站在拥有内部专业知识来解决任何可能出现的问题时，都会为供应商提供支持，比供应商可以更快，甚至更便宜。 是否购买供应商支持最终是您必须作出的商业决策（或者build议pipe理层）。
这就是红帽所说的 ：
红帽不支持Red Hat Enterprise Linux的任何主要版本之间的原地升级。 主要版本由整数版本更改表示。 例如，红帽企业Linux 5和红帽企业Linux 6都是红帽企业Linux的主要版本。
跨主要版本的就地升级不保留所有系统设置，服务或自定义configuration。 因此，从一个主要版本升级到另一个主要版本时，红帽强烈build议重新安装。
他们进一步警告说：
但是，在select升级系统之前，请注意以下限制：
- 执行升级后，由于各种configuration文件格式或布局的变化，单个程序包configuration文件可能会也可能不会运行。
- 如果您安装了Red Hat的分层产品（如Cluster Suite），则可能需要在Red Hat Enterprise Linux升级完成后手动升级。
- 升级后，第三方或ISV应用程序可能无法正常工作。
当然，他们会介绍如何通过方法1进行就地升级，以防万一您真的想要这样做。 这个function是存在的，红帽把开发时间放在里面，所以这个function是支持的。 但如果出现问题，红帽会告诉你安装新鲜的; 他们不会提供供应商支持的事情，因为升级而中断。
为了logging，我从来没有真正遇到RHEL / CentOS或Fedora系统就地升级的问题，我无法自己解决。 典型的问题来自于重命名软件包，第三方软件库以及软件包的i386和x86_64体系结构之间偶尔的版本不匹配。 我想，安装程序在处理这些问题上要好一些。
我通常会提醒人们，他们应该每隔3 – 4年就要维护一次，以便将RHEL系统从一个主要版本升级到另一个版本。 虽然升级一般顺利，但意外事件总会发生。
对于您的两种环境，我都希望能够进行就地升级，但我强烈build议您首先彻底进行testing。 P2V是服务器的一个有代表性的示例，并通过就地升级在虚拟系统上运行，以查看您将要遇到的问题。 然后，您可以根据对发生的事情有更好的了解来计划实际的生产升级。
对于像这样的大型部署，可以考虑使用Limoncelli的“一对多”方法。 升级一台机器，看看出现了什么问题，解决它们，然后利用升级一小批机器时学到的经验教训，重复吸取经验教训的事情，然后当你相信你有所有的纠结，升级大批量的。
在这样的时刻，我也build议您长时间仔细观察应用程序的部署过程。 如果它不够自动化，你可以用一个命令来启动它，并合理地确信应用程序将正确部署，那么开发人员可能需要开展工作。 进行这样的部署过程将使得更新版本的EL的全新安装变得容易，然后部署到其上。
基于Debian的发行版确实有一个支持就地升级的方法，它大部分都能正常工作，但是它不能解决问题。 例如，通过支持的方法， 从Ubuntu 10.04 LTS升级到12.04 LTS的用户就遭受了很多打击 。 目前尚不清楚Debian或Canonical是否将足够的开发时间投入到“支持”这个function，即确保它能够正常工作。 如果你想要别人牵着你的手，你实际上还得购买厂商支持这个发行版。 所以我怀疑你会从切换到这样的分配获得很多。
您可以通过切换到诸如Gentoo或Arch之类的滚动发布版本来获得收益。 但是，这也不能让你免于问题; 这意味着您必须在服务器的整个生命周期内（例如，无论何时您或开发人员决定更新系统上的某些内容）连续处理升级问题，而不是一次性按计划完善的分发升级时间。 您也没有供应商提供支持。
Fedora项目正在开发一种工具来改善就地升级。 他们有一个名为preupgrade的工具，被放弃了，并用一个名为fedup的新工具取代， 从Fedora 18开始 。 这已经添加到RHEL7，现在就地升级已经完全支持 ，至less从RHEL 6到RHEL 7 。 根据我自己的经验，我可以说，虽然fedup仍然有一些fedup ，它正在成为一个非常有用的工具。
CentOS也在尝试使用滚动释放types的存储库 ，但它只适用于较小的版本（例如6.3-6.4）。
我接受你最后一段：
我想有configurationpipe理的angular度，但是我所看到的大多数Puppet安装并不能很好地转化为具有高度自定义的应用程序服务器的环境（环境B可能有一个服务器，其ifconfig输出如下所示）。 不过，我很乐意听到关于如何使用configurationpipe理来帮助组织跨越RHEL主要版本的build议。
我认为configurationpipe理系统的真正价值，尤其是在环境B的背景下，是他们提供了独立于运行服务器的服务来构build服务的工具。 如果不使用CMS来创build现有服务，那么在重新创build服务时可能无济于事。
我知道这并不能解决你眼前的问题，但对我来说，这是源于组织思考服务器而不是服务。 在以服务为中心的思维中，只要服务继续运行，个人服务器的个性就不需要维护。 如果以有纪律的方式使用CMS来构build整个服务，那么将该服务移动到另一个系统应该是相对简单的，因为所有机器的个性都将由CMS构build。
PS我不太清楚在这种情况下ifconfig输出的重要性 – 它是由一个configuration文件和一些脚本产生的（否则它不会在启动时出现），如果需要，可以由CMSpipe理。