Guía de Administración de Redes con Linux - Caducando Noticias

En B News, la caducidad de las noticias solía realizarse mediante el programa expire, que tomaba como argumento una lista de los grupos de noticias, junto con una especificación del tiempo después del cual los artículos caducaban. Para hacer que diferentes jerarquías caducasen en momentos distintos, tenía que escribir un guión que invocase a expire por cada uno de ellos en forma individual. C-News ofrece una solución más conveniente a esto. En un fichero llamado explist, puede especificar los grupos de noticias y los respectivos intervalos. Una orden llamada doexpire se activa diariamente desde cron y procesa todos los grupos acorde a esta lista.

Ocasionalmente, Ud. puede querer mantener artículos de ciertos grupos incluso después de que hayan caducado; por ejemplo, podría querer mantener los programas enviados a comp.sources.unix. A esto se le llama archivado. explist le permite marcar grupos para el archivado.

Una entrada en explist tiene el siguiente formato:

|| grouplist perm times archive ||

grouplist es una lista separada por comas de los grupos de noticias a los que aplica la entrada. Se pueden especificar jerarquías completas indicando el prefijo del nombre del grupo, añadiendo, opcionalmente all. Por ejemplo, para indicar una entrada que se aplique a todos los grupos de comp.os, o tambien comp.os o comp.os.all.

Cuando se van a caducar las noticias de un grupo, se constata el nombre del grupo con todas las entradas de explist en el orden dado. La primer entrada que coincida es la que se aplica. Por ejemplo, para eliminar la mayoría de comp después de cuatro días, excepto comp.os.linux.announce, que desea mantener por una semana, debe simplemente tener una entrada para esto, que especifique un período de caducidad de siete días, seguida por una para comp, que especifique cuatro días.

El campo perm detalla si la entrada se aplica a grupos moderados, no moderados, o a cualquier grupo. Debe tomar uno de los valores m, u, o x, lo que designa la condición de moderado, no moderado o cualquier tipo.

El tercer campo, times, usualmente contiene un solo número. Éste es el número de días después de los cuales caducarán los artículos si no se les ha asignado una fecha de caducidad artificial en el campo Expires: de la cabecera del artículo. Debe darse cuenta de que éste es el número de días contando desde la llegada a su servidor, no desde la fecha de publicación.

Sin embargo, el campo times puede ser más complejo que eso. Puede ser una combinación de hasta tres números separados unos de otros por un guión (-). El primero designa el número de días que tienen que pasar antes de que el artículo sea considerado candidato para estar caduco, incluso si el campo Expires: ya haya indicado esta condición. Rara vez es útil usar otro valor que no sea cero. El segundo campo, es el valor mencionado arriba, es decir, el número predeterminado de días después de los cuales caducará. El tercero es el número de días después de los cuales un artículo caducará incondicionalmente, sin tomar en cuenta si tiene un campo Expires: o no. Si sólo se indica el número de en medio, los otros dos toman valores por omisión. Éstos pueden especificarse usando la entrada especial /bounds/, la cual se describe un poco más abajo.

El cuarto campo, archive, designa si el grupo de noticias tiene que archivarse, y dónde. Si no desea archivarlo, debería usar un guión. De lo contrario, use la ruta completa (apuntando a un directorio), o use una arroba (@). La arroba designa el directorio de fichero por omisión cuyo valor debe darse a doexpire usando el parámetro –a en la línea de órdenes. Éste directorio debe ser propiedad del usuario news. Cuando doexpire archiva un artículo de, digamos, comp.sources.unix, lo almacena en el directorio comp/sources/unix bajo el directorio de fichero, creándolo si no existe. Sin embargo, no se creará el propio directorio de fichero.

Hay dos entradas especiales en el fichero explist de las que depende doexpire. En vez de una lista de grupos de noticias, tienen las palabras clave /bounds/ y /expired/. La entrada /bounds/ contiene los valores predeterminados usados por el campo times descrito anteriormente.

El campo /expired/ determina cuánto tiempo guardará C-News las entradas del fichero history. C-News no borrará una línea del fichero de historial una vez que el (los) artículo(s) hayan caducado, pero lo guardará por si acaso llega un duplicado tras esa fecha. De lo contrario, un par de semanas es un valor aconsejable para las redes UUCP, dependiendo de los retrasos que experimente con los artículos de esos servidores.

A continuación se reproduce un fichero explist de ejemplo con unos intervalos de expiración bastante ajustados:

|| # Mantiene las líneas de historial dos semanas. # Ningún artículo consigue más de tres meses. /expired/ x 14 - /bounds/ x 0-1-90 - # grupos que queremos mantener más tiempo que el resto. comp.os.linux.announce m 10 - comp.os.linux x 5 - alt.folklore.computers u 10 - rec.humor.oracle m 10 - soc.feminism m 10 - # Archiva los grupos *.sources comp.sources,alt.sources x 5 @ # Valores predeterminados para los grupos de tecnología. comp,sci x 7 - # Suficiente para un fin de semana largo. misc,talk x 4 - # desecha rápidamente lo inservible junk x 1 - # los mensajes de control, también son de escaso interés control x 1 - # para el resto de ellos, la entrada comodín all x 2 - ||

Hay un cierto número de problemas potenciales con la caducidad en C-News. Uno es que su lector de noticias puede depender del tercer campo del fichero active descrito anteriormente, el cuál contiene el número de artículo más bajo disponible. Cuando C-News caduca artículos, no actualiza este campo. Si necesita (o quiere) que este campo represente la situación real, necesita ejecutar un programa llamado updatemin después de cada ejecución de doexpire. (En versiones anteriores de C-News, existe un guión llamado upact que realiza este trabajo.)

C-News no caduca los artículos examinando el directorio de los grupos de noticias, sino que simplemente comprueba en el fichero history si el artículo debe caducar.[1] Si el fichero history consigue de alguna manera estar fuera de sincronismo, sus artículos pueden permanecer en su disco duro para siempre, porque C-News los ha olvidado literalmente.[2] Puede reparar esto usando el guión addmissing que se encuentra en /usr/lib/news/maint, el cuál añadirá los artículos perdidos al fichero history o a mkhistory, el cuál reconstruye el fichero desde cero. No olvide ser news antes de invocarlo, o de lo contrario terminará con un fichero history imposible de leer por C-News.

Notas

|| [1] || La fecha de llegada del artículo se almacena en el campo de en medio de la línea de historia, dado en segundos desde el 1 de Enero de 1970 ||
|| [2] || No se por qué ocurre esto, a mí me sucede de vez en cuando. ||