Page précédente Page suivante Table des matières

4. Installation d'un récupérateur d'articles

Deux voies s'ouvrent à vous :

4.1 Méthodes simples

Les méthodes simples consistent à laisser un programme assurer la récupération des articles et leur gestion locale.

Il existe beaucoup de programmes permettant de profiter des news sous Linux. Après en avoir testé plusieurs, nous n'en retiendrons que 2 : PerUser et Leafnode.

Vous pouvez aussi tester slrn-pull, slurp, etc. (suck et newsx seront étudiés plus loin).

PerUser

L'avantage de ce programme est qu'il intègre toutes les fontionnalités que l'on est en droit d'attendre d'un logiciel de lecture off-line des news. De plus, il gère aussi le courrier.

Sa philosophie est proche de celle de Forte Agent pour ceux qui viennent du sous-monde MS-Windows : on récupère les en-têtes des nouveaux articles, on choisit off-line ceux qui nous intéressent, et on les récupère après reconnexion. Cette ressemblance, la gestion du courrier, et l'intégration de la récupération et de la consultation des news est son principal avantage.

Mais c'est aussi son principal inconvénient... On ne peut utiliser les lecteurs de news auxquels on est habitués (Netscape, slrn, tin, Gnus-Emacs, etc...).

D'autre part, l'aspect tout en un est un peu déroutant et, surtout, la gestion de l'historique des articles (base de données permettant de savoir quels sont les articles déjà chargés) est inexistante : l'interface de lecture des news étant pauvre, on est obligé de souvent purger les articles qui deviennent alors inaccessibles à jamais... (pas moyen de reconsulter de vieux articles car l'expiration, c'est à dire la destruction des vieux articles, est automatique...).

Enfin, la politique consistant à se connecter au fournisseur, télécharger les en-têtes, se déconnecter, sélectionner puis se reconnecter pour télécharger les corps des articles sélectionnés n'a pas prouvé son efficacité face au téléchargement systématique de tous les articles avec un filtrage efficace.

Cela dit, c'est la méthode la plus simple pour qui veut récupérer ses news et gérer son courrier sans se poser de questions (attitude que nous n'encourageons pas...)

Remarque :

L'utilisation de PerUser suppose que vous ayez installé le paquetage XForms-0.86 disponible dans les contribs de RedHat. Cependant lors de son lancement, il se plaindra de ne pas trouver libforms.so.0.87... Ne trouvant cette bibliothèque nulle part, la seule solution que nous ayons trouvé est de faire un lien symbolique :

ln -sf libforms.so.0.86 libforms.so.0.87

À part ça, l'installation de présente pas de difficulté majeure : on récupère les binaires sous forme de .tgz (un package rpm existe), on détare ce fichier dans un répertoire temporaire, puis, comme indiqué dans le README qui l'accompagne, on déplace les binaires dans un répertoire du PATH, on secoue et c'est prêt...

Lors du premier lancement (peruser), le programme présente une boîte de dialogue vous permettant de le configurer pour votre serveur de news et de mail distants.

Leafnode

La philosophie de leafnode est plus proche du monde Unix. En fait, Leafnode est un ensemble de programmes en même temps qu'un mini-serveur de news NNTP. Une fois installé (via un paquetage disponible dans les contribs), on dispose d'un programme permettant de récupérer les articles sur le serveur distant :

fetch news.fai.fr 

récupère tous les articles des groupes souscrits et les place automatiquement dans le spool de news (/var/spool/news) dans des répertoires correspondants aux noms des groupes.

Ainsi, les articles de fr.comp.os.linux seront stockés dans :

/var/spool/news/fr/comp/os/linux

Pour ajouter un groupe à la recherche, il suffit de créer un fichier nommé comme lui dans /var/spool/news/interesting.groups (par un touch fr.comp.os.linux, par exemple).

Inversement, pour supprimer un groupe de la recherche, il suffit de supprimer le fichier qui le décrit dans /var/spool/news/interesting.groups (la suppression de son entrée dans .newsrc ne suffit pas).

La récupération terminée, vous lancez votre lecteur de news favori pour lire les nouveaux articles.

Attention, votre lecteur doit alors savoir que le serveur de news est VOTRE machine (localhost). Ceci sera indiqué soit dans le /etc/profile (grâce à une ligne export NNTPSERVER=localhost) ou via une option de configuration ou de ligne de commande du logiciel de lecture. Tout ceci est possible car l'installation de Leafnode a transformé votre machine en serveur de news local. Bien sûr, ce serveur est limité, mais suffit pour la plupart des besoins.

Un conseil : avant de lancer Leafnode, lisez la documentation, elle vous guide pas à pas pour l'installation.

Notamment, vous constaterez qu'il faut faire au préalable une connexion sur votre serveur de news distant afin de créer un fichier active.read, récupérer la liste et la description des groupes présents sur celui-ci (cette étape est plutôt longue en connexion, mais ne doit être faite qu'une fois, alors patience... Ça peut durer plus de 10 minutes).

