将应用程序/HTTP 服务安装到“/srv”？

Question

我一直在与一个团队合作，该团队曾经将所有应用程序和 HTTP 服务（如Apache或Tomcat）安装到“/srv”目录。我怀疑主要是为了尽可能地将已安装的服务与操作系统分开。对于我自己的项目，我保留了这种做法。然而，随着时间的推移，它越来越看起来可能不是一个好主意：它阻止您使用特定于发行版的软件包（他们在那个团队中名声很差，所以大部分都是自定义安装），我注意到在尝试使用已经可用的厨师食谱时，我遇到了一些麻烦。

所以最近我很想切换到使用特定于发行版的包，而不是尝试构建适合该目录结构的自定义安装。我想知道是否有任何我可能会忽略的东西。实际上是否有充分的理由将所有内容都放入“/srv”目录中，或者是否有充分的理由不使用特定于发行版的软件包？

我的堆栈中目前需要的是：nginx、 Tomcat (Oracle JDK ) 和MongoDB。

Answer 1

安装第三方软件的 FHS 兼容路径不是/srv，而是/opt。检查这里和这里。

关于是否使用预编译包，你有两种选择：

• 如果您信任有关安全更新和错误修复的供应商，请使用它们。我愿意，他们肯定比贵公司拥有更多的人力和资源来完成这项任务。您可以继续使用操作系统默认存储库和打包基础架构。您可以使用供应商提供的任何版本（以及向后移植的修复程序）。
• 不要使用它们，并修补您的家中自酿的安装，每次一个新的漏洞被公布于众。您需要维护您的私有存储库（好吧，您也可以每次手动安装所有内容）。您可以使用该软件的更新版本。

如果您只需要维护 5-10 台机器，那么将所有设备都放在下面/opt是可行的，但是如果您维护一个超过几百台的农场，您就做错了™

在我看来，专业的方法是使用供应商提供的预编译包，除非有令人信服的理由不这样做。

Answer 2

我不认为/srv是一个好主意。对于这种情况，有/usr/local或/opt目录，而/srv用于系统提供的特定于站点的数据。

这是由 Filesystem Heararchy Standard 定义的，请记住，并非在所有发行版中都遵循 100%。FHS 建议：

• /srv - 系统提供的站点特定数据。
• /opt - 可选的应用软件包。

关于发行版特定的软件包，您通常应该使用它们，除非有很好的理由不这样做。保持所有内容都是最新的并确保您拥有最新的补丁可能很难维护，并且会使系统面临额外的安全风险。即使在您的 linux 发行版的包管理器提供的版本比所需版本旧的情况下，您通常也可以找到社区维护的某些包的较新版本的存储库，这比您自己的包更容易维护。这通常适用于更流行的软件包nginx，例如发行版CentOS（个人经验）。

我会保留什么/srv（请记住，这是个人喜好）：

• 基于 http vhost 的目录（例如/srv/http/example.com）
• ftpsites（例如/srv/ftp/example.com）
• 邮箱（例如/srv/mail/example.com/user）

这有助于我/srv/使用通常管理的数据保持组织，而大多数发行版会将这些文件/var保存在 .

Answer 3

这个特殊的例子，将每个包重新定位到 /srv，虽然是一种工作保障，但从业务角度来看似乎非常短视和低效（其中生产意味着提高这些应用程序所服务的工作环境的可用性/盈利能力/安全性/等） .

如果您可以接受发行版软件包对您的系统的影响，那么您就是在利用开发和测试制作该软件包的团队现在以及更新后投入的工作。如果您不能接受发行版软件包对您的系统所做的事情，那么请找到另一个软件包或说服/欺骗/骚扰开发团队以“您的方式”做事（或至少让“您的方式”更容易做） ) 或将其封装在虚拟机中。或者投入最少的精力来解决实际/感知的问题，并使用您最喜欢的工具集自动完成供应和配置管理。套用 Dijkstra 的话，简单性和可重复性是可靠性的先决条件。