Mini-COMO para inn2+suck+varios servidores de news. <author>Han Solo <tt><hsolo@escomposlinux.org></tt> <date>v. 0.1 24 de Marzo de 2000 <abstract>Este documento describe cómo montar de manera rápida un servidor <tt/inn2/ local e intercambiar noticias de varios servidores con <tt/suck/. </abstract> <toc> <sect>Descargo y licencia. <p> Lo habitual en estos casos, yo no garantizo nada, no me responsabilizo de lo que pueda estropearse si haces caso de este documento, no tiene porqué funcionar en tu sistema y lo único que puedo decir es que a mi me ha funcionado. Este documento se distribuye bajo licencia GPL y todas esas cosas que ya sabéis; es decir, lo podéis copiar, manipular, traducir... pero sería un detalle que me mandárais una copia. <sect>Dedicatoria. <p> Este documento está dedicado a Benjamín Albiñana, por dos razones: La primera es que se saque la espinita de <tt/inn2/; no se puede ir por ahí, presumiendo de ser un tipo de pelo en pecho, y funcionar con <tt/leafnode/. La segunda es para que luego no diga que los emacseros no tenemos nuestro corazoncito... <sect>Consideraciones previas. <p> Hay varias maneras de configurar <tt/inn2/ frente al tradicional inn. Ahora, se pueden almacenar las news en un </em/spool/ local más compacto, en lugar de la forma tradicional de una fichero por cada mensaje. Yo he escogido hacerlo a la manera tradicional por dos razones: le primera es que estoy actualizando desde un sistema inn 1.7, y ya tenía artículos en el <em/spool/ tradicional. La segunda es que (no lo he comprobado), <tt/suck/ no es capaz de intercambiar mensajes si están almacenados en el nuevo formato. Yo tengo el sistema funcionando a partir de los script que vienen con <tt/suck/ modificados. Si usas el nuevo sistema de almacenamiento de almacenamiento de <tt/inn2/, tendrás que usar <tt>newsx</tt> para el intercambio de noticias. El usar varios servidores, no sé cómo se podrá hacer entonces y te lo tendrás que currar tú ;-). Yo intercambio artículos con dos servidores: <em/news.cis.dfn.de/ y <em/news.antakira.conf/. El primero es un servidor alemán, que requiere registrarse previamente en <htmlurl url="http://www.cis.dfn.de" name="http://www.cis.dfn.de"> Por otra parte, he escrito este documento en <tt>sgml</tt> utilizando el DTD <tt>linuxdoc</tt>. Últimamente, parece que es estándar de moda es <tt>DocBook</tt>, pero no tengo tiempo ahora de ponerme a explorar ese DTD, así que si a alguien le apetece, puede pasarlo a <tt>DocBook</tt>. Por otra parte, a mí me gusta más la salida del <tt/linuxdoc/ clásico. <sect>Cómo funciona todo esto. <p> La idea de todo esto es tener un sistema de news local, para leer las news offline. Para ello, instalamos un servidor de news local, <tt/inn/, que es al que se conectarán nuestros clientes (Gnus, Netscape, e incluso, por qué no, slrn). cuando escribamos, lo haremos a nuestro servidor. Estos mensajes que escribamos, lo tendremos que mandar a otros servidores de news, generalmente los de nuestro ISP. Por otro lado, para necesitaremos bajar las news del servidor de nuestro ISP a nuestro servidor local. De todo este intercambio de mensajes se encarga <tt>suck</tt>. Suck es el que ``llama'' a los distintos servidores, se identifica si es necesario, baja los artículos nuevos y envía los que hayamos escrito. <tt/suck/ se comporta como un cliente ante ambos servidores, el local y el remoto. Esto es así, porque existen dos protocolos para el intercambio de noticias: el nntp, usado para el intercambio entre servidores, y el nnrp, para el intercambio con clientes. Para bien o para mal, nuestro servidor no puede intercambiar artículos mediante nntp, ya que los servidores ``grandes'' sólo admiten este tipo de intercambio con un puñado de servidores ``escogidos''. Así pues, tendremos que configurar por separado <tt/inn/ y <tt/suck/, y a eso dedicaremos los siguientes capítulos. <sect>Elementos necesarios.</sect> <p> Pues no son demasiados, <tt/inn2/ y <tt/suck/ ;-)Yo estoy usando una distribución <htmlurl url="http://www.debian.org" name="Debian Potato">, con los paquetes siguientes: <tscreen><verb> $ dpkg -l suck inn2 Desired=Unknown/Install/Remove/Purge/Hold | Estado=No/Instalado/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: mayúsc.=malo) ||/ Nombre Versión Descripción +++-==============-==============-============================================ ii suck 4.2.2-4 Small newsfeed from an NNTP server with stan ii inn2 2.2.2.2000.01. News transport system `InterNetNews' by the </verb></tscreen> Si usas otra distribución, las cosas podrían cambiar un poco, pero no creo que demasiado. <sect>Configuración de <tt/inn/.</sect> <p> Para empezar, supondré que ya tienes <tt/inn/ instalado. No entraré pues en los detalles de la compilación ni en la instalación desde paquetes <tt/.deb/, <tt/.rpm/ o similares. Para eso está la documentación de la instalación de <tt/inn/ y los manuales de los sistemas de paquetes. Sólo hablaré de los ficheros de configuración. <sect1>El sistema de almacenamiento. <p> Como dijimos más arriba, hay varias formas de almacenar los artículo que bajemos en nuestro servidor local: la primera es el sistema <em/tradicional/, en el que cada mensaje se almacena en un fichero, y estos ficheros se ordenan en directorio siguiendo el nombre de la jerarquía a la que pertenecen; esto es, un artículo de <tt/es.comp.os.linux.misc/, se guardará en <tt>/var/spool/news/es/comp/os/misc/</tt>. Según la documentación, el problema de este sistema en que el acceso a los artículos es un cuello de botella en sistemas con mucha carga. La segunda forma de almacenar los mensajes el tipo <em/timehash/, que que es parecido al tradicional, pero la clasificación en directorios se hace en base a la fecha de llegada. El cuello de botella se reduce porque hay menos archivos en cada directorio. La tercera forma es el método <em/cnfs/. Los artículos se guardan en un <em/buffer/ preconfigurado. Cuando los artículos van llegando, se van borrando automáticamente los más antiguos. Como dijimos antes, nos quedaremos con el sistema tradicional, que es el compatible con <tt/suck/. <sect1>Ficheros de configuración. <p> En principio, al menos en Debian, los ficheros de configuración de <tt/inn/ están en el directorio <tt>/etc/news/</tt>. En adelante, nos referiremos a ellos sólo por su nombre. Otro detalle importante, es que todas las modificaciones a los ficheros de configuración hay que hacerlas como usuario <tt/news/; de lo contrario, habrá cosas que no funcionen aunque aparentemente estén bien. De hecho, lo más probable es que <tt/inn/ ni siguiera arranque, y os aviso que los mensajes de error de <tt/inn/ son bastante ``opacos''. <sect1><tt/inn.conf/ <p> Este es uno de los ficheros más importantes de la configuración de <tt/inn/. Tiene multitud de opciones que se describen en su página man (<tt/man inn.conf/). Conviene leérsela con calma. Os pongo las que yo he cambiado: <tscreen><verb> organization: The Rebel Alliance server: alderaan.maptel.es pathhost: alderaan.maptel.es domain: maptel.es fromhost: alderaan.maptel.es </verb></tscreen> Aparte, cambié alguna más, en lo referente a los directorios donde se almacenan los artículos, pero no recuerdo exactamente los cambios que hice, así que os pego el final del fichero para que veáis cómo lo tengo: <tscreen><verb> # --------------------------------- # Paths to various aspects of the news system # 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: /tmp pathspool: /var/spool/news patharticles: /var/spool/news 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 </verb></tscreen> <sect1><tt/newsfeeds/ <p> Este es el fichero más oscuro y difícil de toda la configuración de inn. Es el que controla cómo y hacia dónde se envían los artículos, hace los enlaces en los mensajes<em/crossposteados/... <footnote>Prometo flagelarme un par de horas después de haber escrito semejante ``palabra''.</footnote>. Este fichero tiene muchas opciones, y no es fácil comprender lo que hace cada una de ellas. Os sugiero una lectura cuidadosa. Como siempre, <tt/man newsfeeds/. Este fichero se organiza en <em/feeds/<footnote>He sido incapaz de encontrar una traducción satisfactoria para esta palabra. Los más aproximado, en el contexto de este fichero, sería <em/fichero de alimentación/, pero me parece lamentable.</footnote>. Cada <em/feed/ se divide en cuatro secciones, separadas por ``:''. Cada sección, puede ocupar más de una línea, separándolas por ``\''. El esquema, sacado de la página <tt/man/, e el siguiente: <tscreen><verb> sitename[/exclude,exclude,...]\ :pattern,pattern...[/distrib,distrib...]\ :flag,flag...\ :param </verb></tscreen> La primera línea indica el nombre del <em/feed/; aunque en al manual le llame <tt/sitename/, el concepto es más amplio. De hecho, puede ser cualquier nombre, aunque si se coge el nombre del servidor remoto, simplifica algo las cosas, si se sabe lo que se está haciendo. Lo describiremos más adelante. Opcionalmente, puede llevar una lista de exclusión, que explicaremos más tarde con un ejemplo. La segunda sección indica cual serán los grupos que se distribuirán en este <em/feed/. Lo de las <tt/distributions/ todavía no he llegado a saber para que sirve, pero tampoco lo he necesitado. No deben ser imprescindibles para un uso local. Vienen descritas en <tt/newsfeeds (5)/, así que si tienes curiosidad, ya sabes. ¡Ah!, y si me cuentas para que sirven, pues mejor. El siguiente campo es una lista de marcas que determina el tipo de <em/feed/ y y establece ciertos parámetros. Para una descripción completa, <tt/man newsfeeds/. El último campo depende de lo que hayamos puesto en el tercero. Como antes, mira la página man para más detalles Ahora, vamos a ir viendo las distintas entradas que tengo en mi <tt>/etc/news/newsfeeds</tt>: <tscreen><verb> ME\ :*,@alt.binaries.warez.*,!junk,!control*,!local*,!foo.*\ /world,usa,na,gnu,bionet,pubnet,u3b,eunet,vmsnet,inet,ddn,k12\ :: </verb></tscreen> La entrada <tt/ME/ es una entrada especial, y tiene que ser necesariamente la primera en <tt/newsfeeds/. La explico. Si la entrada <tt/ME/ tuviera una lista de exclusión (en este caso no la tiene), cualquier mensaje que tuviera en el campo (cabecera) <tt/path:/ un servidor de la lista sería descartado inmediatamente. La segunda línea indica que se aceptan todos le mensajes (``*'') excepto lo que vengan de los grupos <tt/junk, control*, local* y foo.*/. Además, se rechazan los que vayan a los grupos <tt/alt.binaries.warez.*/ aunque vengan por <em/crosspost/ de otros grupos admitidos. Este matiz lo define la arroba (``@''). Los asteriscos actúan como comodines: de esta forma, <tt/local*/ incluye <tt/local.pruebas, local.experimentos/... Además, de limitar la entrada de mensajes, <tt/ME/ limita la salida de dichos grupos. Es muy útil para pruebas locales, o para tener grupos corporativos, sin que intenten distribuirse a otros servidores. La línea siguiente (dentro del mismo campo, o sección), indica las distribuciones que se aceptan, caso de que el mensaje lleve indicada una distribución concreta. El siguiente campo, está vacío en este caso. La opción por defecto es <tt/Tf/ (una vez más, <tt/man newsfeeds/ si tienes curiosidad...). La última sección, también está vacía, lógico teniendo en cuenta que la anterior también estaba en blanco. Lo siguiente en mi <tt/newsfeeds/ es: <tscreen><verb> crosspost:*:Tc,Ap,WR:/usr/lib/news/bin/crosspost </verb></tscreen> Si usas crosspost (altamente recomendado en la doc de <tt/inn/), hay que añadir la opción <tt/-L/ a la variable <tt/innflags/ en el fichero <tt/inn.conf/. <tscreen><verb> innfeed!:\ !*,\ :Tc,Wnm*,S30000:/usr/lib/news/bin/startinnfeed controlchan!\ :!*,control,control.*,!control.cancel\ :Tc,Wnsm:/usr/lib/news/bin/controlchan </verb></tscreen> Y ahora, la parte emocionante, la que se refiere a los servidores que estamos usando: <tscreen><verb> # Servidor news.cis.dfn.de cis-dfn/news.cis.dfn.de,news.dfncis.de,fu-berlin.de,uni-berlin.de,\ news.antakira.com,kenobi.antakira.com\ :*,!alt.sex.*,!es.pruebas,!linux.debian.spanish\ :: # Servidor antakira antakira/news.cis.dfn.de,news.dfncis.de,fu-berlin.de,uni-berlin.de,\ news.antakira.com,kenobi.antakira.com\ :!*,alt.sex.*,es.pruebas,linux.debian.spanish\ :: </verb></tscreen> Como se ve, se puede usar cualquier nombre para referirse al <em/sitename/ o <em/feed/. La lista de exclusión, contiene los nombres de los servidores de los que estemos bajando artículos y sus alias. Son iguales en las dos entradas para que no se crucen mensajes entre servidores. Los nombres de los servidores que aparecen se comparan con la cabecera ``<tt/path:/'' de cada mensaje. Así, un mensaje que venga de <em/news.cis.dfn.de/ no será reenviado por ninguno de los dos servidores. El siguiente campo indica qué grupos se enviarán por cada servidor. Para la entrada <tt/cis-dfn/: <tscreen><verb> :*,!alt.sex.*,es.pruebas,!linux.debian.spanish\ </verb></tscreen> Indica que por aquí se enviarán todos los mensajes (``<tt/*/''), excepto (``<tt/!/'') los del grupo<footnote>No seáis mal pensados, no son grupos porno aunque pudiera parecerlo. Se trata de <tt/alt.sex.jargon.ecol/ y de <tt/alt.sex.kick.me.I.am.using.emacs/</footnote> <tt/alt.sex*, es.pruebas/ y <tt/linux.debian.spanish/. Por el contrario, la línea equivalente de la entrada de <tt/antakira/: <tscreen><verb> :!*,alt.sex.*,es.pruebas,linux.debian.spanish\ </verb></tscreen> Indica que por este servidor no se envíe ningún mensaje (``<tt/!*/''), salvo <tt/alt.sex*, es.pruebas/ y <tt/linux.debian.spanish/. <sect1><tt/incoming.conf/. <p> Este fichero indica qué máquinas se pueden conectar a nuestro servidor, como servidores. Para un uso casero, basta con nuestra máquina y las de nuestra red. Aquí se pueden definir claves para según que máquinas o grupos, el número de conexiones simultáneas... Yo tengo: <tscreen><verb> peer ME { hostname: "localhost, 127.0.0.1, alderaan.maptel.es, 192.168.0.3" } </verb></tscreen> Que es totalmente redundante, pero me daba un problema cuando lo estaba configurando y creía que esa eso. Al final era otra cosa, pero me olvide de cambiarlo y ahora no tengo tiempo ;-) Si queréis saber todas las posibilidades de este fichero, <tt/man incoming.conf/, aunque los comentarios que vienen en él son bastante claros. <sect1><tt/expire.ctl/. <p> Transcribo la documentación de <tt/inn/ sobre este fichero: <tscreen><verb> The expire.ctl file is the configuration for the expiration policy. See the expire.ctl man page for more details. </verb></tscreen> Vamos, que RTFM. Tampoco tiene mayor secreto. Yo puse: <tscreen><verb> /remember/:14 *:A:1:10:never news.announce.*:M:1:35:90 </verb></tscreen> <sect1><tt/nnrp.access/. <p> Este fichero indica qué clientes se pueden conectar y si pueden leer, escribir... Cada línea tiene el siguiente formato: <tscreen><verb> servidor:acceso:usuario:clave:grupos </verb></tscreen> <tt/servidor/ puede ser una IP, <tt/192.168.0.3/, un rango de direcciones, <tt>192.168.0.0/24</tt>, un nombre de máquina, <tt/alderaan.maptel.es/, o un grupo definido por comodines, <tt/*.maptel.es/ <tt/acceso/ puede ser ``R'' (<em/read/, lectura), ``P'' (<em/posting/, escritura), u otras cosas más esotéricas que vienen en el manual (<tt/man nnrp.access/). De los campos <tt/usuario/ y <tt/clave/, la documentación de <tt/inn/ dice: <tscreen><verb> See the man page for details of how to user the `user' and `password' fields. Leave them blank to use solely host-based authentication. </verb></tscreen> Otro RTFM, pes lo dicho <tt/man nnrp.access/. Por si os sirve de consuelo: <tscreen><verb> *::::!* stdin:Read Post:::* localhost:Read Post:::* 127.0.0.1:Read Post:::* alderaan.*:Read Post:::* </verb></tscreen> Lo de la redundancia es por la misma razón que antes. Por último, el campo <tt/grupos/ es simplemente un lista de grupos, separada por comas, en la que se pueden usar comodines (``<tt/*/''). Como véis en lo que yo tengo, lo más sencillo es poner un asterisco para todos los grupos. <sect1>Comprobando los ficheros. <p> Para comprobar que todos estos ficheros están en orden, hay una utilidad: <tt/inncheck/, que (al menos en Debian) está en <tt>/usr/lib/news/bin/</tt>. Si ejecutamos este fichero, comprobará los permisos y la sintaxis de todos los ficheros de configuración de los que hemos hablado. Es una herramienta muy útil, ya que protesta por la mínima pijada. Cuando deje de dar errores, tendremos casi listo el sistema. En versiones anteriores de <tt/inn/, una vez que <tt/inncheck/ daba todo como correcto, el sistema ya estaba listo para funcionar; lamentablemente, ahora las cosas han cambiado, y todavía hay que seguir haciendo ajustes. <sect1>Creación de los ficheros <tt/db/. <p> Ahora hay que configurar la base de datos del servidor de news, es decir, los ficheros que controlan los artículos que se encuentran en el servidor, los grupos que se alojan... Es un paso delicado, así que te aconsejo que leas este apartado hasta el final antes de tocar nada. Yo me puse a hacer cambios, y casi jodo todo. De hecho, la configuración de esta parte fue lo que más me costó con diferencia. Insistir, como insiste la documentación de <tt/inn/ en este punto, que debemos trabajar como usuario <tt/news/, para que los permisos queden correctamente establecidos. <sect2>Configurando los ficheros <tt/db/ por primera vez.<label id="desdecero"> <p> Si estás configurando <tt/inn2/ desde cero, es decir, si no estás actualizando desde una versión anterior de <tt/inn/, necesitarás los ficheros <tt/active/, y <tt/newsgroups/, que se pueden bajar de <htmlurl url="ftp://ftp.isc.org/pub/usenet/CONFIG" name="ftp://ftp.isc.org/pub/usenet/CONFIG">. También puedes bajar los que utilizo yo, de mi página, que ocupan bastante menos: <htmlurl url="http://www.escomposlinux.org/hsolo/archivos/inn+suck/active" name="http://www.escomposlinux.org/hsolo/archivos/inn+suck/active">, <htmlurl url="http://www.escomposlinux.org/hsolo/archivos/inn+suck/newsgroups" name="http://www.escomposlinux.org/hsolo/archivos/inn+suck/newsgroups"> Descarga los ficheros <tt/active/, y <tt/newsgroups/ y cópialos en el directorio de los archivos <tt/db/, que viene definido en <tt/inn.conf/ por la variable <tt/pathdb:/; por defecto <tt>/var/lib/news</tt>. Ahora, hay que generar el fichero <tt/history/; esto se hace con el comando<footnote>el comando <tt/makehistory/ se encuentra en <tt>/usr/lib/news/bin/</tt>. Si añades el directorio al <em/PATH/ del usuario <tt/news/ el trabajo es más cómodo</footnote> <tscreen><verb> makehistory -i </verb></tscreen> Cuando acabe, hay que renombrar los ficheros <tt/history.n*/ a <tt/history*/. Para acabar con la configuración de <tt/inn/, hay que cambiar los permisos de los ficheros que se acaban de crear: <tscreen><verb> chmod 0664 * </verb></tscreen> Si todo ha ido bien, ya tenemos acabada la configuración de <tt/inn/. <sect2>Configuración a partir de una versión anterior de <tt/inn/. <p> Si partimos de una versión anterior de <tt/inn/, ya tendremos un fichero <tt/history/ y los archivos <tt/active/ y <tt/newsgroups/. Estos ficheros valen para la nueva configuración, pero hay que incluirles ciertas modificaciones. De esta forma, nos evitamos tener que descargarlos, y mantenemos nuestra configuración antigua. Para poder usar los archivos existentes, hay que añadir la línea <tscreen><verb> control.cancel 0000000000 0000000000 n </verb></tscreen> en <tt/active/, y la línea <tscreen><verb> control.cancel Pseudo-group where news system directives are filed. </verb></tscreen> en <tt/newsgroups/. Para regenerar el fichero <tt/history/ <tscreen><verb> makehistory -h history -t H </verb></tscreen> Esto debería regenerar el <tt/history/ con el nuevo formato<footnote>Lamentablemente, yo lo hice mal la primera vez, y borré accidentalmente el fichero <tt/history/, así que esto que escribo es un acto de fe en la pagina man de <em/history/. Para evitar lo que me pasó a mí, os aconsejo que hagáis copias de todos los ficheros antes de regenerar el <tt/history/, especialmente este último. Si todo falla, lo peor que puede pasar es que tengas que regenerar desde cero, como se describe en <ref id="desdecero" name="Configurando los ficheros <tt>db</tt> por primera vez"> </footnote> Al igual que antes, hay que renombrar los ficheros <tt/history.n*/ a <tt/history*/ y cambiar los permisos: <tscreen><verb> chmod 0664 * </verb></tscreen> De nuevo, si todo está correcto, podemos lanzar el demonio <tt/inn2/ con<footnote>En Debian, en otras distribuciones esto pude cambiar un poco.</footnote>: <tscreen><verb> /etc/init.d/inn2 start </verb></tscreen> <sect1>Si la cosa no funciona... <p> Pues si la cosa no funciona, mal asunto. Pueden pasar dos cosas; que yo me haya equivocado (posible, pero improbable, ya que yo tengo el sistema funcionando en casa), o que tu te hayas equivocado, así que empieza a leer desde el principio, y ten más suerte la próxima vez. Bromas aparte, <tt/inn/ es completamente opaco en lo que a mensajes de error se refiere. Todas las salidas de <tt/inn/ se almacenan en <tt>/var/log/news/</tt>, pero cuando uno está haciendo pruebas, es más cómodo seguir los mensajes de error en el <tt/syslog/: <tscreen><verb> tail -f /var/log/syslog </verb></tscreen> Lo poco que escupe <tt/inn/ se puede ver de esta manera. <sect1>...y si funciona <p> Pues si funciona enhorabuena, ya tienes la parte de <tt/inn/ configurada correctamente, lo más difícil ya está hecho. Para comprobar que la cosa funciona, puedes hacer un telnet a nuestra máquina: <tscreen><verb> $ telnet localhost 119 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 200 alderaan.maptel.es InterNetNews server INN 2.2.2 13-Dec-1999 ready quit 205 . Connection closed by foreign host. </verb></tscreen> <sect1>Añadiendo grupos. <p> Si todo funciona correctamente, ya podremos añadir grupos a nuestro servidor. Esto se hace con el programa <tt/ctlinnd/. Por ejemplo, para añadir un grupo local: <tscreen><verb> $ ctlinnd newgroup local.pruebas Ok </verb></tscreen> O uno de nuestros preferidos: <tscreen><verb> $ ctlinnd newgroup es.comp.os.linux.misc Ok </verb></tscreen> Y para borrar los grupos: <tscreen><verb> $ ctlinnd rmgroup local.pruebas Ok </verb></tscreen> Os recomiendo la lectura detenida de la página man de <tt/ctlinnd (8)/, en la que explica el mantenimiento de grupos. <sect>Configuración de <tt/suck/. <p> Como dijimos antes, <tt/suck/ es el encargado de intercambiar artículos entre nuestro servidor local y los servidores remotos. El sistema normal de configuración de <tt/suck/, coloca los ficheros de configuración en <tt>/etc/suck</tt>. Para llamar a <tt/suck/, hay un script (como siempre, hablo de mi Debian), <tt>/usr/sbin/get-news</tt>. Para bajar artículos de varios servidores, lo que yo he hecho es modificar este script, de forma que acepte un parámetro extra, <tt/-dirconf/, que especifica los distintos ficheros de configuración para cada servidor. La nueva versión del script se llama <tt>/usr/sbin/baja-news</tt>. Evidentemente, los ficheros ya no estarán directamente en <tt>/etc/suck</tt>. Yo los he colocado en subdirectorios bajo <tt>/etc/suck</tt>: <tscreen><verb> $ ls -l /etc/suck/ total 10 drwxrwsr-x 2 news news 1024 mar 29 16:02 antakira drwxrwsr-x 2 news news 1024 mar 29 16:01 cis-dfn lrwxrwxrwx 1 news news 21 dic 31 03:10 get-news.conf -> cis-df n/get-news.conf -rw-r--r-- 1 news news 818 feb 18 2000 get-news.conf.dpkg-dist -rw-r--r-- 1 hsolo hsolo 618 mar 28 00:43 personal.killfile lrwxrwxrwx 1 news news 30 sep 6 2000 suckkillfile -> /home/h solo/web/suckkillfile -rw-r--r-- 1 news news 405 dic 31 16:01 sucknewsrc </verb></tscreen> Como podéis ver, yo tengo varios subdirectorios, que corresponden a los distintos servidores: <tt/cis-dfn/ para <em/news.cis.dfn.de/, y <tt/antakira/ para <em/news.antakira.com/. Los enlaces, que apuntan a <tt/cis-dfn/ los tengo para cuando se llama a <tt/get-news/, para que news.cis.dfn.de sea el servidor por defecto. Y en cada directorio de configuración: <tscreen><verb> $ ls -l /etc/suck/cis-dfn/ total 5 -rw-r--r-- 1 news news 862 dic 15 12:38 get-news.conf lrwxrwxrwx 1 root news 20 ene 6 23:14 personal.killfile -> .. /personal.killfile lrwxrwxrwx 1 root news 15 ene 6 23:13 suckkillfile -> ../suck killfile -rw-r--r-- 1 root root 404 mar 29 15:59 sucknewsrc -rw-r--r-- 1 root root 404 mar 29 04:05 sucknewsrc.old </verb></tscreen> <sect1><tt/get-news.conf/. <p> El fichero de configuración principal de <tt/suck/ es <tt/get-news.conf/. Describo las opciones: <tscreen><verb> server: alderaan </verb></tscreen> El nombre del servidor local (el nuestro, vaya) <tscreen><verb> remoteserver: news.cis.dfn.de </verb></tscreen> El nombre del servidor remoto, evidentemente. <tscreen><verb> outgoingfile: cis-dfn </verb></tscreen> El nombre, es el que hayamos decidido para el <em/feed/ en <tt>/etc/news/inn.conf</tt>. Es la única precaución que hay que tener. Esto es válido teniendo en cuenta que no hemos cambiado el fichero de salida en las opciones del <em/feed/, añadiendo un <em/flag/ <tt/-Tf/ e indicando otro nombre alternativo. <label id="sedcmd"> <tscreen><verb> sedcmd:/^NNTP-Posting-Host:\|^Xref:\|^X-Trace:\|^X-Complaints-To:\|^NNTP-Posting-Date:/d </verb></tscreen> Esto es un punto delicado, haz un acto de fe de momento. Lo explicaré más adelante en <ref id="bugs" name="Bugs, apaños y otras trampas..."> <tscreen><verb> userid: tu_usuario </verb></tscreen> Pues eso, el nombre del usuario remoto. <tscreen><verb> password: tu_clave </verb></tscreen> La clave en el servidor, evidentemente. <sect1><tt/sucknewsrc/. <p> El fichero <tt/sucknewsrc/ describe qué grupos nos bajaremos de cada servidor. Si estamos bajando distintos grupos de distintos servidores, lo suyo es que sean complementarios, para no bajar los mismos artículos dos (o más) veces. Sin embargo, tampoco hay nada que nos impida hacerlo. Si bajamos noticias de servidores que pierden muchos mensajes, puede ser incluso un buena política, aunque yo creo que mejor política es cambiar de servidor. En cualquier caso, es un gasto de tiempo, ya que primero <tt/suck/ baja todas las noticias pendientes de cada servidor, y luego es <tt/inn/ quien las rechaza por repetidas. Os pego el <tt/sucknewsrc/ para <em/news.cis.dfn.de/, y os lo explico: <tscreen><verb> control 901240 junk 0 test -100 to 1000708 #es.comp.os.linux 1078346 es.comp.lenguajes.java 17802 es.comp.seguridad.pgp 2957 #es.comp.hackers 1134047 es.comp.os.linux.misc 34503 es.comp.os.linux.instalacion 24050 es.comp.os.linux.programacion 5747 es.comp.os.linux.redes 13307 es.ciencia.matematicas 14540 es.pruebas 90123 #es.news.admin 1005265 </verb></tscreen> Cada línea indica el nombre de un grupo que hay que bajarse. Las cuatro primeras, hay que ponerlas para todos lo servidores, esto es, en cada <tt/sucknewsrc/ que tengamos. El número que va detrás de cada grupo, es actualizado por <tt/suck/ después de cada descarga, y es el número del último artículo bajado de cada servidor para cada grupo, para que la próxima vez que se conecte baje de desde ese número. Para bajar artículos por primera vez, puedes ponerlos a ``0'', con lo que se bajará todos los artículos que haya en el <em/spool/ del servidor remoto. Si pones un número negativo, bajará los <em/n/ últimos artículos; por ejemplo, si pones -100, bajará los últimos 100 artículos. Las líneas que comienzan por ``#'' se consideran comentarios, y no son tenidas en cuenta. <sect1>Filtros. <p> El fichero de filtros por defecto es <tt>/etc/suck/suckkillfile</tt>. Como estamos cambiando los directorios de configuración, la ubicación de los filtros también cambia. Así, si usamos como directorio de configuración <tt>/etc/suck/cis-dfn/</tt>, <tt/suck/ buscará los ficheros de filtros allí. Yo lo que hago es tener los filtros en <tt>/etc/suck/killfile</tt>, y mantengo enlaces a él desde los distintos directorios de configuración: <tscreen><verb> $ ls -l /etc/suck/cis-dfn/*killfile lrwxrwxrwx 1 root news 20 ene 6 23:14 /etc/suck/cis-dfn/perso nal.killfile -> ../personal.killfile lrwxrwxrwx 1 root news 15 ene 6 23:13 /etc/suck/cis-dfn/suckk illfile -> ../suckkillfile $ ls -l /etc/suck/antakira/*killfile lrwxrwxrwx 1 root news 20 dic 30 17:10 /etc/suck/antakira/pers onal.killfile -> ../personal.killfile lrwxrwxrwx 1 root news 15 dic 30 17:11 /etc/suck/antakira/suck killfile -> ../suckkillfile </verb></tscreen> Como podéis ver, los ficheros de filtros en los dos directorios apuntan al mismo fichero del directorio superior. <sect1>Configuración del segundo servidor (o los siguientes). <p> Pues no tienen ningún misterio, basta con seguir los pasos anteriores, escribiendo los ficheros de configuración en un directorio aparte, bajo <tt>/etc/suck/</tt>, y ya está. <sect1><tt/baja-news/, el meollo de todo esto. <p> El script <tt>/usr/sbin/baja-news/</tt> es el que se encarga de buscar en los distintos directorios de configuración, y se conecta a los distintos servidores. Es una versión modificada de <tt>/usr/sbin/get-news</tt>, que viene con la Debian, y que es parte del paquete <tt/suck/. La modificación fundamental, es que ahora acepta el parámetro <tt/-dirconf/ <em/directorio/, que indica a <tt/suck/ el directorio en el que debe buscar los ficheros de configuración, los filtros... Te puedes bajar este script de <htmlurl url="http://www.escomposlinux.org/hsolo/archivos/baja-news" name="http://www.escomposlinux.org/hsolo/archivos/baja-news"> El uso es sencillo: <tscreen><verb> $ /usr/sbin/bajanews -dirconf cis-dfn </verb></tscreen> Esto hará que <tt/suck/ busque la configuración en <tt>/etc/suck/cis-dfn</tt> <sect1>Bugs, apaños y otras trampas...<label id="bugs"> <p> Aparte de las modificaciones mencionadas en <tt/baja-news/, he introducido otras, para corregir un pequeño <em/bug/ de ese fichero<footnote>Tengo que agradecer desde aquí la colaboración que me prestó Andrés Herrera <htmlurl url="mailto:aherrerm@escomposlinux.org" name="aherrerm@escomposlinux.org"> para descubrir y solucionar este <em/bug/, que me aguantó pacientemente durante casi dos horas una noche en el IRC</footnote>. Este bug consiste en lo siguiente: muchos servidores que requieren identificación (<em/news.cis.dfn.de/ es uno de ellos, y <em/news.antakira.com/ es otro), necesitan que el cliente se identifique nada más conectarse, en vez de esperar a la petición de autorización (sacado de <tt/ man 1 suck/). Esto se consigue pasando a <tt/suck/ y a <tt/rpost/ (el programa que se usa para enviar artículos a un servidor remoto, y que es llamado automáticamente por <tt/get-news/ o <tt/baja-news/), el parámetro <tt/-u/. Por defecto, al menos como viene <tt/get-news/ con la Debian, no se pasa ese parámetro ni en las llamadas a <tt/suck/ ni a <tt/rpost/. Yo lo he metido en los sitios que llaman a estos programas. Esto no debería tener efecto en los servidores que no necesitan autentificación, o los que no son tan estrictos en ese sentido. Desgraciadamente, no lo he probado, así que si tienes problemas en ese sentido, escríbeme para que adapte el script. En <ref id="sedcmd" name="get-news.conf">,nos apareció la siguiente línea de configuración: <tscreen><verb> sedcmd:/^NNTP-Posting-Host:\|^Xref:\|^X-Trace:\|^X-Complaints-To:\|^NNTP-Posting-Date:/d </verb></tscreen> Tanto <em/news.cis.defn.de/ como <em/news.antakira.com/, no aceptan todas la cabeceras que coloca nuestro <tt/inn/ local, y rechazan los mensajes que contienen esas cabeceras. Lo que hace la variable de arriba, es eliminar precisamente esas cabeceras. Del manual de <tt/get-news.conf/: <tscreen><verb> sedcmd Indica el comando que empleará put-news para fil­ trar los mensajes antesde ser enviados al servidor remoto. Todo el artículo pasará a travésdel editor de flujo "sed" con este argumento. Por ejemplo, si se deseaeliminar los campos NNTP-Posting-Host y Xref de la cabecera del artículodebería usarse el valor sedcmd: /^NNTP-Posting-Host:^Xref:/d </verb></tscreen> Estos valores pueden cambiar para cada servidor de news, por lo que es posible que los tengas que ajustar a mano. Yo he puesto los que son correctos para los servidores que yo utilizo. Puedes probar con el valor de <tt/sedcmd/ que viene por defecto e ir ajustando hasta que funcione: <tscreen><verb> sedcmd: /^NNTP-Posting-Host:\|^Xref:/d </verb></tscreen> Esto elimina las cabeceras <tt/NNTP-Posting-Host:/ y <tt/Xref:/. De hecho, esta configuración era suficiente en versiones anteriores de inn. Os pego un mensaje de error cuando el servidor remoto rechaza un mensaje por una cabecera: <tscreen><verb> Connected to news.cis.dfn.de 200 news.fu-berlin.de welcomes 212-7-50-134.wolbiz.worldonline.es (212.7.50.134) . Authorization required for reading and posting. 340 Ok, recommended ID <99ct6g$oc5j$1@ID-63837.news.dfncis.de> 441 Can't set system "X-Trace" header ^^^^^^^^^ 340 Ok, recommended ID <99ct6h$oc5j$2@ID-63837.news.dfncis.de> 240 Article posted <87wv9ij6mp.fsf@alderaan.maptel.es> Closing connection to news.cis.dfn.de Error remote posting You can hang up the modem now </verb></tscreen> Por último, contar un pequeño problema que tuve. En algún momento de la configuración hoce cambios sobre el lugar del <em/spool/ de artículos, cambiando entre <tt>/var/spool/news/articles/</tt>, y <tt>/var/spool/news</tt>. A resultas de esto, los artículos se guardan en <tt>/var/spool/news</tt>, pero <tt/suck/, a la hora de buscarlos para enviarlos al servidor remoto, trata de encontrarlos en <tt>/var/spool/news/articles/</tt>. Supongo que se podría resolver revisando la configuración. De hecho, parece que en la nueva versión de <tt/inn/ los artículos ser guardan en <tt>/var/spool/news/articles/</tt> por defecto. Puedes dejarlo así, con losa configuraciones por defecto, que deberían funcionar correctamente, o hacer un pequeño apaño, que es convertir el directorio <tt/articles/ en un enlace simbólico: <tscreen><verb> $ cd /var/spool/news/ $ln -s . articles </verb></tscreen> De esta forma, el directorio <tt>/var/spool/news/articles/</tt> ``se convierte'' en <tt>/var/spool/news</tt>. Esto es un apaño como otro cualquiera. No es de lo más elegante, pero funciona (y no es con mucho de lo peor que tengo en mi sistema). Si consigues un sistema más depurado, escríbeme y lo añado para futuras versiones de este documento. <sect>Feedback. <p> Pues lo de siempre. He escrito esto basándome en mi configuración y en mi experiencia, y aunque os aseguro que a mí me funciona, puedo haber cometido errores, tanto de procedimiento como de redacción. Por eso, cualquier comentario, sugerencia, crítica, etc será bienvenida. Un área importante que estaría bien incluir para futuras versiones, es la configuración de todo esto con <tt/newsx/ en lugar de hacerlo con <tt/suck/. Así, que si alguien se anima y escribe algo, podemos incluirlo más adelante. La última versión de este documento, la puedes bajar de mi página personal: <htmlurl url="http://www.escomposlinux.org/hsolo" name="http://www.escomposlinux.org/hsolo">, y todos los ficheros de configuración de <htmlurl url="http://www.escomposlinux.org/hsolo/archivos/inn+suck" name="http://www.escomposlinux.org/hsolo/archivos/inn+suck"> </article>