Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 04 de junio de 2008 - Miércoles
Mailman incluye una pasarela "news"<->lista de correo. El programa se conecta al servidor de "news" de vez en cuando (normalmente vía "cron"), y se encarga de transferir los mensajes nuevos de un sistema al otro.
A la hora de transferir los mensajes de "news" a la lista de correo, Mailman utiliza un "watermark": Dado que los mensajes dentro de cada grupo de news se numeran de forma correlativa, basta con llevar la cuenta de cuál es el último mensaje que hemos transferido. Cuando se vuelve a conectar a las "news", sencillamente transfiere los mensajes cuya numeración es mayor que el "watermark" actual y, luego, lo actualiza y lo almacena para la siguiente conexión.
Este sistema funciona... mientras no cambiemos de servidor de "news". Si lo hacemos, su numeración será distinta y, por tanto, pueden pasar dos cosas:
En mi caso estoy el segundo supuesto, como pueden verse claramente en los logs:
[root@tesalia logs]# tail fromusenet Jun 04 17:03:02 2008 (17617) comp.arch watermark: 261235 Jun 04 17:23:02 2008 (24782) comp.arch: [44454..45010] Jun 04 17:23:02 2008 (24782) nothing new for list comp.arch Jun 04 17:23:02 2008 (24782) comp.arch watermark: 261235 Jun 04 17:43:03 2008 (1386) comp.arch: [44454..45010] Jun 04 17:43:03 2008 (1386) nothing new for list comp.arch Jun 04 17:43:03 2008 (1386) comp.arch watermark: 261235 Jun 04 18:03:02 2008 (7250) comp.arch: [44454..45010] Jun 04 18:03:02 2008 (7250) nothing new for list comp.arch Jun 04 18:03:02 2008 (7250) comp.arch watermark: 261235
He cambiado de servidor de "news", y las numeraciones no se corresponden. No veré ningún mensaje nuevo hasta que la numeración del nuevo servidor iguale el "watermark", lo que puede suponer varios años :-).
Evidentemente, algo hay que hacer. Lo más obvio es buscar dónde se guarda el "watermark", y cambiarlo por un valor apropiado. ¿Qué valor es ese?. El más natural parece ser 44454, para resincronizarnos. Pero en ese caso corremos el riesgo de recibir cientos de mensajes que ya habíamos pasado a la lista de correo hace semanas. Lo más inteligente sería buscar en el servidor de "news" cuál es el primer mensaje que no hemos recibido, y fijar el "watermark" al valor anterior. Esta idea sería perfecta si no fuese porque los mensajes de "news" se distribuyen por "flood" y, por tanto, el orden relativo de los mensajes en servidores diferentes puede ser distinto.
Una solución intermedia es dar un par de días de margen hacia atrás, a la hora de actualizar el "watermark": nos llegarán algunos duplicados, y probablemente algún mensaje que no habíamos recibido por medio, pero nos ahorramos la duplicación de los 500 mensajes anteriores.
No voy a explicar cómo se realiza el proceso de búsqueda. Baste decir que hay que entrar por "telnet" al servidor de "news" y usar bipartición binaria para localizar el primer mensaje de un par de días antes del cambio de servidor. Por supuesto también se puede utilizar el módulo "nntplib" de Python. En mi caso ese mensaje es el número 44947 (este grupo de "news" tiene poco tráfico...).
Ahora toca buscar dónde se guarda el "watermark". Para ello, normalmente, haría un "grep" al código fuente de Mailman, buscando referencias a mensajes en los logs y tirando del hilo desde ahí. Pero tengo la razonable sospecha de que el "watermark" se guarda en fichero de configuración de cada lista de correo. Para comprobarlo, hago:
[root@tesalia comp.arch]# grep -i watermark config.pck Binary file config.pck matches
La cosa tiene buena pinta. Por experiencias previas, además, sé que la configuración de las listas en Mailman se guardan como un objeto "pickle" de Python. Lo sencillo sería parar el sistema Mailman, cargar el "pickle" en memoria, cambiar el "watermark", volver a grabar el "pickle" (conservando la versión vieja, por si acaso) y reactivar Mailman.
Pero me apetece aprender un poco más sobre las tripas de Mailman, así que descubro una interesante herramienta llamada "mailman/bin/withlist":
[root@tesalia bin]# pwd /usr/local/mailman/bin [root@tesalia bin]# python withlist -i -l comp.arch Loading list comp.arch (locked) The variable `m' is the comp.arch MailList instance >>> m <mailing list "comp.arch" (locked) at 84166cc> >>> dir(m) ['AddMember', ..., 'usenet_watermark', ...] >>> m.usenet_watermark 261235 >>> m.usenet_watermark=44947 >>> m.Save()
Como abrimos la configuración para cambiarla, la bloqueamos primero, por si las moscas. Es conveniente, claro, que esa edición dure lo mínimo posible.
Hay que tener cuidado con el nuevo fichero "config.pck", porque puede tener los permisos incorrectos (porque lo hemos editado como "root"). Si es así, basta con cambiarlos. En mi caso me pone como propietario a "root", pero como grupo a "mailman", de forma que no me causa problemas. Y en cuanto la configuración se actualice de forma "normal" (por ejemplo, cuando empiece a transferir mensajes y actualice el "watermark"), esta anomalía desaparecerá automáticamente.
Si todo va bien, veremos algo así en el log:
Jun 04 19:23:02 2008 (29369) comp.arch: [44454..45011] Jun 04 19:23:02 2008 (29369) gating comp.arch articles [44948..45011] Jun 04 19:23:02 2008 (29369) posted to list comp.arch: 44948 Jun 04 19:23:03 2008 (29369) posted to list comp.arch: 44949 .............................................................. Jun 04 19:23:26 2008 (29369) posted to list comp.arch: 45009 Jun 04 19:23:27 2008 (29369) posted to list comp.arch: 45010 Jun 04 19:23:27 2008 (29369) posted to list comp.arch: 45011 Jun 04 19:23:27 2008 (29369) comp.arch watermark: 45011
¡Problema solucionado!. Compruebo también que el nuevo fichero de configuración tenga los permisos apropiados... ¡Todo perfecto!
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
