# rm-rf.es

En servidores web con cPanel y versiones 11.25.0-RELEASE_42399 y 11.25.0-CURRENT_42399 se ha detectado un problema de configuración que provoca errores de sintaxis en apache con mod_userdir tweak activado. El error que encontraréis en los logs al reiniciar apache es:

UserDir “enable” keyword requires a list of usernames

También veréis que las nuevas cuenta redireccionan siempre a defaultwebpage.cgi El problema se soluciona reconstruyendo la configuración de apache en el servidor, desde línea de comandos ejecutad:

/scripts/rebuildhttpdconf
/scripts/restartsrv_httpd

también:

/scripts/autorepair userdir_enable_fix
/scripts/restartsrv_httpd

O desde WHM:

Service Configuration -> Apache Configuration -> Global Configuration -> Save -> Rebuild Configuration and Restart Apache

Otra forma es actualizar la versión de cPanel a la 11.25.0-CURRENT_42400 o 11.25.0-RELEASE_42400:

/scripts/upcp

Al parecer en algunas versiones del nuevo cPanel 11.25.0-RELEASE se están detectando errores en la instalación del módulo de perl Mail::SPF. Si ejecutamos /scripts/checkperlmodules encontramos los siguientes errores:

CPAN.pm: Going to build J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz

perl-64bit-hack: enabled
# running Build.PL --otherldflags -L/usr/lib64 --config ldflags=-L/usr/lib64 --extralibdir /usr/lib64
Creating new 'MYMETA.yml' with configuration results
Creating new 'Build' script for 'Mail-SPF' version 'v2.7.0'
Prereq 'v5.6' for 'perl' is not supported by Module::Build::Compat
make: *** No targets.  Stop.
 JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz
 /usr/bin/make OTHERLDFLAGS=-L/usr/lib64 LDFLAGS=-L/usr/lib64 EXTRALIBDIR=/usr/lib64 OTHERLDFLAGS=-L/usr/lib64 LDFLAGS=-L/usr/lib64 EXTRALIBDIR=/usr/lib64 -- NOT OK
Running make install
 Make had returned bad status, install seems impossible
perlmod--Install done

Para efectuar la instalación de un modo correcto ejecutad el siguiente comando:

 perl -MCPAN -e "get('Mail::SPF')" && cd /home/.cpan/sources/authors/id/J/JM/JMEHNLE/mail-spf && tar -xzvf Mail-SPF-v2.007.tar.gz && cd Mail-SPF-v2.007 && perl Build.PL && ./Build && ./Build test && ./Build install && /scripts/checkperlmodules --full

Fuente | Foros cPanel

En caso de recibir el siguiente error al acceder all servicio de webmail Roundcube en un servidor con cPanel:

SERVICE CURRENTLY NOT AVAILABLE!
Error No. [0x01F4]

Debéis revisar en primera instancia si habéis desactivado en el servicio MySQL el motor de base de datos INNODB, si aparece lo siguiente en el fichero de configuración my.cnf es que lo habéis desactivado:

skip-innodb

En ese caso, la solución pasa por volver a activar INNODB, o forzar a Roundcube a usar MyISAM, para ello, simplemente forzad la reinstalación del webmail con el siguiente comando:

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

Una entrada rápida que tiene que ver con el sistema de estadísticas Urchin montado de forma independiente en servidores con cPanel/WHM.

Básicamente el problema nos lo encontramos en que sin razón aparente se para el servicio de estadísticas, y en los logs de urchin efectivamente lo verificamos:

mv /usr/local/urchin  /usr/local/stats_urchin

Últimamente encuentro bastante a menudo este error en servidores bajo cPanel. Este error se recibe en la cuenta de correo configurada para recibir todas las alertas de backups, creación de cuentas, etc.

En la mayor parte de casos, el error era provocado por una asignación incorrecta a los permisos de la carpeta public_ftp, por algún motivo tenían permisos 000, siendo los adecuados 750. El error entonces se soluciona reasignando los permisos correctos:

chmod 0750 public_ftp/

Si recibís el error pese a tener bien los permisos de la carpeta public_ftp, revisad los de las demás carpetas de la cuenta con problemas. Desde una actualización reciente, los backups se ejecutan con el usuario de la cuenta en vez de como root, lo que provoca que si una de las carpetas no tiene los permisos suficientes, salte el error.

Parece ver que este bug en Mailman bajo cPanel vuelve a salir a la luz, me suena que desde hace bastante había quedado solucionado (este o uno similar, fue hace más de dos años…).

El error que recibes al tratar de acceder a la administración de una lista de correo Mailman es el siguiente:

Bug in Mailman version 2.1.11.cp3

We’re sorry, we hit a bug!

Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.

Se trata de un fallo en los permisos de la carpeta mailman dentro de las aplicaciones de terceros de cPanel, asignadle los permisos abajo indicados y el fallo quedará solucionado:

chmod 02775 -R /usr/local/cpanel/3rdparty/mailman/

Si por algún casual no surtiera efecto, quizás deberíais tratar de actualizar cPanel:

/scripts/upcp --force

O reinstalar mailman:

/scripts/reinstallmailman --force

Sino, lo mejor es revisar los logs para ver cual es el fallo exacto.

cPHulk es una herramienta integrada en WHM de cPanel mediante la cual se bloquearán las IP’s que intenten acceder a cualquiera de los servicios del servidor mediante fuerza bruta. Para activarla acceded a WHM (puerto 2086 ó 2087), y en la sección “Security Center” lo encontraréis.

Antes de nada, hay que asegurarse de introducir nuestras propias IPs en la lista blanca del servicio (Trusted Hosts List). Si por lo que sea os bloqueara el acceso y no hubierais hecho esto, podéis desbloquearlo accediendo a la consola mysql por SSH y realizando lo siguiente:

mysql

mysql> use cphulkd;

mysql>BACKUP TABLE `brutes` TO '/path/to/backup/directory';

mysql> SELECT * FROM `brutes` WHERE `IP`='xxx.xxx.xxx.xxx';

mysql> DELETE FROM `brutes` WHERE `IP`='xxx.xxx.xxx.xxx';

mysql>quit

Más información interesante.

Es muchísimo más rápido cambiar la clave de acceso al panel de control/ftp de una cuenta en un servidor cPanel desde línea de comandos que accediendo al WHM, para hacerlo desde shell tenéis que ejecutar dos scripts:

/scripts/chpass usuario clave

/scripts/ftpupdate

Nota: La ejecución del segundo script sirve para sincronizar el nuevo password asignado con el servicio FTP, si no lo ejecutamos la clave se cambiará para el panel de control pero no para el servicio FTP.