El NNTP proporciona una forma de intercambio de noticias totalmente diferente de Cnews, para adaptarse a los protocolos de transporte usados en la Red. NNTP son las siglas de "Network News Transfer Protocol" (Protocolo de Transferencia de Noticias de Red), y no consiste en un paquete de programas en particular, sino que es un estándar de Internet1 Esta basado en una comunicación orientada a la conexión _generalmente sobre TCP_ entre un cliente en algún lugar de la red, y un servidor que almacena las noticias en disco.

La conexión de flujo permite al cliente y al servidor negociar la transferencia de artículos interactivamente, sin apenas retrasos, manteniendo bajo el número de artículos duplicados.

Junto con los altos ratios de transferencia de Internet, esto supone un transporte de noticias que supera ampliamente a las redes UUCP originales. Mientras que hace algunos años no era extraño que un articulo tardase dos semanas o más en llegar hasta el último rincón de Usenet, ahora suele tardar menos de dos días; en la propia Internet, es incluso cuestión de minutos.2

Varios comandos permiten a los clientes obtener, enviar y publicar artículos. La diferencia entre enviar y publicar es que esto último puede incluir a artículos con cabeceras incompletas.3 La obtención de artículos puede ser usada por clientes de transporte de noticias o por lectores de noticias. Esto hace del NNTP una excelente herramienta para proporcionar acceso a muchos clientes de una red local sin tener que pasar por las dificultades que implica usar NFS.

_____________________________________________
1 Especificado formalmente en la RFC 977.
2 N. del T.: Parece ser que el autor tiene la fortuna de no conocer los servidores españoles.
3 Cuando se publica un articulo mediante NNTP, el servidor siempre añade como mínimo un campo en la cabecera: NNTP-Posting-Host:, que contiene el nombre del sistema del cliente.

El NNTP también proporciona una forma activa y otra pasiva de transmitir las noticias, llamadas coloquialmente "empujar" y "tirar". Empujar es básicamente lo mismo que el protocolo ihave/sendme de Cnews. El cliente ofrece un articulo al servidor a través del comando "IHAVE <msgid>", a lo que el servidor responde con un código que indica si ya tiene el artículo o si lo quiere. En el último caso, el cliente envía el artículo, terminado en un solo punto en una línea separada.

Empujar las noticias tiene la única desventaja de que consume muchos recursos del servidor, ya que éste tiene que buscar en su archivo histórico para cada artículo.

La técnica opuesta es tirar de las noticias, en la que el cliente solicita una lista de todos los artículos disponibles en un grupo que hayan llegado después de una fecha especificada.

La consulta es llevada a cabo por el comando NEWNEWS. De la lista de identificativos de mensaje obtenida, el cliente selecciona aquellos que aun no tenga, usando el comando ARTICLE para obtener cada uno de ellos.

El problema de esta técnica es que necesita un estricto control por parte del servidor, que debe tener en cuenta que grupos y distribuciones permite solicitar al cliente. Por ejemplo, debe asegurarse de que ningún material confidencial de sus grupos locales sea enviado a clientes no autorizados.

Existe también cierto número de comandos convenientes para los lectores de noticias que permiten obtener la cabecera del articulo y el cuerpo del mismo separadamente, o incluso solo ciertos campos de la cabecera de un rango de artículos. Esto permite mantener todas las noticias en un servidor central, con todos los usuarios de la red (presumiblemente local) utilizando programas clientes basados en el NNTP para leer y publicar. Esto es una alternativa a exportar los directorios mediante NFS tal como se describe en el capítulo 17.

Un problema extendido en NNTP es que permite a gente con los conocimientos suficientes insertar artículos con remitentes falsos en el flujo de noticias. Esto se conoce como falsificar las noticias.4 Una extensión del NNTP permite requerir autentificación del usuario para ciertos comandos.

Hay cierto número de paquetes NNTP disponibles. Uno de los mas conocidos es el demonio NNTP, también conocido como la implementación de referencia. Fue escrito originalmente por Stan Barber y Phil Lapsley para ilustrar los detalles de la RFC 977. Su versión más reciente es nntpd-1.5.11, que se describirá a continuación. Usted puede obtener el código fuente y compilarlo por su cuenta, o usar el nntpd del paquete binario net-std de Fred van Kempen. No se proporcionan ejecutables del nntpd listos para funcionar, ya que varios valores específicos de cada sistema deben ser introducidos antes de la compilación.

_____________________________________________
4 El mismo problema existe con el SMTP, el Simple Mail Transfer Protocol (Protocolo Simple para Transferencia de Correo).

El paquete nntpd consiste en un servidor y dos clientes para empujar y tirar de las noticias, respectivamente, así como un sustituto para inews. Están pensados para trabajar en el entorno de Bnews, pero trabajándoselo un poco lo harán con Cnews sin demasiada dificultad. Sin embargo, si planea Vd. usar el NNTP para algo mas que ofrecer acceso a su servidor a los lectores de noticias, la implementación de referencia no es realmente una opción. Por tanto, discutiremos solamente el demonio NNTP contenido en el paquete nntpd, dejando de lado los programas clientes.

También hay un paquete llamado "InterNet News", o INN para abreviar, escrito por Rich Salz. Este paquete proporciona tanto transporte NNTP como UUCP, y es el más adecuado para grandes servidores. En lo que a transporte NNTP se refiere, es definitivamente mejor que nntpd. La versión actual de INN es inn-1.4sec. Existe un paquete de Arjan de Vet para construir INN en una maquina Linux; esta disponible en sunsite.unc.edu en el directorio system/Mail. Si quiere configurar INN, por favor remítase a la documentación que acompaña al código fuente, así como al FAQ de INN, publicado regularmente en news.software.b.

