Page suivante Page précédente Table des matières 5. Installation et configuration d'INN 5.1 Installation à partir d'un paquetage précompilé Certains diront qu'il faut mieux partir des sources d'INN et les compiler : cela permet de mieux maîtriser toutes les options de fonctionnement. C'est sûrement vrai, mais les paquetages précompilés pour Linux s'avèrent si faciles à installer ! Dans cette documentation, nous ne parlerons pas de la compilation d'INN (pour cela, récupérez le paquetage rpm source et lisez le fichier install.ms après l'avoir transformé en fichier PostScript comme indiqué dans la documentation qui l'accompagne). La dernière version d'INN existe dans toutes les bonnes distributions (Debian, Red Hat, Slackware, etc.), sinon la version précédente doit se trouver sur le CD-ROM. Si vous avez récupéré un fichier tgz, la démarche est identique à celle de l'installation de suck : décompactez-le dans un répertoire temporaire et déplacez les différents fichiers aux endroits indiqués ci-dessous. Si vous avez un rpm, installez-le via rpm en ligne de commande, ou glint sous X. INN utilise plusieurs répertoires : /etc/news contient les fichiers de configuration : actsync.cfg expire.ctl innwatch.ctl nnrp.access actsync.ign hosts.nntp moderators nntpsend.ctl control.ctl hosts.nntp.nolimit motd.news overview.fmt distrib.pats inn.conf newsfeeds passwd.nntp /var/lib/news contient les fichiers de travail : active history send-ihave subscriptions active.times history.dir innlog.pl send-nntp distributions history.pag newsgroups send-uucp /var/lib/news/innd contient les fichiers utilisés par innd : control nntpin /usr/lib/news contient les fichiers scripts nécessaires à l'exécution d'inn, ainsi que l'exécutable rnews déjà évoqué : innshellvars innshellvars.pl parsecontrol innshellvars.csh innshellvars.tcl rnews /usr/lib/news/bin contient les exécutables : actmerge ctlinnd inncheck news.daily sendbatch actsync ctlrun innconfval newsrequeue sendxbatches actsyncd cvtbatch innmail nntpget shlock archive expire innstat nntpsend shrinkfile auth.dir expireover innwatch overchan tally.control batcher expirerm innxbatch pgpverify tally.unwanted buffchan fastrm innxmit prunehistory writelog control filechan makeactive rnews convdate getlist makegroup scanlogs crosspost grephistory makehistory scanspool /var/log/news contient les fichiers de trace d'activité : expire.log news news.err nntpsend.log errlog expire.rm news.crit news.notice unwanted.log Il est hors de question de décrire le rôle de chacun de ces fichiers : nous ne traiterons que des plus importants (les descriptions des autres, ainsi que leurs rôles respectifs, sont décrits dans les pages du manuel en ligne). 5.2 Les fichiers de /etc/news : inn.conf, hosts.nntp, nnrp.access, newsfeeds, moderators Tous ces fichiers, comme la plupart des fichiers de configuration d'INN, débutent par une explication (parfois sibylline, il est vrai...) de leur syntaxe. Pour leurs modifications, mettez-vous sous le compte news, il est impératif que ces fichiers appartiennent à l'utilisateur et au groupe news pour qu'INN fonctionne correctement... D'autre part, avant de les modifier, sauvegardez leur contenu original (par ex, cp newsfeeds newsfeeds.orig) inn.conf Chaque ligne est de la forme : paramètre: valeur (attention, il y a un espace après le ':'). Paramètre et valeur sont des chaînes de caractères. Les différents paramètres valides et intéressants pour nous sont : organization : comme valeur, mettez ce que vous voulez voir apparaître dans le champ ORGANIZATION des articles que vous posterez ; fromhost : le nom de votre machine, qui apparaîtra après votre username@ dans le champ FROM des articles que vous posterez. En fait, normalement, c'est votre lecteur de news qui doit s'en charger ce qui veut dire que si cette valeur est utilisée, c'est que votre lecteur est mal configuré... Pour cette raison, on met une valeur comme « un.lecteur.mal.configure » ce qui permettra de détecter rapidement ce problème. pathhost : pour les utilisateurs de la méthode Fyr, le contenu de ce champ est important car il permet au serveur d'Oléane de gérer les exclusions en vous reconnaissant (ce que vous indiquez ici apparaîtra au début des champs Path:). C'est l'identifiant unique de votre serveur sur tout Usenet. Mettez ici ce que vous aura indiqué le newsmater d'Oléane lorsque vous aurez demandé à être feedé par cette méthode. Pour ceux qui utilisent suck ou newsx, ce champ n'est pas nécessaire. Les autres paramètres, s'ils ne sont pas mentionnés, prennent les valeurs des variables d'environnement, par exemple, le paramètre server sera par défaut positionné à la même valeur que la variable d'environnement NNTPSERVER (qui, normalement doit être positionnée à localhost dans le fichier /etc/profile). Mon inn.conf contient les lignes suivantes : organization: JacoSoft Intl. fromhost: mail.dotcom.fr pathhost: jacoboni Ce qui fait que, lorsque je poste un article, son en-tête ressemble à ceci (sur mon serveur) : From: Eric Jacoboni <jaco@mail.dotcom.fr> Organization: JacoSoft Intl. Subject: blah blah blah... Path: jacoboni!not-for-mail ... de même, tous les articles que je reçois d'Oléane ont leur champ Path: commençant par jacoboni!dial.oleane.com!.... Ainsi que nous le disions plus haut, le jacoboni en première position correspond au champ pathhost configuré dans le fichier inn.conf de notre serveur, et ce champ Path: est, finalement, le résultat de la concaténation de tous les pathhost des serveurs NNTP par lesquels l'article est passé. Si je décide d'avoir plusieurs feeds, cela permettra à Oléane de ne pas me reproposer les articles que j'aurais émis. On notera la contenu du champ From : l'adresse jaco@mail.dotcom.fr est formée à partir de la configuration de mon logiciel de news, pas à partir du contenu de l'entrée fromhost de inn.conf, ce qui précède cette adresse est le contenu du champ user_name du fichier /etc/passwd. En fait, il est préférable de définir cette adresse au niveau du fichier de configuration du lecteur de news. Avec gnus, par exemple, il suffit d'ajouter les lignes suivantes à son ~/.gnus : (setq user-mail-address "jaco@mail.dotcom.fr") (setq user-full-name "Eric Jacoboni") (setq mail-default-reply-to "jaco@mail.dotcom.fr") (setq mail-host-address "mail.dotcom.fr") hosts.nntp Il ne doit comporter qu'une ligne : localhost:. Attention à ne pas mettre d'espace après le ':', ni de ligne après celle-ci. Pour utiliser la méthode Fyr, il faudra rajouter une ligne pour que le serveur distant qui vous alimente en articles soit reconnu par votre serveur local. Par exemple, chez moi, cette ligne est news.dial.oleane.com: car c'est lui qui m'envoie les batchs. Dans ce cas précis, il faudra aussi ajouter une entrée correspondant à news.dial.oleane.com dans votre fichier /etc/hosts car INN a besoin de connaître l'adresse IP de toutes les entrées de hosts.nntp lors de son démarrage. Mon fichier /etc/hosts est donc le suivant : 127.0.0.1 titine.jacosoft.fr localhost titine 194.2.28.1 news.dial.oleane.com nnrp.access Ce fichier liste les noms de machines qui auront le droit d'utiliser notre serveur de news ... et les autorisations (lecture et publication de nouveaux articles) associées. Le mien contient les lignes suivantes : # Default to no access *:: -no- : -no- :!* # Allow access from localhost localhost:Read Post:::* 127.0.0.1:Read Post:::* stdin:Read Post:::* Consultez la page de man (5) concernant ce fichier pour comprendre la signification de ces lignes... newsfeeds Ce fichier décrit les sites que vous approvisionnez en news. Il faut donc y décrire celui de notre FAI afin de pouvoir lui expédier les articles que nous postons sur notre propre serveur. Le mien contenait les lignes suivantes lorsque mon fournisseur était HOL : ME:*,!junk,!control,!local,!foo:: crosspost:*:Tc,Ap,WR:/usr/lib/news/bin/crosspost -s - overview!:*:Tc,WO:/usr/lib/news/bin/overchan news.hol.fr/news1.isdnet.net,news2.isdnet.net,news3.isdnet.net,news4.isdnet.net\ :*,!junk,!control:Tf,Wnm: La syntaxe complète de ce fichier est décrite dans le manuel en ligne. Il faut retenir que la ligne ME concerne notre machine. Ici elle récupère tous les groupes sauf junk, control, local et foo. Les lignes crosspost et overview servent à gérer les articles cross-postés et l'historique. La ligne news.hol.fr nécessite plus d'explications : elle indique d'abord que les descriptions des articles que nous postons (via rpost) seront placés dans le fichier /var/spool/news/out.going/news.hol.fr, c'est là que rpost ira chercher leurs noms afin de les expédier au serveur du FAI pour qu'ils circulent. D'autre part, normalement INN est conçu pour pouvoir fonctionner grâce à plusieurs sites « feeds », lui fournissant des articles. Il envoie donc à tous les serveurs listés dans le fichier newsfeeds une copie de chaque article reçu. Mais, ainsi que nous l'avons évoqué dans la section 2, il est inutile de renvoyer à un serveur donné les articles qu'il nous a lui-même expédiés (!) ainsi que ceux que avons récupérés grâce à un serveur avec lequel il est déjà lui-même en relation. Chaque article contient donc un champ Path dressant peu à peu une liste des noms de serveurs sur lesquels il est « passé », chaque nom étant séparé du suivant par un point d'exclamation. Dans le fichier newsfeeds, on précise à INN ce qu'il doit faire des articles reçus. On y trouve une ligne pour chaque élément (pas obligatoirement un autre serveur de news) auquel INN doit passer des informations sur les articles reçus. Chaque ligne est composée de champs séparés par :. Ce fichier offre, par exemple, le moyen d'indiquer qu'on ne doit pas réexpédier à un serveur donné la copie d'un article déjà passé par tel ou tel serveur. Le tronçon de ligne news.hol.fr/news1.isdnet.net,news2.isdnet.net,news3.isdnet.net,news4.isdnet.net se lit ainsi : « il existe un serveur par commodité appelé ici « news.hol.fr ». Tu dois lui expédier les copies des articles, SAUF de ceux dont dont le champ Path contient « news1.isdnet.net » ou « news2.isdnet.net » ou « news3.isdnet.net » ou « news4.isdnet.net » ». Le tronçon de ligne:*,!junk,!control concerne aussi la déclaration destinée à informer INN de l'existence d'un serveur qu'il faut alimenter en articles. Ce serveur est appelé par commodité « news.hol.fr ». Il s'agit, en fait, d'une seule ligne pour INN car le caractère « barre oblique inversée » (antislash) placé après le premier tronçon sert de « continuateur » (comme souvent sous UNIX). Ce tronçon se lit ainsi : « ceci est valable pour tous les groupes reçus ici, sauf « junk », « control » ». En fait, cette partie de ligne pourrait être raccourcie : l'entrée ME correspond à des valeurs par défaut qui seront ajoutées à toutes les entrées suivantes, et notamment à l'entrée news.hol.fr. Il n'y a donc pas besoin de répéter ce que ME a déjà indiqué, ce qui fait que ce tronçon peut rester vide (le : doit quand même être conservé). Le tronçon suivant (:Tf,Wnm:) détermine le mode de transmission des articles. Par défaut, le fichier utilisé pour garder la trace des articles sera donc /var/spool/news/out.going/news.hol.fr. Si vous désirez qu'il porte un autre nom, il suffit de le mentionner après le dernier :. De la même façon, les articles dont l'envoi à ce feed ont échoué seront mentionnés dans le fichier /var/spool/news/out.going/news.hol.fr.fail On a ainsi créé un « feed » d'articles, c'est-à-dire un canal logique (on ne se soucie pas, pour le moment, de la façon dont les articles seront transportés) par lequel votre serveur peut en alimenter d'autres. À ce stade vous devez comprendre l'intérêt de créer des feeds lorsque votre machine est connectée à plusieurs autres (et participe donc au réseau, en interconnectant d'autres participants). Mais pourquoi le faire lorsque l'on est une "feuille" de l'arbre, une machine uniquement connectée à une seule autre, via une connexion PPP, comme dans le cas qui nous intéresse ? Eh bien créer ainsi un « feed » vers votre fournisseur vous permettra de voir circuler les articles que vous posterez, tout simplement ! Mais tout article venant de news.hol.fr devrait ne pas être réenvoyé vers news.hol.fr. Cela ne poserait pas de problème particulier car un serveur recevant un article commence par vérifier (grâce au Message-Id) s'il en dispose déjà, et le rejette si c'est le cas. Mais cela occasionne des transferts inutiles. Malheureusement (je vous ai prévenu, j'ai eu tous les problèmes possibles...), HOL fait appel à un fournisseur de news externe (en l'occurrence isdnet) ce qui fait que news.hol.fr n'apparaît jamais dans le champ `Path' des articles et que ceux-ci seront donc réenvoyés lors du prochain appel de rpost (avec les messages de « article déjà existant » qui en résultent...). Pour expliquer que les articles provenant des serveurs de news d'isdnet ne doivent pas être réenvoyés, on l'indique entre le / et le :. Si vous ne précisez pas ces exclusions, tous les articles reçus seront décrits dans le fichier /var/spool/news/out.going/news.hol.fr car ils ne contiennent pas news.hol.fr dans leur champ Path... Pour savoir quel est le serveur que votre FAI utilise (afin de l'exclure comme cela est décrit plus haut), deux méthodes sont possibles : Faire un telnet news.fai.fr nntp qui vous renseignera sur le nom de la machine qui vous envoie les articles (le abcdef cité dans l'exemple de la section 2). Cette méthode nécessite, bien sûr, d'être connecté. Vous pouvez économiser une unité téléphonique en utilisant la deuxième possibilité... À l'aide de votre lecteur de news, visualisez la totalité des en-têtes d'un article reçu. Le champ qui nous intéresse est Path: qui indique la route suivie par cet article pour arriver jusqu'à nous. Le nom qui suit celui de votre machine (ou qui suit le nom spécifié par l'entrée pathhost du fichier inn.conf) est le nom de la machine qui vous l'a envoyé. Prenons un exemple : depuis la première version de ce document, j'ai quitté HOL pour Easynet, puis pour Oléane. Voici le contenu du champ Path: de chaque article que je reçois : Path: jacoboni!dial.oleane.com!...!... dial.oleane.com doit donc être exclu, ce qui fait que mon fichier newsfeeds contient désormais, à la place de la ligne news.hol.fr, la ligne suivante : oleane/dial.oleane.com\ ::Tf,Wnm: Notez bien que cela suppose que mon entrée ME soit la suivante : ME\ :*,!junk,!control,!local,!foo:: Le fichier contenant les références des articles que j'envoie au site distant est donc désormais /var/spool/news/out.going/oleane Attention : le fichier newsfeeds est chargé en mémoire au lancement d'INN, donc toute modification de celui-ci implique son rechargement (cf. la section sur l'utilisation de ctlinnd et l'utilisation du paramètre reload). moderators Ce fichier est utilisé lorsqu'on désire poster un article dans un forum modéré (fr.comp.os.linux.annonces et fr.comp.os.linux.moderated, par exemple). La différence entre un forum non modéré est un forum modéré est que tout le monde peut poster n'importe quoi (et, malheureusement, certains en abusent...) dans le premier tandis que la parution d'un article dans le second est soumise à l'acceptation d'une ou plusieurs personnes : les modérateurs de ce forum. Ceci signifie que, pour poster un article dans un forum modéré, on doit d'abord l'envoyer au modérateur sous la forme d'un message email. Le modérateur recevra alors votre proposition d'article et décidera de le publier dans le forum, ou le rejettera s'il juge qu'il ne correspond pas à la charte. Toute cette démarche est inutile car, heureusement, INN s'occupe de tout. Il permet de publier dans les forums modérés comme dans les autres et se charge de transformer automatiquement l'article en message qu'il expédie aux modérateurs. Il cherche pour cela l'adresse email du modérateur dans le fichier moderators. La page de manuel moderators (5) détaille la syntaxe du contenu de ce fichier. En résumé : un enregistrement par ligne, deux champs par enregistrement, séparés par le signe « : ». Le premier champ contient un « motif » de sélection de nom de forum (« fr.* », par exemple, correspond à tous les forums de la hiérarchie « fr »). Le second champ contient l'adresse du modérateur de ce forum. Cas spécial : la paire de caractères « %s », utilisée dans le second champ, est remplacée par le nom du forum visé. Sa dernière ligne devrait toujours être une entrée « par défaut » contenant *:%s@moderators.isc.org (ou *:%s@moderators.news.oleane.net, pour les abonnés d'Oléane) qui indique que tous les articles postés dans un forum modéré au nom non précédemment sélectionné par les entrées précédentes devront être envoyé à l'adresse nom_du_forum@moderators.isc.org. La machine destinatrice dispose toujours de la liste à jour des noms de forums et des adresses de leurs modérateurs. Dans l'absolu, cette règle (*:%s@moderators.isc.org) suffit dont : aucune autre n'est strictement nécessaire. Mais il est de bon ton de ménager les serveurs centraux... et cela accélère le service. Par exemple, pour pouvoir poster au plus vite dans un forum fr modéré de la hiérarchie fr (par exemple fr.comp.os.linux.annonces ou fr.comp.os.linux.moderated), il suffit d'ajouter (au début du fichier, juste après la dernière ligne de commentaires) une entrée : fr.*:%s@moderators.usenet.fr.net Attention : Il faut bien entendu ajouter les entrées avant la ligne générique (*:%s@moderators.isc.org) et en étudiant aussi les autres entrées pour ne pas qu'elles correspondent au motif de la nouvelle ligne saisie, car INN prend en charge la première ligne satisfaisante rencontrée. La solution la plus sûre consiste à ajouter en tête de ce fichier. 5.3 Les fichiers de /var/lib/news : active, history, newsgroups Comme les précédents, ces fichiers doivent appartenir à l'utilisateur news active Ce fichier contient les noms des forums reçus par INN. Cela n'a rien à voir avec le fait de recevoir les articles : on peut très bien récupérer les articles d'un forum fr.bidon par suck, et ne pas les distribuer sur notre machine si le forum fr.bidon n'est pas décrit dans le fichier active... Les fournisseurs d'accès mettent, en général, leur fichier active à disposition, vous pouvez en récupérer un par FTP à ftp://ftp.oleane.net/pub/Oleane/active. Le contenu actuel de mon fichier active est le suivant (en fait, il à beaucoup changé depuis la première version de ce document...) : control 0000000006 0000000007 y junk 0000000000 0000000001 y test 0000000000 0000000001 y to 0000000000 0000000001 y fr.comp.os.linux 0000002676 0000001543 y fr.comp.os.linux.annonces 0000000166 0000000052 m fr.comp.mail 0000000341 0000000089 y fr.usenet.logiciels 0000000530 0000000226 y fr.comp.text.tex 0000000210 0000000156 y fr.comp.applications.x11 0000000141 0000000092 y fr.usenet.forums.evolution 0000001655 0000000703 y fr.test 0000000034 0000000028 y fr.comp.applications.emacs 0000000086 0000000049 y On a une ligne par forum, sachant que les 4 premiers sont obligatoires pour qu'INN fonctionne (il vous suffit de les désactiver dans votre lecteur de news si vous ne voulez pas les voir apparaître...). Attention : Ne modifiez pas le fichier active manuellement, mais utilisez le programme ctlinnd (voir la section sur l'utilisation de ctlinnd). Pour la syntaxe, as usual, cf. les pages du manuel en ligne... Au départ, initialisez ce fichier afin que les champs numériques soient tous de la forme 0000000000 0000000001, ils seront mis à jour automatiquement à chaque appel de rnews (le « y » signifie que l'on autorise le postage d'article dans le forum, « m » signifie qu'il est modéré). Comme d'habitude, attention à ne pas placer de retour chariot après la dernière ligne... En fait, et nous le répétons une nouvelle fois, pour éviter de mauvaises manipulations, il est préférable de ne pas modifier manuellement le fichier active mais d'utiliser le programme ctlinnd (voir la section sur l'utilisation de ctlinnd). history Ce fichier est automatiquement géré par INN, vous n'avez pas à vous en occuper pour le moment... Sachez quand même que suck consulte ce fichier (sauf si vous utilisez l'option -H) afin d'éviter de récupérer un article déjà présent sur votre serveur. newsgroups Ce fichier permet d'associer une description à chaque forum. Normalement il devrait donc contenir autant de lignes que le fichier active, mais ce n'est pas une obligation : tout dépend du courage de l'administrateur... Comme pour le fichier active, vous pouvez récupérer un newsgroups complet par FTP à ftp://ftp.oleane.net/pub/Oleane/newsgroups. Le mien est plutôt spartiate : control Usenet control messages - DO NOT REMOVE junk Articles for missing newsgroups - DO NOT REMOVE test A place for test posts - DO NOT REMOVE to Special Group for INN use - DO NOT REMOVE fr.comp.os.linux Forum de discussion Linux - non modéré fr.comp.os.linux.moderated Forum de discussion Linux - modéré En fait, cela permet à votre lecteur de news d'afficher la description correspondante en face du nom du forum... 5.4 Derniers réglages Si vous avez configuré ces différents fichiers, il ne reste plus qu'à soumettre votre configuration au programme de vérification livré avec INN. Pour cela, lancez la commande /usr/lib/news/bin/inncheck -a et ne vous inquiétez pas de l'avertissement « /etc/news/newsfeeds:0: warning you accept all incoming article distributions » qui est parfois produit. Si vous utilisiez Leafnode auparavant, vérifiez bien que vous avez supprimé la ligne nntp stream tcp nowait news /usr/sbin/tcpd /usr/local/sbin/leafnode de votre fichier /etc/inetd.conf. Vérifiez la présence de /var/spool/news qui doit appartenir à news et qui doit être vide (sinon, sauvegardez ce qui s'y trouve...). Il n'y a rien d'autre à faire : l'installation d'INN par rpm aura modifié pour vous les scripts de démarrage, sinon, éditez le fichier /etc/rc.d/rc.local et rajoutez la ligne suivante : su news -c /etc/rc.d/rc.news >/dev/console et vérifiez la présence du fichier /etc/rc.d/rc.news... Dans ce fichier, recherchez la ligne commençant par DOINNWATCH et remplacez la valeur true, qui est sûrement celle que l'installation par défaut a dû mettre, par false : cela évitera le lancement d'innwatch qui ne sert à rien dans la situation particulière qui est la nôtre et évitera aussi une boucle de temporisation inutile (sleep 600). innwatch sert à « surveiller » le bon fonctionnement du serveur : si le démon innd tombe, ou si un autre problème critique intervient, il se charge de prévenir l'administrateur par courrier. D'autre part, une mauvaise configuration de l'expiration des articles que vous stockez peut entraîner une saturation du disque : là aussi, innwatch intervient en lançant à intervalles réguliers une commande comme df. Dans le cas d'une configuration comme la nôtre, son intérêt est donc quasi nul puisque nous maîtrisons l'ajout des nouveaux articles. Il sert surtout dans les cas où le serveur est alimenté en permanence. En tant que root, lancez la commande : /etc/rc.d/init.d/news qui doit normalement vous répondre innd pour vous informer que le démon est lancé... Vérifiez par un ps axu qui doit comporter des entrées similaires à celles-ci : news 212 0.0 3.0 1912 1428 ? S < 15:39 0:00 /usr/sbin/innd -p4 -i0 -L news 236 0.0 0.6 888 308 ? S < 15:39 0:00 /usr/lib/news/bin/crosspost -s - news 237 0.0 0.6 888 312 ? S < 15:39 0:00 /usr/lib/news/bin/overchan Si vous obtenez cela, c'est qu'INN fonctionne, bravo... Page suivante Page précédente Table des matières