Cette étape réalisée, utilisez en tant que root n'importe quel programme capable de créer un fichier de suivi de vos activités de lecture, traditionnellement nommé ~/.newsrc. Le logiciel rtin, élément de l'ensemble de programmes de lecture des news nommé tin, par exemple, se charge fort bien de cela car il vous permet de souscrire aux groupes qui vous intéressent en vue de créer le .newsrc dans votre répertoire /root. Ce fichier contient une ligne par groupe souscrit. D'autre part, le répertoire /var/spool/news/interesting .groups doit contenir des fichiers portant le nom des groupes sélectionnés (ces fichiers sont vides, c'est normal... ils ne servent que d'indicateurs)

Relancez fetch et vous récupérez les nouveaux articles des groupes sélectionnés. À partir de là, vous n'avez plus besoin de rtin, vous pouvez utiliser votre lecteur de news favori : Netscape 3, Knews, Gnus, Slrn, etc. (Attention, j'ai lu ça et là qu'il y avait des problèmes avec Netscape 4... À tester...)

Quand vous posterez un article, le serveur de news de leafnode créera un fichier contenant cet article dans /var/spool/news/out.going.

En fait, fetch fait plus que simplement récupérer les news : il commence par poster les articles présents dans /var/spool/out.going, puis les détruit (si un problème de postage survient, les articles non envoyés sont stockés dans un répertoire auxiliaire, ce qui vous permet, en les remettant dans out.going de les re-soumettre). Ensuite, il passe à la phase de récupération : si tout s'est bien passé, vous devez donc récupérer les articles que vous avez postés.

Leafnode étant plus qu'un simple récupérateur d'articles, il vous appartient d'administrer votre mini-serveur, notamment en veillant à supprimer les vieux articles à l'aide du programme texpire. Les délais d'expiration sont paramétrables à l'aide d'un fichier config (cf. la doc pour connaitre son emplacement, normalement /usr/lib/leafnode et sa syntaxe très simple).

Le programme texpire doit être lancé régulièrement (tous les jours), vous pouvez donc en faire une tâche cron (par exemple, sous Red Hat, en créant un script l'appelant placé dans /etc/cron.daily) en vous débrouillant pour que le lancement ait lieu à une heure où votre machine est allumée, ou bien le lancer lors du démarrage, à partir du fichier /etc/rc.d/rc.local, par exemple.

Normalement, si vous avez choisi de l'installer en utilisant un .rpm, tout cela est configuré pour vous : il ne vous reste qu'à éditer le fichier config pour modifier les délais d'expiration et le fichier se trouvant dans /etc/cron.daily pour modifier l'heure de lancement de texpire.

Les versions récentes de Leafnode (supérieures à 1.4.4) disposent d'un moyen pour lutter contre les spams : on peut interdire la récupération d'un article crossposté dans plus d'un nombre spécifié de groupes (un article crossposté dans plus de 10 groupes a de fortes chances d'être un spam...). Par contre, il n'existe pas encore de système de kill-file.

Pour l'avoir longtemps pratiqué, Leafnode est parfait pour une utilisation simple des news. Le logiciel est très fiable, son seul défaut (et la raison pour laquelle je suis passé à autre chose) est de ne pas permettre un tri sélectif des articles récupérés (killfiles). D'autre part, c'est une bonne introduction à la problématique de l'administrateur Usenet.

Je le conseille donc à tous ceux qui désirent pouvoir lire les news off-line sans avoir à se plonger dans les arcanes de gros programmes comme INN (cf. plus loin). Notamment, son utilisation avec le lecteur Knews (qui, lui, permet le tri sélectif, mais après la récupération) est très simple et pratique.

En fait, pendant tout le temps de l'installation et des tests de suck et d'INN, j'ai gardé Leafnode (pour poster mes questions désespérées et obtenir les réponses...). De cette façon, vous pouvez continuer à perfectionner votre future installation tout en gardant une base stable. Pour ce faire, le plus simple est d'installer une config Linux minimale sur une autre partition qui vous servira de partition test, et de ne modifier votre système que lorsque vous êtes sûrs de votre coup. Ce serait une très mauvaise idée de faire cohabiter Leafnode et INN sur le même système car ils utilisent le même répertoire de spool des news (entre autres...).

Performances de Leafnode

Leafnode semble parfois très lent. Voici un conseil de G. Laurent :

Verifiez le fichier de log, où arrivent les messages de leafnode (en géneral news.log), en recherchant des messages d'erreur du genre

writev() for .overview failed: Invalid argument 

leafnode et fetch peuvent produire de tels messages. Ils indiquent que leafnode se plante en écrivant ses .overview qui lui servent d'index pour chaque groupe. Ces .overview restent alors le plus souvent vides, et chaque fois que votre newsreader demande a leafnode le contenu d'un groupe, celui-ci cherche à reconstituer le .overview correspondant et passe donc à nouveau en revue tous les articles déjà présents dans le groupe, d'où une activité intense du disque dur.

