Planeta BSD

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, 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, e , 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):

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.

Leer el post completo »

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:

El siguiente susto ha sido actualizando y , 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:

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.

Leer el post completo »