El plan consiste básicamente en realizar consultas SQL a la base de datos de Plesk para Windows, a partir de las cuáles se pueda obtener una serie de scripts que utilicen los comandos CLI provistos por Plesk. Una vez replicada la estructura de clientes y dominios, ya se comienza a pasar los datos, vía FTP, del código de las webs, y mediante exports de MySQL para las bases de datos. Para el correo se creó una utilidad en Python que analizaba el fichero AUTH.TAB de MailEnable, generando un script que crea los buzones en Plesk, y después invoca a imapsync para copiar el contenido de los mismos.

Estructura de dominios en Plesk

Comenzamos generando la estructura de revendedores, clientes y dominios en el servidor destino, creando una serie de comandos para el CLI de Plesk, ejecutando comandos SQL en el servidor origen:

SQL que genera los revendedores:

SELECT "reseller -c " + cl.login +
" -name """ + cl.pname + """" +
" -passwd " + cl.passwd +
" -company """ + cl.cname + """" +
" -phone """ + cl.phone + """" +
" -email """ + cl.email + """" +
" -address """ + cl.address + """" +
" -city """ + cl.city + """" +
" -zip """ + cl.pcode + """" +
" -country """ + cl.country + """" +
" -creation-date """ + FORMAT(cl.cr_date,"YYYY-MM-DD") + """"
FROM clients cl
WHERE type = "reseller"

SQL que genera un script para la creación de clientes, obviando los suscriptores, que ya tienen su cuenta del paso anterior:

SELECT "customer -c " + cl.login +
" -name """ + cl.pname + """" +
" -passwd " + cl.passwd +
" -company """ + cl.cname + """" +
" -phone """ + cl.phone + """" +
" -email """ + cl.email + """" +
" -address """ + cl.address + """" +
" -city """ + cl.city + """" +
" -zip """ + cl.pcode + """" +
" -country """ + cl.country + """" +
" -creation-date """ + FORMAT(cl.cr_date,"YYYY-MM-DD") + """" +
" -owner """ + res.login + """"
FROM clients cl
LEFT JOIN clients res ON (res.id = cl.parent_id)
  WHERE type <> "reseller"

En este punto, nosotros reemplazamos el owner “admin” por nuestra empresa, para que nada dependiese del usuario raíz, ya que según la nueva estructura de Plesk 10, parece más correcto.

Por último, el SQL que genera un script para la creación de suscripciones a partir de los dominios de Plesk 9. Los dominios los crea con el DNS desactivado, dado que seguiremos manejando el servicio DNS con el otro servidor, y a la IP compartida (que está, claramente, modificada). También el login utiliza sólo minúsculas, ya que se ha introducido esta restricción en Plesk 10.

SELECT "domain -c " + dom.name +
" -owner """ + cl.login + """" +
" -dns false" +
" -hosting true " +
" -ip 192.168.0.164 " +
" -login """ + LCASE(hos.fp_adm) + """" +
" -passwd """ + hos.fp_pass + """" +
" -creation-date """ + FORMAT(dom.cr_date,"YYYY-MM-DD") + """"
FROM (domains dom
LEFT JOIN clients cl ON (cl.id = dom.cl_id))
LEFT JOIN hosting hos ON (hos.dom_id = dom.id)

Puntos mejorables:

• Hay que revisar los DNS a mano. Hemos preferido hacerlo así, para hacer limpieza, pero tampoco sería complejo realizar un script similar a los mostrados, y marcar las suscripciones con el servicio DNS activado por defecto, de forma que sólo quedase pendiente realizar la modificación en el dominio.
• Las redirecciones de correo y demás opciones específicas deben ser revisadas, ya que el script únicamente ignora las cuentas que estén desactivadas en MailEnable, pero nada más.
• Todas las suscripciones pasan como hosting, así que las que son redirecciones o simplemente sin hosting no pasan mediante el script. Esto es debido a que se hace un JOIN con la tabla hosting de Plesk 9.
• Las suscripciones y revendedores pasan con un plan personalizado. En nuestro caso nos da igual, porque vamos a aprovechar para repasar todos los clientes y revisar así usos y precios.

Correo electrónico

Bien, tras esto ya tenemos los revendedores, clientes, suscripciones y dominios en Plesk 10. A continuación presentamos una pequeña utilidad en Python que genera dos ficheros, uno que permite la creación de los buzones en Plesk, y otro que sincroniza los correos entre los dos servidores mediante IMAP, creando la estructura de carpetas existente en el antiguo.

# This Python file uses the following encoding: utf-8
'''
me2plesk: Utilidad para la transformación de AUTH.TAB en scripts Plesk 10 e imapsync
Created on 13/10/2011
@author: Vicente Monroig (Digital Disseny)
'''

import os
import sys

def parse_authtab(fichero):
    '''Abre el fichero AUTH.TAB, lo parsea y devuelve una lista con los buzones y contraseñas.'''
    print "Procesando fichero AUTH.TAB " + fichero + "..."
    f = open(fichero, "r")
    lista = []
    while True:
        lin = f.readline().strip()
        if not lin: break
        campos = lin.split('\t')
        # Ignoramos los que estén desactivados
        if campos[1] <> 1:
            lista.append([campos[0], campos[2]])
    f.close()
    return lista

# Obtenemos la ruta donde se está ejecutando el archivo
ruta = os.path.dirname(os.path.abspath(__file__)) + '/'
# Recogemos el parámetro donde está el AUTH.TAB o mostramos la ayuda
if (len(sys.argv) > 1):
    # Extraemos los pares correo, contraseña
    lista = parse_authtab(sys.argv[1])
    print("Generando scripts...")
    # Creamos los archivos de script
    fplesk = open(ruta + 'me2plesk_plesk.txt', "w")
    fsync = open(ruta + 'me2plesk_imapsync.txt', "w")
    for elemento in lista:
        # Creamos una nueva línea en ambos scripts
        fplesk.write("/opt/psa/bin/mail --create " + elemento[0] + " -passwd " + elemento[1] +
                     " -mailbox true\n")
        fsync.write("imapsync --host1 origen.com" +
                    " --user1 " + elemento[0] + " --password1 " + elemento[1] +
                    " --host2 destino.com" +
                    " --user2 " + elemento[0] + " --password2 " + elemento[1] +
                    " --sep1 / --prefix1 ""  --subscribe --fastio1 --fastio2 --fast\n")
    fplesk.close()
    fsync.close()
    print("Scripts me2plesk_plesk.txt y me2plesk_imapsync.txt generados en %s." % ruta)
else:
    print """
