我应该使用(官方)存储库中的 CentOS 软件包版本,还是软件包的最新稳定版本?

我应该使用(官方)存储库中的 CentOS 软件包版本,还是软件包的最新稳定版本?

这是一个开放式的问题,但我确实希望就此话题进行建设性和有益的讨论。

因此,要澄清这个问题:在运行 CentOS 7(或任何其他 Linux 发行版/版本)的服务器上,最好坚持使用 Base/EPEL 存储库中的软件包版本,还是可以从软件包站点获取最新的稳定版本?在这种情况下,我更具体地指的是 nginx、MariaDB 和 PHP 7 等软件包。例如,安装 nginx 1.8.0 而不是 EPEL 版本 1.6.3 的优缺点是什么?这两种方式是否存在性能差异或安全风险?

欢迎所有讨论和经验,请尽量引用资源和事实。

答案1

一般来说,我会尽量使用系统默认包。

然而,有时这是不可能的。要做出明智的选择,你必须回答以下问题:

  1. 发行版的软件包是否提供了您需要的功能?如果是,您甚至不需要搜索其他软件包;只需使用系统存储库提供的软件包。
  2. 您是否需要官方支持和/或必须遵守特定政策?如果是,您不能使用非官方存储库。在这种情况下,您可能对您的软件项目使用了错误的发行版。
  3. 如果前面的问题的答案是“否”,则必须搜索较新的软件版本。是否存在公认的存储库是否带有所需的软件包?如果有,请使用它。
  4. 如果没有特定的、信誉良好的存储库,则必须使用上游软件。在这种情况下,尽量使用套装软件(例如:RPM、DEB、ecc)而不是普通的 tar.gz(或类似的)。

答案2

Matthew Ife 和 shodanshok 的回答涵盖了一般性问题,但我想通过将问题放在背景中来解决您的具体问题,因为我管理的正是这些类型的系统。

我当前部署 PHP/MySQL Web 应用程序的版本是:

首先,让我们考虑一下我们为什么选择特定的发行版或软件包集。我们要么重视稳定性而不是最新功能,要么重视最新功能而不是稳定性。通常不可能在同一个发行版中同时拥有这两者,因为稳定软件需要时间来修复错误,而添加新功能会引入错误,从而导致不稳定。

一般来说,我希望应用程序运行的操作系统尽可能稳定,但具有相当现代的功能集。因此,我会选择 CentOS 7 而不是 CentOS 6,后者目前相当老旧,虽然它会工作,它的支持生命周期所剩时间不多了,所以我不会将它用于新项目。

然而,我随后遇到了一个问题,即 CentOS 附带的 nginx 版本太旧了,没有一些必需的功能和错误修复。因此我开始寻找替代软件包,发现 nginx.org 分发了他们自己的软件包。我几乎立即切换到它们,并且发现它们在长期内非常稳定。

然后是 PHP。我从历史中知道,CentOS 附带的 PHP 版本将是它唯一的版本,并且只会获得安全更新;没有新功能或错误修复。因此,一旦上游不再支持它,如果我使用这些软件包,我最终将无法运行现代 PHP Web 应用程序。因此,也有必要替换这些。

从长期经验中,我了解到最好跟踪 PHP 的错误修复版本,而不是简单地冻结某个版本并仅进行安全修复,因为我运行的 Web 应用程序也将更新并需要这些错误修复。因此,在评估了许多不同的 PHP 软件包集后,我选择了 remi 的软件包。Remi 恰好是 Red Hat 的员工,还负责 RHEL/CentOS 中的 PHP 软件包。所以我知道他的软件包质量很高,事实也确实如此。它们是系统软件包的直接替代品,并且运行完美。

最后我们来谈谈 MariaDB。您选择保留系统软件包,不会受到任何不良影响。我选择切换到 MariaDB 的 10.0 软件包(很快将升级到 10.1),以利用 TokuDB 和 CentOS 附带的 5.5 版本中没有的一些其他性能增强功能,并且它永远不会收到重大升级。


总体而言,您需要基础系统的稳定性,但 Web 应用程序的变化速度比业务线软件等要快得多,您的服务器需要跟上变化。因此,我选择了目标点,在这些点上升级软件包可以获得明显的好处,而不需要额外的管理开销(即工作量)。

答案3

简短的回答是,始终使用系统存储库提供的内容。非常小心你安装了哪些存储库?有些存储库简直糟透了。

您不应该用较新版本覆盖系统包,Redhat 的设计和编排非常谨慎,如果这样做,您可能会遇到奇怪的错误或问题。

需要考虑和注意的一些可能导致问题的事情包括:

  1. 有些存储库维护得很糟糕。它们没有更新软件包的安全修复程序。
  2. 人们往往会编写糟糕的 RPM,他们不会将配置文件标记为配置文件,每次更新时都会覆盖您的配置,这可能会导致问题。我以前见过这个问题。
  3. 他们没有充分正确地声明其依赖关系。我以前也见过这种情况,将php包放到系统上但没有更新pear引入问题的包。
  4. 安装多个提供相同软件包名称的存储库可能会导致系统出现无法预料的依赖问题。
  5. 某些软件包会覆盖或重写其他软件包所依赖或期望存在的系统配置文件。这会导致其他软件包出现您可能意想不到的问题。

绝不从源代码构建软件包并将它们安装在现有软件包之上。这会破坏系统软件包的完整性,从而导致奇怪的 ABI 问题,例如接收unresolved symbolundefined reference消息。系统维护可靠且准确的索引,以了解在给定系统上部署了哪些软件,以确保所有软件都能正常工作,这一点非常关键,这就是我们首先使用 RPM 的原因。

解决这个问题的可行方法(并且得到 Redhat 的认可)是使用软件集合。

www.softwarecollections.org

它会将软件及其“新”依赖项安装在自己的根目录中。这可能会使在您的环境中应用软件包变得稍微困难​​一些,但确实可以保护您的系统免受奇怪的错误或问题的影响。它还会将软件包安装在自己的命名空间中,让您可以并行安装软件包的多个版本。

该网站提供了如何安装和激活这些软件包的说明,它包含了人们在旧版本的 CentOS 和 Redhat(尤其是 EL6)上所缺少的大部分内容。我从这个网站上成功使用了一些东西。

  • MySQL 5.6 和 MySQL 5.7,MariaDB。
  • PHP 5.5 和 PHP 5.6
  • Apache 2.4

请注意,你对此事的默认立场应该是不要调整 Redhat 存储库所推动的内容。相反,你应该评估自己是否真的需要更新版本的软件包,特别是你的具体要求是什么、它应该修复哪些问题以及它会带来哪些风险。

一般来说,如果您发现自己不断需要更新软件和/或需要同一软件包的多个并行版本才能使其正常工作,这通常表明您做错了什么。

相关内容