Como lidar com atualizações freqüentes e constantes de versões PHP / MySQL

Question

O problema:

Eu sei que muitas pessoas não estão tão felizes com as mudanças frequentes nas versões. Especialmente quando a última versão do PHP ou MySQL que você está preso não está mais disponível em seu repositório (na minha situação é REMI) mas você tem que instalar um novo servidor com alguns pacotes PHP / MySQL de uma versão um pouco mais baixa ( anterior / anterior), a partir de então disponível no repositório.

Na maioria das vezes estamos usando a versão mais recente do Apache, PHP, MySQL típico no topo do sistema operacional Centos 5.8 GNU / Linux x86_64.

Mas agora é preciso muito tempo para a nossa equipe de QA testar todos os nossos projetos para compatibilidade com as versões mais recentes, que são tão rápidas que, no momento, recebemos luz verde da equipe de QA para atualizar o PHP e / ou MySQL e / ou instalar um novo servidor com essas versões específicas, descobrimos que ele já se tornou obsoleto e agora é substituído com uma versão mais recente.

Isso é especialmente especial quando o McAfee PCI Compliance diz que nossos sites usam uma versão potencialmente perigosa do PHP e nos obrigam a atualizar todo o servidor com a versão mais recente do PHP.

No momento atual, nosso ambiente de trabalho padrão consiste em:

SO:

CentOS release 5.8 (Final) Linux censored.example.com 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Apache:

Server version: Apache/2.2.3 Server built: Feb 23 2012 21:16:56

PHP:

PHP 5.3.13 (cli) (built: May 9 2012 16:20:57) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator

MySQL:

mysql Ver 14.14 Distrib 5.5.23, for Linux (x86_64) using readline 5.1

Soluções possíveis:

• Repositório local / espelho de versões antigas Basta criar um instantâneo de repositório personalizado dos últimos pacotes instalados para que possamos instalar / instalar novos servidores com os mesmos pacotes, mesmo que eles não sejam mais suportados antes de estarmos prontos para seguir em frente. Prós & Contras: Fácil instalação, usando os mesmos comandos do YUM, mas não vai quebrar dependências com outros pacotes do sistema que podem ser atualizados? Existem pedras aquáticas escondidas dessa maneira?

• Compile da origem Esqueça o YUM e o RPM e volte aos bons tempos com o compilador GCC e infernos de dependência usando versões compiladas estaticamente. Prós & Contras: Não depende mais das versões do repositório (ou ainda de alguma forma indireta?), Mas terá que obter todo o código-fonte manualmente e ter algum tipo de gerenciamento dessas coisas.

• Crie e use uma imagem personalizada Basta compilar e configurar uma vez um servidor adequado, tirar seu instantâneo (como máquina virtual ou sua imagem iso HD física) e apenas expandir sua imagem no novo servidor físico ou importar a máquina virtual para o host de visualização. Prós & Contras: Certamente não há mais dores de cabeça com alterações de versão e dependências, mas como é confiável? Sim, é uma paz de bolo se estamos falando de máquinas virtuais, mas algum tempo temos que implantar projetos em máquinas físicas, mas não temos nada além de acesso SSH.

• Aceitar atualizações se for apenas alteração secundária de versão Não se preocupe muito com correções de bugs e alterações de versão devido a problemas de segurança críticos corrigidos que aumentam o número menor. Basta atualizar para eles o mais rápido possível. Prós & Contras: Certamente, o McAfee PCI Compliance ficará satisfeito e, portanto, fará nossos clientes, mas não é perigoso? E se fosse uma pequena alteração nos valores de configuração padrão do PHP que não foram substituídos? Não será possível um desastre total?

Alguma sugestão, queridos especialistas?

    

Answer 1

Ok - então vamos reduzir isso:

O principal problema que você está enfrentando é que você precisa executar uma versão mais nova do PHP / MySQL, mas quando a sua equipe de QA testou o software no novo sistema, essa versão está desatualizada.

Isso não é uma falha do seu time; isso é uma falha da equipe de QA.

Sua equipe de controle de qualidade deve ter casos de teste automatizados. Seus desenvolvedores devem fornecer módulos de teste à medida que avançam. Por exemplo:

• O desenvolvedor cria sistema de faturamento proporcional
• O Developer fornece uma interface de teste para pro-rating (ou seja, aceita todos os detalhes necessários para testar o sistema, mas na verdade não gera uma fatura. Ou talvez funcione, mas em um sistema de teste).
A equipe de QA da QI planeja uma série de testes para executar a rotina. Qual é a entrada e qual é o resultado correto ? Por exemplo. $ 50 / mês rateado por meio mês == $ 25.

