Uma verificação primária dos logs do kernel confirmaram load elevado, com consumo de processador ou memória em 100% momentos antes do reboot.

A princípio achamos que foi causado por algum tipo de aumento na carga do Apache junto com o PHP. Todo dia primeiro e quinze do mês nosso relatório de checagem é executado no servidor e além das checagem ele faz também a atualização do kernel e demais componentes através do yum. Consideramos a hipótese de que algum componente tinha sido atualizado e passou a causar a instabilidade, já que todos os servidores haviam mostrado a instabilidade aproximadamente no mesmo horário.

Um acompanhamento foi feito nestes servidores durante a manhã e derrubando a primeira hipótese, não houve instabilidade em nenhuma das máquinas afetadas. Partindo ainda do horário muito próximo em todas as máquinas e sendo este horário próximo à execução do relatório executamos testes nas funções do relatório separadamente. Os testes acusaram a causa da instabilidade nos servidores e confirmamos.

Há duas semanas implementamos uma série de testes novos para garantir a checagem e integridade dos discos do servidor, onde os testes nos informam o tempo de vida do disco, verifica badblocks, status da “saúde” dos discos, desempenho, entre outros. Por algum motivo estes procedimentos, que em nosso ambiente de testes foram bem sucedidos, entraram em loop chamando a si mesmos dentro do próprio processo o que acabou por consumir memória e processamento do hardware.

Não foram afetados todos os servidores, a maioria conseguiu executar os testes normalmente sem qualquer erro ou instabilidade no sistema, porém ainda não identificamos quais as diferenças entre os dois grupos de servidor que podem ter causado tal erro, todos rodam no mesmo SO, na mesma versão, mesmo kernel.

Tais funcionalidades foram removidas do script, serão reavaliadas e passarão por novos testes. O script já foi atualizado em todos os servidores, afetados ou não.

Peço desculpas em nome da equipe a todos os clientes e colaboradores afetados pelo nosso erro.

Thiago Voltolini

WideCom Brasil

Nosso colaborador Ricardo Lobo da Seu Site Imobiliário nos deu o alerta.

Ele aparece ao declarar uma variável com o valor 2.2250738585072011e-308 ou próximo que, segundo o autor do bug report, é o maior número ponto flutuante.
Ao declarar atribuir o valor a uma variável o script entra em um loop e pode permanecer em processamento até o tempo de timeout ser atingido ou pode vir a consumir todo o processamento do servidor, o que é o ponto preocupante.

No dia 30 de dezembro o bug foi reportado ao PHP, no dia 06 de janeiro uma nova atualização do PHP para correção do bug foi lançada e ontem, dia 10, a correção foi confirmada pelos desenvolvedores.
No dia 06 foram lançadas as versões 5.2.17 e 5.3.5 e um script que realiza o teste, indicando se o servidor apresenta ou não o bug, na página de notícias do PHP

Todos os servidores gerenciados pela WideCom Brasil foram testados. Se você não recebeu nenhuma notificação significa que seu servidor não apresentou erro no teste e não apresenta o bug.

Em nossos testes nenhum servidor com PHP na versão 5.2 apresentou o problema, apenas servidores rodando a versão 5.3.x equipados com processadores Intel 32bits.

[Update]

Nos servidores WHM/cPanel as novas versões do PHP ainda não estão disponíveis mas todas as versões 5.x do PHP disponibilizadas no EasyApache foram atualizadas com um patch de correção do bug.
Se seu servidor apresenta o problema, basta compilar sua build novamente, sem necessidade de nenhuma atualização.

Forum cPanel

Maiores detalhes nos links abaixo:
Notícias PHP
PHP :: Bug
Exploring Binary

Com acesso apenas a revenda do cliente temos que gerar os backups completos, domínio por domínio. Quando a revenda é pequena não há muita dificuldade, mas e se a revenda tiver, digamos, 200 contas?