Il y a par ailleurs un problème avec texpire : il n'efface pratiquement aucun article, et le /var/spool/news grossit démesurément. Ce qui en rajoute au problème précédent, puisque les groupes contiennent de plus en plus d'articles. Le délai d'attente pour lire un groupe se rallonge donc de plus en plus.

4.2 La totale : suck + INN

Cette configuration est, à ma connaissance, la plus complète pour la situation qui nous intéresse. Le prix à payer est son installation, mais, celle-ci réalisée, l'administration n'est pas plus compliquée que celle de Leafnode : il s'agit principalement de veiller à l'expiration régulière des articles. En fait la seule chose qui change est, qu'ici, les programmes de récupération, de postage et le serveur de news sont des entités distinctes qu'il faut faire bien cohabiter...

Quand je dis que l'installation est plus compliquée que celle des autres produits décrits plus haut, j'exagère beaucoup : en fait, ce n'est pas l'installation qui est compliquée, mais le fait qu'il faut comprendre un minimum de choses sur le fonctionnement de Usenet. Le but premier de ce document était justement de produire une synthèse de tous les problèmes (et de leurs solutions) auxquels j'ai été confrontés : j'ai eu de la chance, j'ai eu tous les problèmes possibles et imaginables...

Le seul commandement : Procéder par ordre (certains diraient : "de façon incrémentale"...)

Rien ne sert d'installer INN tant que l'on ne sait pas rapatrier les articles. Par conséquent, la première chose à faire est d'installer et de tester suck. Lorsqu'on sera sûr que tout fonctionne correctement, on passera à la phase suivante, pas avant !

Installation et tests de suck

Installation

suck peut être récupéré sous la forme d'un rpm ou sous la forme d'un tgz. La première solution est, évidemment la plus simple. À l'heure où ces lignes sont écrites, la version la plus récente est la 3.8.0.

Si vous utilisez un rpm, pas de problème : vous installez avec rpm en ligne de commande, ou glint sous X, et c'est tout.

