我一直在与一个团队合作，他们曾经安装过所有的应用程序和 HTTP 服务，比如阿帕奇或者雄猫到“/srv”目录。我怀疑主要是为了尽可能地将安装的服务与操作系统分开。对于我自己的项目，我保留了这种做法。然而，随着时间的推移，这越来越看起来可能不是一个好主意：它阻止您使用分配特定的软件包（他们在那个团队中声誉很差，所以大多数都是自定义安装），我注意到在尝试使用已经可用的厨师食谱时我遇到了很大的麻烦。
所以最近我倾向于使用发行版特定的软件包，而不是尝试构建适合该目录结构的自定义安装。我想知道我是否可能忽略了什么。是否有充分的理由将所有内容放入“/srv”目录或是否有充分的理由不使用发行版特定的软件包？
答案1
安装第三方软件的 FHS 兼容路径不是/srv，但是/opt。检查这里和这里。
关于是否使用预编译包，您有两种选择：
- 如果您信任供应商的安全更新和错误修复，请使用它们。我会的，他们肯定比您的公司有更多的人力和资源专门用于这项任务。您可以继续使用操作系统默认存储库和打包基础设施。您可以使用供应商提供的任何版本（以及反向移植的修复）。
- 不要使用它们，并修补你自制的安装每次A新的漏洞是公开。您需要维护您的私有存储库（当然，您也可以每次手动安装所有内容）。您可以使用较新版本的软件。
如果你只需要维护 5-10 台机器，那么把所有机器都放在下面/opt是可行的，但如果你维护一个超过几百台机器的农场，那么你就做错了™
我认为，专业的方法是使用供应商提供的预编译包，除非有令人信服的理由不这样做。
答案2
我认为/srv这从来都不是一个好主意。在这种情况下，有/usr/local或/opt目录，而/srv用于系统提供的特定于站点的数据。
这是由文件系统层次结构标准定义的，请记住，并非所有发行版都 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，我使用这个，这样我就可以在不同的发行版中为常见的特定于站点的数据使用相同的目录结构。
答案3
这个特定的例子，将每个包重新定位到 /srv，虽然是一种工作保障的形式，但从商业角度来看，似乎是特别短视和无效的（其中高效意味着提高这些应用程序所服务的工作环境的可用性/盈利能力/安全性/等等）。
如果你能接受发行版软件包对你的系统造成的影响，那么你就可以利用软件包制作团队现在投入的开发和测试和更新。如果您无法忍受发行版软件包对您的系统造成的损害，那么请寻找另一个软件包或说服/哄骗/骚扰开发小组按照“您的方式”做事（或至少使其更容易按照“您的方式”做事）或将其封装在虚拟机中。或者投入最少的努力来修复实际/感知到的问题，并使用您最喜欢的工具集自动完成配置和配置管理。套用 Dijkstra 的话，简单性和可重复性是可靠性的先决条件。