Guía de Administración de Redes con Linux - INN: Ficheros de Configuración (II)

Controlando el acceso de los Lectores de Noticias

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:

hostname

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

streaming

Esta clave determina si el servidor puede enviar flujos de órdenes. El valor es booleano, que por omisión está establecido a verdadero (true).

max-connections

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

password

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.

patterns

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:

Hostname o dirección IP

Este campo, está sujeto a las reglas sobre identidades que establece wildmat(3), y describe los nombres o direcciones IP de los servidores.

Permissions

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.

Username

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.

Password

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

Newsgroups

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:

patrón

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.

opciones_moderados

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.

mantener

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.

omisión

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

purgar

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 ||
Esta entrada le permite especificar el número mínimo de días que un artículo será recordado en el fichero de historial, sin tomar en cuenta de que el mismo haya expirado o no. Esto puede ser útil si uno de los sitios que le proveen de noticias es de uso poco frecuente o si tiene el hábito de enviarle artículos viejos o los mismos cada vez que accede a él. Introduciendo el campo /remember/ ayudará a prevenir que el servidor del cual se provee, vuelva a enviarle los mismo artículos incluso cuando éstos ya hayan caducado en su servidor local. Su servidor podrá recordar si un artículo ya ha sido recibido, y rechazará cualquier intento remoto de reenvío. Es importante recordar que esta configuración no surte efecto en todos los artículos; sólamente afecta a aquellos que se encuentran guardados en el historial. .

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.

El fichero control.ctl

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:

mensaje

Este es el nombre del mensaje de control. Los mensajes de control típicos se describen después.

desde

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

grupos_noticias

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.

acción

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:

checkgroups

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.

newgroup

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.

rmgroup

Petición de eliminar a un grupo.

sendsys

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.

version

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.

all

Este es un código especial que compara cualquier mensaje de control.

El campo mensaje debe contener alguna de las siguientes acciones:

doit

El comando requerido es ejecutado. En muchos casos, se envía un mensaje al administrador comunicándole qué acción ha temido lugar.

doit=fichero

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.

doifarg

La orden requerida se ejecuta si contiene algún argumento. Si no contiene ningún argumento, el mensaje de control se ignora.

drop

El mensaje solicitado se ignora.

log

Se envía a la salida un mensaje de registr stderr del proceso innd. Ésto generalmente está dirigido al fichero /var/log/news/errlog.

log=file

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.

mail

Se envía un correo al administrador de noticias conteniendo un pedido de detalle de un comando. Ninguna otra acción toma lugar.

verify-*

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

Notas

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