Error de Plesk con SSL en /var/log/sw-cp-server/error_log

El error que sale continuamente en el log de Plesk /var/log/sw-cp-server/error_log es el siguiente : Error: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure

La solución parece ser un bug de Plesk , aunque estuve googleando un buen rato, no encontré mucho sobre el tema, el caso es que estaba obteniendo este error en /var/log/sw-cp-server/error_log, además aparecía cada 6 minutos por lo que en 3 días con el servidor funcionando, ya tenía dos historicos del archivo comprimidos en .gz.

Finalmente, buscando en la ayuda de Plesk, encontré la forma de que no volviera a aparecer más, la verdad es que no tiene mucha complicación, lo único que tenemos que hacer es, generar un certificado, dependiendo de las necesidades de cada uno, se puede comprar o autogenerarlo, os hago un copy/paste de la solución en la ayuda de Plesk .

En caso de que necesite generar un certificado autofirmado, siga este procedimiento:

1. Vaya a Inicio > Seguridad > Certificados SSL. Se le mostrará una lista de los certificados SSL existentes en su repositorio.
2. Haga clic en Añadir Certificado SSL.
3. Indique las propiedades del certificado:
* Nombre del certificado. Este le ayudará a identificar este certificado en el repositorio.
* Nivel de Encriptación. Escoja el nivel de encriptación para su certificado SSL. Le recomendamos que escoja un valor superior a 1024 bits.
* Indique su ubicación y el nombre de la organización. Los valores introducidos no deben exceder los 64 símbolos permitidos.
* indique el nombre del servidor para el que ha adquirido el certificado SSL. Por ejemplo: your-domain.com
* Introduzca su dirección de email.
4. Haga clic en el botón Autofirmado. Se generará su certificado y se almacenará en el repositorio.

Como luchar contra el SPAM en Plesk con Qmail

Primero compruebe que todos los dominios tienen la opción ‘Correo para usuario inexistente’ definida a ‘Rechazar’ pero no a reenviar. Puede cambiar este ajuste para todos los dominios usando “Operaciones en Grupo” en la página “Dominios” del CP de Parallels Plesk Panel. La prestación ‘Rechazar correo para usuario inexistente’ está disponible a partir de Parallels Plesk Panel 7.5.3.

Asimismo, compruebe que todas las redes e IPs incluidas en la lista blanca son de su confianza.

Compruebe cuántos mensajes hay en la cola de Qmail con:

# /var/qmail/bin/qmail-qstat
messages in queue: 27645
messages in queue but not yet preprocessed: 82

Si la cola tiene demasiados mensajes, intente descubrir la procedencia del SPAM.

Si el correo está siendo enviado por un usuario autorizado pero no desde el script PHP, puede ejecutar el comando que aparece a continuación para descubrir el usuario que envió la mayoría de mensajes (desde Plesk 8). Tenga en cuenta que es necesario tener activada la opción ‘Autorización SMTP’ en el servidor para poder ver estos registros:

# cat /usr/local/psa/var/log/maillog |grep -I smtp_auth |grep -I user |awk ‘{print $11}’ |sort |uniq -c |sort -n

La ruta a ‘maillog’ puede cambiar en función del SO que esté usando.

El próximo paso es la utilidad `qmail-qread`, que puede usarse para leer las cabeceras de los mensajes:

# /var/qmail/bin/qmail-qread
18 Jul 2005 15:03:07 GMT #2996948 9073 bouncing
done remote user1@domain1.com
done remote user2@domain2.com
done remote user3@domain3.com
….

Esta muestra los remitentes y destinatarios de los mensajes. Si el mensaje incluye demasiados destinatarios, probablemente se tratará de SPAM. Ahora intente encontrar este mensaje en la cola por su ID #2996948:

# find /var/qmail/queue/mess/ -name 2996948

examine el mensaje y encuentre la primera línea “Recibido” para saber desde dónde se envió la primera vez, por ejemplo, si encuentra:

Received: (qmail 19514 invoked by uid 10003); 13 Sep 2005 17:48:22 +0700

Significa que este mensaje fue enviado a través de algún CGI por el usuario con UID 10003. Usando este UID puede encontrar el dominio correspondiente:

# grep 10003 /etc/passwd 

Si la línea ‘Recibido’ contiene un UID de un usuario ‘apache’ (por ejemplo “invoked by uid 48″) – significa que el SPAM fue enviado a través de algún script PHP. En este caso, puede intentar conocer el spammer usando la información de los correos spam (direcciones de/para, asunto o cualquier otro dato). Generalmente es muy difícil descubrir la fuente de SPAM. Si está completamente seguro de que en este momento hay algún script enviando SPAM (la cola crece rápidamente sin motivo aparente), puede usar el siguiente script para saber qué scripts PHP se están ejecutando en este momento:

# lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk ‘ { if(!str) { str=$1 } else { str=str”,”$1}}END{print str}’` | grep vhosts | grep php

También puede aplicar el artículo 1711, que describe el procedimiento para conocer desde qué dominios se está enviando el correo a través de scripts PHP.

Líneas recibidas como:

Received: (qmail 19622 invoked from network); 13 Sep 2005 17:52:36 +0700
Received: from external_domain.com (192.168.0.1)

