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.

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.