%20%E4%BB%A5%E5%AE%B9%E7%BA%B3%E4%BC%81%E4%B8%9A%E8%BD%AF%E4%BB%B6.png)
我不确定有多少人对此感兴趣，但我认为如果你拥有超过几百台服务器，它就会开始成为一个问题。
应用程序团队/中间件发送请求，称他们需要在某应用服务器上安装企业软件的下一个版本。您会怎么做？
- 供应商没有向您提供 RPM
- 即使他们这么做了，RPM 也是一团糟
- 例如，我们基本上将一个 tarball 安装到 /tmp 中的一个 RPM，在安装后对其进行解压，然后删除该 tarball 文件。如果您还没有看到它，则意味着无法卸载，因为它只安装了一个文件。
- 他们再次提供安装脚本......
- 除了信任文档之外，您根本不知道文件将被安装到哪里。
简而言之，每个供应商都有自己的“规则”和“默认值”，最糟糕的是，有些供应商似乎没有任何规则和默认值。
我发现解决这个问题的唯一方法是研究在开发机器上的安装，并为其创建我自己的 RPM - 这就引出了这篇文章的主题 - 提出一个事情应该如何发展的标准。
这Unix FHS处理许多问题，但由于这不是它的工作 - 它也忽略了特定于第三方软件的问题。
扩展 FHS、供应商产品安装标准和规则
我和我的同事一直致力于将此标准扩展到内部供应商软件（Oracle 数据库、Oracle 应用程序服务器、Teamsite、Informatica 等）。
我已经记录了这一点这里，我们确实对此非常满意……
- 它不会以任何方式违反母公司 FHS
- 它足够灵活，可以解决严格的企业软件安装问题
如果有人对此事感兴趣（即高度重视遵循标准，并在需要的地方制定标准，并关心维护一个干净的系统，让新手可以（几乎）直观地学习并开始行走）——我想知道……
- 你是如何解决这个问题的？
- 如果这个模型适合您，如果不适合 - 为什么不呢？
我的最终目标是使该模型成为任何公司任何人都可以拿起并使用的东西。
笔记
关于文档页面...
- 这是一项正在进行的工作，因此如果有什么不清楚的地方，我深表歉意（并且会修复它）
/opt作为第三方的选择不是一个必须- 如果您确实想要，也可以使用/usr/local，只要它是一致的。我们只是更喜欢/opt。- 在你询问之前，诸如
/etc/opt/<vendor>/<product>和类似的路径做有其存在的理由，并且直接从 FHS 继承而来。
问题
- 这个模型适合你吗？
- 您觉得这里还有什么问题没有解决吗？
当然，假设您有足够的服务器来保证使用此标准。
答案1
在我看到您在提议的扩展中建议使用 /opt/<vendor>/<product> 之前，我就已经打算建议使用这个了。所以，是的，它对我来说是有效的。
我的经验法则是：
/, /usr：操作系统本身；使用本机包装系统的东西。
/usr/local：我自己开发的东西，或者从源代码编译的东西。
/opt：第三方产品。