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.