Si vous utilisez un tgz, faites en sorte de placer les binaires de (suck, lmove, testhost, rpost) dans /usr/bin, les pages de manuel iront dans /usr/man/man1 et les scripts et fichiers de configuration (get.news.innxmit, get.news.rnews, put.news, sucknewsrc, suckkillfile) iront dans /var/lib/suck. Enfin, le fichier script suck (à ne pas confondre avec le programme... ira dans /etc/logrotate.d.

Premiers tests

Maintenant, on peut tester la récupération (on suppose que le telnet news.fai.fr nntp, décrit plus haut, a été testé...). Pour ce faire, on édite le fichier sucknewsrc qui abritera les noms des groupes à récupérer. L'exemplaire livré contient plusieurs lignes que l'on supprime. À des fins de test, on ajoute une seule ligne :

fr.comp.os.linux -10

pour indiquer à suck que le prochain ramassage sera le premier pour ce groupe et qu'il concernera les 10 derniers articles du groupe fr.comp.os.linux, sachant que le serveur ne possède pas tous les articles depuis l'origine du groupe (n'oubliez pas le 10 car, sinon, vous risquez de récupérer tous les articles de ce groupe disponibles sur le serveur !)

Vérifiez que le sous-répertoire /var/lib/suck/Msgs existe, sinon créez-le.

On sauvegarde ce fichier, et, en restant dans /var/lib/suck, on tape la commande suivante (après établissement de la connexion PPP...) :

suck news.fai.fr -H -K

Les options -H -K demandent à suck d'ignorer les fichiers d'historique et le kill-file... (cf. plus loin...)

Normalement, l'affichage vous apprend que vous êtes connecté au serveur de news distant, puis vous indique que le nombre d'articles à récupérer dans fr.comp.os.linux est limité à 10. Enfin, la récupération commence : le nombre d'articles restant à récupérer et la vitesse de transfert s'affiche. Lorsque cela est terminé, vous pouvez couper votre connexion PPP : les articles sont sur votre machine...

Normalement, plusieurs choses ont dû de passer dans le répertoire /var/lib/suck :

Détaillons un peu :

Le problème est que sucknewsrc n'a pas été modifié, or suck n'utilise que ce dernier pour stocker le numéro du dernier article récupéré afin de pouvoir, lors de la session suivante, ne télécharger que les nouveaux. Cela signifie donc que si vous relancez suck maintenant, il récupèrera exactement les mêmes articles...

Pour éviter cela, il faut détruire l'ancien sucknewsrc, et renommer suck.newrc en sucknewsrc... Fastidieux, non ?

Heureusement, l'option -c (comme clean) passée à suck effectue cela automatiquement :

Nous vous conseillons donc de n'utiliser cette option que lorsque vous aurez bien vérifié que tout fonctionne correctement : en effet, les différents fichiers sont autant de traces de fonctionnement.

Bon, on a supposé que tout avait marché comme sur des roulettes... Ce serait trop simple : votre premier lancement de suck a très bien pu ne pas se dérouler comme prévu... Notamment, vous pouvez avoir eu des erreurs du style :

430 No such article
..........

Si ces erreurs sont rares (1 sur 10, par exemple) ce n'est pas trop grave, il faudra quand même surveiller les sessions suivantes. Si, par contre, il y en a beaucoup (au pire, 10 sur 10) alors bienvenue dans le premier problème...

Il faut savoir que chaque article porte un champ d'immatriculation. C'est l'en-tête (« header ») appelé « Message-id », établi lors de la publication de l'article de façon à être (très vraisemblablement) unique.

Sur toute machine utilisant un logiciel serveur de news classique (par exemple INN) chaque article est stocké dans un fichier nommé d'après son numéro d'arrivée, lui-même placé dans un répertoire le plus souvent placé sous /var/spool/news et au nom établi d'après celui du groupe. Le premier article arrivé sur un serveur donné pour le groupe fr.comp.os.linux, par exemple, a toutes les chances d'être stocké dans un fichier appelé /var/spool/news/fr/comp/os/linux/1.

Attention : par « premier article arrivé », il ne faut pas entendre « le premier article paru dans le groupe », car un nouveau serveur récupère, sitôt connecté, les articles circulant à ce moment et non les anciens.

Le « Message-id » d'un article donné est le même sur tous les serveurs, mais son « numéro » sur deux serveurs distincts sera très probablement différent.

suck récupère les articles par leur Message-id, or certains serveurs de news dont ceux qu'utilise Havas On Line (qui s'appellent news1.isdnet.net, news2.isdnet.net, etc.) ont configuré leur système pour que la récupération ait lieu sur le numéro d'article... La récupération classique par suck ne fonctionne donc plus, d'où ces erreurs...

Heureusement, Emmanuel Chantreau a corrigé ce problème en modifiant le code de suck pour lui ajouter une option -n lui permettant de récupérer les articles par leur numéro sur le serveur plutôt que sur leur Message-id. Cette modification a été intégrée dans la dernière version de suck (la 3.8.0).

À partir de là, on suppose donc que suck a bien récupéré vos articles. Si ce n'est pas le cas, n'allez pas plus loin, recommencez tout depuis le début : ce ne sera pas une perte de temps...

Tests supplémentaires : préparation à l'utilisation dernews

Si les tests précédents ont donné satisfaction, on peut passer à l'étape suivante pour préparer l'installation de INN et la lecture des articles avec un lecteur de news digne de ce nom...

Au lieu de sauvegarder chaque article dans un fichier séparé comme c'était le cas jusqu'alors, on va créer un fichier de traitement par lots ("batch") qui pourra ensuite être traité par le programme rnews (cf. plus loin).

La commande permettant de réaliser cela est la suivante (qui doit être invoquée à partir du répertoire /var/lib/suck :

suck news.fai.fr -c -H -W -br nouveau

Les options -c -H -W ont déjà été décrites plus haut...

Si vous avez besoin de l'option -n de la version d'Emmanuel Chantreau, n'oubliez pas de l'ajouter.

L'option -br nouveau indique à suck de créer un fichier batch, qui s'appelera nouveau, contenant tous les articles reçus afin qu'ils puissent ensuite être envoyés à votre serveur de news local via rnews (il existe aussi une option -bi réalisant la même chose en vue d'un traitement par innxmit : toutes les informations sur les formats de ces fichiers batch sont disponibles par la commande man suck et ne seront donc pas traitées ici.)

On va d'abord faire en sorte de récupérer des articles : éditez le fichier /var/lib/suck/sucknewsrc, ôtez la deuxième valeur en face de fr.comp.os.linux et modifiez le chiffre restant (numéro du dernier article récupéré de ce groupe) en lui otant 10 : vous devriez donc récupérer au moins 10 articles... Lancez la commande décrite plus haut.

Les choses ont changé par rapport aux premiers tests :

Éditez le fichier nouveau et vérifiez qu'il contient bien les articles reçus (séparés par des champs #rnews xxxxxxxx est la taille de l'article. Tant que vous n'avez pas installé INN (et donc rnews) vous ne pouvez pas en faire grand chose hormis le parcourir...

Ce qui est important c'est que, si vous êtes arrivés là, vous êtes prêts pour la suite... Sinon, ne continuez pas : assurez-vous que tout ce qui a été décrit plus haut fonctionne correctement !

Newsx

Présentation de newsx

newsx remplit à peu près les mêmes fonctions que suck, on choisira d'utiliser suck ou newsx pour des raisons de confort (rapidité, facilité d'utilisation).

Les avantages de newsx par rapport à suck sont :

