Compromisso entre pacotes PHP novos e seguros em servidores de produção?

2

Eu tenho um punhado de servidores de produção rodando o Centos. Meu aplicativo requer uma versão bastante recente do PHP (> 5.2, IIRC). As opções atualmente disponíveis para os usuários do Centos são:

  1. O oficial, pacotes mainstream centos5 / redhat.
    • Prós: mais estável, mais seguro, fácil de instalar - redhat libera regularmente atualizações e alertas de segurança.
    • Contras: os pacotes são antigos (5.1.6?)
  2. Repositórios de terceiros (como o repositório Remi Collet )
    • Prós: Bleeding-edge, fácil de instalar
    • Con: Não confiável - nós costumávamos usar o repositório de utterramblings ... mas o cara tem sido totalmente MIA há mais de um ano. Eu não quero ficar alto e seco assim novamente.
    • Con: Não tão seguro ou estável
  3. Use o repositório de testes do CentOS
    • Prós: Versão bastante recente, fácil de instalar
    • Contras: instável. Eles não chamam isso de "teste" por nada. Não é ideal para um servidor de produção
  4. Construir a partir do código fonte (php.net)
    • Prós: ponta de sangramento
    • Contras: Trabalho intensivo, inseguro, instável

Outras opções:

  1. O Redhat oferece a pilha de aplicativos Redhat que inclui compilações recentes, mas não existe nenhum equivalente centos.
    • Existe algum motivo para as versões do CentOS desses pacotes não existirem? A fonte deve estar disponível, certo?
    • A fonte precisa estar disponível, certo? Quão difícil seria construir os pacotes centos?
  2. Outras distribuições linux
    1. O Debian é comparável em estabilidade ao redhat, mas oferece pacotes antigos
    2. O Ubuntu oferece pacotes mais recentes, mas menos estáveis / seguros
    3. Outros?

Então, no final, minha pergunta é a seguinte: Existe uma boa fonte de pacotes PHP estáveis, seguros e atualizados regularmente ou de fontes lá fora (para QUALQUER distro linux)? De onde você tira sua fonte / binários?

    
por Frank Farmer 04.06.2009 / 03:54

5 respostas

4

Apenas para destacar o lado do Debian:

O lançamento anterior do Debian - Etch (8 de abril de 2007) - veio com o PHP 5.2.0.

O lançamento atual do Debian - Lenny (14 de fevereiro de 2009) - veio com o PHP 5.2.6.

Se houver atualizações importantes nos pacotes durante um ciclo de lançamento, essas versões geralmente estarão disponíveis em backports.org se elas tiverem uma base de usuários perceptível. Uma lista completa dos pacotes de backport disponíveis para Lenny pode ser encontrada aqui . Esta lista é relativamente curta a partir de agora, já que o último lançamento tem apenas alguns meses.

Para ver as versões específicas para PHP e outros pacotes no Debian você pode usar packages.debian.org .

    
por 04.06.2009 / 04:08
3

Eu construo meus próprios RPMs porque não confio em mantenedores de terceiros para ficar na face da Terra.

É um pouco trabalhoso (embora eu apenas construa alguns pacotes), mas sei o que estou recebendo quando termino. Eu uso os arquivos spec do upstream (RHEL / CentOS), mas os modifico para atender às minhas necessidades quando necessário, e os substituo em qualquer versão da fonte que estou procurando (modificando os patches do upstream, quando necessário).

Isso também ajuda meu fluxo de trabalho a não instalar compiladores em sistemas de produção, já que posso enviar meus binários personalizados para eles. Eu também faço isso para fornecer backports para pacotes mais recentes para sistemas operacionais mais antigos quando estou "preso" executando um sistema operacional mais antigo (sem orçamento para atualização, etc.).

Se você conseguir colocar as mãos no SRPMS, criar um pacote não é muito difícil. (É principalmente juntar o ambiente de compilação para um determinado pacote que pode ser uma dor.) Construir um RPM a partir do nada (ou seja, escrever a especificação) é um bom exercício, embora você deva ler alguns specfiles prontos "profissionalmente" primeiro para obter um sentir por isso.

    
por 04.06.2009 / 04:00
1

Eu não posso realmente responder à sua pergunta, mas o que eu costumo fazer é usar a versão oficial do código-fonte e depois compilá-la em um ambiente de desenvolvimento.

Então eu apenas faço um pacote dele usando a ferramenta dpkg (estou usando o debian), mas deve haver uma maneira similar de fazer um pacote com o RedHat como o SO.

Então, você só tem que espalhá-lo em seus servidores.

    
por 04.06.2009 / 04:03
0

Mantemos uma VM em execução para criar pacotes que não estão disponíveis nos repositórios da distribuição. Este é um problema constante quando você está usando uma distro; A solução geralmente é criá-los e manter-se atualizado sobre os avisos de segurança e vazamentos para esses pacotes. Os patches de segurança que os distribuidores distribuem geralmente são fornecidos primeiro por meio das listas de segurança, depois são testados e integrados pelos fornecedores e liberados.

Francamente, contanto que você gpg-key verifique seu código (e assine seus pacotes com sua própria chave), você será tão seguro quanto o código da distro. Você só tem que manter-se atualizado, o que não é inseguro, é apenas trabalho. Se você precisa da funcionalidade, então cabe a você fazer o trabalho. Caso contrário, vá com uma distro que não tenha os problemas básicos que o centOS tem ou que tenha um serviço de compilação oficial ( cough OpenSuSE) ou compre uma licença de um fornecedor que atualize com mais frequência. Você pode trabalhar ou pode pagar. Sua escolha, mas há apenas muito 'livre' em 'cerveja' ...

E saia com alguns cabelos grisalhos e velhos que vão gostar de dizer o quanto era trabalhoso manter uma caixa quando TUDO foi compilado da fonte. ;)

    
por 04.06.2009 / 08:25
0

Outras opções que valem a pena considerar

  • Sun Web Stack - link
  • Zend Core do Zend Community Server - link
por 19.06.2009 / 16:57