扩展文件系统层次标准 (FHS) 以容纳企业软件

我不确定有多少人会对此感兴趣，但我认为如果你有超过几百台服务器，它就会开始成为一个问题。

应用程序团队/中间件发送一个请求，要求他们需要在这个和那个应用服务器上安装下一个版本的企业软件。你做什么工作？

• 供应商不向您提供 RPM
• 即使他们这样做了，RPM 也是一团糟
  • 例如一个 RPM，我们基本上在 /tmp 中安装了一个 tarball，在安装后，解压缩它，然后删除 tarball 文件。如果您还没有看到它，则意味着无法卸载，因为它只安装了 1 个文件。
• 他们再次提供安装脚本的地方......
  • 除了信任文档之外，您不知道文件将安装到哪里。

简而言之，每个供应商都有自己的“规则”和“默认设置”，最糟糕的是，有些供应商似乎没有。

我发现解决这个问题的唯一方法是研究开发机器上的安装，并为它创建我自己的 RPM - 这引发了这篇文章的主题 - 提出了事情应该去哪里的标准。

Unix FHS处理了许多问题，但这不是它的工作——它也错过了特定于 3rd 方软件的问题。

扩展供应商产品安装的 FHS、标准和规则

我和我的一位同事一直在努力将这个标准扩展到容纳供应商软件（Oracle 数据库、Oracle 应用服务器、Teamsite、Informatica 等）。

我在这里记录了这一点，我们实际上对此非常满意......

• 它不会以任何方式违反父 FHS
• 它足够灵活，可以解决僵化的企业软件安装

如果有人对这件事感兴趣（即，高度重视遵循标准，并将它们设置在需要的地方，并关心维护一个干净的系统，让新手可以（几乎）直观地拿起并开始行走） - 我想知道....

• 你是如何解决这个问题的？
• 如果这个模型对你有用，如果不是 - 为什么不呢？

我的最终目标是让这个模型成为任何公司的任何人都可以拿起和使用的东西。

笔记

关于文档页面...

• 这是一项正在进行中的工作，所以如果有什么含糊之处，我深表歉意（并将修复它）
• 指定/opt为 3rd 方的选择不是必须的——如果你真的想的话，你可以改为使用/usr/local，只要它是一致的。我们只是更喜欢/opt.
• 在你问之前，诸如此类的事情/etc/opt/<vendor>/<product>和类似的路径确实有这样的理由，并且直接从 FHS 继承。

问题

1. 这个模型对你有用吗？
2. 这里有什么你觉得没有被解决的吗？

当然假设您有足够的服务器来保证使用此标准。