Les inconvénients de newsx par rapport à suck sont :

Installation de newsx

newsx 0.9 est disponible dans la redhat 4.2 dans la section contrib, sur sunsite dans le répertoire system/news/transport et, pour debian, il n'est pas dans le 3.1 stable mais dans la section non stable.

Pour lancer newsx, tapez la ligne suivante :

newsx -ddd -i -W40 news.fai.fr news.fai.fr

Voilà, il n'y a rien d'autre à faire. Avec cette commande, newsx s'occupe d'envoyer les news à poster et de lire les groupes indiqués dans le fichier newsfeeds d'INN. Les news reçus seront lisibles quelques minutes plus tard par votre newsreader, cela dépend de la fréquence de la répartitions des news (toutes les 15 minutes chez moi).

Il est possible de combiner l'utilisation de newsx et suck de manière à bénéficier de la gestion des kill-files, très utile pour certains groupes. Pour cela, il faut créer deux lignes (deux feeds) pour le serveur news.fai.fr. Une pour les groupes à prendre avec newsx, et une pour les groupes à prendre avec suck. Chaque ligne devra exclure les groupes de l'autre. sucked.news.fai.fr ne correspond pas à un vrai serveur mais cela n'a pas d'importance, il suffit de mettre les noms des vrais serveurs après le « / ».

Exemple pour CNEWS :

# newsgroups pris et postes par newsx
news.fai.fr/news1.isdnet.net,news2.isdnet.net,news3.isdnet.net,news4.isdnet.net:
all,!fr.comp.os.linux.annonces,!fr.soc.politique,!junk/all:FL:
 
# newsgroups pris par suck et postes par newsx
sucked.news.fai.fr/news1.isdnet.net,news2.isdnet.net,news3.isdnet.net,news4.isdn
et.net:fr.comp.os.linux.annonces,fr.soc.politique/all:FL:

Et on lance newsx par les commandes :

# nntp server=news.fai.fr, feed=sucked.news.fai.fr, --nofetch empeche de
# prendre les articles, on ne fait que poster.
newsx --nofetch -ddd --stat /tmp/log/news.stat --cnews sucked.news.fai.fr news.fai.fr  >>/tmp/log/news.log 2>&1

# nntp server=news.fai.fr, feed=news.fai.fr, on poste et on prend
newsx -ddd --stat /tmp/log/news.stat --cnews -W40 news.fai.fr news.fai.fr  >>/tmp/log/news.log 2>&1

Nous allons maintenant passer à l'installation d'INN. Certains aspects de suck ont été omis : c'est volontaire car ils n'on aucun sens tant que notre serveur de news n'est pas installé...

