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

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

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

  • 供应商不会为您提供RPM
  • 即使他们这样做,RPM是一个巨大的混乱
    • 例如,一个RPM我们已经基本安装了一个tarball到/ tmp,并且作为一个安装后,解压缩它,然后删除tarball文件。 如果你还没有看到它,这意味着它将不可能卸载,因为它只安装了一个文件。
  • 他们在哪里提供安装脚本,再次…
    • 除了信任文档之外,您不知道要将文件安装到哪里。

总之,每个厂商都有自己的“规则”和“违约”,最坏的是有的似乎没有。

我唯一的办法就是在开发机器上研究安装,然后为它创build自己的RPM – 这就提出了这篇文章的主题 – 提出了一个事情应该去的标准。

Unix的FHS处理很多问题,但不是它的工作 – 它也错过了第三方软件特有的问题。


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

我和我的一个同事正在将这个标准扩展到供应商软件(Oracle数据库,Oracle应用服务器,Teamsite,Informatica等等)。

我已经logging在这里 ,我们其实已经非常高兴

  • 它不以任何方式违反父母的FHS
  • 它足够灵活,可以解决严格的企业软件安装问题

如果有人对这个问题感兴趣(即高度重视下列标准,并将其设置在需要的地方,并且关心维持一个干净的系统,新手可以(几乎)直觉地接受和开始行走) – 我想知道….

  • 你是怎么设法解决这个问题的?
  • 如果这个模型适合你,如果不行 – 为什么不呢?

我的最终目标是使这个模型成为任何公司的任何人都可以拾取和使用的模型。


笔记

关于docson页面…

  • 这是一个进行中的工作,所以如果有些东西是模糊的,我表示歉意(并且将会解决这个问题)
  • 指定/opt作为第三方的select并不是必须的 – 如果你真的想要的话,可以使用/usr/local ,只要它是一致的。 我们只是喜欢/opt
  • 在你问之前,诸如/etc/opt/<vendor>/<product>和类似的path确实有这样一个原因,并且直接从FHSinheritance。

  1. 这个模型适合你吗?
  2. 你觉得这里有什么东西没有解决?

假设当然是你有足够的服务器来保证使用这个标准开始。

甚至在我们看到您在build议的扩展中提出build议之前,我会build议/ opt / <vendor> / <product>。 所以,是的,它适用于我。

我的经验法则是:

/,/ usr:操作系统本身; 使用本地包装系统的东西。

/ usr / local:我自己开发的东西,或者我从源代码编译的东西。

/ opt:第三方产品。