significan que el mensaje ha sido aceptado y entregado a través de SMTP y que el remitente es un usuario de correo autorizado.

Error en Plesk: Espacio insuficiente en /migration del servidor fuente de la migración

Vaya tela…. este error persiste y persiste en las versiones de Plesk …

Síntomas
La migración de un dominio Parallels Plesk Panel finaliza sin ningún error. De todas formas, el dominio no presenta ningún archivo html.

Causa

La causa de este problema es una cantidad de espacio de disco insuficiente en el directorio /migration del servidor fuente.

El Administrador de Migraciones de Parallels Plesk Panel carga el Agente de Migración al servidor fuente. El Agente de Migración es un script perl que realiza el volcado de los datos, usando /migration en el servidor fuente como directorio temporal para la migración. Si el directorio /migration ya no dispone de más espacio o se encuentra en una partición de tamaño limitado, los datos no se volcan debido a esta insuficiencia de espacio de disco.

Puede comprobar el tamaño de la partición ejecutando el comando «df -h». Por ejemplo:

~# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 950M 254M 649M 29% / <- la partición es demasiado pequeña

/dev/sda2 4.7G 1.6G 3.1G 35% /usr

/dev/sda3 100G 60G 41G 60% /var

/dev/sda4 4.7G 5.5M 4.7G 1% /home

~#

La partición “/” donde se encuentra el directorio /migration es demasiado pequeña. Tar no puede volcar los datos debido a la insuficiencia de espacio de disco.

Resolución

Le recomendamos liberar el directorio /migration en el servidor fuente. También puede transferir el directorio a una partición de mayor capacidad.

Por ejemplo, creemos el directorio de migración en otra partición que tenga espacio suficiente:

source~# mkdir /home/migration

Entonces creeamos un vínculo simbólico:

source~# rm -rf /migration

source~# ln -s /home/migration/ /migration

Y yasta amigos a migrar dominios a saco de servidor a servidor….

Problema con la libreta de direcciones en Horde al actualizar a Plesk a la versión 9.5.1

El problema que os comento me ha pasado con Horde (webmail por defecto en Plesk) por actualizar Plesk de la versión 9.3.0 a 9.5.1.

El problema estaba bien claro, al intentar acceder a la libreta de direcciones que Horde guarda, Horde daba el siguiente error:

DBError: field

y el log de Horde daba el siguiente error:

error log : Apr 20 18:05:16 HORDE [error] [kronolith] DB Error: no such  field:
SELECT event_id, event_uid, event_description, event_location,  event_private, event_status,
event_attendees, event_keywords,  event_title, event_category, event_recurcount, event_recurtype,
 event_recurenddate, event_recurinterval, event_recurdays, event_start,  event_end, event_alarm,
event_modified, event_exceptions,  event_creator_id FROM kronolith_events WHERE calendar_id =  'email@domain.com'
AND event_alarm > 0 AND ((event_end >=  '2010-04-20 00:00:00') OR (event_recurenddate >=
'2010-04-20  00:00:00' AND event_recurtype <> 0))
[nativecode=1054 ** Unknown  column 'event_private' in 'field list'] [pid 26294 on line 323 of  "/usr/share/psa-horde/kronolith/lib/Driver/sql.php"]
 Apr 20 18:05:16 HORDE [error] [turba] DB Error: no such field: SELECT  object_id, owner_id,
 object_type, object_members, object_uid,  object_firstname, object_lastname, object_middlenames,
 object_nameprefix, object_namesuffix, object_alias, object_bday,  object_homestreet,
object_homepob, object_homecity, object_homeprovince,  object_homepostalcode, object_homecountry,
 object_workstreet,  object_workpob, object_workcity, object_workprovince,  object_workpostalcode,
object_workcountry, object_tz, object_email,  object_homephone, object_workphone, object_cellphone,
object_fax,  object_pager, object_title, object_role, object_company,  object_category, object_notes,
object_url, object_freebusyurl,  object_pgppublickey, object_smimepublickey FROM turba_objects WHERE
 (object_type = 'Group' AND owner_id = 'email@domain.com')  [nativecode=1054 ** Unknown column
'object_firstname' in 'field list']  [pid 26294 on line 173 of  "/usr/share/psa-horde/turba/lib/Driver/sql.php"]

Vale pues despues de tantos errores aqui os digo la solución que mas o menos daban en los foros de parallels y que yo le aplique al dichoso error.

El error es debido a que Plesk al actualizar a la versión 9.5.1 instala la versión de psa-turba 2.3.3 que es la que crea el complemento de la libreta de direcciones en Horde, pues desinstalamos ese rpm que Plesk instalo:

rpm -e –nodeps psa-turba-2.3.3

Ahora nos vamos a bajar el anterior paquete rpm de la versión de psa-turba que es el 2.1.7 y posteriormente lo instalamos y listo.

wget http://autoinstall.plesk.com/PSA_9.3.0/dist-rpm-CentOS-5-x86_64/opt/horde/psa-turba-2.1.7-cos5.build93091230.06.noarch.rpm

rpm -i psa-turba-2.1.7-cos5.build93091230.06.noarch.rpm

Y listo¡¡¡ ya tenemos la libreta de direcciones que guarda Horde y no hemos perdido ningún contacto porque no hemos tocado la base de datos ni las tablas que usa Horde.