Archivo de la categoría: cPanel

Nuevo Backup de cPanel – FTP se Deshabilita Solo

Backups - Respaldos, cPanel

A veces el nuevo sistema de backups de cpanel se desconecta solo cuando se hace vía ftp.

Es bastante molesto, a veces llega un email que dice que se a desconectado por que a superado cierto número de errores y esos backups los deja en el servidor local, si se a desconectado llega un email que dice que no esta activado el servidor FTP y que se a espesificado no dejar ninguna copia en local:

The exact error was: The store local backup option is disabled and no active transports exist. Please see «Backup Configuration» in WHM for more information

Se puede desactivar por que dura mucho tiempo ejecutandose y la solución sería aumentar ese tiempo la máximo en 

Inicio »
Backup »
Backup Configuration

En la parte de Advanced Settings : Maximum destination timeout 50000 in seconds con eso no debemos de tener problemas, igual si los tenemos no podemos hacer más ya que es valor máximo.

Aunque también podemos cambiarlo vía SSH.

El otro motivo es por que a superado el número de errores, esto lo podemos cambiar en el archivo:

/var/cpanel/backups/config

Aquí cambiamos la opción:

ERRORTHRESHHOLD: 3

Y la podemos dejar en 10, o 20 o algún otro valor más alto, dependiendo de las veces que haya fallado el backup, con 20 a de ir bien.

ERRORTHRESHHOLD: 20

Eso es todo.

Cpanel nuevos sitema de backups desde SSH

Backups - Respaldos, cPanel

Desde que salio el nuevo sistema de backups no son solo más que problemas, es bastante bueno si, ya era hora de que se pudieran guardar varios backups semanales, al estilo de plesk que lo tiene desde siempre, pero tiene un problema este nuevo sistema como que el otro no tenia y es que se para solo y se desactiva el backup ftp si tarda mucho tiempo en ejecutarse, esa es la gran pega.

Pero bueno, no es tan grave, no siempre pasa y si pasa te avisa y si nos molesta podemos ejecutar los dos sistemas de backups a la vez, que si bien parece una tonteria no lo es.

Podemos configurar uno para que a diario a haga backups de las bases de datos y el otro una vez por semana de bases de datos y archivos, tal vez es una de las ventajas de tener dos sistemas de backups.

Ejecutar backup desde ssh

Toda la vida el comando era este:

/script/cpbackup

Y sigue siendo ese, pero solo para el backup legacy, para el nuevo sistema de backups tenemos que ejecutarlo con este otro comando:

/usr/local/cpanel/bin/backup

Deshabilitar PHP.ini en las cuentas de cPanel

cPanel

PHP.ini cuestas cpanel

Si tenemos un hosting pequeño o compartimos servidor con alguien y no queremos que use php.ini ya sea por que tenemos desabilitadas funciones y no queremos que las habilite o por lo que sea, podemos deshabilitar la creación del PHP.ini y solo hacer que use el nuestro:

Editamos el suphp.conf

/opt/suphp/etc/suphp.conf

Buscamos la linea:

[phprc_paths]

Y descomentamos estas 3 opciones:

;application/x-httpd-php=/usr/local/lib/
;application/x-httpd-php4=/usr/local/php4/lib/
;application/x-httpd-php5=/usr/local/lib/

O sea quitamos el punto y como del inicio, cerramos, reiniciamos apache y listo.

Esto lo que hace es decirle al php que solo puede usar el PHP.ini que esta en esas rutas.

Si usamos fastcgi, cgi o DSO lo dicho en este tema no servirá.

Centos Error en EasyApache (cPanel) The server’s system package manager, ‘YUM’, failed

cPanel,

Aveces no va el easyapache en cpanel aunque no es justamente un fallo del cpanel, a veces falla el YUM y easy apache nos lo dice:

The server’s system package manager, ‘YUM’, failed

This is the command that failed:
yum -y install gettext automake19 libstdc++.x86_64 libpng-devel openssl libpng-dev zlib-devel autoconf261 libidn-devel gmake libidn libXpm openssl-devel automake coreutils patch libltdl3-devel libltdl libopenssl0.9.7-static-devel libtool-ltdl-devel libXpm-devel sed libXpm-dev lsof krb5-dev flex glibc-dev expat-dev krb5-devel libstdc++-devel.x64_64 xorg-x11-devel libtool-ltdl libssl-dev pam-devel libopenssl0-devel zlib1-devel expat-devel libopenssl0-dev glibc-devel expat gcc-c++ zlib bison libjpeg-devel libtool-libltdl-devel libtool openssl-dev libopenssl0 libz-devel libjpeg-dev pam-dev fileutils libltdl-devel libopenssl0.9.7-devel e2fsprogs-devel ca_root_nss make libstdc++-dev.x86_64 libX11-devel libstdc++-devel.x86_64 gd cpp xorg-x11-dev gcc ssl-dev autoconf lex
!!
!!
Since EasyApache was unable to resolve it automatically you should:
1) Manually run the failed YUM command (shown above) via SSH
2) See if your particular error is addressed at http://go.cpanel.net/eaerror
3) Resolve the YUM problem manually
4) Re-run EasyApache
!!
!! Please visit http://go.cpanel.net/eaerror for help with this error. !!

!! Restoring original working apache !!

Si intetamos ejecutar el comando anualmente o solo actualizar nos da otro error con más pistas:

yum update

rpmdb: Thread/process 8065/140191218157312 failed: Thread died in Berkeley DB library
error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 – (-30974)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:

Error: rpmdb open failed

Por lo que dice el error hay problemas en la base de datos y no puede sacar la lista de paquetes, la solución borrar la base de datos.

Ejecutamos:

rm /var/lib/rpm/__db*

