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

Recentemente tivemos um cliente que decidiu alterar o IP de envio de emails do seu domínio para um dos IPs livres do seu servidor. Este IP nunca antes havia sido utilizado para envio de qualquer tipo de mensagem. Para nossa surpresa, foi detectado que ele estava bloqueado em uma RBL.

Como pode um IP que nunca foi utilizado estar bloqueado por envio de spam? Simplesmente porque algumas destas entidades decidem que é mais fácil bloquear uma faixa inteira de IPs, quando deveriam bloquear apenas os IPs que originaram as mensagens. E ainda pra dar uma de espertinho, resolvem cobrar valores que chegam perto dos 100 (cem) dólares para que a remoção do IP seja feita.

Nossa velha conhecida é a backscatterer.org. Fazem bloqueio por classe de IPs. Me lembro de uma ocasião há alguns anos atrás em que bloquearam toda a classe 72.232, classe que pertence à LayeredTech. Um dos clientes de dedicado resolveu, por conta própria, efetuar o pagamento do valor de U$97,00 (noventa e sete dólares) para ter seu IP imediatamente removido da lista. O IP dele foi removido por um dia, e no dia seguinte estava novamente listado. Motivos para o bloqueio?

“…your system tried to send bounces or autoresponders to claimed but in reality faked senders, or your system tried sender verify callouts against our members near that time.”

“…seu sistema tentou enviar resposta de erro ou auto-respostas para endereços falsos ou tentou realizar uma checagem de remetente de nossos usuários”

Então se ocorre algum erro no envio eu tenho que deixar meus usuários sem saber o que fazer, achando que o envio foi bem sucedido porque meu servidor não pode fornecer retorno de erro? Meus clientes também não podem configurar o próprio email como desejam pois não posso permitir configuração de auto-respostas, caso contrário vou ter que pagar 200 reais pra remover meu IP de uma blacklist.

Eles ainda informam que o bloqueio é apenas temporário. Dentro de “apenas” 4 semanas, se não houver reincidência, o IP será removido da lista automaticamente. Então se eu remover todas as auto-respostas do meu servidor por um mês terei meu servidor livre. ¬¬

Neste caso recente nos deparamos com a Fabelsources. A entidade não cobra valor para remoção do IP, apenas solicitam registro. Porém bloquearam toda a faixa de IPs onde o servidor se encontra. Por este motivo, um IP que nunca tinha sido usado, de repente aparece listado em uma RBL.

As mais utilizadas RBLs são SpamCop e Spamhaus. Elas prestam um serviço sério e muito bom, o próprio cPanel agregou há algum tempo opções na configuração do Exim para utilizá-las no seu servidor apenas selecionando uma checkbox. A SpamHaus também tem um serviço que filtra não apenas os IPs de servidores, mas IPs de usuários que disparam spams, o que nem sempre é bom se seu computador estiver infectado com algum malware enviando mensagens por aí, mas é bastante interessante.

Particularmente gosto muito do serviço da SpamCop por oferecer ferramentas de checagem e denúncia bem simples. Além disso, se seu IP foi bloqueado eles lhe disponibilizam o email que originou o bloqueio, com cabeçalho completo, e alternativa de réplica, caso seu IP foi listado indevidamente. Da mesma forma trabalha a Outblaze.

Não vou me extender muito, até porque não conheço muito o programa, mas com ele também é possível executar alguma tarefa e forçar que um core seja gerado, pra verificação posterior ou caso o processo dê erro e não gere o core nem nenhuma outro informação.

Você pode instalá-lo pelo yum:

yum install gdb

Acesse a pasta onde o arquivo core se encontra. Ao executar o comando gdb no shell você acessará seu “prompt”. Depois basta executar o comando core core.nnnn.

Abaixo temos um exemplo do resultado obtido:

[root@servidor /]# gdb
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".

(gdb) core core.27445
Core was generated by `/usr/bin/php'.
Program terminated with signal 11, Segmentation fault.
[New process 27445]
#0  0x00000031b2a78d80 in ?? ()

(gdb) quit
[root@servidor /]#

Erro gerado pelo PHP que não trazia detalhes nos logs de erro.

Para sair execute o comando quit.