viernes, 13 de noviembre de 2015

Instalación del cliente de DB2 9.7 en Debian 7 (wheezy) y 8 (jessie)

Es muy común que las aplicaciones que solicitan cumplir ciertos requerimientos no sean muy específicas con cuales deben cumplir. Un ejemplo es el cliente de DB2.

Al ejecutar el script de comprobación aparece en primer lugar el siguiente mensaje de error:

root@srv----:/tmp/client# ./db2prereqcheck 
WARNING:
   Can't use string to find the version of libstdc++.
   Check the following web site for the up-to-date system requirements
   of IBM DB2 9.7
   http://www.ibm.com/software/data/db2/udb/sysreqs.html
   http://www.software.ibm.com/data/db2/linux/validate

Traté de hacer una búsqueda de ese archivo en /usr/lib y allí estaba... instalé la versión de 32 bits, las librerías de desarrollo, etc y seguía sin superar ese requerimiento... hasta que se me encendió la bombilla e instalé, siguiendo la ruta de instalar librerías de desarrollo, el compilador "g++":

root@srv----:/tmp/client# apt-get install g++
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
El paquete indicado a continuación se instaló de forma automática y ya no es necesario.
  php5-ldap
Utilice «apt-get autoremove» para eliminarlo.
Se instalarán los siguientes paquetes extras:
  binutils cpp cpp-4.9 g++-4.9 gcc gcc-4.9 libasan1 libatomic1 libc-dev-bin libc6-dev
  libcilkrts5 libcloog-isl4 libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0 libmpc3
  libmpfr4 libquadmath0 libstdc++-4.9-dev libtsan0 libubsan0 linux-libc-dev manpages-dev
Paquetes sugeridos:
  binutils-doc cpp-doc gcc-4.9-locales g++-multilib g++-4.9-multilib gcc-4.9-doc
  libstdc++6-4.9-dbg gcc-multilib make autoconf automake libtool flex bison gdb gcc-doc
  gcc-4.9-multilib libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg libasan1-dbg
  liblsan0-dbg libtsan0-dbg libubsan0-dbg libcilkrts5-dbg libquadmath0-dbg glibc-doc
  libstdc++-4.9-doc
Se instalarán los siguientes paquetes NUEVOS:
  binutils cpp cpp-4.9 g++ g++-4.9 gcc gcc-4.9 libasan1 libatomic1 libc-dev-bin libc6-dev
  libcilkrts5 libcloog-isl4 libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0 libmpc3
  libmpfr4 libquadmath0 libstdc++-4.9-dev libtsan0 libubsan0 linux-libc-dev manpages-dev
0 actualizados, 26 nuevos se instalarán, 0 para eliminar y 0 no actualizados.
Se necesita descargar 45,6 MB de archivos.
Se utilizarán 136 MB de espacio de disco adicional después de esta operación.
¿Desea continuar? [S/n] s

Por fin había superado el primer tropezón, ahora faltaba el segundo:

root@srv----:/tmp/client# ./db2prereqcheck 
WARNING:
   The 32 bit library file libstdc++.so.6 is not found on the system. 
   32-bit applications may be affected.

Éste ya era obvio, hay que empezar activando el soporte multiplataforma y agregar la arquitectura i386:

root@srv----:/tmp/client# dpkg --add-architecture i386 && apt-get update

Por último instalar libstdc++ para la arquitectura i386:

root@srv----:/tmp/client# apt-get install libstdc++6:i386
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
El paquete indicado a continuación se instaló de forma automática y ya no es necesario.
  php5-ldap
Utilice «apt-get autoremove» para eliminarlo.
Se instalarán los siguientes paquetes extras:
  gcc-4.9-base:i386 libc6:i386 libc6-i686:i386 libgcc1:i386
Paquetes sugeridos:
  glibc-doc:i386 locales:i386
Se instalarán los siguientes paquetes NUEVOS:
  gcc-4.9-base:i386 libc6:i386 libc6-i686:i386 libgcc1:i386 libstdc++6:i386
0 actualizados, 5 nuevos se instalarán, 0 para eliminar y 83 no actualizados.
Se necesita descargar 5.639 kB de archivos.
Se utilizarán 13,9 MB de espacio de disco adicional después de esta operación.
¿Desea continuar? [S/n] s

Finalmente los requerimientos fueron satisfechos y la instalación pudo comenzar. Espero que le sirva de ayuda a quien lo necesite.

viernes, 20 de marzo de 2015

Error Courier IMAP y Outlook Express en Windows XP: actualizando courier-imap usando repositorios oneiric y wheezy "fijados" (pinned)

