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: %[email protected]
#
# 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 [email protected], 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:[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 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/. |