Información:
    me2plesk es una pequeña utilidad que analiza sintácticamente el fichero AUTH.TAB del
    servidor de correo MailEnable para Windows, generando dos scripts, uno que llama a la
    función mail del CLI de Plesk 10, creando los buzones encontrados, y un segundo que
    invoca a la utilidad imapsync, una vez por cada buzón, permitiendo con la combinación
    de ambos la mudanza de un servidor MailEnable Windows a un Plesk 10.
Uso:
    me2plesk.py <AUTH.TAB>
       """

Además, como algunos ISPs son algo lentos cambiando los registros DNS, tenemos la ventaja de que no perderemos ningún correo, al poder ejecutar la sincronización varias veces, incluso con los DNS ya cambiados y propagados.

Una pega: Aquellos clientes que mantengan correo en el servidor y utilicen POP3 como protocolo, verán sus correos duplicados en los clientes. Sin embargo, los que utilicen IMAP no tendrán este problema, dado que imapsync, la utilidad llamada por el script para sincronizar los buzones, respeta las flags de cada mensaje.

Webs (código y bases de datos)

Para pasar el código de las webs utilizaremos FTP, y más concretamente LFTP, que incorpora un comando mirror que nos va a permitir realizar todo el traspaso en una única línea de comandos ejecutada en el servidor destino:

lftp -e "mirror httpdocs /var/www/vhosts/<dominio>/httpdocs --parallel=10" -u <usuario>,<contraseña> <servidor_fuente>

Quedaría ajustar los permisos y propietario de los distintos archivos. Podemos poner unos estándar para Plesk y después repasar lo que necesite permisos de escritura, como carpetas para ficheros temporales.

chown -R <usuarioplesk>:psacln /var/www/vhosts/<dominio>/httpdocs/*
find /var/www/vhosts/<dominio>/httpdocs/* -type d -exec chmod 755 {} \;
find /var/www/vhosts/<dominio>/httpdocs/* -type f -exec chmod 644 {} \;

Vamos a por las bases de datos. Nos centraremos en MySQL, que son las que nos vamos a encontrar en su mayoría (WordPress, Joomla, Magento, Drupal…). Aprovechando que todavía tenemos un servidor Windows, podemos utilizar HeidiSQL para realizar una copia de seguridad, y si configuramos debidamente el servidor destino para aceptar conexiones externas, también podremos utilizarlo para restaurar, todo desde el mismo servidor origen.

DNS

Ya están la estructura de usuarios recreada, correos pasados, código fuente transferido y bases de datos restauradas. Tan sólo queda modificar los DNS de los dominios para que dirijan al nuevo servidor.

Como último apunte, antes de comenzar con los cambios de IPs en los DNS es muy recomendable modificar los registros SOA, indicando un TTL de 5 minutos, con lo que podremos realizar modificaciones que se propaguen mucho más rápido. Por supuesto, esto conlleva un aumento del tráfico, pero con las máquinas y anchos de banda de hoy en día, no debería ser ningún problema.

Recordad también que el archivo hosts es nuestro amigo, y que es muy conveniente realizar pruebas en el nuevo servidor antes de cambiar los DNS. Siempre podemos relanzar la sincronización de correos y volver a pasar la copia de seguridad de la base de datos cuando estemos seguros de que todo está operativo de nuevo.

Organización

Lo más crucial, lo más importante y lo único que no puede fallar durante el proceso es la organización. Sobre esto poco voy a decir, pues esto es un blog técnico, pero sí quiero remarcar que antes de empezar hay que planificar y dividir las tareas que van a tener que hacerse fuera de horario de oficina. Hay que comunicar a los clientes previamente lo que se va a hacer, y que les quede claro que puede haber problemas, y cuándo se va a hacer, no sea que les dé por liarse a actualizar su web justo cuando tenemos pensado ponernos a migrar sus servicios.

Prepara una hoja de cálculo, verifica y anota los servicios a trasladar, agrúpalos por similitud y anota los posibles problemas y su resolución. Como mínimo.

Lamentablemente, parece que por cuestiones de licencia, ya no se siguen generando los binarios en paquetes Debian, por lo que el método recomendado de instalación es compilar a partir del código fuente, pero esto necesita un cambio en el servidor Apache que viene con Plesk 10 para Ubuntu, así que mejor dejamos la última versión disponible instalable con apt, y procedemos con:

apt-get install libapache-mod-security

Esto nos dejará instalados y activados los módulos mod_security2 y mod_unique_id, con sus enlaces en /etc/apache2/mods-enabled. Ahora necesitamos un conjunto de reglas para ModSecurity, y las que vamos a utilizar son las gratuitas de Atomicorp, los editores de ASL, que las ofrecen con un retraso de 90 días sobre las de pago, disponibles en http://updates.atomicorp.com/channels/rules/delayed/. Las descargamos y descomprimimos en /etc/apache2/modsecurity.d:

mkdir /etc/apache2/modsecurity.d
wget http://updates.atomicorp.com/channels/rules/delayed/modsec-2.5-free-latest.tar.gz
tar xvf modsec-2.5-free-latest.tar.gz

Ahora creamos un fichero de configuración, también en /etc/apache2/modsecurity.d, llamado modsecurity_crs_10_config.conf, con el siguiente contenido:

SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType (null) text/html text/plain text/xml
SecResponseBodyLimit 2621440
SecServerSignature Apache
SecComponentSignature 200911012341
SecUploadDir /var/asl/data/suspicious
SecUploadKeepFiles Off
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogType Concurrent
SecAuditLog /var/log/apache2/modsecurity/audit_log
SecAuditLogParts ABIFHZ
SecArgumentSeparator "&"
SecCookieFormat 0
SecRequestBodyInMemoryLimit 131072
SecDataDir /var/asl/data/msa
SecTmpDir /tmp
SecAuditLogStorageDir /var/asl/data/audit
SecResponseBodyLimitAction ProcessPartial

#SecPcreMatchLimit  100000
#SecPcreMatchLimitRecursion 100000

SecDebugLog /var/log/apache2/modsecurity/modsec_debug_log
SecDebugLogLevel 3

Atención a las carpetas especificadas para las estructuras de datos necesarias para ModSecurity, que deben existir y Apache tener permiso sobre ellas, por lo que ejecutamos:

mkdir /var/asl /var/asl/data /var/asl/data/audit /var/asl/data/msa /var/asl/data/security
chown -R www-data:www-data /var/asl/data/

Por último, creamos un fichero 00_modsecurity.conf en /etc/apache2/conf/, con ese nombre para que cargue el primero, activando las reglas que deseemos, que en nuestro caso son las siguientes:

LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so

  # Todas + exclusiones personalizadas:
  Include /etc/apache2/modsecurity.d/00_asl_0_global.conf
  Include /etc/apache2/modsecurity.d/00_asl_custom_exclude.conf
  # Quitamos RBL porque coge las IPs incorrectamente, como desordenadas
  #Include /etc/apache2/modsecurity.d/00_asl_rbl.conf
  #Include /etc/apache2/modsecurity.d/00_asl_whitelist.conf
  # Esta sólo funciona con ModSecurity > 2.6.1
  #Include /etc/apache2/modsecurity.d/00_asl_z_antievasion.conf
  Include /etc/apache2/modsecurity.d/00_asl_zz_strict.conf
  Include /etc/apache2/modsecurity.d/05_asl_exclude.conf
  # No tenemos el CLAM antivirus instalado
  #Include /etc/apache2/modsecurity.d/05_asl_scanner.conf
  Include /etc/apache2/modsecurity.d/09_asl_rules.conf
  Include /etc/apache2/modsecurity.d/09_asl_rules_antievasion.conf
  Include /etc/apache2/modsecurity.d/10_asl_antimalware.conf
  Include /etc/apache2/modsecurity.d/10_asl_antimalware_output.conf
  Include /etc/apache2/modsecurity.d/10_asl_rules.conf
  Include /etc/apache2/modsecurity.d/11_asl_data_loss.conf
  Include /etc/apache2/modsecurity.d/12_asl_brute.conf
  Include /etc/apache2/modsecurity.d/20_asl_useragents.conf
  Include /etc/apache2/modsecurity.d/30_asl_antimalware.conf
  Include /etc/apache2/modsecurity.d/30_asl_antispam.conf
  Include /etc/apache2/modsecurity.d/30_asl_antispam_referrer.conf
  Include /etc/apache2/modsecurity.d/40_asl_apache2-rules.conf
  Include /etc/apache2/modsecurity.d/50_asl_rootkits.conf
  Include /etc/apache2/modsecurity.d/60_asl_recons.conf
  Include /etc/apache2/modsecurity.d/61_asl_recons_dlp.conf
  Include /etc/apache2/modsecurity.d/98_asl_jitp.conf
  Include /etc/apache2/modsecurity.d/99_asl_exclude.conf
  Include /etc/apache2/modsecurity.d/99_asl_jitp.conf
  Include /etc/apache2/modsecurity.d/99_asl_redactor.conf
  # No tenemos el CLAM antivirus instalado
  #Include /etc/apache2/modsecurity.d/99_asl_scanner.conf

Vamos, prácticamente todas, menos la que da problemas por la versión de ModSecurity, que no es la 2.6.1 o superior, las de listas negras y las del antivirus CLAM.

Ya está todo listo. Comprobamos que la configuración de Apache es correcta con

apache2ctl configtest

Y si lo es, reiniciamos apache con

apache2ctl graceful

Hale, ya podemos empezar a ver correr en /var/log/apache2/modsecurity/audit_log la lista de peticiones bloqueadas.

Actualización: Cómo desactivar reglas

Es muy posible que tengamos que desactivar algunas reglas al encontrarnos con falsos positivos, mostrando errores 403 cuando los permisos y el código están perfectamente. En nuestro caso, al alojar tiendas, algunos TPVs virtuales dan problemas, así que decidimos desactivar globalmente. Para esto, se modifica el fichero /etc/apache2/modsecurity.d/00_asl_custom_exclude.conf, añadiendo el siguiente contenido:

<LocationMatch .*>
  <IfModule mod_security2.c>
    SecRuleRemoveById 350147
    SecRuleRemoveById 350148
  </IfModule>
</LocationMatch>

Al modificar el fichero de configuración global y utilizar .* como patrón, indicamos que para cualquier dominio y URL alojada en el servidor no queremos que se tengan en cosideración esas reglas. También podemos modificar una regla para un dominio en particular, modificando el fichero vhost.conf que Plesk utiliza para este menester, y regenerando la configuración, por supuesto.

Como ya hemos comentado en anteriores ocasiones, los webmails incluidos con Plesk 10 no eran de nuestro agrado, así que cuando sustituímos Plesk 9.5 Windows por Plesk 10.3 Linux, decidimos cambiarlo por Roundcube. El problema ha sido que los usuarios han echado de menos cierta funcionalidad de la que disponían con MailEnable, pero lo hemos podido solventar mediante el desarrollo de plugins o drivers para plugins ya existentes, que queremos publicar:

Todos los desarrollos asumen que Roundcube se está ejecutando en el mismo servidor que Plesk, y precisan de permisos de ejecución de las utilidades CLI para el usuario que esté ejecutando Apache. La ventaja de llamar nativamente a Plesk es que los cambios realizados en el panel se ven en el webmail, y viceversa, además de que se incluyen en la copia de seguridad de Plesk.

As mentioned previously, webmails included with Plesk 10 were not to our liking, so when we switched from Plesk 9.5 Windows to Plesk 10.3, we decided to replace them with Roundcube. The problem was that users have missed some functionality available with MailEnable, but we were able to solve by developing plugins or drivers for existing plugins which we want to publish:

All developments assume that Roundcube is running on the same server as Plesk, and require execute permissions over CLI utilites for user running Apache. The advantage of call natively Plesk through his CLI is that changes made in the panel are shown in the webmail, and vice versa, in addition to being included in the Plesk backup.

Update 23/12/2011: Changed link for Vacation message to GitHub repository, where latest version should be found, with contributions from other authors.

/usr/local/psa/admin/bin/mail_auth_view: Muestra en la salida estándar una tabla con todos los buzones de correo, el estado de la cuenta y la contraseña.

mysql -uadmin -p`cat /etc/psa/.psa.shadow` -e "use psa; select sys_users.home, sys_users.login, accounts.password from accounts INNER JOIN sys_users ON accounts.id=sys_users.account_id;": Muestra una lista de los usuarios y contraseñas FTP, el directorio raíz (que nos da una pista del dominio o subdominio al que acceden), y su contraseña.

mysql -uadmin -p`cat /etc/psa/.psa.shadow` -e "USE psa; SELECT domains.name AS domain_name, data_bases.name AS database_name, db_users.login, accounts.password FROM data_bases, db_users, domains, accounts WHERE data_bases.dom_id = domains.id AND db_users.db_id = data_bases.id AND db_users.account_id = accounts.id ORDER BY domain_name;": Muestra una lista con el dominio, nombre de la base de datos, usuario y contraseña de todas las bases de datos registradas en Plesk.

for i in `mysql -uadmin -p\`cat /etc/psa/.psa.shadow\` psa -Ns -e "select concat(mail.mail_name,\"@\",domains.name) as address from mail,domains,accounts where mail.dom_id=domains.id and mail.account_id=accounts.id order by address"`; do /usr/local/psa/bin/spamassassin -u $i -status true -action move -modify-subj false; done: Activar el sistema de detección de correo basura Spamassassin en todas las cuentas, configurado para mover los mensajes sospechosos a una carpeta específica y sin modificar el asunto.

mysql -uadmin -p`cat /etc/psa/.psa.shadow` -e "USE psa; SELECT cl.type, cl.login, acc.password FROM clients cl, accounts acc WHERE acc.id = cl.account_id;": Obtiene todos los nombres de usuario y contraseñas de clientes y revendedores.

El tema es que a partir de la versión 10.2 de Plesk, han incorporado un sistema para añadir webmails externos, pero o bien somos extremadamente torpes, o simplemente no funciona correctamente. Y como ya conocemos a los amigos de Parallels, casi que me inclino por lo segundo. Además, tengo pruebas.

Sin embargo, es posible instalarlo, o bien como reemplazo de alguno de los webmails existentes, cosa que no termino de recomendar ya que en alguna actualización de Plesk volará todo, o bien desinstalando los dos existentes y dejando como única opción para los clientes el nuevo, cosa que tenemos instalada en producción.

Así pues, empezamos desinstalando los webmails existentes:

apt-get remove psa-horde psa-atmail

Después se descomprime el webmail, en /var/www/roundcube, por ejemplo.

wget http://sourceforge.net/projects/roundcubemail/files/roundcubemail-beta/0.5-RC/roundcubemail-0.5-rc.tar.gz
tar xvfz roundcubemail-0.5-rc.tar.gz
mkdir /var/www/roundcube
mv /roundcubemail-0.5-rc/* /var/www/roundcube

Como alternativa a utilizar el instalador que incorpora el webmail, también se puede seguir este post, lo que otorga mayor control sobre lo que se está haciendo, aunque está algo desfasado, ya que en las últimas versiones se pueden utilizar variables de reemplazo para acceder al domino actual, o al del servidor IMAP. No olvidarse de hacer desaparecer el directorio installer al terminar, para evitar posibles problemas.

Por último, ya que hemos eliminado los webmails conocidos para Plesk, éste no interferirá con el subdomino webmail, así que creamos un VirtualHost común a todos nuestros dominios, creando un fichero roundcube.conf en el directorio /etc/apache2/conf.d, con el siguiente contenido:

<VirtualHost 192.168.0.250:80>
    ServerName webmail
    ServerAlias webmail.*
    DocumentRoot /var/www/roundcube
    <Directory "/var/www/roundcube">
        allow from all
        php_flag magic_quotes_gpc Off
        php_flag register_globals Off
        php_flag include_path /usr/share/awl/inc
    </Directory>
</VirtualHost>

Por supuesto, hay que cambiar la IP por la que toque, así como las rutas, si no son las correctas. Tras un reinicio del Apache podremos acceder al webmail si teníamos los DNS configurados.

service apache2 restart

Por cierto, gracias a Florian Moker por su inestimable ayuda en esto.

Así, el siguiente .htaccess:

RewriteEngine on
Options +FollowSymlinks

RewriteCond %{HTTP_HOST} url\.original\.com
RewriteRule (.*)$ http://otroserver.com/undircualquiera/$1 [P,L]

Que lo que busca es la redirección “neutra”, mediante un proxy, de una URL a otro sitio (por la directiva [P]), genera el siguiente error:

[Mon Sep 19 13:33:04 2011] [alert] [client x.x.x.x] /var/www/vhosts/dominio.com/subdominio/.htaccess: Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration.

Bien, esto lo que nos indica es que el módulo no está activado, ya que instalado sí está en Plesk, así que procedemos a su activación con a2enmod proxy. Tras esto, nos podemos encontrar con otro error:

[Mon Sep 19 13:57:08 2011] [warn] proxy: No protocol handler was valid for the URL /. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

Esto es debido a que el módulo mod_proxy por si solo no funciona, así que instalaremos otros dos módulos, con a2enmod proxy_balancer y a2enmod proxy_http, y reiniciaremos apache con service apache2 restart.

Tras esto, ya deberíamos tener mod_proxy redirigiendo correctamente las peticiones, sin que cambie la URL que el cliente ve en su navegador.

Si en lugar de utilizar .htaccess preferimos definir las reglas en vhosts.conf, conviene recordar que la carpeta adecuada es /var/www/vhosts/dominio.com/conf, que luego Plesk ya generará el fichero vhosts.conf completo.

Bonus: mod_rewrite en IIS

Si por lo que sea —jugando a adivinar, por mantener ASP.NET en un servidor IIS 6— necesitamos mantener el Internet Information Server, pero queremos disfrutar de mod_rewrite, permitiendo así tener URLs amigables, disponemos de una estupenda solución: Helicon Ape.

Es gratuito hasta tres dominios, y si se necesitan más, tiene un precio muy interesante. Como se puede ver, soporta no sólo mod_rewrite, sino casi cualquier módulo que se te ocurra de Apache.

Sin embargo, se puede modificar el fichero de configuración, situado en /usr/local/psa/etc/modules/watchdog/rkhunter.conf, añadiendo las siguientes líneas, para que esto no ocurra:

XINETD_ALLOWED_SVC=/etc/xinetd.d/ftp_psa
XINETD_ALLOWED_SVC=/etc/xinetd.d/poppassd_psa
ALLOWHIDDENDIR=/dev/.udev
APP_WHITELIST="gpg OpenSSL PHP named"
ALLOW_SSH_ROOT_USER=no

La última línea dependerá de cómo tengamos configurado SSH, permitiendo acceso como root o no.

La siguiente vez que se lance el proceso ya no debería haber errores o advertencias, por lo que no se recibirá el correo. Si se desea lanzar manualmente el proceso de revisión, se puede realizar bien a través de Plesk, o desde consola, con el comando /usr/local/psa/admin/bin/modules/watchdog/rkhunter --check.

En servidores Plesk, este cambio se puede realizar cómodamente modificando la base de datos. Este es el SQL a utilizar a partir de la versión 8.3, y probado sobre una 9.5.1:

UPDATE 'dns_zone' SET 'ttl' = '300', 'ttl_unit' = '60' WHERE 'id' > 1;

Una vez modificada la base de datos, ejecutamos este comando para que Plesk regenere los archivos de zona:

"%plesk_bin%\dnsmng.exe" update *

Hay que tener en cuenta que los cambios no serán inmediatos, debido al propio funcionamiento del sistema DNS, que provoca que la propagación no se pueda garantizar hasta que vaya caducando en la caché de los distintos servidores el registro anterior, así que hay que anticiparse y realizar este cambio al menos 24 horas antes de realizar la modificación de la IP.

Bonus 1: Modificación de la base de datos MDB de Plesk

Si estuvimos poco hábiles el día de la instalación de Plesk y decidimos que utilizase Access en lugar de MySQL, tendremos alguna dificultad para realizar cambios sin instalar el Microsoft Access, del que tendríamos que adquirir una licencia para poder realizar esta modificación, además de que dejarlo instalado en un servidor de producción no mola.

Pero tenemos una buena alternativa: MDB Viewer Plus, que permite examinar y desde hace bien poco también la ejecución de SQL sobre tablas Access, utilizando MDAC, que viene instalado con Windows.

Bonus 2: Comprobación de los registros DNS

Para comprobar que efectivamente el TTL de nuestros registros DNS es el correcto, podemos utilizar el comando dig en Linux contra cualquier servidor DNS, que nos mostrará lo que tenga almacenado:

jefazo@servidor:~$ dig midominio.tld @8.8.8.8

; <<>> DiG 9.7.3 <<>> midominio.tld @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10873
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;midominio.tld.                        IN      A

;; ANSWER SECTION:
midominio.tld.         300     IN      A       1.2.3.4

;; Query time: 108 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Sep 10 22:12:07 2011
;; MSG SIZE  rcvd: 48

1.- Desde la opción de “Directorios protegidos con contraseña” añades el directorio que quieres proteger y le creas el usuario que quieras
2.- En este momento tienes el directorio protegido y si escribes la ruta completa a un fichero (p.e http://www.dominio.com/pruebas/documento.pdf) te pedirá usuario y contraseña para descargarlo o mostrarlo pero si pones una ruta sin fichero (p.e http://www.dominio.com/pruebas) no listará el contenido de la carpeta. Osea protege los ficheros con contraseña y no deja listarlos.
3.- Para que te deje listarlos tienes que crear un directorio virtual. Para eso te vas a directorios virtuales y creas uno nuevo con las opciones:
3.1 Ponle un nombre (p.e. pruebaspetardas o el mismo de antes)
3.2 Ruta: Deselecciona la opción “Crear directorio físico con el mismo…….” y te aparecerá una casilla nueva para poner la carpeta donde tienes los ficheros
3.3 Navegacion directorio: Finalmente selecciona la opcion “Navegación directorio”

Y ahora si, ya se lista el directorio. Para eso escribiriamos si pones www.dominio.com/pruebaspetardas.