Este último passo deve ser totalmente automatizado. Deve demorar alguns minutos ou horas (dependendo da complexidade do software ou de quantos testes existem) para determinar quaisquer erros. E.G.

• O PHP altera sua matemática de ponto flutuante do arredondamento normal para o cieling (sempre arredondar para cima)
• Teste caso de pro-rating em US $ 5 / mês por meio mês
• Resposta correta: $ 2,50, mas o caso de teste retorna $ 3. Falha automática.

Agora, sei que nada disso realmente responde à sua pergunta. Portanto, se sua equipe de controle de qualidade não puder ser corrigida, quais são nossas outras opções:

Não há uma resposta correta para isso. Pessoalmente, o que fazemos com nosso software é sua última opção - aceitamos todos os service packs e atualizações para nossos ambientes de tempo de execução, mas não mudamos as versões sem uma análise completa e completa de controle de qualidade. Embora o software que usamos em nossos tempos de execução (que é MSSQL e outro back-end, não PHP) só libere novas versões a cada 18 meses a 2 anos, com atualizações e service packs entre eles, então há muito tempo entre lançamentos principais. / p>

Após testes de controle de qualidade em nossos sistemas de preparo, implementamos a atualização em nossos sistemas de dogfood primeiro. Se não encontrarmos problemas importantes, lançamos as atualizações de tempo de execução em nossos sistemas hospedados. Se ainda não tivermos problemas importantes, lançamos avisos para nossos clientes auto-hospedados para que eles possam instalar as atualizações, se quiserem.

Pessoalmente eu me encolho toda vez que recebo uma máquina virtual pré-empacotada. Mesmo que seja totalmente atualizado (eles nunca são, como você apontou) é algo que eu preciso trabalhar na integração em nossa rede. E às vezes eles vêm com sistemas operacionais ou tempos de execução horrivelmente desatualizados.

    

Answer 2

Você declarou sua pergunta da seguinte forma:

1. Periodicamente, falhas críticas de segurança são encontradas nos componentes da sua pilha de servidores, incluindo PHP e MySQL.

2. Quando essas falhas são descobertas, os desenvolvedores de PHP e MySQL lançam novas versões. No interesse da segurança, versões antigas / inseguras podem não estar mais disponíveis nos repositórios que você usa.

3. Seu aplicativo da web deve ser compatível com PCI. Quando você usa versões antigas e inseguras do PHP e do MySQL, seu aplicativo da Web falha nas varreduras de segurança do PCI que devem passar para obter conformidade.

4. Você nunca é capaz de usar a versão atual com todas as correções de segurança, porque sua equipe de QA leva "muito tempo" (aparentemente meses) para dar luz verde para usar cada versão de segurança do PHP e MySQL. Na verdade, eles demoram tanto para aprovar as atualizações de segurança que você nunca foi totalmente corrigido.

Você então explora várias possibilidades para facilitar a instalação de versões antigas do PHP e do MySQL com vulnerabilidades conhecidas. No entanto, os itens # 1-3 acima não são negociáveis .

Item # 4, por outro lado, é negociável. Ergo, a equipe de QA da sua empresa é o problema. Atualizações de segurança incrementando o número da versão em 0.0.1 (por exemplo, do PHP v5.4.2 para v5.4.3) são muito improváveis interromper sua aplicação.

Você deve instalar a nova versão em seu ambiente de teste, executar seus testes automatizados, realizar testes manuais mínimos e, em seguida, transferi-los. Como acontece com qualquer mudança, você precisa ter um plano de retorno em caso de problemas inesperados, mas ... vamos lá, você está falando sobre patches para explorações conhecidas! O risco de segurança que você corre por não patches (que, a propósito, inclui falha garantida de suas verificações de conformidade com PCI) longe excede qualquer risco que você corre por patch.

Atualizações de recursos (por exemplo, do PHP v5.3.x para v5.4.x) podem exigir testes mais completos e por um bom motivo: por exemplo, a versão 5.4.0 removeu vários recursos herdados e alguns aplicativos antigos podem precisar ser atualizado em conformidade. Felizmente, você faz meses para testar esses lançamentos. É exatamente por isso que as atualizações de segurança são fornecidas simultaneamente para a versão atual e a anterior.

Parece bastante que sua equipe de controle de qualidade está confundindo atualizações de segurança menores com atualizações reais de recursos.

Resumo executivo:

1. As atualizações Segurança que não adicionam / removem recursos devem ser aplicadas imediatamente com o mínimo de testes. É inaceitável que os processos da sua empresa submetam pequenas atualizações de segurança a atrasos burocráticos, a menos que problemas reais sejam encontrados nos testes iniciais.
2. Quando se trata de versões de recursos que têm uma probabilidade muito maior de quebrar aplicativos legados, sua equipe de controle de qualidade pode continuar aproveitando seu tempo.