Aunque parezca mentira no sólo me quejo en este apartado de que aún haya clientes que sigan usando Windows XP (que de por sí es una irresponsabilidad). El problema en sí es que el sistema operativo del servidor también es anticuado.

Aunque estoy en proceso de migrar a Debian 7 (y en la mayoría de los casos a una configuración basada en ISPConfig) todos los viejos ubuntu server que tenía instalados (hace un par de años migré una ubuntu 10.04, el año pasado un par de ubuntus 12.04, etc), aún tengo un servidor que se resiste debido a que una de las páginas principales del cliente no funciona en versiones actuales de PHP, por lo que pasar de PHP 5.3 a 5.4 supone perder la funcionalidad del negocio y se considera una catástrofe.

Dejando a parte que actualizar dicha aplicación no sería demasiado costoso, tuve que actualizar el hardware y aproveché para hacerlo sobre una instalación limpia (y obsoleta, sin soporte ni actualizaciones de seguridad) de Ubuntu 11.10 Server (oneiric).

Hecha la locura (una espina que tengo clavada y que me costará tiempo quitarla) fui a migrar el servidor de correo y todo iba de maravilla hasta que uno de los clientes empezó a llamar alertado porque su cliente Outlook Express de Windows XP le decía que no podía descargar nuevos mensajes.

Hasta donde me alcanzaba la memoria recordé que ese fue un problema que ya pasamos y que tras buscar mucho por Internet solucioné instando una versión ligeramente superior de courier-imap. Se trataba de un bug conocido que habían arreglado en una versión posterior, por lo que de una instalación originalmente con estos paquetes:

ii  courier-base             0.66.1-1ubuntu3                 Courier mail server - base system
ii  courier-imap             4.9.1-1ubuntu3                  Courier mail server - IMAP server
ii  courier-imap-ssl         4.9.1-1ubuntu3                  Courier mail server - IMAP over SSL
ii  courier-ssl              0.66.1-1ubuntu3                 Courier mail server - SSL/TLS Support

Terminé dejando esto instalado en el servidor, sin recordar de dónde saqué los paquetes.

ii  courier-base             0.66.3-2                        Courier mail server - base system
ii  courier-imap             4.9.3-2                         Courier mail server - IMAP server
ii  courier-imap-ssl         4.9.3-2                         Courier mail server - IMAP over SSL
ii  courier-ssl              0.66.3-2                        Courier mail server - SSL/TLS Support

Mucho me temo, basándome en que ya no aparecen las palabras "ubuntu" en los paquetes, que generé los paquetes actualizados desde el código fuente y sólo instalé los paquetes DEB necesarios en el servidor. El problema es que de ello hace ya tanto tiempo que ya no dispongo de esos paquetes, ¡ni quiero tenerlos!, prefiero que se actualicen junto con el "sistema operativo" durante un apt-get update, aunque obviamente no voy a tener demasiadas actualizaciones.

¿Cómo hice la actualización en el nuevo servidor?: usar repositorios de oneiric y wheezy (debian 7) de manera simultánea.

Como he dicho, quería evitar usar paquetes generados desde las fuentes para evitar "tragarme" un agujero de seguridad que hubiera sido subsanado por una actualización. Con esta solución al menos el servidor de imap estará actualizado y al día.

¿Cómo se hace esta proeza? Fácil si seguimos las instrucciones que aparecen en la propia página de ubuntu: Pinning Howto

Para empezar definimos la distribución objetivo por defecto ("oneiric") en un archivo llamado, por ejemplo, /etc/apt/apt.conf.d/00default:

APT::Default-Release "oneiric";

Posteriormente configuramos el repositorio de Debian Wheezy (obtenido a través de este generador, cambiando "stable" por "wheezy" para evitar sorpresas en un futuro cercano) en /etc/apt/sources.list.d/wheezy.list:

deb http://ftp.es.debian.org/debian wheezy main

Creamos el archivo /etc/apt/preferences.d/wheezy.pref con el siguiente contenido:

Package: courier-imap courier-imap-ssl courier-base courier-ssl
Pin: release n=wheezy
Pin-Priority: 1000

Package: *
Pin: release n=wheezy
Pin-Priority: -1

Y posteriormente creamos el archivo /etc/apt/preferences.d/oneiric.pref con el siguiente contenido:

Package: *
Pin: release n=oneiric
Pin-Priority: 990

Hay que notar que en otros "howtos" de debian y apt-preferences fija las prioridades mediante la "suite" ("archive") a=stable, mientras que en la guía de ubuntu y mi solución usamos "codename" n=wheezy para ser homogéneos.

