Habiendo concluido con estas tareas generales, puede dirigirse hacia la parte más interesante de INN: Sus ficheros de configuración. Todos ellos residen en /etc/news. Algunos cambios se han introducido a partir de la versión 2, la cual es descrita aquí. Si tiene nstalada una versión anterior, este capítulo le puede ser útil en el momento de mejorar su configuración actual. Durante las próximas secciones, se discutirá cada fichero por separado, construyendo la configuración de la Cervecera Virtual como ejemplo.
Si necesita más información de alguna característica o de algún fichero en especial, puede consultar las páginas del manual; la distribución de INN contiene información de cada fichero por separado.
INN posee un número de parámetros que son de naturaleza global; estos afectan a todos los grupos de noticias que gestiona.
El fichero principal de configuración de INN es inn.conf. Entre otras cosas, éste determina cómo se conoce su computadora en Usenet. La versión 2 de INN posee un número desconcertante de parámetros. Afortunadamente, la mayoría de éstos tienen valores predeterminados, que son razonablemente compatibles para diferentes situaciones. El fichero de ayuda inn.conf(5) detalla todos los parámetros, y debería leerlo con cuidado si experimenta algún problema.
Un ejemplo simple de inn.conf:
# Ejemplo de inn.conf para la Cervecera 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 ficheros 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 primera 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 biblioteca que resuelve los nombres, sólamente retorna nombres no calificados, el nombre dado en el campo domain se deriva 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 omite este campo, por domisión será completado con el nombre de dominio entero. Ésta es siempre la mejor opción. Puede, por ejemplo, tener noticias y mensajes gestionados por diferentes servidores. En este caso, deberá dar el nombre del servidor de correo 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. En la mayoría de los casos, querrá utilizar el nombre del dominio de su servidor de noticias; si éste es el caso, puede omitir esta línea ya que por omisión 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 qué texto debe introducir en el campo Organization: de los artículos publicados por los usuarios locales. Formalmente, éste es el lugar donde debe ir una descripción de su organización, o el nombre extendido de la misma. Si 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 correo, usado para enviarle mensajes al moderador. %s se reemplaza por la dirección de correo del moderador.
La línea que contiene la entrada moderatormailer define la dirección predeterminada que se utiliza 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 fichero separado, pero toma mucho tiempo seguirle los pasos a todos ellos. La entrada moderatormailer es, por consiguiente, consultada como último recurso. Si ésta está 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 correo, 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 fichero perteneciente a INN. Si instaló INN desde los paquetes, estas ubicaciones han sido creadas por usted. Por el contrario, si se decidió a 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 qué usuarios tienen acceso a los grupos. INN provee dos ficheros de configuración, los cuales dejan al administrador decidir cuáles son los grupos de noticias a los cuáles se les da soporte, y además proveen una descripción de cada uno de ellos.
Los ficheros active y newsgroups se usan para guardar y describir los grupos de noticias alojados 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 ficheros se pueden encontrar en el directorio /var/lib/news/.
El fichero active determina a qué grupos de noticias se le da soporte. Su sintaxis es lineal. Cada línea del fichero 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á más en uso. Si luego se publica un artículo nuevo, 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 número por más que haya sido borrado. lowmark permanece en 2. Este mecanismo le permite encontrar un artículo fácilmente, ya que poseen números únicos y calcular de forma aproximada cuántos 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 está 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, sólamente 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 más 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 fichero /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 fichero newsgroups no es muy sofisticado. Sólamente provee una breve descripción (de una sola línea) de los grupos de noticias. Algunos lectores son capaces de leer este fichero y presentarle la información al usuario para ayudarlo a decidir si quiere suscribirse al grupo descrito.
El formato del fichero newsgroups es el siguiente:
name description |
Para el ejemplo de la Cervecera Virtual, si deseamos poner una descripción a los grupos, cree un fichero 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 Cervecera Virtual |
INN le da al administrador la habilidad de controlar qué grupos son reenviados y de qué forma, a otros servidores de noticias. El método mas usado, utiliza NNTP (visto anteriormente) como transporte, pero pueden utilizarse otros como UUCP.
En el fichero 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á descrito de forma esquemática. Las páginas man de newsfeeds(5) explican cómo implementarlo. El formato es el siguiente:
# formato del fichero newsfeed
site:pattern:flags:param
site2:pattern2\
:flags2:param2 |
El campo site nombra el sitio con el cual ese alimentador se 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 se usará posteriormente y se referirá a una entrada en una tabla que proporciona el nombre del servidor al programa innxmit que transmite los artículos a través de NNTP hacia el servidor remoto. Puede tener múltiples entradas para cada sitio; cada entrada será tratada individualmente.
El campo pattern especifica qué grupos son enviados a ese servidor. Por omisión, son enviados todos los grupos. Si es lo que usted desea, sólamente 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 introducir 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 recibirán artículos para el grupo rec.crafts.brewing.private el cual, sólamente está disponible para los usuarios que utilizan el servidor local. Si, 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 introducir primero los parámetros más específicos, para que los menos específicos introducidos 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 las órdenes 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 búffer antes de escribirlo en la salida.
El artículo deberá tener por lo menos count saltos; por omisión es 1.
Tamaño del búffer interno (para el fichero de salida).
Sólo los grupos moderados pueden hacer uso del patrón.
Sólo 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 (fichero), 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 fichero de salida donde escribirá el suministro de salida. En otras configuraciones, puede dejarlo fuera. También, dependiendo de la configuración, puede tener otro significado. Si 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 primera línea en el fichero. Esta entrada sirve para controlar las configuraciones preeterminadas 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. Ésto le permite a Ud., por ejemplo, declarar cuales grupos de noticias serán 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 la instrucción 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 programa 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 sólamente, y el grupo rec.crafts.brewing.poison que no queremos que la gente de la Cervecera 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 fichero 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 fichero de salida. Volveremos al tema del comando nntpsend en un momento. El resultado del suministro de noticias es el siguiente:
# fichero /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 fichero de configuración para flexibilizar a nuestros suministros de noticias.
nntpsend espera encontrar ficheros 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 fichero en el campo param y eso satisface los requerimientos de la entrada al comando nntpsend.
El programa nntpsend tiene un fichero de configuración llamado nntpsend.ctl que generalmente es guardado en el directorio /etc/news/.
El fichero 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 fichero 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 fichero nntpsend.ctl muy sencillo. Sólo 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 más grande, simplemente se pueden crear nuevas entradas por cada suministro, que en tal caso se verán muy parecidas a ésta:
# /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 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 sólamente a los usuarios de su red. INN provee ficheros de configuración para controlar esos accesos.
Se mencionó en la introducción a INN que su eficiencia consiste en separar el mecanismo de suministro del mecanismo de lectura de noticias. El fichero /etc/news/incoming.conf es donde se especifica qué servidores van a proveerle de noticias usando el protocolo NNTP, además de algunos parámetros de control y cómo serán suministrados los artículos. Cualquier servidor que no se encuentre en la lista, no será gestionado por el demonio innd en cambio, podrá gestionarse con el demonio nnrpd.
La sintaxis del fichero /etc/news/incoming.conf es bastante simple, pero toma algún tiempo acostumbrarse a ella. Tres tipos de entradas están disponibles. Pares de clave/valor, para claves específicas con su valor respectivo; compañeros (peers), que especifican el nombre de los servidores que tienen permitido enviar artículos usando NNTP; y los grupos (groups) , que es la manera de aplicar los pares (pairs) de clave/valor a los grupos (groups) de compañeros . Los pares clave/valor tienen tres tipos diferentes de ámbitos. Global, el cual abarca a cualquier par definido en el fichero. Grupos de pares, que son aplicadas sólamente a un grupo determinado. Pares que son aplicadas a un solo compañero. Las definiciones específicas anulan a las definiciones más amplias: por consiguiente, las definiciones de compañeros (peers) anulan a las de grupos (groups), que a su vez anulan a las globales.
Las llaves ({}) se usan para delimitar el inicio y fin de un grupo (group) y las especificaciones de los compañeros (peer). El carácter # se usa como comentario. Los pares (pairs) clave/valor se separan por dos puntos (:) y aparecen de una a una en diferentes líneas.
Existe un número de claves diferentes. Las más comunes y útiles son:
Esta clave, separada por comas, especifica una lista de los nombres o direcciones IP de los servidores compañeros (peers) que están autorizados a enviar artículos. Si esta clave no se pone, se usará como nombre del servidor de la estiqueta del compañero (peer).
Esta clave determina si el servidor puede enviar flujos de órdenes. El valor es booleano, que por omisión está establecido a verdadero (true).
Aquí se especifica el número máximo de conexiones que puede aceptar el grupo de compañeros (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 compañero (peer) si éste está autorizado a transferir noticias. Por omisión no se requiere el uso de contraseñas.
Esta clave especifica qué grupos de noticias serán aceptados del compañero (peer) asociado. Este campo es codificado precisamente con las mismas reglas que se usan en el fichero newsfeeds.
En el ejemplo de la Cervecera 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 introduzca ningún artículo a nuestro grupo privado desde el exterior. El fichero hosts.nntp se muestra así:
# Cervecera virtual, fichero incoming.conf
# Parámetros globales
streaming: true
max-connections: 5
# Permitir la publicación de artículos por NNTP de un cliente local.
peer ME {
hostname: "localhost, 127.0.0.1"
}
# Permitirle a Groucho el acceso a todos los grupos excepto al privado.
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 fichero hosts.nntp, para conectarse al servidor de INN se gestionan por el programa nnrpd. Este programa utiliza el fichero /etc/news/nnrp.access para determinar quién está autorizado a acceder al servidor de noticias, y qué tipo de permisos tiene.
El fichero 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 qué 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 fichero, debe coincidir con el nombre del servidor que va a ser usado; así que nuevamente, deben introducirse los patrones generales primero, seguidos de los más específicos. Los cinco campos deben ser introducidos 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 sólo lectura y P permisos de publicación.
Este campo es opcional y le permite a 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 cuáles son los grupos a los que el cliente tiene permitido el acceso. Este patrón sigue las mismas reglas usadas en el fichero newsfeeds La opción predetermnada, es no acceder a ninguno, así que normalmente debería existir algún patrón configurado aquí.
En el ejemplo de la Cervecera Virtual, dejamos que cualquier cliente vía NNTP en el dominio de la cervecera, pueda leer y publicar en cualquier grupo de noticias. Además se da acceso a cualquier cliente por NNTP (fuera del dominio) sólamente para leer cualquier grupo de noticias excepto el grupo privado. Nuestro ejemplo del fichero nnrp.access se ve de esta forma:
# Cervecera Virtual - fichero 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 Cervecera
# Virtual, puede publicar y leer los artículos de cualquier grupo.
*.vbrew.com:RP::* |
Cuando los artículos se reciben en el servidor, se guardan 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 de que espacio en disco se usa de forma efectiva, puede optar por eliminar automáticamente algunos artículos después de un período de tiempo. Este proceso se llama expiración de artículos. Naturalmente, INN proporciona 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 fichero llamado /etc/news/expire.ctl donde se encuentran las reglas que van a dirigir la eliminación de los artículos.
La sintaxis del fichero /etc/news/expire.ctl es medianamente simple. Como la mayoría de los ficheros de configuración, las líneas en blanco y las que comienzan con el símbolo #, son ignoradas. La idea general, es que 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:
patrón:opciones_moderados:mantener:omisión:purgar |
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) se usa 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 fichero.
Este parámetro describe cómo se aplica una regla a un grupo moderado. Puede usarse una M que asigne esa regla sólamente a los grupos moderados, una U para los grupos que no están moderados, o una A la cuál 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 debe mantenerse guardado un artículo que contenga la cabecera de expiración. La unidad de tiempo es días, y este valor se guarda como una variable de punto flotante, así que 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 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 se codificado de la misma forma que el campo mantener, donde never significa que los artículos sin la cabecera no expiran nunca
Este campo le permite especificar el tiempo máximo que un artículo con cabecera de expiración será guardado después de que expire. La codificación de este campo es la misma que para el campo mantener.
Para la cervecera, nuestros requerimientos son simples. Serán guardados todos los artículos en todos los grupos 14 días por omisión, 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 para que ningún artículo del mismo expire:
# fichero expire.ctl file de la Cervecera Virtual
# Los artículos expiran en 14 días por omisión,
# 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 fichero /etc/news/expires.ctl. Debe tener una línea en el fichero exactamente como se muestra a continuación:
/remember/:días |
Igualmente que con C News, INN puede procesar mensajes de control de forma automática. INN proporciona un mecanismo de configuración muy potente para controlar qué acción se toma para uno de los mensajes de control y un mecanismo de control de acceso puede iniciar acciones contra algún grupo de noticias.
La estructura del fichero control.ctl es bastante simple. Su sintaxis es muy parecida a otros ficheros 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 se delimitan con dos puntos :.
Cuando se recibe un mensaje de control, se verifica con cada regla hasta el final. La última regla en el fichero 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 fichero. La sintaxis general es la siguiente:
mensaje:desde:grupo_noticias:acción |
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 se describen después.
Éste es un patrón de búsqueda al estilo del intérprete de órdenes para buscar a la persona que envía el mensaje. La dirección de correo se convierte 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 línea de órdenes para crear o eliminar grupos.
Este campo especifica qué acción se debe tomar para cualquier mensaje que coincida con la regla. Existen muchas acciones que se pueden tomar; éstas se describen en la siguiente lista.
El campo mensaje 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 fichero sys del servidor de noticias sea transmitido por correo al creador del mensaje de control. En el documento RFC-1036 se describe que éste es un requisito de los miembros de Usenet que este fichero esté disponible públicamente ya que se 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 mensaje debe contener alguna de las siguientes acciones:
El comando requerido es ejecutado. En muchos casos, se envía un mensaje al administrador comunicándole qué acción ha temido lugar.
Esta acción es similar a doit excepto que crea un mensaje en el (fichero) de registro. Si el nombre del fichero especificado es mail, la entrada de registro se envía por correo. Si la cadena especificada es nula, el mensaje de registro se escribe en /dev/null lo que equivale a una acción descalificada (doit). Si el nombre del (fichero) comienza con el carácter / , el nombre se toma como un nombre de fichero absoluto; por el contrario, si no se especifica, será trasladado a /var/log/news/file.log.
La orden requerida se ejecuta si contiene algún argumento. Si no contiene ningún argumento, el mensaje de control se ignora.
El mensaje solicitado se ignora.
Se envía a la salida un mensaje de registr stderr del proceso innd. Ésto generalmente está dirigido al fichero /var/log/news/errlog.
Es igual a la acción log excepto que el fichero de registro está especificado como un par de reglas dadas de la acción doit=fichero.
Se envía un correo 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 el fichero control.ctl en la práctica. Esto es un ejemplo ilustrativo del fichero, bastante limitado:
## Ejemplo de /etc/news/control.ctl
##
## Cuidado: No se debe utilizar este fichero, es suministrado
## sólamente 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 herramientas diseñadas para autenticar o encriptar mensajes utilizando técnicas de clave 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/. |