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: %[email protected]
#
# 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 [email protected], 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:[email protected]:*:verify-news.announce.newgroups
newgroup:[email protected]:comp.*|misc.*|news.*:verify-news.announce.newgroups
newgroup:[email protected]:rec.*|sci.*|soc.*:verify-news.announce.newgroups
newgroup:[email protected]:talk.*|humanities.*:verify-news.announce.newgroups
rmgroup:[email protected]:comp.*|misc.*|news.*:verify-news.announce.newgroups
rmgroup:[email protected]:rec.*|sci.*|soc.*:verify-news.announce.newgroups
rmgroup:[email protected]:talk.*|humanities.*:verify-news.announce.newgroups
## GNU ( Free Software Foundation )
newgroup:[email protected]:gnu.*:doit
newgroup:news@*ai.mit.edu:gnu.*:doit
rmgroup:[email protected]:gnu.*:doit
rmgroup:news@*ai.mit.edu:gnu.*:doit
## LINUX (Suministro para news.lameter.com)
checkgroups:[email protected]:linux.*:doit
newgroup:[email protected]:linux.*:doit
rmgroup:[email protected]: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/. |