Instale o aplicativo / serviços HTTP em “/ srv”?

Question

Tenho trabalhado com uma equipe que costumava instalar todos os aplicativos e serviços HTTP como Apache ou Tomcat para o diretório '/ srv'. Eu suspeito principalmente, a fim de manter os serviços instalados separados do sistema operacional, tanto quanto possível. Para meus próprios projetos, mantive essa prática. No entanto, com o tempo, parece cada vez mais que isso pode não ser uma boa ideia: ele impede que você use distribuição específica pacotes (eles tinham uma reputação muito ruim naquele time, então quase tudo era instalações customizadas), e notei que eu estava me metendo em alguns problemas ao tentar usar livros de receitas do chef, que já estão disponíveis.

Então, ultimamente, fiquei tentado a usar os pacotes específicos de distribuição, em vez de tentar criar instalações personalizadas que se encaixam nessa estrutura de diretórios. Eu queria saber se há algo que eu possa estar negligenciando. Existe realmente algum bom motivo para colocar tudo em um diretório '/ srv' ou algum bom motivo para não usar os pacotes específicos da distribuição?

O que eu preciso atualmente na minha pilha é: nginx , Tomcat (Oracle JDK ) e MongoDB .

    

Answer 1

O caminho compatível com o FHS para instalar software de terceiros não é /srv , mas /opt . Verifique aqui e aqui .

Com relação a usar ou não pacotes pré-compilados, você tem duas opções:

• Use-os se confiar no fornecedor em relação a atualizações de segurança e correções de bugs. Eu certamente teria mais recursos humanos e recursos dedicados a essa tarefa do que sua empresa. Você pode continuar usando os repositórios padrão do SO e a infraestrutura de empacotamento. Você pode conviver com qualquer versão que o fornecedor forneça (mais correções com backport).
• Não os use e corrija sua instalação caseira toda vez uma nova nova vulnerabilidade é made public . Você precisa manter seus repositórios privados (bem, você também pode instalar tudo manualmente toda vez). Você pode usar versões mais recentes do software.

Se você só precisa manter de 5 a 10 máquinas, colocar tudo em /opt é factível, mas se você mantiver um farm de mais de algumas centenas, estará Fazendo isso errado

Na minha opinião, a maneira profissional de fazer isso é usar os pacotes pré-compilados fornecidos pelo fornecedor, a menos que haja uma razão convincente para não fazê-lo.

    

Answer 2

Eu não acho que /srv tenha sido uma boa ideia. Para este caso, há /usr/local ou /opt directory, enquanto /srv é para dados específicos do site que são servidos pelo sistema.

Isso é definido pelo Filesystem Heararchy Standard, tenha em mente que não é seguido por 100% em todas as distribuições. FHS sugere isso:

• /srv - Dados específicos do site que são servidos pelo sistema.
• /opt - Pacotes de software de aplicativo opcionais.

Em relação a pacotes específicos de distro, você deve geralmente usá-los, a menos que haja uma boa razão para não usá-los. Manter tudo atualizado e garantir que você tenha os patches mais recentes pode ser muito difícil de manter e pode expor o sistema a riscos adicionais de segurança. Mesmo nos casos em que o gerenciador de pacotes da distribuição linux fornece uma versão mais antiga que a necessária, geralmente é possível encontrar repositórios mantidos pela comunidade para versões mais recentes de determinados pacotes, o que seria mais fácil de manter do que seus próprios pacotes. Este é geralmente o caso de pacotes mais populares como nginx em distrubutions como CentOS (experiência pessoal).

O que eu manteria em /srv (lembre-se de que essa é uma preferência pessoal):

• link
• ftpsites (por exemplo, /srv/http/example.com )
• caixas de correio (por exemplo, /srv/ftp/example.com )

Isso me ajuda a manter /srv/mail/example.com/user organizada com dados normalmente gerenciados, enquanto a maioria das distribuições manteria esses arquivos em /srv/ , eu uso isso para ter a mesma estrutura de diretórios para dados comuns específicos do site em diferentes distribuições.

    

Answer 3

Este exemplo particular, redirecionando cada pacote para / srv, enquanto uma forma de segurança de trabalho, parece singularmente míope e improdutivo de um negócio prospectivo (onde produtivo significa avançar a usabilidade / lucratividade / segurança / etc. do ambiente de trabalho, esses aplicativos estão servindo).

Se você pode viver com o que um pacote de distribuição faz no seu sistema, então você está aproveitando o desenvolvimento e o teste que a equipe que produz o pacote colocou nele e com as atualizações. Se você não pode viver com o que o pacote distro faz ao seu sistema, então encontre outro pacote ou convença / persuadir / assediar o grupo de desenvolvimento a fazer as coisas "do seu jeito" (ou pelo menos facilite fazê-lo "do seu jeito") ) ou encapsulá-lo em uma máquina virtual. Ou coloque o mínimo de esforço necessário para corrigir o problema real / percebido e automatize o gerenciamento de provisionamento e configuração com seu conjunto de ferramentas favorito. Parafraseando Dijkstra, simplicidade e repetibilidade são pré-requisitos para confiabilidade.