Habiendo concluido con estas tareas generales, Ud. puede virar hacia la parte más interesante de INN: Sus archivos de configuración. Todos ellos residen en /etc/news. Algunos cambios se han introducido a partir de la versión 2, la cual es descripta aquí. Si Ud. tiene instalada una versión anterior, este capítulo le puede ser útil al momento de mejorar su actual configuración. Durante las próximas secciones, se discutirá cada archivo por separado, construyendo la configuración de la cervecería virtual como ejemplo.
Si necesita más información de alguna característica o de algún archivo en especial, puede consultar las páginas del manual; la distribución de INN contiene información de cada archivo por separado.
INN posee un número de parámetros que son de naturaleza global; estos afectan a todos los grupos de noticias que maneja.
El archivo principal de configuración de INN es inn.conf. En medio de otras cosas, éste determina como es conocida su computadora en Usenet. La versión 2 de INN posee un número desconcertante de parámetros. Afortunadamente, la mayoría de estos tienen valores por defecto, que son razonablemente compatibles para diferentes situaciones. El archivo de ayuda inn.conf(5) detalla todos los parámetros, y Ud. debería leerlo con cuidado si experimenta algún problema.
Un ejemplo simple de inn.conf se debe ver como este:
# Ejemplo de inn.conf para la cervecería virtual
server: vlager.vbrew.com
domain: vbrew.com
fromhost: vbrew.com
pathhost: news.vbrew.com
organization: La cervecería vertual
mta: /usr/sbin/sendmail -oi %s
moderatormailer: %s@uunet.uu.net
#
# Rutas de acceso y archivos de INN.
#
pathnews: /usr/lib/news
pathbin: /usr/lib/news/bin
pathfilter: /usr/lib/news/bin/filter
pathcontrol: /usr/lib/news/bin/control
pathdb: /var/lib/news
pathetc: /etc/news
pathrun: /var/run/news
pathlog: /var/log/news
pathhttp: /var/log/news
pathtmp: /var/tmp
pathspool: /var/spool/news
patharticles: /var/spool/news/articles
pathoverview: /var/spool/news/overview
pathoutgoing: /var/spool/news/outgoing
pathincoming: /var/spool/news/incoming
patharchive: /var/spool/news/archive
pathuniover: /var/spool/news/uniover
overviewname: .overview |
La primer línea le dice a rnews y a inews cuál es el servidor al que deben contactar para entregar los artículos. Esta entrada es absolutamente crucial; para pasarle artículos a innd, se debe establecer una conexión NNTP con el servidor.
El campo domain (dominio) debe contener la porción de la dirección del servidor que se encuentra completamente calificada. Un par de programas necesitan esta porción del nombre de dominio; si la librería que resuelve los nombres, solamente retorna nombres no calificados, el nombre dado en el campo domain es derivado hacia ella. No es un problema configurar este modo, pero es mejor definir un dominio en domain.
La siguiente línea define el nombre del servidor que inews va a utilizar cuando agregue la línea From: a los artículos publicados por los usuarios locales. Muchos lectores de noticias utilizan el campo From: cuando se compone un mensaje de respuesta para el autor de un artículo. Si Ud. omite este campo, por defecto, será llenado con el nombre de dominio completo. Esta es siempre la mejor opción. Ud. puede, por ejemplo, tener noticias y mensajes manejados por diferentes servidores. En este caso, Ud. deberá proveer el nombre del servidor de mail después de la declaración fromhost.
pathhost, define el nombre del servidor que INN agregará a la cabecera Path: cuando quiera recibir un artículo. El la mayoría de los casos, Ud. querrá utilizar el nombre del dominio de su servidor de noticias; si éste es el caso, puede omitir esta línea ya que por defecto se utiliza este nombre. Ocasionalmente, puede utilizar el nombre genérico, como por ejemplo news.vbrew.com,para dar servicio a un dominio grande. Haciendo esto, se puede mover el sistema de noticias fácilmente hacia un servidor diferente, cuando se requiera.
La siguiente línea contiene la clave organization. Esta declaración le permite saber a inews que texto debe ingresar en el campo Organization: de los artículos publicados por los usuarios locales. Formalmente, este es el lugar donde debe ir una descripción de su organización, o el nombre extendido de la misma. Si Ud. no desea ser tan formal, está muy de moda, que las organizaciones con un poco de humor lo expresen aquí.
El campo mta es obligatorio y especifica la ruta de acceso y el nombre del agente de transporte de los mensajes, usado para enviarle mensajes al moderador. %s es reemplazado por la dirección de mail del moderador.
La línea que contiene la entrada moderatormailer define la dirección por defecto que es utilizada cuando un usuario intenta dejar un mensaje en un grupo de noticias que se encuentra moderado. Las direcciones de los moderadores de cada grupo usualmente son guardadas en un archivo por separado, pero toma mucho tiempo seguirle los pasos a todos ellos. La entrada moderatormailer es, por consiguiente, consultada como último recurso. Si ésta es definida, inews reemplazará la cadena %s con el (sigilosamente transformado) nombre del grupo de noticias y enviará el artículo entero a esa dirección. Por ejemplo, si se desea publicar en soc. feminism, el artículo será enviado a soc-feminism@uunet.uu.net, pasándole la configuración citada. En UUNET, se debe encontrar el alias del mail, instalado para cada una de las direcciones dependientes, que serán automáticamente utilizadas para reenviar todos los mensajes al moderador apropiado.
Finalmente, cada una de las entradas restantes, especifica la ubicación de algún componente o archivo perteneciente a INN. Si Ud. instalo INN desde los paquetes, estas ubicaciones han sido creadas por usted. Por el contrario, si se decidió compilar el sistema, debe asegurarse que estas entradas reflejen las ubicaciones donde se encuentra INN.
El administrador del sistema de noticias, es capaz de controlar que usuarios tienen acceso a los grupos. INN provee dos archivos de configuración los cuales dejan al administrador decidir cuáles son los grupos de noticias a los cuales se les da soporte, y además proveen una descripción de cada uno de ellos.
Los archivos active y newsgroups son usados para guardar y describir los grupos de noticias hospedados en el servidor. En ellos se encuentran los grupos de noticias en los que se tiene interés en publicar y recibir artículos, y además, algo de información administrativa. Estos archivos se pueden encontrar en el directorio /var/lib/news/.
El archivo active determina a que grupos de noticias se le da soporte. Su sintaxis es lineal. Cada línea del archivo active contiene cuatro campos delimitados por un espacio en blanco:
name himark lomark flags |
El campo name es el nombre del grupo. El campo himark es el mayor número que se ha usado para un artículo en ese grupo. lomark es usado para guardar el número más bajo de un mensaje activo. Para ilustrar como trabaja esto, considere el siguiente escenario como ejemplo. Imagine que ha creado un grupo; himark y lowmark se encuentran en 0 por que no hay artículos. Luego se publican 5 artículos, que se numeran del 1 al 5. himark ahora estará en 5, el número del artículo más alto, y lowmark será puesto en 1, el número mas bajo. Si el artículo 5 es cancelado, no habrá ningún cambio; himark permanecerá sin cambios para asegurarse de que ese numero de artículo no sea usado nuevamente y lowmark seguirá en 1 el número de artículo más bajo. Ahora, si se cancela el artículo 1, himark permanecerá sin cambios, pero lowmark será igual a 2, ya que 1 no está mas en uso. Si luego se publica un nuevo artículo, se le asignará el número 6, lo que pondrá a himark en 6. El artículo 5 ha estado en uso, así que no se usará su numero por más que haya sido borrado. lowmark permanece en 2. este mecanismo le permite a Ud. encontrar un artículo fácilmente, ya que poseen números únicos y calcular de forma aproximada cuantos artículos activos hay en el grupo haciendo: himark–lowmark.
El campo flag, debe contener alguno de estos parámetros:
Permite la publicación de forma directa en el servidor.
Publicar directamente en el servidor no esta permitido. Esto previene que los lectores de noticias publiquen de forma directa los artículos en el servidor. Los artículos nuevos, deben venir de otros servidores de noticias.
El grupo está moderado. Cualquier artículo publicado en este grupo es desviado hacia la dirección del moderador, para su aprobación antes de ser publicado. La mayoría de los grupos, no están moderados.
Los artículos en estos grupos no son almacenados, solamente son pasados a otro servidor. Esto causa que el servidor de noticias acepte los artículos, pero todo lo que hace es reenviarlos al siguiente servidor que se encuentra mas alto en la cadena de flujo. Esto no permite que los artículos estén disponibles para lectura por parte de los usuarios de ese servidor.
Este grupo de noticias no acepta artículos. La única forma de que los artículos sean recibidos por este servidor, es que provengan de otro servidor de noticias. Los lectores de noticias, no podrán acceder para publicar artículos.
Los artículos son guardados en el servidor local con el nombre de grupo «foo.bar».
En nuestro ejemplo de configuración, tenemos una pequeña cantidad de grupos de noticias, así que el archivo /var/lib/news/active se verá de este modo:
control 0000000000 0000000001 y
junk 0000000000 0000000001 y
rec.crafts.brewing 0000000000 0000000001 y
rec.crafts.brewing.ales 0000000000 0000000001 y
rec.crafts.brewing.badtaste 0000000000 0000000001 y
rec.crafts.brewing.brandy 0000000000 0000000001 y
rec.crafts.brewing.champagne 0000000000 0000000001 y
rec.crafts.brewing.private 0000000000 0000000001 y |
El archivo newsgroups no es muy sofisticado. Solamente provee una breve descripción (de una sola línea) de los grupos de noticias. Algunos lectores son capaces de leer este archivo y presentarle la información al usuario para ayudarlo a decidir si quiere suscribirse al grupo descripto.
El formato del archivo newsgroups es el siguiente:
name description |
Para el ejemplo de la cervecería virtual, si deseamos poner una descripción a los grupos, cree un archivo newsgroups con el siguiente formato:
rec.crafts.brewing.ales Elaboración casera de cerveza negra y rubia
rec.crafts.brewing.badtaste Elaboración casera de cerveza adulterada
rec.crafts.brewing.brandy Elaboración casera de brandy
rec.crafts.brewing.champagne Elaboración casera de Champagne
rec.crafts.brewing.private Grupo local de la cervecería virtual |
INN le provee al administrador la habilidad de controlar cuales grupos son reenviados y de que forma, a otros servidores de noticias. El método mas usado, utiliza NNTP (visto anteriormente) como transporte, pero pueden utilizarse otros tales como UUCP.
En el archivo newsfeeds se encuentran determinados los artículos que serán enviados. Normalmente se encuentra en el directorio /etc/news/.
El formato de newsfeeds puede parecer un poco complicado al principio. Aquí será descripto de forma esquemática. Las páginas man de newsfeeds(5) explican como implementarlo. El formato es el siguiente:
# formato del archivo newsfeed
site:pattern:flags:param
site2:pattern2\
:flags2:param2 |
El campo site nombra el sitio al cual ese alimentador relaciona. El nombre del sitio puede ser codificado de la forma que uno quiera y no tiene que ser el nombre del dominio del sitio. Este nombre será usado posteriormente y se referirá a una entrada en una tabla que provee el nombre del servidor al programa innxmit que transmite los artículos a través de NNTP hacia el servidor remoto. Ud. puede tener múltiples entradas para cada sitio; cada entrada será tratada individualmente
El campo pattern especifica que grupos son enviados a ese servidor. Por defecto, son enviados todos los grupos. Si es lo que Ud. desea, solamente deje este campo en blanco. Este campo es usualmente una lista de expresiones que corresponden a un patrón de búsqueda, delimitado por comas. El carácter * equivale a cualquier carácter, incluyendo al cero. El carácter . (punto) no tiene ningún significado especial, el carácter ! (usado al comienzo de una expresión) realiza la operación lógica NOT, y el carácter @ al comienzo del nombre de un grupo significa que no se envíen o reenvíe ningún articulo publicado en el grupo. Esta lista, es leída y analizada gramaticalmente de izquierda a derecha, así que asegúrese de ingresar las reglas específicas al principio. Un ejemplo del patrón:
rec.crafts.brewing*,!rec.crafts.brewing.poison,@rec.crafts.brewing.private |
En el ejemplo, se desea enviar todos los grupos pertenecientes a la jerarquía rec.crafts.brewing excepto el grupo rec.crafts.brewing.poison. Tampoco se enviarán o recibiran artículos para el grupo rec.crafts.brewing.private el cual, solamente está disponible para los usuarios que utilizan el servidor local. Si Ud., en el ejemplo, invierte los dos primeros patrones de búsqueda, el primero de ellos será ignorado por el segundo, y los mensajes del grupo rec.crafts.brewing.poison serán enviados. Lo mismo pasa con el primer y último de ellos; Siempre se deben ingresar primero los parámetros más específicos, para que los menos específicos ingresados después de estos, sean efectivos.
El campo flags controla y restringe los artículos que van al proveedor de noticias. Este campo (flags) se encuentra delimitado por comas y contiene una lista de cualquiera de los comandos que se encuentran en la siguiente lista:
El tamaño del artículo debe ser menor que lo expresado, en bytes.
Los artículos serán verificados. items puede ser uno o más de d (deberá contener cabecera de distribución) o p (no se verificará el destino en la cabecera path).
Define el tamaño del buffer antes de escribirlo en la salida.
El artículo deberá tener por lo menos count saltos; por defecto, es 1.
Tamaño del buffer interno (para el archivo de salida).
Solo los grupos moderados pueden hacer uso del patrón.
Solo los grupos sin moderar pueden hacer uso del patrón.
Iniciar la cola de mensajes si el tamaño especificado en bytes es alcanzado.
Tipo de alimentación con el proveedor: f (archivo), m (canalizar; el campo param contiene el nombre al cual serán suministrados los artículos), p (tubería (pipe) que apunta a un programa), c (envía al canal de stdin los parámetros en param), y x (parecido al parámetro c pero manejando los comandos de stdin).
Que se escribirá: b (el tamaño del artículo en bytes), f (la ruta de acceso completa), g (el primer grupo de noticias), m (el identificador de artículo), n (la ruta de acceso relativa), s (origen del artículo), t (antigüedad), * (nombre del canal alimentador o todos los lugares donde llegará el artículo), N (cabecera del grupo de noticias), D (cabecera de distribución), H (todas las cabeceras), O (datos de información general), y R (datos de réplica).
El campo param tiene una codificación especial que es dependiente del tipo de suministro. En las configuraciones más comunes es donde se especificará el nombre del archivo de salida donde Ud. escribirá el suministro de salida. En otras configuraciones, puede dejarlo fuera. También, dependiendo de la configuración, puede tener otro significado. Si Ud. desea que realice algo inusual, el las páginas man de newsfeeds(5) le explicarán el uso de param con algunos detalles.
Existe un nombre especial que debe ser codificado como ME y debe ser la primer línea en el archivo. Esta entrada sirve para controlar las configuraciones por defecto para los suministros de noticias. Si la entrada ME tiene una lista de distribución asociada con ella, esta lista será anexada con cada una de las otras entradas antes de que se envíen. Esto le permite a Ud., por ejemplo, declarar cuales grupos de noticias serás automáticamente suministrados, o bloqueados de suministro, sin tener que repetir el patrón para cada entrada.
Se mencionó anteriormente que es posible el uso de suministros especiales para generar hilos de mensajes, haciendo más fácil el trabajo de los lectores de noticias. Esto es posible mediante el comando overchan que es parte del paquete INN. Para hacer esto, se debe crear un suministro especial llamado overview que será el que pase los artículos al comando overchan para luego ser procesados como información general.
El servidor de noticias mostrado como ejemplo, provee un solo suministro, que se dirige hacia la universidad Groucho Marx y recibe los artículos de todos los grupos excepto de control y de junk, el grupo rec.crafts.brewing.private queda para uso local solamente, y el grupo rec.crafts.brewing.poison que no queremos que la gente de la cervecería pueda publicar.
Se utiliza el comando nntpsend para el transporte de noticias vía NNTP hacia news.groucho.edu. nntpsend requiere el uso del método del archivo para la entrega, además de la ruta de acceso completa y el identificador de cada artículo. Cabe destacar que el campo param ha sido configurado con el nombre del archivo de salida. Volveremos al tema del comando nntpsend en un momento. El resultado del suministro de noticias es el siguiente:
# archivo /etc/news/newsfeeds para la Cervecería Virtual
#
# Envía todos los grupos por defecto, excepto control y junk
ME:!control,!junk::
#
# Genera ingormacion general para cualquier lector que se utilice.
overview::Tc,WO:/usr/lib/news/bin/overchan
#
# Alimenta a Groucho Marx University con todo, excepto el grupo privado
# y cualquier artículo publicado en rec.crafts.brewing.poison.
gmarxu:!rec.crafts.brewing.poison,@rec.crafts.brewing.private:\
Tf,Wnm:news.groucho.edu
# |
El programa nntpsend maneja la transmisión de los artículos usando NNTP como protocolo invocando al comando innxmit. Hemos hecho un vistazo de nntpsend anteriormente, pero él también dispone de un archivo de configuración para flexibilizar a nuestros suministros de noticias.
nntpsend espera encontrar archivos de guiones para los grupos que suministra. La ruta que el comando necesita para encontrar los guiones, sigue el siguiente patrón /var/spool/news/out.going/sitename. innd crea esos guiones cuando actúa como entrada en newsfeeds, como ya hemos visto anteriormente. Se especifica el nombre del sitio como nombre de archivo en el campo param y eso satisface los requerimientos de la entrada al comando nntpsend.
El programa nntpsend tiene un archivo de configuración llamado nntpsend.ctl que generalmente es guardado en el directorio /etc/news/.
El archivo nntpsend.ctl le permite asociar un nombre de dominio completo, algunas restricciones acerca del tamaño de los suministros, y un número de parámetros acerca de las transmisiones de un sitio en particular. El nombre del sitio significa excepcionalmente un suministro lógico de los artículos. El formato general es el siguiente:
sitename:fqdn:max_size:[args] |
La siguiente lista describe los elementos de este formato:
El nombre del sitio escrito en el archivo newsfeeds.
El nombre de dominio completo del servidor de noticias que será suministrado con los artículos.
El máximo volumen de artículos a suplir en una sola transferencia.
Argumentos adicionales que serán pasados el comando innxmit.
Nuestro ejemplo de configuración requiere un archivo nntpsend.ctl muy sencillo. Solo existe un suministro de noticias. Se restringe el tamaño máximo de tráfico a 2 MB y se pasa como argumento a innxmit un tiempo de espera de 3 minutos (180 segundos). Si se posee un sitio mas grande, simplemente se pueden crear nuevas entradas por cada suministro, que en tal caso se verán muy parecidas a esta:
# /etc/news/nntpsend.ctl
#
gmarxu:news.groucho.edu:2m:-t 180
# |
No hace mucho tiempo, era muy común que las organizaciones dieran acceso público a sus servidores de noticias. Hoy en día es muy difícil encontrar acceso público a algún servidor; la mayoría de las organizaciones, controlan cuidadosamente quién tiene acceso a sus servidores, típicamente conceden acceso solamente a los usuarios de su red. INN provee archivos de configuración para controlas esos accesos.
Se mencionó en la introducción a INN, que su eficiencia y manejo, consiste en separar el mecanismo de suministro del mecanismo de lectura de noticias. El archivo/etc/news/incoming.conf es donde se especifica cuales servidores lo van a proveer a Ud. de noticias usando el protocolo NNTP, además de algunos parámetros de control y como serán suministrados los artículos. Cualquier servidor que no se encuentre en la lista, no será manejado por el demonio innd en cambio, podrá manejarse con el demonio nnrpd.
La sintaxis del archivo /etc/news/incoming.conf es bastante simple, pero toma algún tiempo acostumbrarse a ella. Tres tipos de entradas están disponibles. Parejas (pairs) de clave/valor, para claves específicas con su valor respectivo; pares (peers), que especifica el nombre de los servidores que tienen permitido enviar artículos usando NNTP; y los grupos (gropups) , que es la manera de aplicar las parejas (pairs) de clave/valor a los grupos (groups) de pares(peers) . Las parejas clave/valor tienen tres tipos diferentes de ámbitos. Global, el cual abarca a cualquier par definido en el archivo. Grupos de parejas, que son aplicadas solamente a un grupo determinado. Parejas que son aplicadas a un solo par (peer). Las definiciones específicas anulan a las definiciones mas amplias: por consiguiente, las definiciones de pares (peers) anulan a las de grupos(groups) , que a su vez anulan a las globales.
Las llaves ({}) son usadas para delimitar el inicio y fin de un grupo (group) y las especificaciones de los pares (peer). El carácter # es usado como comentario. Las parejas (pairs) clave/valor son separadas por dos puntos (:) y aparecen de a una en diferentes líneas.
Existe un número de llaves diferentes. Las más comunes y útiles son:
Esta llave, separados por comas, especifica una lista de los nombres o direcciones IP de los servidores pares (peers) que están autorizados a enviar artículos. Si esta llave no es puesta, se usará como nombre del servidor la estiqueta del par (peer).
Esta llave determina si el servidor puede enviar flujos de comandos. El valor es booleano, que por defecto está establecido a verdadero (true).
Aquí se especifica el número máximo de conexiones que puede aceptar el grupo de pares (peers). Si el valor es cero, son ilimitadas (también se puede especificar usando none).
Puede especificar una contraseña que será usada por el par (peer) si éste esta autorizado a transferir noticias. Por defecto no se requiere el uso de contraseñas.
Esta llave especifica que grupos de noticias serán aceptados del par (peer) asociado. Este campo es codificado precisamente con las mismas reglas que se usan en el archivo newsfeeds.
En el ejemplo de la cervecería existe un solo servidor que espera suplirnos de noticias: el servidor de la universidad Groucho Marx. No se requiere una contraseña, pero nos aseguraremos de que no ingrese ningún artículo a nuestro grupo privado desde el exterior. El archivo hosts.nntp luce así:
# Cervecería virtual, archivo incoming.conf
# Parámetros globales
streaming: true
max-connections: 5
# Permitir la publicación de artículos vía NNTP de un cliente local.
peer ME {
hostname: "localhost, 127.0.0.1"
}
# Permitirle a groucho el acceso a todos los grupos excepto el local.
peer groucho {
hostname: news.groucho.edu
patterns: !rec.crafts.brewing.private
} |
Se mencionó anteriormente, que los lectores de noticias, y los servidores que no estén en la lista del archivo hosts.nntp, para conectarse al servidor de INN son manejados por el programa nnrpd. Este programa utiliza el archivo /etc/news/nnrp.access para determinar quién está autorizado a acceder al servidor de noticias, y que tipo de permisos tiene.
El archivo nnrp.access contiene una estructura similar a la vista en la configuración anterior. Está compuesto por un conjunto de patrones usados para encontrar equivalencias con nombres o direcciones IP de los servidores, y algunos campos que determinan que tipos de permisos se les conceden. Cada entrada debe aparecer en una sola línea, y los campos, separados por dos puntos. La última entrada de este archivo, debe coincidir con el nombre del servidor que va a ser usado, así que, nuevamente, deben ingresarse los patrones generales primero, seguidos de los más específicos. Los cinco campos deben ser ingresados en el orden en que aparecen en la siguiente lista:
Este campo, está sujeto a las reglas sobre identidades que establece wildmat(3), y describe los nombres o direcciones IP de los servidores.
Aquí se determinan los permisos que tendrá el servidor. Existen dos permisos: R le otorga permisos de solo lectura y P permisos de publicación.
Este campo es opcional y le permite a Ud. especificar el nombre de usuario del cliente NNTP que deberá autenticarse en el servidor antes de publicar algún artículo. Puede dejarse en blanco. No se pedirá autenticación alguna para leer artículos.
También es opcional, y es la contraseña que acompaña al campo anterior (username). Dejándolo en blanco, no se pedirá ninguna contraseña para publicar artículos
Este campo especifica un patrón de cuales son los grupos que el cliente tiene permitido el acceso. Este patrón sigue las mismas reglas usadas en el archivo newsfeeds La opción por defecto, es no acceder a ninguno, así que normalmente debería existir algún patrón configurado aquí.
En el ejemplo de la cervecería virtual, dejamos que cualquier cliente vía NNTP en el dominio de la cervecería, pueda leer y publicar en cualquier grupo de noticias. Además se da acceso a cualquier cliente vía NNTP (fuera del dominio) solamente a leer cualquier grupo de noticias excepto el grupo privado. Nuestro ejemplo del archivo nnrp.access se ve de esta forma:
# Cervecería Virtual - archivo nnrp.access
# Se permite la lectura pública de todos los grupos excepto el privado.
*:R:::*,!rec.crafts.brewing.private
# Cualquier servidor que pertenezca al dominio de la cervecería
# virtual, puede publicar y leer los artículos de cualquier grupo.
*.vbrew.com:RP::* |
Cuando los artículos son recibidos por el servidor, son guardados en el disco. Estos artículos deben estar disponibles un cierto período de tiempo para que su uso sea eficaz, de modo que los grandes servidores de noticias, consumen mucho espacio en disco manteniéndolos. Para asegurarse que espacio en disco es usado de forma efectiva, Ud. puede optar por eliminar automáticamente algunos artículos después de un periodo de tiempo. Este proceso es llamado expiración de artículos. Naturalmente, INN provee una manera automática para caducar los artículos.
El servidor INN utiliza un programa llamado expire para eliminar los artículos caducos. Este programa, utiliza un archivo llamado /etc/news/expire.ctl donde se encuentran las reglas que van a gobernar la eliminación de los artículos.
La sintaxis del archivo /etc/news/expire.ctl es medianamente simple. Como la mayoría de los archivos de configuración, las líneas en blanco y las que comienzan con el símbolo #, son ignoradas. La idea general, es que Ud. especifique una regla por línea. Cada una de estas reglas definen como se ejecutarán la tareas de expiración en los grupos que concuerden con el patrón suministrado. La sintaxis de una regla se ve de esta forma:
pattern:modflag:keep:default:purge |
La siguiente lista describe cada campo:
Este campo está delimitado por comas, y contiene una lista de los nombres o patrones de búsqueda para los grupos de noticias. La rutina wildmat (3) es usada para buscar con los patrones dados. La última regla que coincida con el nombre de un grupo es la única que va a ser aplicada, o sea que si desea aplicar patrones con comodines (*), se deben encontrar al principio del archivo.
Este parámetro describe como una regla es aplicada a un grupo moderado. puede usarse una M que asigna esa regla solamente a los grupos moderados, una U para los grupos que no están moderados, o una A la cual significa que se ignore el estado de moderado y se aplique la regla a todos los grupos de noticias.
El siguiente campo, le permite especificar el tiempo mínimo que un artículo que contenga la cabecera de expiración, se guarde antes de que expire. La unidad de tiempo es días, y este valor es guardado como una variable de punto flotante, así que Ud. puede especificar valores como 7.5 para siete días y medio. También puede especificar never si desea que los artículos se queden en el servidor para siempre.
El campo más importante, el cual le permite a Ud. especificar el tiempo que un artículo sin cabecera de expiración permanece en el grupo. La mayoría de los artículos no tienen cabecera de expiración ( expires). Este campo es codificado de la misma forma que el campo keep, donde never significa que los artículos sin la cabecera no expiren nunca
Este campo le permite a Ud. especificar el tiempo máximo que un artículo con cabecera de expiración será guardado luego de que expire. La codificación de este campo es la misma que para el campo keep.
Para la cervecería, nuestros requerimientos son simples. Serán guardados todos los artículos en todos los grupos 14 días por defecto, y entre 7 y 21 días los artículos que tengan cabecera de expiración (Expires). El grupo rec.crafts.brewing.private es interno, así que se prestará atención de que ningún artículo del mismo expire:
# archivo expire.ctl file de la cervecería virtual
# Los artículos expiran en 14 días por defecto,
# entre 7 y 21 días los que contengan cabecera Expires:
*:A:7:14:21
# Este es un grupo especial donde los artículos nunca expiran.
rec.crafts.brewing.private:A:never:never:never |
Existe una entrada especial que debe estar en el archivo /etc/news/expires.ctl. Ud. debe tener una línea en el archivo exactamente como se muestra a continuación:
/remember/:days |
Igualmente que con C News, INN puede procesar mensajes de control en forma automática. Un mecanismo de configuración muy potente es provisto por INN para controlar que acción es tomada para alguno de los mensajes de control y un mecanismo de control de acceso que puede iniciar acciones contra algún grupo de noticias
La estructura del archivo control.ctl es bastante simple. Su sintaxis es muy parecida a otros archivos de configuración que posee INN. Las líneas que comienzan con # (comentarios) son ignoradas, para continuar con una línea, se usa /, y los campos son delimitados con dos puntos :.
Cuando un mensaje de control es recibido, es verificado con cada regla en término. La última regla en el archivo que coincida con un mensaje es la que será usada, de modo que se deben poner primero las reglas genéricas y luego las más especificas al final del archivo. La sintaxis general es la siguiente:
message:from:newsgroups:action |
El significado de cada uno de los campos es el siguiente:
Este es el nombre del mensaje de control. Los mensajes de control típicos son descriptos luego.
Este es un patrón de búsqueda al estilo del shell para buscar a la persona que envía el mensaje. La dirección de mail es convertida a minúsculas antes de la comparación.
Si el mensaje de control es newgroup o rmgroup, este campo es un patrón de búsqueda al estilo shell para crear o eliminar grupos.
Este campo especifica que acción se debe tomar para cualquier mensaje que coincida con la regla. Existen muchas acciones que se pueden tomar; estas están descriptas en la siguiente lista.
El campo message de cada línea puede contener uno de estos valores:
Este mensaje envía una petición al administrador de noticias para que re-sincronice la base de datos de los grupos de noticias con la lista adjuntada en el mensaje.
Este mensaje envía una petición para la creación de un nuevo grupo. El cuerpo del mensaje de control debe contener una descripción corta del propósito de la creación de un nuevo grupo.
Petición de eliminar a un grupo.
Este mensaje envía una petición para que el archivo sys del servidor de noticias sea transmitido vía mail al creador del mensaje de control. En el documento RFC-1036 se describe que este es un requerimiento de los miembros de Usenet de que este archivo esté públicamente disponible ya que es usado para que el mapa de Usenet esté actualizado.
Este mensaje envía una petición para que el nombre y la versión del software utilizado por el servidor de noticias, le retornen al creador del mensaje de control.
Este es un código especial que compara cualquier mensaje de control.
El campo message debe contener alguna de las siguientes acciones:
El comando requerido es ejecutado. En muchos casos, un mensaje es enviado al administrador comunicándole que acción ha tomado lugar.
Esta acción es similar a doit excepto que crea un mensaje en el archivo (file) de registro. Si el nombre del archivo especificado es mail, la entrada de registro es enviada por mail. Si la cadena especifica es nula, el mensaje de registro es escrito en /dev/null lo que equivale a una acción descalificada (doit). Si el nombre del archivo (file) comienza con el carácter / , el nombre es tomado como un nombre de archivo absoluto; por el contrario, si no se especifica, será trasladado a /var/log/news/file.log.
El comando requerido es ejecutado si contiene algún argumento. Si no contiene algún argumento, el mensaje de control es ignorado.
El mensaje solicitado es ignorado.
Un mensaje de registro es enviado a la salida stderr del proceso innd Esto generalmente dirigido al archivo /var/log/news/errlog.
Es igual a la acción log excepto que el archivo de registro está especificado como un par de reglas dadas de la acción doit=file.
Un mail es enviado al administrador de noticias conteniendo un pedido de detalle de un comando. Ninguna otra acción toma lugar.
Si una acción comienza con la cadena “verify-”, el mensaje de control es autenticado usando PGP (o GPG). [1]
A continuación se muestra como se ve el archivo control.ctl en la práctica. Esto es un ejemplo ilustrativo del archivo, bastante limitado:
## Ejemplo de /etc/news/control.ctl
##
## Cuidado: No se debe utilizar este archivo, es suministrado
## solamente con propósitos ilustrativos.
## Manejo de mensajes de control
all:*:*:mail
checkgroups:*:*:mail
ihave:*:*:drop
sendme:*:*:drop
sendsys:*:*:log=sendsys
senduuname:*:*:log=senduuname
version:*:*:log=version
newgroup:*:*:mail
rmgroup:*:*:mail
## Manejo de mensajes de control para las ocho jerarquías más importantes
## COMP, HUMANITIES, MISC, NEWS, REC, SCI, SOC, TALK
checkgroups:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop
newgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop
rmgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop
checkgroups:group-admin@isc.org:*:verify-news.announce.newgroups
newgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify-news.announce.newgroups
newgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify-news.announce.newgroups
newgroup:group-admin@isc.org:talk.*|humanities.*:verify-news.announce.newgroups
rmgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify-news.announce.newgroups
rmgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify-news.announce.newgroups
rmgroup:group-admin@isc.org:talk.*|humanities.*:verify-news.announce.newgroups
## GNU ( Free Software Foundation )
newgroup:gnu@prep.ai.mit.edu:gnu.*:doit
newgroup:news@*ai.mit.edu:gnu.*:doit
rmgroup:gnu@prep.ai.mit.edu:gnu.*:doit
rmgroup:news@*ai.mit.edu:gnu.*:doit
## LINUX (Suministro para news.lameter.com)
checkgroups:christoph@lameter.com:linux.*:doit
newgroup:christoph@lameter.com:linux.*:doit
rmgroup:christoph@lameter.com:linux.*:doit |
| [1] | PGP y GPG son las herramientas designadas para autenticar o encriptar mensajes utilizando técnicas de llave pública. GPG es la versión GNU de PGP. GPG puede encontrarse en http://www.gnupg.org/, y PGP en http://www.pgp.com/. |