Bien, ¿qué son esas prioridades?

  • 1000: Toma preferencia sobre cualquier otra versión disponible de igual o superior versión. Sólo la prioridad 1001 permite bajar de versión un paquete previamente instalado. De este modo nos aseguraremos que la versión de los paquetes requeridos será la disponible en los repositorios de wheezy.
  • 990: Prioridad normal, con especial cuidado de que no será actualizado por ningún paquete que no sea de la distribución objetivo configurada. Sólo se instalarán paquetes nuevos y se actualizarán los existentes con aquellos pertenecientes a "oneiric".
  • -1: Sólo puedes instalar un paquete de este repositorio si manualmente lo indicas. Por ejemplo, se podría hacer un apt-get install traceroute/wheezy para forzar la instalación del traceroute disponible en wheezy, y no en oneiric.

Ahora basta con hacer un apt-get update para que se actualicen sólo los paquetes deseados a la versión disponible en los repositorios wheezy.

Solución alternativa 1: poniendo una prioridad a wheezy inferior a oneiric (por ejemplo 500 o 100) todo funcionaría igual con apt-get update (no se metería de manera automática un paquete más actual de wheezy). Sin embargo si hacemos un apt-get dist-upgrade podremos "liarla parda" ya que deja de hacer uso la distribución objetivo y usa las versiones de paquete más actuales, por lo que prefiero dejarle una prioridad -1.

Solución alternativa 2: dejando únicamente una prioridad -1 para wheezy y no configurando prioridad 1000 para los paquetes de courier deseados podríamos hacer una instalación "forzada" de los paquetes de wheezy usando el siguiente comando: apt-get install courier-ssl/wheezy courier-imap/wheezy courier-imap-ssl/wheezy courier-base/wheezy.

Al final todo ha quedado de la siguiente manera:

ii  courier-base             0.68.2-1                        Courier mail server - base system
ii  courier-imap             4.10.0-20120615-1               Courier mail server - IMAP server
ii  courier-imap-ssl         4.10.0-20120615-1               Courier mail server - IMAP over SSL
ii  courier-ssl              0.68.2-1                        Courier mail server - SSL/TLS Support

jueves, 19 de marzo de 2015

Courier maildrop: Cómo enviar los mensajes marcados como SPAM a la carpeta de correo no deseado

Gracias a ISPConfig estoy empezando a jugar con Dovecot y su filtrado gestionado por ManageSieve. Este servicio permite a los usuarios gestionar sus scripts de filtrado sin necesidad de tener acceso físico (FTP, SCP, WebDAV o similar) al sistema de archivos mediante un estándar que puede ser integrado en diferentes clientes (como roundcube, horde, thunderbird, etc).

Como en la actualidad mantengo algunos servidores con postfix+courier hasta ahora usaba un script de maildrop genérico que detecta el flag de SPAM que deja Spamassassin en los mensajes para enviarlos a una carpeta IMAP en particular (SPAM hasta hace poco). Como la mayoría de clientes de correo usan la carpeta "Junk" como destino de los correos marcados como SPAM, decidí cambiar dicho directorio de destino y, de paso, publicar el script para que otras personas puedan usarlo.

Este es el archivo /etc/maildroprc genérico que uso en esos servidores:

# Global maildrop filter file

# Uncomment this line to make maildrop default to ~/Maildir for
# delivery- this is where courier-imap (amongst others) will look.
#DEFAULT="$HOME/Maildir"

# Compruebo si es un correo con puntuación mayor de 25. En ese caso lo mando a
# una carpeta que periódicamente usa "spamassassin -r" para reportar a Pyzor,
# Razor, DCC e incluso Spamcop (luego los valido manualmente en su web) y no
# permito que llegue al destinatario.
if (/^X-Spam-Level: *\*{25,}/)
{
    DESTINO="/var/mail/cron.SPAM"
    # Compruebo si la carpeta existe y en caso contrario la creo
    exception {
        `test -d "$DESTINO"`
            if( $RETURNCODE == 1 )
            {
                `/usr/bin/maildirmake "$DESTINO"`
            }
    }
    to "$DESTINO"
}

# Si está marcado como SPAM (y tiene una puntuación inferior a 25) lo mando a
# la carpeta "Junk" del usuario.
if (/^X-Spam-Flag: *YES/)
{
    # Compruebo si la carpeta existe y en caso contrario la creo
    exception {
        `test -d "$DEFAULT/.Junk"`
            if( $RETURNCODE == 1 )
            {
                `/usr/bin/maildirmake "$DEFAULT/.Junk"`
            }
    }
    to "$DEFAULT/.Junk"
}

# Si no es ninguno de los dos casos anteriores lo tramito normalmente.
to "$DEFAULT"

Por hacer: tener un patrón genérico de correo electrónico y línea de comandos para probar el correcto funcionamiento de maildrop.