Você poderia perder um dia inteiro de trabalho para acessar o cpanel de cada uma das contas, gerar o backup, preencher o formulário de envio 200 vezes e conferir se todos os backups chegaram no servidor de destino. No processo ainda existem as contas suspensas, que precisam ser liberadas para possibilitar o envio do backup para o novo servidor.

Dessa necessidade surgiu o script de transferência automatizada de revenda WHM/cPanel. Uma transferência de 200 domínios agendada para levar pelo menos 24 horas foi realizada em apenas 4 horas.
A partir desse script simples, iniciamos o trabalho de uma ferramenta mais completa.

Este script faz o seguinte:

1. Transfere todos os domínios de uma revenda em um servidor externo (origem) para seu servidor (destino). (Você precisa ser o root para rodá-lo)
2. Libera os domínios suspensos na revenda antes de iniciar os backups.
3. Envia todos os backups para uma conta FTP criada no servidor de destino.
4. Restaura todos os backups quando os mesmos chegarem ao servidor de destino.
5. Suspende os usuários novamente nos servidores de origem e destino.

O script ainda possui os parâmetros –backup e –restore, caso você queira rodar apenas uma parte do script.

O script foi concluído e disponibilizado comercialmente em nossa central: Transferência automatizada de revenda WHM/cPanel

A idéia do script partiu da necessidade de automatizar tarefas comuns à todos os servidores.

Começou com uma lista de procedimentos que nossa equipe armazenou ao longo dos anos de trabalho e que até então era executada manualmente para fazer instalações, limpezas e verificações em geral no servidor.

Com o surgimento do serviço de gerenciamento mensal, novas possibilidades foram vistas para o script que hoje conta com 33 funções, verificação automática de updates e execução de rotinas previamente configuradas, por exemplo a atualização do Exim feita semana passada.

Ele é responsável pela execução quinzenal dos relatórios, verificação de exploits no servidor, atualização de kernel, entre outros.
Atualmente o script roda apenas em servidores gerenciados, verificando o status do cadastro de cada servidor na base do nosso WHMCS.

Suas últimas atualizações foram:

• –hdtest – Testa o I/O do disco
• –watchapache – Monitora os acessos ao Apache
• –fixweekly – Corrige a data do backup weekly para o domingo
• Atualização do RKHunter no relatório, compatível com a nova versão

Está em desenvolvimento um plugin para o WHM, que vai agregar todas as funcionalidades do script ao painel de controle, e o usuário poderá utilizá-lo diretamente no painel, sem precisar de acesso ao shell do servidor.

Novidades pra 2011.

Uma vulnerabilidade foi encontrada no Exim, o MTA usado pelo cPanel. Um patch de correção já foi aplicado e a versão corrigida liberada para atualização.

De acordo com notícia divulgada pelo desenvolvedora o exploit é um buffer overflow que explora capacidades relacionadas a alteração das configurações em tempo de execução. Isso permite que comandos sejam executados com o usuário que executa o Exim. O problema é que o usuário retém permissões de root quando executado com os parâmetros -D ou -C.

Para solucionar o problema, a nova versão disponibilizada trava os arquivos de configuração em /etc/exim* e também impede que o Exim seja executado com as flags -D e -C

Para conferir a versão atual em seu servidor, utilize o comando:
rpm -qa exim

Todos os servidores WHM/cPanel gerenciados pela WidecomBrasil já foram atualizados com a nova versão do MTA (Exim 4.69-25).

Fonte: Blog Cpanel

Segue o log de mudanças:

• Corrigido URL’s no relatório do Server Check para cPanel se os Security Tokens estiverem habilitados na versão v11.25+.
• Adicionada explicação ipv6 de que a informação é determinada a partir da saída do ifconfig and exibidos os endereços ipv6 encontrados.
• Adicionada a habilidade de utilizar declarações Include nos arquivos csf.deny e csf.allow. Veja o readme.txt para informações e restrições.