Tag courier - Userlinux.net

Increible, o como diría Andrés Montes: "dos de dos!... jugón!". Segunda actualización fuerte en la misma máquina y de nuevo falla el mismo paquete: courier-authlib.

Aunque esta vez he leido y repasado el /usr/ports/UPDATING creo que a alguien se le ha ido la mano con el principal fichero de configuración. Ahora la actualización machaca tus configuraciones y coloca unas por defecto. Cierto es que antes genera una copia de seguridad pero solo faltaría que se quedara tan ancho.

# ls -flash /usr/local/etc/authlib/authmy*
10 -rw-------   1 courier  courier   8.3K Oct  3 16:45 authmysqlrc
 2 -rw-------   1 courier  courier   521B Nov 17  2006 authmysqlrc.bak

Nada que cp/mv no arreglen pero aún así resulta molesto perder el control de esta forma. Tirón de orejas para oliver@freebsd.org ;).

No recuerdo la última entrada sobre servidores de correo, he debido de tener bastante suerte porque suele ser el pan de cada día en materia de administración. Debe ser cierto eso de que una vez configurado y funcionando este tipo de servicios comen poco tiempo al BOFH de turno.

Un repaso de configuraciones de vez en cuando no viene mal, así que juntadas unas cuantas quejas decido comprobar los parámetros que se mandan al servidor encargado de repartir el correo, courier en este caso. El problema concreto se centra en la respuesta del servidor, no se efectúa en la totalidad de los casos y vistas las estadísticas del tráfico medio de ancho de banda, no debería ser problema de conectividad (al menos no en tantos casos).

Los correos se sirven en dos bandejas, POP e IMAP, las diferencias son notorias así que resumiendo demasiado el primer protocolo consiste en la descarga de todos los mensajes para poder leerlos offline mientras que el segundo es una sincronización continua de los correos del servidor. ¿Qué significa?, que por norma general POP usa menos tiempo la conexión con el servidor pero ocupando mayor caudal de descarga e IMAP establece una conexión más duradera y ligera (dependiendo del tipo de caché cliente, descarga de cabeceras...).

Si seguimos acumulando factores y después de analizar a grosso modo los logs del sistema, creo que soy el único que utiliza IMAP, es muy probable que el servidor POP se sature de cuando en vez (no por ancho de banda, sino por límite de peticiones):

# grep imapd /var/log/maillog | wc -l ; grep pop3d /var/log/maillog | wc -l
      88
    1382
# grep MAXDAEMONS /usr/local/etc/courier-imap/pop3d
    ##NAME: MAXDAEMONS:0
    MAXDAEMONS=40
# 

40 es, por defecto, el número de peticiones simultáneas que atiende (tanto pop3d como imapd). Visto que imapd lleva 88 peticiones en total (hoy) no creo que haga falta cambiar demasiado su configuración, sin embargo puede quedarse corto para el resto de clientes que usan pop3d, así que me parece inteligente probar con un valor más alto. 300 sería una cifra óptima para un gran servidor de correo, pero no queriendo pecar de protagonismo, 'ni pa tí ni pa mi', probaré un tiempo con 80 a ver si disminuyen las quejas.

Cuando tratas de actualizar masivamente los paquetes de un servidor FreeBSD es porque basicamente has dejado pasar bastante tiempo desde la última actualización y probablemente encuentres sorpresas por el camino. La primera de ellas ha sido pear-PEAR, lo han cambiado de sitio y con los últimos ports no había Makefile disponible para compilación, con lo que... cual escopeta de feria.

Menos mal que tenemos un /usr/ports/UPDATING que en este caso nos ha ahorrado mucho tiempo:

20051213:
  AFFECTS: users of pear ports
  AUTHOR: ale@FreeBSD.org

  A few old pear ports have been removed from the tree in favour of a
  single devel/pear port.  If portupgrade complains about missing ports,
  you may safely remove pear-XML_RPC, pear-Console_Getopt, pear-Archive_Tar
  and php[45]-pear and then run:

  portupgrade -o devel/pear -f pear-PEAR

El siguiente susto ha sido actualizando courier-authlib-base y courier-authlib-mysql, aunque me decanto por el último sin saber muy bien lo ocurrido. Después justo de actualizar el paquete reinicio el authdaemond y a partir de ese momento IMAP ha dejado de funcionar, miro las configuraciones y veo que /usr/local/etc/authlib/authmysqlrc no es para nada lo que yo había configurado tiempo ha. Me sonaba más el contenido de authmysqlrc.bak.

Presupongo que alguno de esos dos paquetes ha sobreescrito mi configuración por la de casa, cosa que no me ha gustado demasiado. Mea culpa por otro lado, si en vez de ejecutar un portupgrade -a hubiera puesto -an la historia sería otra.

De todas formas no salgo de mi asombro al ver que con pkg_info todas mis suposiciones se van al traste:

# pkg_info -L courier-authlib-mysql-0.58
Information for courier-authlib-mysql-0.58:

Files:
/usr/local/etc/authlib/authmysqlrc.dist
/usr/local/lib/courier-authlib/libauthmysql.so
/usr/local/lib/courier-authlib/libauthmysql.so.0
/usr/local/share/doc/courier-authlib/README.authmysql.html
/usr/local/share/doc/courier-authlib/README.authmysql.myownquery

No sé si es un bug del port, si notificar un pr o que... En fin, llamaremos a Mulder & Scully que vengan a hacer de forenses.