Estendendo o Hierarchy Standard (FHS) do Filesystem para abrigar o Enterprise Software

Question

Não tenho certeza de quantas pessoas estariam interessadas nisso, mas acho que, se você tiver mais de algumas centenas de servidores, isso se tornará um problema.

Uma equipe de aplicativos / middleware envia uma solicitação para que eles precisem da próxima versão de um software corporativo a ser instalado neste e no servidor de aplicativos. O que você faz?

• O fornecedor não fornece um RPM
• Mesmo se o fizerem, o RPM é uma grande bagunça
  • Por exemplo, um RPM basicamente instalou um tarball em / tmp e, como uma pós-instalação, o untarred e, em seguida, removeu o arquivo tarball. Se você ainda não o viu, isso significa que será impossível desinstalá-lo, pois ele só instalou um arquivo.
• Onde eles fornecem scripts de instalação, novamente ...
  • Você não tem visibilidade de onde os arquivos serão instalados, além de confiar nos documentos.

Em suma, cada fornecedor tem suas próprias "regras" e "padrões" e, pior, alguns parecem não ter nenhum.

A única maneira que eu encontrei para combater isso é estudar a instalação em uma máquina de desenvolvimento, e criar meu próprio RPM para isso - isso então trouxe o tópico deste post - chegando com um padrão de onde as coisas deveriam vai.

O Unix FHS lida com muitos dos problemas, mas como não é o seu trabalho - também ignora os que são específicos para software de terceiros.

Estendendo o FHS, Padrões e & Regras para instalação de produtos de fornecedores

O que um colega meu e eu estamos trabalhando é estender esse padrão para software de fornecedor doméstico (bancos de dados Oracle, servidores de aplicativos Oracle, Teamsite, Informatica, etc., etc.).

Eu documentei este aqui , e nós ve realmente muito feliz com isso ...

• Isso não viola de forma alguma o FHS pai
• É flexível o suficiente para trabalhar em instalações de software corporativas rígidas

Se alguém estiver interessado neste assunto (ou seja, pensa muito em seguir os padrões, e defini-los onde for necessário, e se preocupa em manter um sistema limpo onde um recém-chegado pode (quase) intuitivamente pegar e começar a andar) d gostaria de saber ....

• Como você conseguiu resolver o problema?
• Se este modelo funcionasse para você, e se não - por que não?

Meu objetivo final é tornar esse modelo algo que qualquer pessoa de qualquer empresa possa pegar e usar.

Notas

Sobre a página docson ...

• É um trabalho em andamento, por isso, se algo é vago, peço desculpas (e vou corrigi-lo)
• A designação de /opt como a opção para terceiros não é uma deve - você pode usar /usr/local se realmente quiser, desde que seja consistente. Nós apenas preferimos /opt .
• Antes de perguntar, coisas como /etc/opt/<vendor>/<product> e caminhos semelhantes do têm um motivo para ser assim e são diretamente herdadas da ESF.

Pergunta

1. Esse modelo funcionaria para você?
2. Algo aqui que você sente não foi abordado?

Suposição é claro que você tem servidores suficientes para garantir o uso deste padrão para começar.

    

Answer 1

Eu sugeriria / opt / < vendedor > / < produto > mesmo antes de ver você sugerir em sua extensão proposta. Então, sim, funciona para mim.

Minha regra é:

/, / usr: o próprio sistema operacional; coisas que usam o sistema de empacotamento nativo.

/ usr / local: coisas que eu mesmo desenvolvi ou que eu compilei da fonte.

/ opt: produtos de terceiros.