Installation et test d'INN

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'ils sont correctement configurés fonctionnent très bien aussi. Dans cette documentation, nous ne parlerons pas de la compilation d'INN (pour cela, 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, redhat, 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 :

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

Pour comprendre : qu'advient-il des articles postés ?

Voici ci-dessous un descriptif du chemin parcouru par les articles. On supposera que vous avez écrit un article dans fr.test quand vous étiez déconnecté. Cet article est placé dans /var/spool/news/fr/test/5214.

 
VSP=/var/spool/news
newsrun est generalement lance automatiquement par cron.
 
                                 VSP/out.going/news.fai.fr 
  --------------  <--- rpost --- +                         <-------
 | Serveur NNTP |                VSP/fr/test/5214                  n
 | news.fai.fr  |                                                  e
 | du provider  |                                                  w
  --------------  ---- suck ----> /var/lib/suck/* --- rnews --     s
                                                              |    r
                                                              |    u
     -- VSP/fr/test etc <-------- newsrun -- VSP/in.coming <--     n
    |                                                ^  |          |
    V                                                |  |          |
  --------------                                     |  |          |         
 | Serveur NNTP |--------- article a poster ---------    --- si poste
 | local        |                                            localement
 | Sert a poster|
 | et lire      |<-----> lecteur de news (knews, tin, readnews etc)
  -------------- 
 

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 sybilline, 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 :

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

Ce qui fait que, lorsque je poste un article, son en-tête ressemble à ceci :

From: Eric Jacoboni <jaco@mail.dotcom.fr>
Organization: JacoSoft Intl.
Subject: blah blah blah...
...

On notera la contenu du champ From : l'adresse jaco@mail.dotcom.fr est formée du nom de login et du contenu du champ fromhost de inn.conf, ce qui précède cette adresse est le contenu du champ user_name du fichier /etc/passwd.

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.

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 qui vous approvisionnent en news. Dans notre cas, comme on a déjà récupéré les news avec suck, c'est en fait notre site qui nous approvisionne.

Il décrit aussi les sites que nous approvisionnons, en l'occurence celui de notre FAI lorsque nous postons de nouveaux articles... Le mien contient les lignes suivantes :

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

Le tronçon suivant (:Tf,Wnm:) détermine le mode de transmission des articles.

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'occurence 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 donc 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 f.a.i. utilise (afin de l'exclure comme cela est décrit plus haut), deux méthodes sont possibles :

Attention :, ce fichier 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 groupe modéré (fr.comp.os.linux.annonces et fr.comp.os.linux.moderated, par exemple). La différence entre un groupe non modéré est un groupe modéré est que tout le monde peut poster n'importe quoi (et, malheureusement, certains en profitent...) 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 groupe. Ceci signifie que, pour poster un article dans un groupe modéré, on doit d'abord l'envoyer au modérateur sous la forme d'un message. Le modérateur recevra alors votre proposition d'article et décidera de le publier dans le groupe, ou le rejettera s'il juge qu'il ne correspond pas à la charte. C'est ici qu'intervient le fichier moderators : on conçoit très bien qu'il n'est pas possible de mémoriser toutes les adresses de tous les groupes modérés auxquels on a souscrit, et c'est pourquoi ce fichier met en relation les groupes modérés avec les adresses de leurs modérateurs. Normalement, votre distribution a dû vous en fournir un contenant déjà plusieurs entrées (voir la page moderators (5), pour la syntaxe exacte) et tout ce qu'il vous reste à faire est d'ajouter les entrées qui vous intéressent. Par exemple, pour pouvoir poster dans fr.comp.os.linux.annonces, il suffit de rajouter l'entrée :

fr.comp.os.linux.annonces:fcola@linux.eu.org
fr.comp.os.linux.moderated:moderateurs-fcolm@efrei.fr

Attention : la dernière ligne de ce fichier est souvent une entrée « par défaut » contenant *:%s@moderators.uu.net qui indique que tous les articles postés dans un groupe modéré non précédemment rencontré dans les entrées devront être envoyé à l'adresse nom-du-groupe@moderators.uu.net. Ceci veut dire que vous devez ajouter vos entrées avant cette ligne et en étudiant aussi les autres entrées pour ne pas qu'elles capturent le nom de votre groupe. La solution la plus sûre consiste à ajouter en tête de ce fichier.

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 groupes 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 groupe fr.bidon par suck, et ne pas les distribuer sur notre machine si le groupe fr.bidon n'est pas décrit dans le fichier active...

Le contenu actuel de mon fichier active est le suivant :

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 groupe, sachant que les 4 premiers sont obligatoires pour que INN fonctionne (il vous suffit de les désactiver dans votre lecteur de news si vous ne voulez pas lez voir apparaître...). 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 ces groupes, 'm' signifie que le groupe est modéré). Comme d'habitude, attention à ne pas placer de retour chariot après la dernière ligne...

En fait, 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...

newsgroups

Ce fichier permet d'associer une description à chaque groupe de news. 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... 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

En fait cela permet à votre lecteur de news d'afficher la description correspondante en face du nom du groupe...

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

Normalement, vous devriez pouvoir consulter les nouveaux articles à partir de votre lecteur de news favori (configuré pour admettre localhost comme serveur de news).

Poster des articles

Vous ne pouvez poster des articles que dans les groupes mentionnés dans le fichier active décrit plus haut (pourvu que l'autorisation de postage (`y') ait été positionnée...)

Ne postez pas d'articles de tests dans n'importe quel groupe ! Pour cela, il existe le groupe fr.test (d'où la présence de ce groupe dans mon fichier active...). Postez un article de test à l'aide de votre lecteur de news, puis vérifiez le contenu du fichier /var/spool/news/out.going/nom_du_feed (chez moi : /var/spool/news/out.going/news.hol.fr : il doit contenir une seule ligne indiquant où se trouve l'article à poster. S'il y a beaucoup de lignes, voir mes remarques sur le fichier newsfeeds...

Connectez-vous à votre FAI et tapez la commande :

rpost serveur_de_news_distant    # (chez moi : rpost news.hol.fr)

Normalement, votre article est posté...

Un script pour automatiser l'envoi et la réception

J'ai écrit ce script (en m'inspirant d'autres scripts glanés ça et là...) pour poster mes articles et récupérer les nouveaux : cet ordre me permet de recevoir les articles que j'ai envoyés (mode parano on...). Placez ce script dans /usr/bin et lancez-le sous root.

#!/bin/bash

SERVEUR_DISTANT=news.hol.fr
PATH_SUCK=/var/lib/suck
PATH_SPOOL=/var/spool/news
NOM_BATCH=$PATH_SPOOL/out.going/$SERVEUR_DISTANT
NOM_FILTRE=$PATH_SUCK/entete

# On commence par poster les articles (localhost->SERVEUR_DISTANT)

echo Envoi des articles...
if test -s $NOM_BATCH
then
 rpost $SERVEUR_DISTANT -b $NOM_BATCH -p $PATH_SPOOL \
       -f $NOM_FILTRE \$\$o=/tmp/filtres \$\$i /tmp/filtres && \
       cat /dev/null > $NOM_BATCH || \
       echo "probleme de postage" | mail news -s "rpost pb rapport"
else
 echo "pas d'articles a poster..."
fi

# puis on recupere les articles (SERVEUR_DISTANT->localhost)

echo Recuperation des articles...
cd $PATH_SUCK
suck $SERVEUR_DISTANT -c -n -br nouveau
rnews nouveau

Le fichier NOM_FILTRE permet de formatter les articles. Normalement, la distribution de suck a dû vous en fournir un... Classiquement, ce filtre a pour but de remplacer le champ NNTP-Posting-Host par le champ Xref. Si cela n'est pas fait, il y a de gros risques pour que le serveur de news de votre F.A.I. refuse votre article.

Utilisation de ctlinnd

Il n'est pas question, ici, de détailler tout ce que peut faire le programme ctlinnd, qui, comme son nom l'indique, sert à contrôler le fonctionnement du serveur innd. Nous ne nous en tiendrons à notre optique simplificatrice : vérification du bon fonctionnement et expiration des articles. Le lecteur intéressé pourra consulter la page du manuel ctlinnd(8). Pensez à vous mettre sous le compte news...

Vérification du fonctionnement d'INN

La commande ctlinnd mode affiche l'état courant de votre serveur de news local, normalement vous devriez obtenir une sortie du type :

Server running
Allowing remote connections
Parameters c 14 i 0 (0) l 0 o 243 t 300 H 2 T 60 X 0 normal specified
Not reserved
Readers separate enabled

La commande ctlinnd checkfile vérifie la syntaxe du fichier newsfeeds (opération qu'il faut mieux faire avant de recharger ce fichier en mémoire à la suite de l'ajout d'un nouveau feed). Normalement, ça doit vous répondre « Ok »

Pour recharger newsfeeds en mémoire, exécutez la commande

ctlinnd reload newsfeeds "rechargement du fichier newsfeeds"

Modification du fichier active

Comme nous le disions plus haut, il est préférable de ne pas modifier manuellement le fichier active. À la place, on utilisera la commande

ctlinnd newgroup fr.comp.mail
pour ajouter le groupe non modéré fr.comp.mail, ou
fr.comp.os.linux.annonces m
pour ajouter le groupe modéré fr.comp.os.linux.annonces.

Pour supprimer une entrée du fichier active on utilisera la commande

ctlinnd rmgroup fr.comp.mail
pour supprimer l'entrée correspondant au groupe comp.mail

Attention : La manipulation du fichier active nécessite de stopper le serveur de news au préalable :

ctlinnd pause "modification du fichier active"

Les modifications terminées, on peut vérigier la cohérence de la configuration avec la commande incheck (voir plus bas).

Si la vérification s'est bien passée, il reste à relancer le serveur après avoir rechargé le fichier active en mémoire :

ctlinnd reload active "rechargement du fichier active"
ctlinnd go "modification du fichier active terminee"

ctlinnd peut faire encore beaucoup d'autres choses, reportez vous aux liens cités en fin de ce document pour en apprendre plus. Pour nous, ça suffit...

Pour vérifier la cohérence de la configuration et la validité des fichiers, utilisez la commande

inncheck -a -v -pedantic
sous le compte news (cf. la page de manuel inncheck(8)).

Chez moi, j'obtiens :

Looking at /var/lib/news/active...
Looking at /etc/news/control.ctl...
Looking at /etc/news/expire.ctl...
Looking at /etc/news/hosts.nntp...
Looking at /etc/news/inn.conf...
Looking at /etc/news/moderators...
Looking at /etc/news/newsfeeds...
ME, crosspost, overview!, news.hol.fr, /etc/news/newsfeeds:0: warning you accept 
all incoming article distributions
done.
Looking at /etc/news/nnrp.access...
/var/lib/news//nntpsend.ctl:0: file missing
Looking at /etc/news/overview.fmt...
Looking at /etc/news/passwd.nntp...

Ce qui n'est déjà pas si mal... Un warning pour l'entrée ME du fichier newsfeeds pour m'avertir que j'accepte toutes les distributions, et un warning pour m'indiquer que le fichier nntpsend.ctl manque, ce qui n'est pas grave pour notre type d'utilisation.

Enfin, pour tracer les différents évènements en cas de doute, consultez les fichiers traces se trouvant sous /var/log/news, notamment news.err, news.crit et news.notice : pour tout article posté dans fr.usenet.logiciels afin de résoudre un problème, indiquez les erreurs reportées dans ces fichiers, ça aidera forcément ceux qui veulent vous répondre...

À ce propos, toute distribution d'INN vient avec une liste de fichiers textes (mais en anglais) recensant toutes les FAQs et les réponses. Une lecture de ceux-ci est chaudement recommandée.

Expiration des articles

La commande permettant d'effacer les articles périmés est expire : en fait, expire dresse une liste qu'il passe ensuite au programme fastrm. L'administrateur doit donc veiller à ce que cette commande soit lancée régulièrement (quotidiennement) : le script news.daily est fait pour cela. Normalement, l'installation du paquetage rpm INN a dû installer le fichier inn-cron-expire dans /etc/cron.daily/ pour appeler news.daily.

Sinon, une façon plus « brutale » de forcer cette expiration est de lancer sous le compte news, la commande /usr/lib/news/bin/expire -v1 suivie d'un /usr/sbin/ctlinnd renumber.

La commande expire utilise le fichier expire.ctl qui permet de paramétrer les durées d'expiration des articles. La syntaxe de ce fichier est décrite dans expire.ctl(5).

Filtrage des articles par suck

suck permet de filtrer les articles qu'il récupèrera sur le serveur distant. Il utilise, pour cela un mécanisme de « kill-files » (cf. suck(1)) Dans le répertoire /var/lib/suck doit se trouver un fichier suckkillfile qui est le fichier de filtrage maître. Le mien contient les lignes suivantes (par discrétion, j'ai caché les noms des indélicats dont je ne souhaite pas récupérer les articles...)

HILINES=10000
#LOWLINES=10
NRGRPS=5
From:aaaa@bbb.fr
From:cccc@ddd.fr
QUOTE=\
GROUP=delete fr.comp.os.linux.annonces suckkillfile.fcola
GROUP=delete fr.usenet.logiciels suckkillfile.no_ms
GROUP=delete fr.comp.mail suckkillfile.no_ms

Chaque entrée de ce fichier peut être de 2 types :

On notera que les entrées de type mot-clé ont la syntaxe mot_clé=paramètre(s) alors que les entrées de type header ont la syntaxe header:valeur (en tous cas, depuis la version 3.6.0).

Les champs HILINES et LOWLINES indiquent, respectivement, qu'il ne faut pas récupérer les articles ayant plus de lignes ou moins de lignes que celles spécifiées. Ici, suck ne récupèrera pas les articles ayant plus de 10000 lignes. J'ai commenté l'entrée LOWLINES car certains auteurs (n'est-ce pas, Nat ?) envoient des articles parfois très courts (un simple lien, par exemple).

Le champ NRGRPS indique le nombre maximal de groupes autorisé pour le postage multiple d'un article. C'est une première précaution pour éviter les « spams », car tout article posté dans de trop nombreux groupes est suspect. Cette entrée n'apparaît qu'à partir de la version 3.8 de suck.

Le champ QUOTE permet de définir le caractère servant à quoter les caractères spéciaux dans les expressions régulières (cf. regexp(3)).

Le champ GROUP permet de définir un comportement pour un groupe particulier : ce comportement est soit delete soit keep. Il s'applique au groupe dont le nom suit, selon les règles de filtrage définies. dans le fichier précisé. Ici, je filtre les articles des groupes fr.comp.os.linux.annonces, fr.usenet.logiciels et fr.comp.mail. Le premier est filtré selon les règles définies dans le fichier de filtrage suckkillfile.fcola et les deux autres selon les règles définies dans suckkillfile.no_ms.

Ici, le fichier suckkillfile ne contient que deux entrées de type header : elles servent à filtrer tous les articles dont le champ « From » contient une des deux adresses spécifiées, quels que soient les groupes dans lesquels ils ont été postés. Cela permet, notamment, d'éliminer les « trolleurs » ou les « spammers » déjà repérés.

Les entrées de type header décrites dans le fichier suckkillfile s'appliquent à tous les groupes.

Pour définir un comportement particulier pour un groupe donné, on utilise une entrée GROUP. Mon fichier suckkillfile.fcola ne contient qu'une ligne :

Path:fr\.howto

Ce qui permet de filtrer les articles contenant fr.howto dans leur champ Path : cela me permet d'éviter la récupération des Howtos publiés mensuellement dans fcola...

Mon fichier suckkillfile.no_ms contient les lignes suivantes :

Subject:.*Eudora
Subject:.*Forte
Subject:.*Outlook
Subject:.*\<Ms
Subject:.*Pegasus
Subject:.*Gravity

Ce qui permet de filtrer les articles dont le champ « Subject » concerne des logiciels dédiés à Microsoft (pas tous, malheureusement...).

À chaque fois qu'il rejette un article, suck l'indique dans le fichier /var/lib/suck/suck.killlog en indiquant la raison de ce rejet. Par des options passées à suck, vous pouvez paramétrer la taille de ces informations : par défaut, suck utilise le format long mais je trouve le format court peu explicite... Jettez un coup d'oeil à ce fichier lorsque vous ajoutez un critère de filtrage afin de vous assurer que les effets obtenus sont bien ceux escomptés.En tous cas, pensez à vider ce fichier périodiquement car il a tendance à grossir assez vite.


Page précédente Page suivante Table des matières