COn ese comando nos pedira confirmación para el borrado, con este otro NO:

rm -f /var/lib/rpm/__db.[0-9][0-9]*

Pero bueno cada quien lo borra como quiera, al de arriba le añadimos la opción -f y será lo mismo.

Y eso es todo, problema solucionado ya el YUM funciona y el EasyApache también.

Les dejo nuestra ultima entrada sobre un script que monitorea el CPU la memoria, el swapt además de los paquetes entrantes y salientes. Si algún valor es mayor o igual al que hemos puesto nos enviará un email para que revisemos el servidor.

Pueden ver toda la entrada y el script en este enlace Script para monitorear el servidor

Error al exportar bases de datos comprimidas en PHPmyadmin WHM/cPanel

cPanel,

Es un error bastante común si tenemos bases de datos grandes y las intentamos exportar en comprimidas, también es verdad que ocurre el problema con mayor frecuencia cuando intentamos exportar en zip, normalmente vemos este error:

File not found /cpsess2414676250/3rdparty/phpMyAdmin/export.php

Viendo los logs de cpanel ( no los de /etc/httpd que son los logs de las webs ) vemos que hay un problema de memoria:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 109580528 bytes) in /usr/local/cpanel/base/3rdparty/phpMyAdmin/libraries/zip.lib.php on line 132

La solución es subir la memoria que puede usar phpmyadmin o bien dejar de usar zip por que consume más.

La memoria la podemos subir en /usr/local/cpanel/3rdparty/php/53/etc/phpmyadmin/php.ini

O si no toma los valores, en este otro archivo: /usr/local/cpanel/3rdparty/php/53/etc/php.ini

No se por que antes en cpanel 11.36 funcionaba en el php.ini de la carpeta phpmyadmin pero luego de la actualización a cpanel 11.38.x ya solo me funciona en la segunda ruta que deje.

Ahora bien cuanto ?

Eso dependerá del error, a mi me dice que me hacen falta poco más de 100MB, así que subo 100, si nos pide mucho es mejor dejar de usar zip por que podemos tener problemas.

Pero bueno si editamos el php.ini que deje arriba tenemos que ejcutar:

 /usr/local/cpanel/bin/install_php_inis

Va eso es todo 🙂

WHM / cPanel: ssh_exchange_identification: Connection closed by remote host

cPanel,

Pues eso hoy otra vez he tenido este error en cpanel, alguna que otra vez me lo he encontrado si no accedo durante un largo periodo al servidor, el error como dice el título:

ssh_exchange_identification: Connection closed by remote host

No se a que es debido, pero si entramos a WHM -> restar services y reiniciamos el SSH problema resualto, esto lo digo por si a alguien le pasa.

Como saben este blog lo he creado para dejar aquí soluciones a errores o bien errores pendientes de solución a los que no tengo tiempo para revisarlo al instante, así que aquí esta el problema, si alguien lee esto y sabe lo que pasa, se le agradece que deje un comentario con la solución o mande un email a yo(arroba)skamasle(punto)com

En todo caso lo intentaré mirar a fondo cuando tenga un rato, igual no es nada grave y casi nunca pasa 🙁

mod_fcgid: process /usr/local/cpanel/cgi-sys/php5 exit(communication error), get unexpected signal 7

cPanel, PHP, Servidor Web, ,

Administro varios servidores con una configuración muy similar, 8 vps en la misma empresa todos con APC pero solo en uno tengo ese error

Error en cPanel mod_fcgid: exit(communication error), get unexpected signal 7

La configuración en la mayoría de VPS:

PHP 5.3.25 o php 5.4 algunos con IONcube y otros sin el, algunos con ZEND y otros sin el, todos con fcgi y APC.

El caso curioso es que solo un servidor tienen el error descrito anteriormente, el cual he deducido que pasa por tener APC, al quitar APC el error desaparece.

El error no es solo un get unexpected signal 7 en el error log si no que también provoca un error 500 en las páginas web del servidor.

Bien según las pruebas que hecho el error desaparece al quitar APC, al cambiar a PHP 5.4 y poner xcache persiste el error pero aparece en ocasiones muy raras.

Así que viendo el error: mod_fcgid: exit(communication error), get unexpected signal 7 puedo ver que pasa con cualquier optcode: apc o xcache.

cPanel
PHP 5.4 ( muy de vez en cuando )
PHP 5.3.25
Con o sin ZEND o ION
Pasa en un solo VPS con cpanel con unas 25 webs.
Pasa en un VPS de 8 en la misma empresa:

4 gigas de RAM
CPU 4x Xeon(R) CPU E5-2660 0 @ 2.20GHz
SSD raid10
Loadaverage entre 0.80 y 2 según la hora y cantidad de tráfico.
Ram consumida no sobre pasa los 3 gigas.

En fin, con esto digo que con php 5.4 y xcache se reduce la cantidad de veces que sucede, aunque es pronto decirlo los cambios en el server los he hecho hace varias horas y aún no llegamos a hora pico, pero lo que si puedo decir es que si tienen el mismo problema, el mismo mensaje en los logs y errores 500 en la web desabiliten APC o xCache.

Yo volveré a escribir cuando pase la hora pico hoy por la noche que es cuando más se ve el error y veremos si PHP 5.4 y xcache lo solucionan si es así probaré con APC y si tampoco recae en el error atribuiré el fallo a php 5.3.25, algún modulo dañado o algo por el estilo que ya me a pasado en otras ocasiones y reinstalandolo me a solucionado otros fallos similares y cargas altas sin motivo aparente.

Lo otro sería que el VPS este en un nodo con algún problemilla con la RAM, se quede sin RAM o algo parecido, aunque la empresa en la que están los VPS siempre tienen mucha RAM libre y no hay overselling en los nodos.