El servidor NNTP se llama nntpd, y puede ser compilado de dos maneras, según el tráfico que se espera que soporte el sistema de noticias. No hay versiones compiladas disponibles, ya que algunos valores por defecto dependientes del sistema en que se vaya a instalar deben ser especificados antes de la compilación. Toda la configuración se hace a través de macros #define en common/conf.h.

nntpd puede ser configurado como un servidor independiente que se inicie desde rc.inet2 al arrancar, o como un demonio controlado por inetd. En el último caso se tendrá que añadir la siguiente entrada en /etc/inetd.conf:

Si configura Vd. nntpd como servidor independiente, asegúrese de que la línea anterior esta comentada en inetd.conf. En cualquier caso, tendrá Vd. que asegurarse de que existe la siguiente línea en /etc/services:

Para almacenar temporalmente los artículos que llegan al sistema, etc, nntpd también necesita un subdirectorio .tmp en el directorio de almacenamiento de noticias. Puede Vd. crearlo usando

El acceso a los recursos NNTP se rige por el fichero nntp_access en /usr/lib/news. Las líneas del fichero describen los derechos de acceso para ordenadores ajenos. Cada línea tiene el siguiente formato:

Si un cliente se conecta al puerto NNTP, nntpd intenta obtener su nombre completo en la red a partir de su dirección IP. El nombre del ordenador del cliente y su dirección IP son contrastados con el campo site de cada entrada, en el mismo orden en el que aparecen en el fichero. Las coincidencias pueden ser parciales o exactas. Si una entrada coincide exactamente, se aplica; si la coincidencia es parcial, solo se aplica si no hay otra entrada posterior igual o mejor. site puede especificarse de una de las siguientes formas:

Las entradas con especificaciones mas generales deberían ser introducidas al principio del fichero, ya que después pueden ser descartadas al encontrarse mejores coincidencias en entradas posteriores.

Los campos segundo y tercero describen los derechos de acceso que se otorgan al cliente.

El segundo detalla los permisos de lectura (read) y transmisión por empuje (xfer) de noticias.

El valor both habilita ambos, el valor no niega el acceso a los dos. El tercer campo detalla si el cliente puede publicar artículos, es decir, enviar artículos con información incompleta en la cabecera que será completada por los programas de noticias. Si el segundo campo contiene no, el tercero es ignorado.

El cuarto campo es opcional. Contiene una lista de grupos separados por comas a los que el cliente no puede acceder.

A continuación se muestra un fichero nntp_access de ejemplo:

Al poner en mayúsculas los elementos del fichero nntp_acces, tales como xfer o read, nntpd exige que el cliente este autorizado para realizar dichas operaciones. Por ejemplo, si se especifica el permiso Xfer o XFER, nntpd no dejara transmitir artículos al cliente a menos que éste acredite que esta autorizado.

El proceso de autorización se lleva a cabo por un nuevo comando del NNTP llamado AUTHINFO. Usando este comando, el cliente transmite un nombre de usuario y una contraseña al servidor NNTP. nntpd los validara comprobando el fichero /etc/passwd, y verificando que el usuario pertenece al grupo nntp.

Lo actual implementación de la autorización NNTP es solo experimental, por lo que no se ha hecho muy portable. Por ello solo funcionara con ficheros /etc/passwd normales; el shadow password no esta soportado.

Cuando recibe un articulo, nntpd debe pasarlo al sistema de noticias. Dependiendo de si lo recibió mediante el comando IHAVE o el POST, lo enviara a rnews o inews, respectivamente. En vez de llamar a rnews, nntpd también puede configurarse (antes de la compilación) para empaquetar los artículos entrantes, y dejar los paquetes resultantes en el directorio /var/spool/news/in.coming, donde serán procesados por relaynews la próxima vez que se le invoque.

Para llevar a cabo con éxito el protocolo ihave/sendme, nntpd tiene que poder acceder al fichero histórico history. Por tanto, antes de la compilación hay que asegurarse de que la ruta a dicho fichero esta correctamente especificada. También hay que asegurarse de que Cnews y nntpd usen el mismo formato de fichero histórico. Cnews usa funciones dbm para acceder al fichero; sin embargo hay bastantes implementaciones ligeramente incompatibles de la librería dbm. Si Cnews esta enlazado con una librería dbm distinta a la de libc, también deberá enlazarse nntpd con dicha librería.

Un síntoma típico de que nntpd y Cnews discrepan en el formato del fichero histórico son los mensajes de error de que nntpd no puede abrirlo, o la recepción de artículos duplicados por NNTP. Una prueba conveniente es coger un articulo del sistema, hacer telnet por el puerto del nntpd, y ofrecérselo a nntpd tal como se muestra en el ejemplo de abajo.

Por supuesto, deberá reemplazarse <msg@id> con el identificativo del articulo que quiera ofrecerse a nntpd.

Este diálogo muestra la reacción correcta de nntpd : el mensaje "Got it" indica que ya tiene dicho articulo. En cambio, si se obtuviese un mensaje como "335 Ok", significaría que nntpd no ha podido acceder adecuadamente al fichero histórico. Cierre la sesión telnet con Ctrl-D. Puede comprobar que ha ido mal revisando el archivo de registro (log) del sistema; nntpd envía todo tipo de mensajes a syslog. El uso de una librería dbm incompatible suele reflejarse en un mensaje que indica que dbminit ha fallado.