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.
[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. |