Instalar pacotes que devem ser auto-compilados no servidor CentOS é uma prática ruim?

Question

Eu tenho um servidor CentOS 6 que está em produção e atualmente hospeda alguns sites. Agora devo instalar o Redmine, que roda no Ruby. O repositório remi / ephel me fornece o Ruby 1.8.7, mas gostaria de usar a versão mais recente (1.9). O problema é que eu deveria compilá-lo e instalá-lo sozinho baixando as fontes e todos os outros pacotes dev necessários para fazer as gemas funcionarem, por exemplo, mysql-devel para o adaptador mysql2. É uma prática ruim instalar pacotes dev em uma máquina de produção? A segurança pode ser comprometida? Devo ficar com os pacotes padrão fornecidos pelos repositórios?

    

Answer 1

Seria melhor ficar no sistema de gerenciamento de pacotes do fornecedor.

Dito isto, se você precisar de uma versão mais recente de um software, pelo menos tente usar pacotes em vez de instalar via make; make build .

Para o Ruby 1.9.3, alguém criou um arquivo de especificação:

link

Você deve ser capaz de usar isso para fazer RPMs para o Ruby 1.9.3 e instalar dessa maneira. Se nada mais, facilitará as atualizações (por exemplo, rpm -Uhv ruby-1.9.3 em vez de make; make install ). Você ainda será responsável por gerar novos pacotes Ruby 1.9 para você mesmo, pois as atualizações serão lançadas, é claro.

Em geral, há uma hierarquia de preferência para instalar o software.

1. Software fornecido pelos repositórios do fornecedor. Nesse caso, você usará o sistema de gerenciamento amigável e simpático para instalar e atualizar pacotes mantidos pelo fornecedor (por exemplo, yum, apt-get).

2. Software fornecido por meio de repositórios de terceiros. Deve haver uma mini-hierarquia aqui, onde você tem repositórios altamente respeitáveis (por exemplo, EPEL para CentOS) para aqueles que são menos (por exemplo, alguns PPA do cara no Ubuntu; eu não estou dizendo que as pessoas estão tentando instalar trojans através PPAs, mais que isso normalmente é algo fornecido por alguém que pode não estar mantendo os pacotes, ou que pode não estar procurando por problemas de compatibilidade).

3. Software instalado por meio de pacotes que você mesmo cria. É aqui que o arquivo de especificação mencionado anteriormente irá cair. Você envolverá o processo de compilação no sistema de pacotes da sua distribuição, para que as instalações e atualizações sejam fáceis (por exemplo, rpm -e , em vez de procurar em / usr / local por arquivos com nomes criptografados). Você assumirá a responsabilidade de criar novos pacotes à medida que as atualizações surgirem.

4. Software instalado sem gerenciamento de pacotes. Este é o clássico wget software.tgz ; tar xzvf software.tgz ; cd software ; ./configure ; make ; make install . Geralmente, você irá vomitar arquivos por todo o / usr / local; pode ser difícil obter informações sobre o software (ou seja, você pode simplesmente executar rpm -q ou rpm -ql ) e será difícil removê-lo. Este deve ser um último recurso.

Acho que algo em torno de 3 é o método rvm mencionado por Alex. Não está realmente nos pacotes do sistema, mas existe uma estrutura em torno da instalação do Ruby. Com Ruby, em um contexto RVM, as gemas associadas a esse Ruby específico serão instaladas via gem install e gerenciadas em uma estrutura específica, também, embora não seja o sistema de gerenciamento de pacotes do SO.

    

Answer 2

A menos que você tenha a necessidade de usar a versão posterior, então, manter a versão 'oficial' é geralmente considerado uma 'coisa boa'. Os patches de segurança são portados para os pacotes oficiais e você pode aproveitar a atualização do gerenciador de pacotes e a resolução de dependências.

Uma vez que você pisa fora das coisas acima pode ficar bastante confuso.

    

Answer 3

Esta é uma questão de opinião, no entanto, eu nunca instalei pacotes diretamente do código-fonte em uma máquina de produção. Isso torna muito mais difícil a aplicação de atualizações de segurança no caminho. Estou paranóico com um possível comprometimento no caminho.

Minha tendência é usar pacotes embutidos sempre que possível e rastrear RPMs adicionais de fontes externas, se necessário. Se eu não conseguir encontrar uma versão que eu precise, eu mesmo construo o pacote em um RPM em uma caixa de desenvolvimento e implantei esse novo RPM para produção. Não é elegante, mas funcional.

    

Answer 4

Eu sempre uso o RVM para criar e gerenciar ambientes Ruby, o RVM parece ser a maneira preferida de instalar o Ruby para muitos Rubyists. Pacotes fornecidos pelos mantenedores Debian e CentOS simplesmente não estão atualizados. Além disso, o RVM é capaz de criar ambientes virtuais isolados como o virtualenv do Python.