我一直在和一个团队合作，他们曾经把所有的应用程序和HTTP服务（比如Apache或Tomcat）安装到'/ srv'目录。 我怀疑主要是为了尽可能地将安装的服务与操作系统分开。 对于我自己的项目，我保持这种做法。 然而，随着时间的推移，越来越多的人认为这可能不是一个好主意：它阻止你使用分发特定的软件包（他们在团队中的声誉非常差，所以大部分都是自定义安装），我注意到当尝试使用已经可用的厨师食谱时，我遇到了相当麻烦。
所以最近我很想切换到使用分发特定的包，而不是尝试构build适合该目录结构的自定义安装。 我想知道是否有什么我可能忽略的。 实际上有没有什么好的理由把所有的东西都放到'/ srv'目录中，或者没有任何理由不使用分发包？
我目前需要的是： nginx ，Tomcat（Oracle JDK ）和MongoDB 。
安装第三方软件的FHS兼容path不是/srv ，而是/opt 。 点击这里和这里 。
关于是否使用预编译包，你有两个select：
如果你只需要维护5到10台机器，把所有东西放在/opt都是可行的，但是如果你维护一个超过几百个的农场，你就会做Doing It Wrong™
在我看来， 专业的做法是使用供应商提供的预编译包，除非有令人信服的理由不要。
我不认为/srv是一个好主意。 对于这种情况，有/usr/local或/opt目录，而/srv是由系统提供的特定于站点的数据。
这是由文件系统Heararchy标准定义的，请记住，在所有分发版本中没有100％。 FHSbuild议这样做：
/srv – 由系统提供的特定于站点的数据。 /opt – 可选的应用程序软件包。 关于发行版的特定软件包，除非有很好的理由，否则通常应该使用它们。 保持最新状态并确保您拥有最新的修补程序可能太难以维护，并可能使系统面临额外的安全风险。 即使你的linux发行版的软件包pipe理器提供的版本比以前版本要旧，你通常可以find社区维护的版本库，以便更新版本的某些软件包，比你自己的软件包更易于维护。 在像CentOS这样的CentOS （个人经验）中，像nginx这样的更受欢迎的软件包通常就是这种情况。
我将保留在/srv而不是（请记住这是个人喜好）：
/srv/http/example.com ） /srv/ftp/example.com ） /srv/mail/example.com/user ） 这可以帮助我保持/srv/通常pipe理的数据组织，而大多数发行将保持这些文件/var ，我使用这个，所以我可以有相同的目录结构跨不同的分布通用的特定于站点的数据。
这个特殊的例子，将每个包redirect到/ srv，同时也是一种工作安全forms，从业务angular度来看，似乎是非常短视的，并且是非生产性的（其中生产力意味着提高这些应用程序所提供的工作环境的可用性/盈利能力/安全性等） 。
如果您可以接受发行版软件包对您系统的作用，那么您就可以利用开发和testing工具包的团队来生成软件包。 如果你不能接受发行版对你的系统的作用，那么find另一个软件包或者说服/开发/骚扰开发小组，以“自己的方式”来做事情（或者至less让你的方式更容易） ）或将其封装在虚拟机中。 或者投入最less的工作量来解决真正的/被感知的问题，并用自己喜欢的工具集自动完成configuration和configurationpipe理。 为了解释Dijkstra，简单性和可重复性是可靠性的先决条件。