Deux voies s'ouvrent à vous :
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).
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.
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...).
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.
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 !
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
.
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
:
suck.newrc, suck.sorted
ont été créés ;/var/lib/suck/Msgs
contient désormais des
fichiers portant les noms 1-10, 2-10, etc. Chacun de ces fichiers correspond
à l'un des 10 articles que vous avez récupéré et vous pouvez les visualiser
avec votre éditeur de texte favori. (Rassurez-vous, il existe des moyens
bien meilleurs de consulter les articles...)Détaillons un peu :
suck.newrc
est une mise à jour de sucknewsrc
:
regardez et vous verrez que la ligne concernant fr.comp.os.linux
a
remplacé -10 par une autre valeur, le numéro du dernier article lu.suck.sorted
contient les en-têtes des articles récupérés. Ce
fichier ne sert pas à grand chose sauf lorsqu'on veut pister d'éventuels
dysfonctionnements.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 :
sucknewsrc
en sucknewsrc.old
(ce qui
permet de revenir en arrière, si nécessaire) ; suck.newsrc
en sucknewsrc
;suck.sorted
(et d'autres fichiers utilisés
temporairement par suck
).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...
rnews
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 :
/var/lib/suck/Msgs
est vide ;nouveau
a été créé dans /var/lib/suck
Éditez le fichier nouveau
et vérifiez qu'il contient bien les
articles reçus (séparés par des champs #rnews xxxx
où xxxx
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
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 :
newsx
est plus rapide que
suck
si on utilise l'option -W
. Cette option permet d'envoyer en
rafale les requêtes au serveur NNTP, le gain de vitesse est difficilement
prévisible. Avec mon fournisseur d'accès, newsx
est environ deux fois
plus rapide que suck
. suck
à INN
ou CNEWS
(il lit les
mêmes fichiers de configuration qu'INN
ou CNEWS
suivant certaines
options).Les inconvénients de newsx
par rapport à suck
sont :
suck
doit prendre l'en-tête de l'article, puis, soit il prend
le corps de l'article, soit il passe au suivant. Donc, quand un article est
pris en entier, il est pris en deux fois au lieu d'une, ce qui est plus
lent.
Cela dit, tout est affaire de circonstances : si, par exemple, vous êtes
abonnés à fr.comp.os.linux.annonces
(ce que je vous conseille) la
récupération mensuelle du contenu de tous les Howtos vous énervera
probablement au bout de quelques temps. suck
vous permet d'éviter cela
(cf. voir plus bas).suck
car il affiche constamment le débit, alors que newsx
ne le fournit qu'à
la fin.newsx
, il est moins
aisé de prendre les n derniers articles qu'avec suck
(mais c'est
faisable).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
-ddd
permet de largement commenter ce que fait newsx
.-i
indique qu'il doit coopérer avec INN
(-c
pour CNEWS
)-W40
indique qu'il doit envoyer les requêtes par paquets de 40.
news.fai.fr
est le spoolname
(cf. installation d'INN
). news.fai.fr
est le serveur NNTP à contacter.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é...
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 :
/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).
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)
--------------
/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 :
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.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 :
telnet news.fai.fr nntp
qui vous renseignera sur
le nom de la machine qui vous envoie les articles. 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é...
Path:
qui indique la route qu'à suivi cet article pour arriver jusqu'à
nous. Le nom qui suit celui de votre machine 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, voici le contenu du
champ Path:
de chaque article que je reçois :
Path: titine.jacosoft.fr!easynet-fr!...!...!...
easynet-fr
doit donc être exclus, ce qui fait que mon fichier
newsfeeds
contient désormais, à la place de la ligne
news.hol.fr
, la ligne suivante :
news.easynet.fr/easynet-fr\ :*,!junk,!control:Tf,Wnm:
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.
/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...
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
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
.
/var/spool/news
qui doit appartenir à
news
et qui doit être vide (sinon, sauvegardez ce qui s'y
trouve...).
INN
, il n'y a rien d'autre à faire :
l'installation 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 la
distribution à dû mettre, par false
: cela évitera le lancement
de 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
)
/etc/rc.d/rc.news start
qui doit normalement vous répondre innd
pour vous informer que le
démon est lancé...
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 avez ça, c'est que INN
tourne, bravo...
suck
(/var/lib/suck
). Vous vous rappelez du fichier nouveau
que
l'on avait généré ? On va l'utiliser pour alimenter NOTRE serveur :
rnews nouveau
Normalement, vous devriez pouvoir consulter les nouveaux articles à partir de votre lecteur de news favori (configuré pour admettre localhost comme serveur de news).
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é...
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.
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
...
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"
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.
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)
.
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 :
HILINES, LOWLINES, QUOTE, GROUP
: ils
définissent un comportement « général » ;From, Subject, Path, ...
(en fait, tout champ
valide d'un en-tête d'article) : ils définissent un comportement
« particulier ».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.