Configuration de <productname class="trade">INN</productname>
Ou comment lire et poster les news off-line sur une
machine Unix.
Éric
Jacoboni
jaco@linux-france.org
Nat
Makarévitch
nat@linux-france.org
V4.0 - 19 novembre 2000
Introduction
Préliminaires
Ce document décrit les différentes procédures à employer pour
pouvoir consulter et poster off-line des articles
dans les forums USENET à partir d'une machine Unix. Vous pouvez
télécharger sa version
PostScript, ou sa version
PDF (ces deux dernières sont imparfaites à cause d'un script
de conversion récalcitrant. Patientez ou agissez...). Vous pouvez
également télécharger son code
source (DTD DocBook/XML V4.1.2). Le site de référence de ce
document est Linux-France :
c'est là que se trouveront les versions les plus récentes. Toutes
remarques et suggestions concernant ce document peuvent être envoyées
à Éric
Jacoboni.
Le but de cette documentation n'est pas de fournir des recettes,
mais d'expliquer les différentes tâches liées à l'installation des
programmes nécessaires à une lecture off-line des
news sur un système Unix. On y trouvera aussi les difficultés
rencontrées lors de la configuration de ces programmes.
Ce document ne traite pas de la connexion de votre système à
Internet, il suppose que cela fonctionne... Par conséquent, nous
renvoyons les utilisateurs de Linux à la lecture de l'ISP-Hookup
HOWTO et du Guide
du Rootard. Les utilisateurs de FreeBSD trouveront les mêmes
informations dans le FreeBSD Handbook.
Par rapport aux versions précédentes de ce document, celle-ci
ajoute l'installation et la configuration de INN
2.x. Étant donné le grand nombre d'INN
1.7 encore en circulation, nous avons conservé la
configuration de celui-ci.
Nous avons aussi choisi de ne plus faire dépendre ce document
d'une implantation particulière d'Unix car les nombreuses
distributions de Linux, les différents Unix et leurs spécificités,
rendent la chose impossible. De plus, INN peut être installé sur de nombreuses
plates-formes et ce serait une erreur de spécialiser ce document car
cela irait à l'encontre de ce qu'ont voulu faire les concepteurs des
logiciels utilisés ici.
Description de la machine type
Système d'exploitation :
N'importe quel Unix
Système :
machine isolée, reliée à un
fournisseur d'accès Internet via PPP.
Prérequis :
la connexion PPP
fonctionne, si tel n'est pas le cas, reportez-vous aux documents
cités précédemment, et à la
rubrique CONNEX.
Bien que nous prétendons que ce document puisse convenir à tout
système Unix, il est évident que nous n'avons pas installé
INN sur tous les Unix
existants, ni même sur toutes les distributions Linux
actuelles...
Au moment où sont écrites ces lignes, nous avons personnellement
testé cette configuration sur les systèmes suivants :
Red Hat Linux 5.x et 6.x
SuSE 6.x
Debian Linux 2.x
FreeBSD 3.x, 4.x et 5.0
De nombreux courriers nous ont confirmé que ce document avait
servi à configurer INN sur d'autres
distributions Linux (Slackware). Il n'y a a
priori aucune raison pour qu'il n'en aille pas de même pour
votre système (si tel était le cas, merci de nous en faire
part).
Les quatre Unix cités disposent d'un mécanisme permettant
d'automatiser l'installation des logiciels : les systèmes de
paquetages RPM de Red Hat (également utilisé par SuSE) ou DEB de
Debian, le système des ports
de FreeBSD permettent une
installation des programmes aux emplacements considérés comme
normaux
sur ces systèmes ainsi que la mise en place des
scripts de démarrage et d'arrêt du serveur. Cela dit, ce que nous
entendons par installation
dépasse la simple copie de
fichiers : elle consiste surtout à fournir les
bonnes informations dans les
bons fichiers de configuration et cela, aucun
système de paquetage ne le fait encore.
Quoi qu'il en soit, il nous faut maintenant régler un détail
d'importance qui empoisonne la vie de ceux qui veulent écrire des docs
généralistes et directement utilisables : le problème des
emplacements où seront installés les différents programmes et fichiers
de configuration. En effet, ces emplacements varient d'une
distribution de Linux à l'autre, et d'un Unix à l'autre. Afin de
mettre tout le monde d'accord (et de me mettre tout le monde à dos),
j'utiliserai les choix des concepteurs des logiciels concernés et
donnerai la liste des emplacements des différents fichiers sur un
système respectant ces choix. À vous de faire la traduction de ces
emplacements en ceux employés sur votre système (il faut bien qu'il
vous reste quelque chose à faire...).
Pour tous les exemples, on supposera donc que :
le serveur de news de votre Fournisseur d'Accès
Internet (F.A.I) se nomme news.fai.fr (par exemple
news.easynet.fr si vous êtes abonnés à Easynet,
news.free.fr si vous êtes abonnés à Free,
/news.aol.com si vous êtes abonnés à AOL
(euh... non, c'est une blague) : votre fournisseur a dû vous le
préciser au moment de votre abonnement) ;
votre connexion PPP est établie lorsque vous utilisez
l'un des récupérateurs de news décrits.
Présentation et installation des logiciels utilisés
Cette documentation traite de trois logiciels :
Suck, Newsx et
INN. Les deux premiers permettent de
récupérer et de poster les articles Usenet (un seul est
nécessaire), tandis que le troisième est celui qui
permettra de transformer votre machine Linux en serveur Usenet
local.
En réalité, seule la configuration
d'INN nous intéresse ici : les deux
premiers programmes ne sont là que pour l'alimenter à partir du
serveur de news de notre fournisseur, ils sont eux-mêmes facultatifs
si vous avez la chance d'être abonné à un fournisseur qui veuille bien
se donner les moyens d'être à la hauteur (mais ils sont
malheureusement peu à le faire...).
Au moment où ces lignes sont écrites, seuls Easynet et
Teaser proposent, à notre connaissance, l'alimentation automatique de
votre serveur INN local (si vous en connaissez d'autres, faites-m'en
part).
La dernière version de Suck
est la 4.2.3. Il existe en paquetages RPM et DEB précompilés sur les
sites des distributions Linux concernées et FreeBSD l'intègre dans son
système de ports. Le code source original peut être récupéré à partir
de cette
page.
En ce qui concerne Newsx,
les paquetages binaires RPM et DEB existent mais il n'existe pas
encore de port pour FreeBSD : pour l'installer, il suffit de récupérer
les sources sur ce
site (par exemple) et de le recompiler en suivant les
instructions données par les différents fichiers texte.
INN fait partie des
distributions Linux, et du système de ports de
FreeBSD. Il existe deux versions qui cohabitent à
l'heure actuelle : la 1.7 et les 2.x. Ce document
présente la configuration de chacune d'elle. Les sources
de ces deux versions peuvent être récupérés sur le
site
officiel.
Autres solutions possibles
La solution que nous préconisons ici a plusieurs
avantages :
elle permet d'écrire et de consulter les articles tout
en étant déconnecté, ce qui, dans notre cas, signifie de
substantielles économies sur la facture
téléphonique...
l'utilisation de Suck
permet un filtrage efficace des articles, ce qui évite de voir les
forums encombrés par des fils de discussions ou par des sujets qui ne
nous intéressent pas, par exemple.
INN offre une souplesse
supérieure à celle des autres outils fonctionnellement
équivalents. Une fois le serveur installé, il n'y a plus rien à
faire : tout est géré par une tâche cron. Le
plus souvent, les seules interventions consistent à ajouter de
nouveaux groupes de discussion, ou à en supprimer
certains.
elle est aussi un moyen d'enseignement par
l'exemple
: installer INN,
c'est comprendre un peu mieux les mécanismes
d'Usenet.
Cela dit, d'autres solutions existent (PerUser,
leafnode, slrnpull,
le mode agent
de gnus, Pan, etc.). Nous n'en
traiterons pas ici.
Préliminaires
Quand on dit que l'installation est compliquée, on exagère
beaucoup : en fait, elle n'est pas difficile dès lors qu'un
minimum de choses sur le fonctionnement d'Usenet sont bien
comprises. 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é : j'ai eu de la chance, j'en ai eu pas
mal...
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'étudier le mode de propagation des articles, puis
d'installer et de tester Suck. Lorsqu'on
sera sûr que tout fonctionne correctement, on passera à la phase
suivante, pas avant !
Fonctionnement de Usenet
Avant de commencer, une rapide présentation du fonctionnement
d'Usenet vous permettra de comprendre ce qu'il advient des articles
postés entre le moment où il sont écrits et celui où vous les
lisez. Et réciproquement, comment peut-on lire un article qui a été
posté à l'autre bout du monde ?
Le spool des news
INN, comme les autres serveurs
Usenet, utilise un spool pour stocker les
articles. Il s'agit d'une arborescence de répertoires qui abritera des
fichiers contenant les articles qu'il gère. Généralement, sous Unix,
tous les répertoires de spool se trouvent sous
/var/spool, le spool des news se trouve donc sous
/var/spool/news et appartient à l'utilisateur et
au groupe news.
Normalement, l'utilisateur et le groupe news
ont dû être créés lors de l'installation de votre système. Vous pouvez
vous en assurer en consultant le contenu du fichier
/etc/passwd (de préférence avec
vipw, si vous en disposez). Vous devriez voir une
entrée comme celle-ci sous Linux :
news:x:9:9:news:/var/spool/news:/bin/sh
ou, sous FreeBSD :
news:*:8:8::0:0:News Subsystem:/usr/local/news:/usr/local/bin/zsh
Si ce n'est pas le cas, créez cet utilisateur et ce groupe de
façon à avoir cette ligne dans /etc/passwd. Pour
cela, utilisez les utilitaires de votre système (sur de nombreux Unix,
la commande useradd ou adduser
s'acquitte parfaitement de cette tâche : consultez le manuel de
votre système pour en savoir plus). Dans tous les cas, nous vous
déconseillons de créer un groupe ou un utilisateur à la
main
(sauf si vous savez exactement ce que vous faites, ou
pour des raisons d'apprentissage...).
Les forums Usenet étant organisés par thèmes, le spool respecte
cette hiérarchie. INN créera donc autant de
répertoires qu'il gère de forums. Par exemple, lorsqu'il reçoit un
article de fr.comp.os.unix, il le place sous le
répertoire /var/spool/news/fr/comp/os/unix
(/var/spool/news/articles/fr/comp/os/unix
ou ~news/spool/articles/fr/comp/os/unix
dans le cas d'INN 2.x) sous la forme d'un
fichier dont le nom est le numéro d'ordre de l'article dans ce
forum. Ce numéro est strictement local : le
fichier stockant le premier article reçu s'appelle
1, le deuxième 2... et ces
noms n'ont aucun rapport avec ceux utilisés par les autres
serveurs.
Bien entendu, il faut qu'il y ait un mécanisme permettant de
supprimer de ces répertoires les articles les plus anciens car, sinon,
le disque se remplirait rapidement. Ce mécanisme est celui de
l'expiration
, gérée par le
programme expire (fourni avec
INN), que nous étudierons plus loin.
Publication de nouveaux articles
Commençons par nous : que se passe-t-il lorsque l'on poste un
article dans un forum non modéré ?
On supposera, pour cet exposé, que l'on a écrit et posté un
article dans fr.test tout en étant
déconnecté.
INN place cet article dans
/var/spool/news/fr/test/xxxx
(/var/spool/news/articles/fr/test/xxxx ou
~news/spool/articles/fr/test/xxxx avec
INN 2.2, et où xxxx est
un nombre représentant le numéro local de votre
article dans ce forum ; ainsi que nous l'avons écrit plus haut,
il est automatiquement généré par
INN.
À partir de ce moment, cet article est disponible pour tous ceux
qui utilisent votre machine comme serveur
INN. Si vous avez plusieurs comptes sur
cette machine, ils pourront le lire et ceci bien que
l'article ne soit pas encore diffusé sur les autres
serveurs ! Cela peut sembler bizarre, mais comprendre
cela, c'est comprendre le fonctionnement d'Usenet : priorité aux
articles locaux, et propagation des articles de serveur en serveur de
part le monde. En fait, un forum Usenet local
est un
forum comme les autres sauf que ses articles ne sont pas distribués
aux autres serveurs...
Oui, mais voilà : vous aurez indiqué quelque part (nous
verrons comment) que vous voulez propager tous les articles que vous
avez postés (sur une machine isolée comme la mienne, il y a peu
d'intérêt à disposer de forums locaux, à part pour se parler
soi-même...). INN aura donc placé les
références de l'article dans le fichier
/var/spool/news/out.going/fai sous la forme d'une
ligne par article à poster. Ici, par exemple, la ligne serait :
fr/test/63 <m3d8fyb7h9.fsf@titine.jacosoft.fr>
car il se trouve que, du point de vue de mon serveur local, l'article
que j'ai posté serait le 63ème du forum
fr.test. Dans certains cas le numéro
d'immatriculation de l'article
(<m3d8fyb7h9.fsf@titine.jacosoft.fr>) n'est
pas placé dans ce fichier, cela importe peu en ce qui nous concerne
ici.
Tout ce processus se répétera à chaque fois que vous posterez un
article, dans quelque forum non modéré que ce
soit. Le problème des forums modérés sera traité lorsque nous
étudierons le rôle du fichier moderators
d'INN.
Lorsque vous vous connecterez à votre fournisseur, il vous
suffira alors d'invoquer le programme rpost (qui
fait partie de la distribution de Suck) qui
se chargera d'expédier les articles que vous avez écrits au serveur
Usenet de celui-ci. Votre fournisseur étant contacté en permanence à
l'Internet, le processus que nous venons de décrire se répètera :
les articles de son serveur sont envoyés aux serveurs auxquels il est
relié, etc.
Réception d'articles
Voyons maintenant ce qui se passe dans l'autre sens :
lorsque vous vous connectez à votre fournisseur, vous récupérez les
articles des forums auxquels vous êtes abonnés soit directement, soit
à l'aide d'un programme comme suck ou
newsx. Ces logiciels regroupent généralement les
articles récupérés dans un fichier batch (rassemblant un lot
d'articles) qui sera ensuite traité par les programmes
rnews ou innxmit, qui font tous
deux partie de la distribution d'INN. Ces
programmes lisent le fichier batch et envoient chacun des articles
qu'il contient au serveur. L'alimentation directe proposée par
certains fournisseurs d'accès automatise tout cela : une commande
suffit pour tout faire (la génération du fichier batch et son
traitement par innxmit ou rnews
est automatique). Le reste est identique au postage d'un article. En
fait, du point de vue du serveur, il n'y a pas vraiment de
différence : il reçoit des articles d'où qu'ils
viennent et les répartit dans le spool de news.
Résumons :
le serveur ne fait que placer les articles qu'il
reçoit dans le spool (en fait, il gère aussi l'historique de ces
articles et leur expiration) ;
lorsqu'on poste un article, le lecteur de news se
charge de l'envoyer au serveur (avec un programme comme
inews, par exemple) ;
lorsqu'on souhaite expédier au serveur de son FAI un
article posté localement, on se connecte et on invoque un programme
comme rpost ;
lorsqu'on souhaite récupérer de nouveaux articles en
provenance du serveur de son FAI, on se connecte et on récupère les
articles avec des programmes comme suck ou
newsx, puis on les envoie à notre serveur local
avec un programme comme rnews ou
innxmit. Ce traitement peut être pris en charge par
votre fournisseur.
Tout ceci peut être représenté par le schéma suivant :
VSP=/var/spool/news (pour INN 1.7)
newsrun est généralement lancé automatiquement par cron.
VSP/outgoing/news.fai.fr
-------------- <--- rpost --- + <-------
| Serveur NNTP | VSP/fr/test/5214 n
| news.fai.fr | e
| du provider | w
-------------- ---- suck ----> /usr/lib/suck/* --- rnews -- s
| r
| u
-- VSP/fr/test etc <-------- newsrun -- VSP/in.coming <-- n
| ^ | |
V | | |
-------------- | | |
| Serveur NNTP |--------- article à poster --------- --- si posté
| local (INN) | localement
| Sert à poster|
| et lire |<-----> lecteur de news (knews, gnus, tin, readnews, etc)
--------------
ATTENTION : pour INN 2.3, les droits
par défaut de rnews et de
inews ne permettent plus de s'en servir
aussi simplement : pour obtenir un fonctionnement identique à
INN 1.7, utilisez les options de
compilation adéquates (cf. le fichier
INSTALL de la distribution) ou modifiez
ces droits manuellement.
Ceux qui ne se sont ni découragés, ni endormis, auront
probablement noté un problème dans ce raisonnement : on a dit
qu'à chaque fois que l'on postait un article, il était référencé dans
/var/spool/news/outgoing/fai (ou
~news/spool/outgoing/fai) et que c'était ce qui
permettait à rpost de savoir quels étaient les
articles à propager vers le serveur du FAI. Mais on a dit aussi que le
comportement était le même face à n'importe quel article qu'il
recevait. Par conséquent, lorsqu'on récupère un article venant de
notre fournisseur, la logique voudrait qu'il soit aussi référencé dans
ce fichier puisque, pour INN, un article
n'a pas d'odeur. Mais, alors, lors du prochain
rpost tous les articles que nous avons récupérés
seront renvoyés à l'expéditeur !? La réponse est
oui, sauf si l'on explique à
INN qu'il ne faut pas renvoyer un article à
son expéditeur, de sorte qu'il se contente d'expédier ceux que nous
avons nous mêmes écrits...
Test du serveur de votre FAI
On peut accéder à un serveur INN par
le biais d'une connexion réseau. Il accepte des commandes grâce
auxquelles n'importe quel agent distant (programme, humain, pingouin
...) habilité peut requérir des services, par exemple obtenir une
copie d'un article disponible ou bien en publier un nouveau.
Vos exemplaires de suck et
d'INN fonctionnent ainsi. Nous allons
simuler cela en nous connectant au serveur de news de notre
FAI.
Connectez-vous tout d'abord à votre FAI.
Puis, tapez la commande suivante :
% telnet news.fai.fr nntp
Normalement vous devez obtenir un message du genre :
Trying xxx.yyy.zzz.ttt...
Connected to news.aaa.net.
Escape character is '^]'.
200 abcdef InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready
Quelques explications :
En précisant nntp lors du
telnet, vous indiquez le protocole que vous
utilisez. NNTP signifie New News
Transfer Protocol. C'est le
protocole utilisé actuellement sur Usenet.
xxx.yyy.zzz.ttt est l'adresse IP du
serveur de news que vous tentez de contacter.
Le fait que vous soyez connecté à
news.aaa.net indique que votre FAI délègue la
gestion des news à ce serveur. La machine porte en fait le nom
abcdef. Comme vous pourrez le constater plus loin,
cette dernière information est importante, nous vous invitons à la
noter car c'est l'identifiant unique de ce
serveur de news sur l'Internet.
Au passage, vous pouvez noter le serveur utilisé par
votre FAI, ici il s'agit d'INN et ce sera
très souvent le cas. C'est toujours rassurant (et gratifiant) de voir
que, finalement, votre machine n'a rien à envier à celle de votre
fournisseur, si ce n'est quelques dizaines de
giga-octets.
La dernière ligne indique que vous êtes connecté au serveur et
que celui-ci attend vos commandes.
Tapez alors la commande :
mode reader
Puis :
group fr.comp.os.unix
(ou le nom de tout autre forum distribué par ce serveur).
Vous devez obtenir une réponse du style :
211 174 2039 2269 fr.comp.os.unix
Sans entrer dans le détail, si vous obtenez cette ligne, cela
signifie que votre serveur de news distribue au moins le forum
fr.comp.os.unix... (2269 signifie qu'il y a 2269
articles dans ce forum, et 2039 est le numéro du premier article
disponible : les articles les plus anciens ont, sur ce serveur,
été effacés...).
Tapez alors :
quit
pour fermer la connexion avec le serveur.
Si vous avez réussi cette étape, c'est que vous pouvez vous
connecter à votre serveur distant. Il reste maintenant à récupérer les
nouveaux articles, à partir de ce serveur distant, sur votre machine.
Lorsque vous aurez configuré INN sur
votre machine, vous pourrez faire exactement la même chose. Sur ma
machine, la commande :
% telnet localhost nntp
me répond :
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
200 jacoboni InterNetNews server INN 2.2 21-Jan-1999 ready
et toutes les opérations décrites plus haut s'appliquent évidemment de
la même façon.
Installation et configuration de
<productname>Suck</productname>
Suck vous permet de récupérer par vous même
les articles sur un serveur NNTP distant.
Toutes les manipulations qui suivent doivent se faire sous le compte
root.
Installation de <productname>Suck</productname>
Suck peut être récupéré sous la forme d'un
paquetage précompilé pour les différentes distributions Linux à base
de paquetages (rpm ou deb). Vous
pouvez aussi préférer récupérer les sources sous la forme d'un fichier
tgz et les compiler pour votre système. La première
solution est, évidemment la plus simple mais la distribution source
vient avec tout ce qu'il faut pour permettre une configuration adaptée
à vos besoins. À l'heure où ces lignes sont écrites, la version la
plus récente est la 4.2.3.
Un argument en faveur de cette mise à jour est que les nouvelles
versions permettent désormais de ne récupérer que les en-têtes des
messages afin de marquer ceux qui nous intéressent pour en récupérer le
corps (option -g). Cette option, ainsi qu'un script
Perl/Tk (header.pl) et une application Java
(Suck.java) permettent de sélectionner les
articles à télécharger via une interface graphique X.
Je n'ai personnellement pas testé ces interfaces graphiques et
toute expérience est donc la bienvenue bien que, personnellement, je
suis plutôt sceptique sur ces récupérations en deux temps (en-têtes,
puis corps des articles sélectionnés) : le mécanisme des
killfiles de Suck me
semble, à ce point de vue, plus efficace... D'autre part, l'un des
grands avantages de Suck, pour moi, est de
pouvoir l'appeler à travers des scripts : l'utilisation d'une
interface graphique annule cette fonctionnalité (mais il est vrai que
l'on n'est pas obligé de l'utiliser).
L'installation de Suck via les paquetages
précompilés de Linux nécessite d'avoir auparavant installé le
paquetage INN. En effet, par défaut,
Suck est prévu pour fonctionner avec
lui. Vous avez donc le choix : forcer l'installation de
Suck sans
INN en utilisant l'option adéquate de votre
gestionnaire de paquetages ou installer INN
avant (cette dernière solution est préférable puisqu'il faudra, de
toutes façons, l'installer...). Si vous utilisez une distribution
Debian, le mieux est d'installer le paquetage via la commande
apt-get install suck qui résoudra toutes les
dépendances et installera les paquetages correctement. Comme avec
l'option --nodeps de rpm, vous
pouvez aussi utiliser l'option --force-depends de
dpkg pour ignorer les dépendances. Reportez-vous à
la section sur l'installation et la configuration de
INN.
Si vous utilisez un paquetage rpm ou
deb, pas de problème : vous
l'installez avec les outils de maintenance des paquetages de
votre système (consultez la documentation de votre
distribution).
Si vous partez des sources, faites en sorte de placer les
binaires (lmove, rpost, suck, testhost) dans
/usr/local/bin, les pages de manuel iront dans
/usr/local/man/man1 et les scripts et fichiers de
configuration (get.news.innxmit,
get.news.rnews,put.news,
sucknewsrc, suckkillfile)
dans /usr/local/etc/suck. Ce sont, en tous cas,
les emplacements préconisés mais vous pouvez en choisir d'autres en
fonction des us et coutumes en vigueur sur votre système...
Dans la suite de ce document, nous utiliserons ces emplacements :
effectuez les adaptations nécessaires en fonction de votre système.
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 (ou on le crée, s'il n'existe pas) qui
abritera les noms des forums qui nous intéressent. L'exemplaire livré
(/usr/local/share/examples/suck/sucknewsrc.sample
pour FreeBSD) contient plusieurs lignes que l'on supprime. À des fins
de test, on ajoute une seule ligne :
fr.comp.os.unix -10
pour indiquer à suck qu'il devra, sitôt lancé,
récupérer les 10 derniers articles du forum
fr.comp.os.unix. N'oubliez pas le
10 car, sinon, vous risquez de récupérer tous les
articles de ce forum disponibles sur le serveur !
Vérifiez que le sous-répertoire
/usr/local/etc/suck/Msgs existe, sinon créez-le
(attention à bien respecter les minuscules et les majuscules).
Placez-vous dans /usr/local/etc/suck et
tapez la commande suivante (après établissement de la connexion
PPP...) :
suck news.fai.fr -m -H -K
L'option -m permet d'invoquer
suck en mode
multi-fichiers : il créera autant de
fichiers qu'il récupère d'articles. Si vous omettez cette option, les
articles seront simplement affichés à l'écran au fur et à mesure de
leur récupération.
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.unix 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...
Plusieurs choses ont dû se passer :
les fichiers /tmp/suck.newrc et
/tmp/suck.sorted ont été créés (éventuellement à
un autre emplacement selon le système que vous
utilisez...) ;
le sous-répertoire
/usr/local/etc/suck/Msgs contient désormais des
fichiers portant des noms étranges (par défaut, c'est là que le mode
multi-fichiers sauve les fichiers
articles). Chacun de ces fichiers correspond à l'un des 10 articles
que vous avez récupérés 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 :
/tmp/suck.newrc est une mise à
jour de sucknewsrc : éditez-le et vous
verrez que la ligne concernant fr.comp.os.unix a
remplacé -10 par une autre valeur, le numéro du
dernier article lu.
/tmp/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 relanciez suck maintenant, il
récupérerait exactement les mêmes articles...
Pour éviter cela, il faut détruire l'ancien
sucknewsrc, et renommer
/tmp/suck.newrc en
sucknewsrc... Fastidieux, non ?
Heureusement, l'option -c (comme
clean), passée à suck effectue
cela automatiquement :
elle renomme sucknewsrc en
sucknewsrc.old (ce qui permet de revenir en
arrière, si nécessaire) ;
elle renomme /tmp/suck.newsrc en
/usr/local/etc/suck/sucknewsrc ;
elle détruit /tmp/suck.sorted (et
d'autres fichiers utilisés temporairement par
suck).
Nous vous conseillons 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 à notre premier problème...
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.
Comme nous l'avons vu dans la section 2, sur toute machine utilisant
un logiciel serveur de news classique (INN,
par exemple) 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 forum. Le premier article arrivé sur un
serveur donné pour le forum fr.comp.os.unix, par
exemple, sera stocké dans un fichier appelé
/var/spool/news/fr/comp/os/unix/1 (ceci pour un
INN 1.7... Pour un INN
2.2, il s'agira plutôt de
/var/spool/news/articles/fr/comp/os/unix/1).
Attention : par premier article
arrivé
, il ne faut pas entendre 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
d'isdnet.net, utilisé par de nombreux fournisseurs
d'accès, 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 à suck à partir de la version 3.8.0.
Cette option a un autre effet, il se trouve qu'elle surcharge moins le
serveur distant, je vous conseille donc de l'utiliser
systématiquement. Passé d'HOL à
Easynet, qui autorise la récupération sur
le Message-id, j'ai remarqué que celle-ci
provoquait de fréquents time-out
(tous les 10 articles,
environ). L'ajout de l'option -n a corrigé ce
problème.
À 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...
Pour vous aider dans le dépistage des problèmes, vous pouvez utiliser
l'option -D qui créera un fichier
debug.suck contenant les traces d'exécution du
programme.
Tests supplémentaires : préparation à l'utilisation de
<command>rnews</command>
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 de INN
(cf. plus loin).
La commande permettant de réaliser cela est la suivante (elle
doit être invoquée à partir du répertoire
/usr/lib/suck) :
suck news.fai.fr -c -n -H -K -br nouveau
Les options -c -n -H -K ont déjà été décrites plus
haut...
L'option -br nouveau indique à
suck de créer un fichier dit batch
,
qui s'appellera 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 rnews et man
innxmit et ne seront donc pas traitées ici).
Attention : Pour une raison que je ne
m'explique pas encore, suck dans sa version 3.9.0
refuse de mettre à jour le fichier de batch si celui-ci existe
déjà... La seule solution que j'ai trouvé pour l'instant est de
renommer celui-ci en nouveau.old avant d'appeler
suck. À noter que ce problème n'apparaissait pas
avec la version précédente mais qu'il est, de toutes façons,
préférable de conserver une version du batch précédent, au cas
où...
On va d'abord faire en sorte de récupérer des articles :
éditez le fichier /usr/local/etc/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 ôtant 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 :
le répertoire /usr/local/etc/suck/Msgs
est vide ;
un fichier nouveau a été créé
dans /usr/local/etc/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 !
À noter que suck dispose de l'option
-a, lui permettant de mettre en batch tous les
articles récupérés même si, pour une raison ou une autre (une
déconnexion intempestive, par exemple), il n'a pu terminer la
récupération totale. En ce cas, les articles déjà récupérés pourront
donc être traités par rnews (sans cette option,
suck ne construit le batch
qu'après s'être terminé normalement).
Nous allons maintenant passer à l'installation de
INN. Certains aspects de suck ont
été omis : c'est volontaire car ils n'ont aucun sens tant que
notre serveur de news n'est pas installé...
Installation et configuration de
<productname>INN</productname>
Installation à partir d'un paquetage précompilé
Certains diront qu'il faut mieux partir des sources
de INN et les compiler : cela permet de
mieux maîtriser toutes les options de fonctionnement. C'est vrai, mais
les paquetages précompilés pour Linux s'avèrent si faciles à installer
que beaucoup choisissent la solution des paquetages...
Dans cette section, nous ne parlerons pas de la compilation
de INN mais de son installation au moyen des
différents systèmes de paquetages précompilés existants sur Linux et
FreeBSD.
La dernière version de INN existe
dans toutes les bonnes distributions Linux (Debian, Red Hat,
Slackware, etc.), sinon la version précédente doit se trouver sur le
CD-ROM. Il en va de même pour FreeBSD. Reportez-vous aux manuel du
gestionnaire de paquetage que vous utilisez (rpm
pour RedHat Linux, apt-get pour Debian Linux, ou
pkg_add pour FreeBSD).
Installation à partir des sources
La procédure est on ne peut plus classique : décompactez le
fichier archive dans un répertoire temporaire, placez-vous dans
celui-ci et exécutez les commandes magiques :
./configure et make. Si tout ce
passe bien, il vous reste à faire make install pour
que les différentes parties du logiciel aillent se placer à leurs
emplacements définitifs.
Fichiers et répertoires de INN 1.7
INN 1.7 utilise plusieurs répertoires
(je donne ici ceux que ma distribution Linux de l'époque utilisaient :
ce sera différent avec FreeBSD, voire avec une autre distribution
Linux) :
/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
Fichiers et répertoires de INN 2.x
Hormis les fichiers de trace qui, comme d'habitude, se trouvent
sous /var/log/news, tous les fichiers de
INN 2.x se trouvent sous l'arborescence de
l'utilisateur news : ~news
(/usr/local/news sur FreeBSD).
Cette arborescence se décompose en :
spool : arborescence du
spool de news (équivalent de
/var/spool/news de INN
1.7).
bin : contient tous les
exécutables (c'est l'équivalent du répertoire
/usr/lib/news/bin de INN
1.7). C'est là, notamment que se trouvent les programmes
innd, ctlinnd,
expire, rnews et le script de
maintenance quotidienne que nous étudierons plus
tard :news.daily.
db : contient les bases de données
utilisées par INN : le fichier
active, les fichiers de l'historique
(history.*) et le fichier de description des
forums (newsgroups).
etc : contient tous les fichiers
de configuration, notamment les fichiers
inn.conf, newsfeeds et
moderators.
lib : contient les bibliothèques
propres à INN ainsi que des scripts comme
docheckgroups,
innshellvars.
run : contient les fichiers
pid correspondant à l'exécution de
INN.
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).
Les fichiers de configuration
Tous ces fichiers, comme la plupart des fichiers de
configuration de INN, débutent par une
explication (parfois sibylline, il est vrai...) de leur
syntaxe. Pour leurs modifications, mettez-vous sous le
compte news, il est impératif que ces fichiers
appartiennent à l'utilisateur et au groupe news
pour que INN fonctionne
correctement... D'autre part, avant de les modifier,
sauvegardez leur contenu original (en faisant, par exemple,
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 (ne mettez
pas de " autour...). Les différents paramètres
valides et intéressants pour nous sont :
organization : comme valeur, mettez
ce que vous voulez voir apparaître dans le champ ORGANIZATION des
articles que vous posterez ;
fromhost : le nom de votre machine,
qui apparaîtra après votre username@ dans le champ
FROM des articles que vous posterez. En fait, normalement, c'est
votre lecteur de news qui doit s'en charger, ce qui veut dire que si
cette valeur est utilisée, c'est que votre lecteur est mal
configuré... Pour cette raison, on met une valeur comme
« un.lecteur.mal.configure » ce qui permettra de détecter
rapidement ce problème ;
pathhost : le contenu de ce
champ est important car c'est lui qui apparaîtra au début des champs
Path: des articles que vous posterez. C'est
l'identifiant unique de votre serveur sur tout Usenet. Il est inutile
si vous utilisez simplement suck ou
newsx pour vous approvisionner sur le serveur de
votre FAI mais il est nécessaire si vous bénéficiez d'un système
d'alimentation directe comme UUCP. Mettez ici ce que vous aura
indiqué le newsmater lorsque vous aurez demandé à être feedé par
cette méthode.
ovmethod : ce champ apparaît
dans INN 2.3 qui, par rapport
aux versions précédente, utilise une gestion différente
des overview
. La méthode utilisée par
défaut est tradindexed : il en
existe d'autres... Voir man inn.conf.
Les autres paramètres, s'ils ne sont pas mentionnés, prennent
les valeurs des variables d'environnement : le paramètre
server, par exemple, 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 ou équivalent sur votre
système).
Certains paramètres permettent de configurer les ordres de
grandeur de INN : nous ne les
modifierons pas ici car ils conviennent à l'utilisation qui sera la
nôtre. Certains autres permettent d'activer (valeur
true ou de désactiver (valeur
false) certains comportements. Pour un petit
serveur, par exemple, il peut être préférable de désactiver
doinnwatch.
Si vous utilisez des répertoires différents de ceux considérés
par défaut, c'est également dans ce fichier qu'il faudra le
préciser.
La page de manuel (man inn.conf) ainsi que le
fichier INSTALL livré avec les sources indiquent
la signification de tous ces paramètres : je vous invite
fortement à consulter ces deux documents.
Avec les lignes suivantes dans un
inn.conf :
organization: Truc Bidule
pathhost: machin
Un article posté sur ce serveur local aura les entêtes suivants :
From: Eric Jacoboni <jaco@youpi.fr>
Organization: Truc Bidule
Subject: blah blah blah...
Path: machin!not-for-mail
...
De même, avec un système d'alimentation directe tous les
articles reçus auront leur champ Path: commençant
par machin!... (cela est configuré au niveau du
fournisseur). Ainsi que nous le disions plus haut, le
machin en première position correspond au champ
pathhost configuré dans le fichier
inn.conf de notre serveur, et ce champ
Path: est, finalement, le résultat de la
concaténation de tous les pathhost des serveurs
NNTP par lesquels l'article est passé. Si l'on veut avoir plusieurs
feeds, cela permet au fournisseur de ne pas reproposer les articles
que l'on a déjà émis.
On notera la contenu du champ From :
l'adresse jaco@youpi.fr est formée à partir de la
configuration de mon logiciel de news, pas à partir du contenu de
l'entrée fromhost de
inn.conf. En fait, il est préférable de définir
cette adresse au niveau du fichier de configuration du lecteur de
news. Avec gnus, par exemple, il suffit
d'ajouter les lignes suivantes à son fichier
~/.gnus :
(setq user-mail-address "jaco@youpi.fr")
(setq user-full-name "Eric Jacoboni")
(setq mail-default-reply-to "jaco@youpi.fr")
(setq mail-host-address "youpi.fr")
Soyez quand même conscient que mettre une adresse farfelue ne
fera pas de vous un anonyme (d'ailleurs, pourquoi voudriez-vous
l'être, hein ?) et qu'elle risque de vous priver de recevoir des
réponses personnelles.
hosts.nntp (Uniquement
pour INN 1.7 : voir incoming.conf
pour INN 2.0). Il ne doit comporter qu'une ligne,
localhost:. Attention à ne pas mettre d'espace
après le ':', ni de ligne après
celle-ci. Lorsque j'utilisais la méthode d'alimentation
directe proposée par Oléane (aka méthode Fyr
), j'avais
dû rajouter une ligne pour que le serveur distant qui m'alimentait en
articles soit reconnu par mon serveur local. Cette ligne était
news.dial.oleane.com: car c'est lui qui m'envoyait
les batchs. Dans ce cas précis, il avait également fallu ajouter une
entrée correspondant à news.dial.oleane.com dans
mon fichier /etc/hosts car INN a besoin de
connaître l'adresse IP de toutes les entrées de
hosts.nntp lors de son
démarrage.
incoming.conf
(Uniquement pour INN 2.x, voir
hosts.nntp pour INN 1.7). Ce fichier, comme
hosts.nntp pour les versions antérieures, permet
d'indiquer les machines qui nous approvisionnent en articles. Le
fichier livré avec les sources, ainsi que la page de manuel
man incoming.conf décrivent toutes ses
possibilités. Si l'on utilise suck ou
newsx, seule la machine locale est habilitée à
poster sur notre serveur, il n'y aura donc une entrée que pour
elle :
peer ME {
hostname: "localhost, 127.0.0.1"
}
Si l'on est approvisionné par l'équivalent de la méthode Fyr
(proposée par Teaser), il faudra rajouter
l'entrée :
peer teaser {
hostname: "feed.teaser.net"
}
et mettre l'adresse de cette machine dans votre fichier
/etc/hosts.
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
*::::!*
# Allow access from localhost
localhost:Read Post:::*
127.0.0.1:Read Post:::*
stdin:Read Post:::*
192.168.2.*:Read Post:::*
Consultez la page de manuel concernant ce fichier pour
comprendre la signification de ces lignes qui consistent à énumérer
les machines autorisées à utiliser notre serveur pour lire les
articles (Read) et en poster
(Post).
Attention : avec INN 2.3, ce
fichier a été remplacé par
readers.conf (voir
ci-dessous).
readers.conf (uniquement à partir
de INN 2.3) : il joue le
même rôle que le fichier
nnrp.access des versions
précédentes mais sa syntaxe a changé. Voici le contenu
d'un readers.conf équivalent au
nnrp.access donné plus
haut :
auth "localhost" {
hosts: "localhost, 127.0.0.1, stdin, 192.168.2.0/24"
default: "<localhost>"
}
access "localhost" {
users: "<localhost>"
newsgroups: "*"
}
storage.conf (uniquement à partir
de INN 2.3). Cette nouvelle
version a modifié la gestion du spool d'articles et
permet d'utiliser plusieurs méthodes pour les
stocker. Ce fichier permet de préciser quelles sont les
méthodes utilisées (on peut utiliser différentes
méthodes pour différents groupes) et il
doit être configuré avec
INN 2.3 (alors que l'on
pouvait se passer de le faire avec INN
2.2).
Voici un exemple indiquant que l'on utilise un spool
traditionnel pour tous les groupes :
method tradspool {
newsgroups: *
class: 0
}
Un effet de bord désagréable de cette évolution est qu'il est
désormais très peu pratique de récupérer un spool
existant lorsque l'on passe d'un INN antérieur à 2.3 à
un INN 2.3 et supérieur...
newsfeeds : Ce fichier décrit les
sites que vous approvisionnez en news.
Il faut donc y décrire celui de notre FAI afin de pouvoir lui
expédier les articles que nous postons sur notre propre serveur. Le
mien contenait les lignes suivantes lorsque mon fournisseur était
HOL :
ME:*,!junk,!control::
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\
::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 et control.
Les lignes crosspost et
overview servent à gérer les articles cross-postés
et l'historique. Elles ne sont plus nécessaires avec INN 2.3
car celui-ci dispose désormais d'un mécanisme interne
permettant de les gérer.
La ligne news.hol.fr nécessite plus
d'explications : elle indique d'abord que les descriptions des
articles que nous postons (via rpost, lorsque l'on
utilise suck) seront placés dans le fichier
/var/spool/news/out.going/news.hol.fr, c'est là
que rpost ira chercher leurs noms afin de les
expédier au serveur du FAI pour qu'ils circulent.
D'autre part, normalement INN est
conçu pour pouvoir fonctionner grâce à plusieurs sites « feeds », lui
fournissant des articles. Il envoie donc à tous les serveurs listés
dans le fichier newsfeeds une copie de chaque article
reçu. Mais, ainsi que nous l'avons évoqué dans la section 2, il est
inutile de renvoyer à un serveur donné les articles qu'il nous a
lui-même expédiés (!) ainsi que ceux que avons récupérés grâce à un
serveur avec lequel il est déjà lui-même en relation.
Chaque article contient donc un champ Path:
dressant peu à peu une liste des noms de serveurs sur lesquels il est
passé
, chaque nom étant séparé du suivant par un point
d'exclamation.
Dans le fichier newsfeeds, on précise à
INN ce qu'il doit faire des articles
reçus. On y trouve une ligne pour chaque élément (pas obligatoirement
un autre serveur de news) auquel INN doit
passer des informations sur les articles reçus. Chaque ligne est
composée de champs séparés par :.
Ce fichier offre, par exemple, le moyen d'indiquer qu'on ne doit
pas réexpédier à un serveur donné la copie d'un article déjà passé par
tel ou tel serveur. Le tronçon de ligne
news.hol.fr/news1.isdnet.net,news2.isdnet.net,news3.isdnet.net,news4.isdnet.net
se lit ainsi : il existe un serveur par commodité appelé
ici news.hol.fr. Tu dois lui expédier les copies
des articles, SAUF de ceux dont le champ Path:
contient news1.isdnet.net ou
news2.isdnet.net ou
news3.isdnet.net ou
news4.isdnet.net
.
Le tronçon de ligne ::Tf,Wnm: 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, de la même ligne que la précédente pour
INN car le caractère 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 et
control
. En effet, ce qui a été défini pour
l'entrée ME s'applique ici aussi
(:Tf,Wnm:) détermine le mode de transmission des
articles. Nous verrons que si l'on utilise UUCP, cette partie devra
être modifiée.
Par défaut, le fichier utilisé pour garder la trace des articles
sera donc
/var/spool/news/out.going/news.hol.fr. Si vous
désirez qu'il porte un autre nom, il suffit de le mentionner après le
dernier :. De la même façon, les articles dont
l'envoi à ce feed ont échoué seront mentionnés dans le fichier
/var/spool/news/out.going/news.hol.fr.fail.
On a ainsi créé un feed
d'articles, c'est-à-dire
un canal logique (on ne se soucie pas, pour le moment, de la façon
dont les articles seront transportés) par lequel votre serveur peut en
alimenter d'autres.
À ce stade vous devez comprendre l'intérêt de créer des feeds
lorsque votre machine est connectée à plusieurs autres (et participe
donc au réseau, en interconnectant d'autres participants). Mais
pourquoi le faire lorsque l'on est une feuille
de
l'arbre, une machine uniquement connectée à une seule autre, via une
connexion PPP, comme dans le cas qui nous intéresse ?
Eh bien créer ainsi un feed
vers votre
fournisseur vous permettra de voir circuler les articles que vous
posterez, tout simplement !
Mais tout article venant de news.hol.fr
devrait ne pas être renvoyé 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 : vous verriez
alors apparaître des messages vous informant que vous envoyez des
messages dupliqués sur le serveur distant.
Malheureusement (je vous ai prévenu, j'ai eu tous les problèmes
possibles...), HOL faisait appel à un fournisseur de news externe (en
l'occurrence isdnet) ce qui fait que
news.hol.fr n'apparaissait jamais dans le champ
Path: des articles et que ceux-ci étaient donc
renvoyés lors du prochain appel de rpost (avec les
messages qui en résultent...). Pour expliquer que les articles
provenant des serveurs de news d'isdnet ne doivent
pas être renvoyés, on l'indique entre le / et le
:. Si ces exclusions n'étaient pas précisées, tous
les articles reçus seraient décrits dans le fichier
/var/spool/news/out.going/news.hol.fr car ils ne
contiennent pas news.hol.fr dans leur champ
Path:...
Pour savoir quel est le serveur que votre FAI utilise (afin de
l'exclure comme cela est décrit plus haut), deux méthodes sont
possibles :
Faire un telnet news.fai.fr nntp
qui vous renseignera sur le nom de la machine qui vous envoie les
articles (le abcdef cité dans l'exemple de la
section 2). Cette méthode nécessite, bien sûr, d'être connecté. Vous
pouvez économiser une unité téléphonique en utilisant la deuxième
possibilité...
À l'aide de votre lecteur de news, visualisez la
totalité des en-têtes d'un article reçu. Le champ qui nous intéresse
est Path: qui indique la route suivie par cet
article pour arriver jusqu'à nous. Le nom qui suit celui de votre
machine (ou qui suit le nom spécifié par l'entrée
pathhost du fichier inn.conf)
est le nom de la machine qui vous l'a envoyé. Prenons un
exemple : depuis la première version de ce document, j'ai quitté
HOL pour Easynet, puis pour Oléane, puis pour Free (avec les FAIs,
comme avec le reste, il faut savoir faire jouer la concurrence). Voici
le contenu du champ Path: de chaque article que je
recevais d'Oléane :
Path: jacoboni!dial.oleane.com!...!...
dial.oleane.com doit donc être exclu, ce qui
fait que mon fichier newsfeeds doit désormais
contenir, à la place de la ligne news.hol.fr, la
ligne suivante :
oleane/dial.oleane.com\
::Tf,Wnm:
Le fichier contenant les références des articles que j'envoie au
site distant était alors
/var/spool/news/out.going/oleane.
Notez bien que cela suppose que mon entrée ME soit la suivante :
ME\
:*,!junk,!control::
Ne vous fiez pas à l'examen d'un seul article car votre
fournisseur d'accès peut disposer de plusieurs serveurs
de news. Ajoutez chaque serveur en le séparant du
précédent par une virgule (voir l'exemple plus haut,
pour HOL).
Attention : le fichier
newsfeeds est chargé en mémoire au lancement de
INN, donc toute modification de celui-ci
implique son rechargement (cf. la section sur l'utilisation de
ctlinnd et l'utilisation du paramètre
reload).
moderators. Ce fichier est
utilisé lorsqu'on désire poster un article dans un forum modéré
(fr.comp.os.linux.annonces ou
fr.usenet.logiciels, par exemple). La différence
entre un forum non modéré et un forum modéré est que tout le monde
peut poster n'importe quoi (et, malheureusement, certains en
abusent...) dans le premier tandis que la parution d'un article dans
le second est soumise à l'acceptation d'une ou plusieurs
personnes : les modérateurs de ce forum.
Ceci signifie que, pour poster un article dans un forum modéré, on doit
d'abord l'envoyer au modérateur sous la forme d'un message email. Le modérateur
recevra alors votre proposition d'article et décidera de le publier dans le
forum, ou le rejettera s'il juge qu'il ne correspond pas à la charte.
Toute cette démarche est inutile car, heureusement,
INN s'occupe de tout. Il permet de publier
dans les forums modérés comme dans les autres et se charge de
transformer automatiquement l'article en message qu'il expédie aux
modérateurs dont il trouve l'adresse électronique dans le fichier
moderators. C'est également pour cette raison
qu'il faut disposer d'un moyen d'envoyer du courrier...
La page de manuel moderators(5) détaille
la syntaxe du contenu de ce fichier. En résumé : un
enregistrement par ligne, deux champs par enregistrement, séparés par
le signe :. Le premier champ contient un
motif
de sélection de nom de forum
(fr.*, par exemple, correspond à tous les forums de
la hiérarchie fr). Le second champ contient
l'adresse du modérateur de ce forum. Cas spécial : la paire de
caractères %s, utilisée dans le second champ, est
remplacée par le nom du forum visé.
La dernière ligne de ce fichier devrait toujours être une entrée
par défaut
contenant
*:%s@moderators.isc.org (ou
*:%s@moderators.news.oleane.net, pour les abonnés
d'Oléane) qui indique que tous les articles postés dans un forum
modéré au nom non précédemment sélectionné par
les entrées précédentes devront être envoyé à l'adresse
nom_du_forum@moderators.isc.org. La machine
destinatrice dispose toujours de la liste à jour des noms de forums et
des adresses de leurs modérateurs.
Dans l'absolu, cette règle
(*:%s@moderators.isc.org) suffit donc : aucune
autre n'est strictement nécessaire. Mais il est de bon ton de ménager
les serveurs centraux... et cela accélère le service.
Par exemple, pour pouvoir poster au plus vite dans un forum
modéré de la hiérarchie fr (par exemple
fr.usenet.logiciels), il suffit d'ajouter au début
du fichier, juste après la dernière ligne de commentaires, l'entrée
suivante :
fr.*:%s@moderators.freenix.org
Attention : Il faut bien entendu ajouter les
entrées avant la ligne générique
(*:%s@moderators.isc.org) et en étudiant aussi les
autres entrées pour ne pas qu'elles correspondent au motif de la
nouvelle ligne saisie, car INN prend en
charge la première ligne satisfaisante rencontrée. La solution la plus
sûre consiste à faire vos ajouts en tête de ce
fichier.
expire.ctl. Ce fichier permet de
configurer le mécanisme d'expiration de
INN. Le contenu de ce fichier
étant richement commenté (la commande man
expire.ctl existe aussi...), nous ne le
détaillerons pas ici : le principe général consiste à
préciser le nombre de jours au-delà desquels les articles d'un
groupe, ou d'un ensemble de groupes, seront supprimés de
votre serveur.
Les fichiers de données :
<filename>active</filename>, <filename>history</filename>,
<filename>newsgroups</filename>
Comme les précédents, ces fichiers doivent appartenir à l'utilisateur
news. Avec INN 2.2, ils
se trouvent dans le répertoire
~news/db.
active. Ce fichier
contient les noms des forums reçus par
INN. Cela n'a rien à voir avec le fait de
recevoir les articles : on peut très bien
récupérer les articles d'un forum fr.bidon par
suck, et ne pas les distribuer sur notre machine si
le forum fr.bidon n'est pas décrit dans le fichier
active... Les fournisseurs d'accès mettent, en
général, leur fichier active à disposition, vous
pouvez en récupérer un par FTP à ftp://ftp.oleane.net/pub/Oleane/active.
Voici les premières lignes de mon fichier
active, qui en contient 238 (en fait, il a
beaucoup changé depuis la première version de ce
document...) :
control 0000001372 0000001085 y
junk 0000000004 0000000005 y
test 0000000000 0000000001 y
to 0000000000 0000000001 y
fr.comp.os.linux.annonces 0000000910 0000000887 m
fr.comp.mail 0000015100 0000014624 y
fr.usenet.logiciels 0000005972 0000005877 m
fr.comp.text.tex 0000009863 0000009378 y
fr.comp.applications.x11 0000005586 0000005308 y
fr.comp.applications.emacs 0000003085 0000002965 y
On a une ligne par forum, 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 les voir
apparaître...).
Attention, INN 2.3 ajoute les entrées
control.cancel,
control.checkgroups,
control.newgroup et
control.rmgroup à ces entrées
obligatoires...
Ne modifiez pas le fichier active
manuellement, mais utilisez le programme ctlinnd
(voir la section sur l'utilisation de
ctlinnd).
Pour la syntaxe, as usual, cf. les pages du
manuel en ligne (man active)... Au
départ, initialisez ce fichier afin que les champs
numériques soient tous de la forme
0000000000 0000000001, ils seront
mis à jour automatiquement à chaque appel de
rnews (le
y
signifie que l'on
autorise le postage d'article dans le forum,
m
signifie qu'il est
modéré). Comme d'habitude, attention à ne pas placer de
retour chariot après la dernière ligne...
Nous le répétons une nouvelle fois :pour éviter de
mauvaises manipulations, il est préférable de ne pas modifier
manuellement le fichier active mais d'utiliser le
programme ctlinnd (voir la section sur
l'utilisation de ctlinnd).
history. Si vous avez utilisé un
système de paquetages pour installer
INN, ce dernier aura
automatiquement créé ce fichier historique, qui sera
ensuite géré par INN, vous
n'avez pas donc à vous en occuper pour le moment... Sachez
quand même que suck consulte ce fichier
(sauf si vous utilisez l'option -H)
afin d'éviter de récupérer un article déjà présent sur
votre serveur.
Si vous avez installé INN à partir
des sources, il vous faudra créer l'historique initial en
suivant ce qui est indiqué dans le fichier
INSTALL : makehistory
-i créera cet historique, il vous restera à
renommer les fichiers history.n*
créés par cette commande en
history*. Enfin, n'oubliez pas de
positionner les droits d'accès avec la commande
chmod 0664 *.
newsgroups. Ce fichier permet
d'associer une description lisible à chaque
forum. Normalement il devrait donc contenir autant de
lignes que le fichier active, mais ce
n'est pas une obligation : tout dépend du courage de
l'administrateur... Comme pour le fichier
active, vous pouvez récupérer un
fichier newsgroups complet par FTP à
ftp://ftp.oleane.net/pub/Oleane/newsgroups. Le
mien est plutôt spartiate :
control Usenet control messages - DO NOT REMOVE
junk Articles for missing newsgroups - DO NOT REMOVE
test A place for test posts - DO NOT REMOVE
to Special Group for INN use - DO NOT REMOVE
fr.comp.text.tex Discussions concernant TeX et LaTeX.
fr.comp.applications.emacs Editeur de textes Emacs et ses extensions.
fr.comp.applications.libres Les solutions libres en informatique. (Moderated)
fr.comp.applications.x11 Systeme de multifenetrage X11.
fr.comp.lang.perl Langage de programmation Perl.
fr.comp.mail Logiciels de messagerie electronique.
fr.comp.os.linux.annonces Annonces concernant Linux. (Moderated)
fr.comp.os.linux.moderated Discussions sur le systeme Linux (moderated).
fr.network.modems Discussions concernant les modems.
fr.usenet.forums.evolution Discussions sur la creation de nouveaux forums fr.
fr.usenet.logiciels Discussions sur les logiciels de News
En fait, cela permet à votre lecteur de news d'afficher la
description correspondante en face du nom du forum...
Derniers réglages
Si vous avez configuré les fichiers que nous venons de décrire,
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
(ou ~news/bin/inncheck -a avec INN
2.2) et ne vous inquiétez pas de l'avertissement
/usr/local/news/etc/newsfeeds:0: warning you accept
all incoming article distributions
qui est parfois
produit.
Si vous utilisiez Leafnode
auparavant, vérifiez bien que vous avez supprimé la ligne
nntp stream tcp nowait news /usr/sbin/tcpd /usr/local/sbin/leafnode
de votre fichier
/etc/inetd.conf.
Il n'y a rien d'autre à faire : l'installation de
INN par un des systèmes de
paquetages déjà cités aura modifié pour vous les scripts
de démarrage.
Si vous êtes partis des sources, utilisez le
mécanisme de lancement des services au démarrage propre à
votre système : il s'agit principalement de lancer le
script
/usr/local/news/bin/rc.news :
Sur un système Linux, les scripts de démarrage se trouveront
probablement sous le répertoire
/etc/rc.d/. Chaque distribution n'en
faisant qu'à sa tête, je vous fais confiance pour adapter
ce démarrage à votre système.
Sur un système FreeBSD, on utilisera l'arborescence
/usr/local/etc/rc.d et on utilisera
le fichier innd.sh contenant les
lignes suivantes (pour INN
2.2) :
#!/bin/sh
if [ $# -eq 0 -o x$1 = xstart ]; then
if [ -x /usr/local/news/bin/rc.news -a -f /usr/local/news/db/history.pag ]; t
hen
limits -C news /usr/local/news/bin/rc.news && echo ' inn'
fi
fi
if [ x$1 = xstop ]; then
/usr/local/news/bin/ctlinnd shutdown machine is going down
fi
Dans le fichier inn.conf, recherchez la
ligne commençant par doinnwatch: et
remplacez la valeur true, qui est
sûrement celle que l'installation par défaut a dû mettre,
par false : cela évitera le
lancement du programme 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). Je ne me rappelle plus si
cette ligne existait dans le inn.conf
de INN 1.7 mais, si ce n'est
pas le cas, recherchez la ligne initialisant la variable
DOINNWATCH dans le script
rc.news et faites de même.
innwatch sert à surveiller
le
bon fonctionnement du serveur : si le démon
innd tombe, ou si un autre problème critique
intervient, il se charge de prévenir l'administrateur par
courrier. D'autre part, une mauvaise configuration de l'expiration des
articles que vous stockez peut entraîner une saturation du
disque : là aussi, innwatch interviendra en
lançant à intervalles réguliers une commande comme
df. Dans le cas d'une configuration comme la nôtre,
son intérêt est donc quasi nul puisque nous maîtrisons l'ajout des
nouveaux articles. Il sert surtout dans les cas où le serveur est
alimenté en permanence.
En tant que root, lancez le script
de lancement adapté à votre système, par exemple :
/etc/rc.d/init.d/news start
sur Red Hat Linux, ou
/usr/local/etc/rc.d/innd.sh start
sous FreeBSD.
Le lancement de ce script doit normalement vous répondre
innd (ou inn) pour
vous informer que le démon est lancé...
Vérifiez par un ps axu qui doit
comporter des entrées similaires à celles-ci :
news 212 0.0 3.0 1912 1428 ? S < 15:39 0:00 /usr/sbin/innd -p4 -i0 -L
news 236 0.0 0.6 888 308 ? S < 15:39 0:00 /usr/lib/news/bin/crosspost -s -
news 237 0.0 0.6 888 312 ? S < 15:39 0:00 /usr/lib/news/bin/overchan
pour INN 1.7 sur un système Linux ou
news 285 0.0 2.1 2988 1992 ?? Is 8:50 0:02.63 /usr/local/news/bin/innd -p4 -L
news 294 0.0 0.5 992 452 ?? IN 8:50 0:00.49 /usr/local/news/bin/crosspost
news 295 0.0 0.5 996 464 ?? IN 8:50 0:00.40 /usr/local/news/bin/overchan
pour INN 2.2 sur un système
FreeBSD.
Pour INN 2.3, sur le même système, on
obtiendra :
news 255 0.0 2.9 7548 2764 ?? Ss 11:11 0:02.69 /usr/local/news/bin/innd -p4
On notera l'absence des entrées crosspost et
overchan qui ne font plus l'objet de
processus séparés.
Si vous obtenez cela, c'est que INN
fonctionne, bravo...
Utilisation de <productname>INN</productname>
Utilisation avec <productname>Suck</productname>
Si vous utilisez Suck, remettez-vous
dans le répertoire /usr/local/etc/suck. Vous vous
rappelez du fichier nouveau que l'on avait
généré ? On va maintenant l'utiliser pour alimenter NOTRE
serveur en effectuant la commande suivante :
# rnews nouveau
Normalement, vous devriez ensuite pouvoir consulter les nouveaux
articles à partir de votre lecteur de news favori (configuré pour
admettre localhost comme serveur de news).
Poster des articles avec <command>rpost</command>
rpost (livré avec la distribution
Suck permet de poster vos articles sur le
serveur distant.
Vous ne pourrez poster des articles que dans les forums
mentionnés dans le fichier active décrit plus
haut (et pourvu que l'autorisation de postage (y)
ait été positionnée pour ce forum...).
Ne postez pas d'article de test dans n'importe quel
forum ! Pour cela, il existe le forum
fr.test (d'où la présence de celui-ci 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 (où
nom_du_feed correspond à la partie gauche de
l'entrée correspondante dans newsfeeds : il
doit contenir une seule ligne indiquant où se trouve l'article à
poster. S'il y a beaucoup de lignes, voir les remarques précédentes
sur le fichier newsfeeds et les serveurs à
exclure...
Connectez-vous à votre FAI et tapez la commande :
# rpost serveur_de_news_distant
Normalement, votre article est posté... Cela dit, ce n'est pas
pour cela qu'il sera accepté par le serveur distant : pour être
conforme, l'en-tête de votre article a besoin d'être légèrement
modifié. Cette opération est réalisée en passant celui-ci à travers un
filtre avant de l'expédier par rpost. D'où
l'intérêt de créer un script automatisant tout cela.
Un script pour automatiser l'envoi et la réception avec
suck
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 :
rendez-le exécutable, placez-le dans
/usr/local/bin et lancez-le sous root.
#!/bin/sh
SERVEUR_DISTANT=news.fai.fr
OUT_GOING=monfai
PATH_SUCK=/usr/local/etc/suck
PATH_SPOOL=/var/spool/news
NOM_BATCH=$PATH_SPOOL/out.going/$OUT_GOING
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 "probleme avec rpost"
else
echo "pas d'articles à poster..."
fi
# puis on récupère les articles (SERVEUR_DISTANT->localhost)
echo Récupération des articles...
cd $PATH_SUCK
if test -f nouveau
then
mv -f nouveau nouveau.old
fi
suck $SERVEUR_DISTANT -c -n -br nouveau
rnews nouveau
Ce modèle suppose que l'entrée correspondant au serveur distant
est de la forme
monfai/serveurs_exclus::Tf,Wnm:
dans votre fichier newsfeeds.
Le fichier NOM_FILTRE permet de formater les
articles. Normalement, la distribution de
Suck a dû vous en fournir
un... Classiquement, ce filtre a pour but de supprimer les champs
NNTP-Posting-Host et Xref (ainsi
que les champs X-Trace, X-Complaints
-To et NNTP-Posting-Date dans le cas de
INN 2.2) en utilisant la commande
sed. 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.
Au cas où vous n'auriez pas un tel filtre, voici le contenu de
/usr/local/etc/suck/entete pour INN 1.7 :
#!/bin/sh
sed -e "/^NNTP-Posting-Host/d" -e "/^Xref/d" $1 > $2
et le même pour INN 2.2 :
#!/bin/sh
sed -e "/^X-Trace/d" -e "/^NNTP-Posting-Host/d" -e "/^Xref/d"\
-e "/^X-Complaints-To/d" -e "/^NNTP-Posting-Date/d" $1 > $2
Ce fichier doit, naturellement, avoir les droits d'exécution
positionnés par chmod +x entete.
Autres options de <command>suck</command>
suck dispose d'autres options lui permettant
de mieux s'adapter à INN :
L'option -A, utilisée avec -hl
localhost, indique à suck qu'il doit
utiliser le fichier active de notre serveur pour
créer et mettre à jour sucknewsrc. Ceci a un
avantage évident : vous êtes sûr que les deux fichiers sont
cohérents et, lorsque vous ajouterez un forum sur votre serveur,
celui-ci sera automatiquement ajouté à la liste des forums à
interroger par suck. De même, si vous supprimez un
forum, la ligne qui lui correspond dans
sucknewsrc sera détruite.
Mais alors, que se passera-t-il pour les forums comme
control, junk,
test, to, et tous ceux qui sont
répertoriés dans active mais que l'on ne veut pas
prendre en compte ? Cela aussi est prévu : il suffit de les
mentionner dans le fichier
/usr/local/etc/suck/active-ignore et
suck les ignorera. Le contenu de ce fichier
commencerait, par exemple, par :
control
junk
test
to
fr.test
Vous pouvez alors vous poser la question : puisque
cette option est si pratique, pourquoi ne pas l'avoir utilisée
dans le script ?
. Ahem, tout simplement parce que, à
l'époque où j'ai écrit ce script, je l'ignorais... Comme disait le
millionnaire : Nobody's perfect !
. De plus,
je ne la trouve pas si pratique, moi, cette option puisqu'elle
nécessite de tenir à jour le fichier
active-ignore et qu'il me semble plus pratique de
gérer directement le fichier sucknewsrc...
D'autres options existent encore : certaines permettent de
modifier les répertoires de travail de suck,
d'autres lui font adopter un comportement particulier dans le cas où
certains serveurs distants produisent des erreurs de connexion, enfin,
on peut même le faire parler en Français ! Nous ne pouvons toutes les
énumérer ici et nous vous renvoyons donc à sa page de manuel pour des
informations complètes.
Installation de <productname>Newsx</productname> et
utilisation avec <productname>INN</productname>
Comparaisons avec suck
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 :
À partir de la version 0.9,
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 certains fournisseurs d'accès,
Newsx est environ deux fois plus rapide que
Suck.
Il s'intègre mieux que Suck
à INN (il lit les mêmes fichiers de
configuration que celui-ci).
Ses inconvénients par rapport à Suck
sont :
Il ne gère pas de kill-file. Il
faut tempérer cet inconvénient par le fait qu'utiliser un
kill-file n'est pas rentable s'il y a peu
d'articles à filtrer et que les articles à filtrer ont une taille peu
importante. En effet, pour décider de prendre ou non un article,
Suck doit prendre les en-têtes 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. Les dernières versions
de Suck corrigent ce problème en permettant
un filtrage utilisant la commande XOVER de NNTP.
Cela dit, tout est affaire de circonstances : si, par exemple,
vous êtes abonnés à un groupe dont certains threads ne vous
intéressent pas du tout, ou si vous avez décidé
d'ignorer les contributions de certaines personnes, le
mécanisme des kill-files vous sera précieux.
Le suivi en direct du chargement des articles est
meilleur avec Suck car il affiche
constamment le débit, alors que Newsx ne le
fournit qu'à la fin.
Quand on démarre la prise d'un groupe avec
Newsx, il est moins aisé de prendre les
n derniers articles qu'avec
Suck (mais c'est
faisable).
Personnellement, je ne pense pas que l'argument de la rapidité
soit vraiment critique si, de toute façon, vous avez tendance à
utiliser la connexion un certain temps (pour surfer, récupérer vos
courriers ou faire de l'IRC par exemple). D'autre part, cette rapidité
de Newsx a un prix : il occupe une
bonne partie de la bande passante de la connexion. Avec
Suck, tandis qu'il poste et récupère les
articles, je peux récupérer et poster des messages email, voire
naviguer sur un site Web...
Installation de <productname>Newsx</productname>
Si vous installez Newsx en utilisant
un système de paquetage Linux (il n'existe pas de paquetage ni
de port FreeBSD), procédez comme vous en avez l'habitude. Si
vous partez des sources, j'imagine que la démarche est classique
(décompression de l'archive, lecture du fichier
README ou
INSTALL)...
Pour lancer Newsx, tapez la ligne
suivante :
newsx -ddd --inn -W40 news.fai.fr news.fai.fr
-ddd permet de largement commenter
ce que fait newsx.
--inn indique qu'il doit coopérer
avec INN.
-W40 indique qu'il doit envoyer les requêtes
par paquets de 40.
Le premier news.fai.fr est le
nom du fichier spool : c'est le
nom du fichier qui se trouve sous
/var/spool/news/out.going.
le deuxième news.fai.fr est le nom
du 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
de INN.
Utilisation conjointe de
<productname>Newsx</productname> et
<productname>Suck</productname>
Il est possible de combiner l'utilisation de
Newsx et de
Suck afin de bénéficier de la gestion des
kill-files, très utile pour certains groupes (voir l'annexe 3). Pour
cela, il faut créer deux lignes (deux feeds) pour le serveur
news.fai.fr :
Une pour les groupes à prendre avec
newsx ;
une pour les groupes à prendre avec
suck.
On modifiera donc le fichier newsfeeds pour
que l'unique feed original soit maintenant réparti sur deux feeds,
d'où deux lignes. 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 /
. Ici, on fait en
sorte d'exclure de la récupération par newsx les
groupes sur lesquels on veut pouvoir filtrer. Ces groupes seront les
seuls récupérés par suck.
# newsgroups pris et postés par newsx
news.fai.fr/serveur-exclu\
:*,!fr.usenet.forums.evolution,!fr.comp.mail,!fr.usenet.logiciels,!junk:Tf,Wnm:
# newsgroups pris par suck et postés par newsx
sucked.news.fai.fr/serveur-exclu\
:fr.usenet.forums.evolution,fr.comp.mail,fr.usenet.logiciels:Tf,Wnm:
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 --inn 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 --inn -W40 news.fai.fr news.fai.fr >>/tmp/log/news.log 2>&1
Il reste alors à modifier le script vu plus haut pour qu'il se
comporte maintenant de la façon suivante :
postage et récupération des articles par
newsx en utilisant les deux lignes-ci dessus
;
récupération des articles des groupes restant par
suck.
Utilisation d'UUCP pour poster et recevoir des
articles
UUCP (Unix to Unix CoPy) est un procédé aussi ancien
qu'Unix. Celui-ci fût initialement conçu pour envoyer des
fichiers d'une machine Unix à une autre : si l'on utilise
aujourd'hui d'autres procédés pour ces copies, UUCP reste un
moyen très efficace pour le transfert des articles Usenet et du
courrier électronique.
Nous ne décrirons pas UUCP en détail ici, il existe une
abondante documentation sur le sujet, dont un article de Denis
Braussen : http://www.linux-france.org/article/connex/uucp/denis-uucp/index.html.
Le principe général qui nous interesse ici consiste à utiliser
des batchs
d'articles (un peu comme ceux que l'on
créait avec l'option -br de
suck).
Là où cela devient intéressant est que ces batchs ne sont pas
créés sur votre machine mais sur le serveur qui vous
approvisionnera. Ajoutez à cela le fait que ces fichiers sont
compressés et vous comprendrez mieux l'intérêt de la chose. De
plus, vous pourrez envoyer vos articles au serveur distant selon
le même principe (et en profiter pour faire de même pour envoyer
et recevoir votre courrier si vous le désirez).
Enfin, UUCP faisant partie intégrante de nombreux Unix (je ne
dis pas tous car je ne les connais pas tous), il n'y a plus
besoin d'installer autre chose que
INN pour disposer d'un
serveur.
Cela dit, pour bénéficier de cette méthode, il faut trouver un
serveur qui acceptera de créer ces fameux fichiers batchs pour
vous, et qui vous autorisera à les configurer pour qu'ils
contiennent les articles des groupes de votre choix. À l'heure
actuelle, je ne connais que Teaser et frmug qui permettent,
moyennant un abonnement dérisoire, d'utiliser UUCP.
Configuration rapide d'UUCP
UUCP utilise un certain nombre de fichiers de configuration
permettant un réglage très fin de son fonctionnement. Dans le
contexte qui nous intéresse ici, nous ne les utiliserons pas
tous. De plus, les communications auront lieu
au-dessus
de PPP, ce qui signifie que nous ne
soucierons pas des problèmes de modem. Voir l'article déjà
cité pour une description plus complète des possibilités de
connexion.
Voici le contenu des fichiers nécessaires à l'utilisation d'UUCP
pour recevoir des articles et/ou du courrier : ils se
trouvent tous dans le répertoire
/etc/uucp. Celui-ci, ainsi que les
fichiers qu'il contient appartiennent à l'utilisateur et au
groupe uucp (qui doivent donc exister). Par
mesure de sécurité (les fichiers en question contiennent des
mots de passe en clair), ce répertoire doit avoir les droits
drwxrwx---.
config. C'est le fichier de
configuration principal. Voici un exemple :
nodename jacoboni
sysfile /etc/uucp/sys
portfile /etc/uucp/port
dialfile /etc/uucp/dial
callfile /etc/uucp/call
passwdfile /etc/uucp/passwd
unknown pubdir /var/spool/uucppublic /var/spool/uucppublic/receive
max-uuxqts 5
debug all
nodename est mon nom UUCP, tel qu'il m'a été
communiqué par l'administrateur du site qui m'enverra les
fichiers batchs. Les autres paramètres sont ceux par
défaut pour mon système : il n'y a pas besoin d'y
toucher.
port. Ce fichier permet de
décrire les ports
de communication
utilisables par UUCP. Ici, nous n'utiliserons que
PPP :
port TCP
type tcp
seven-bit false
reliable true
half-duplex false
service uucp
sys. Ce fichier décrit les
connexions avec les systèmes susceptibles de nous
approvisionner. Ici nous n'en décrivons qu'un, celui de
notre fournisseur :
system teaser
address uucp.teaser.net
myname jacoboni
protocol t
time any
chat-timeout 120
chat "" \r\c ogin: mon_login word: mon_mot_de_passe
commands /bin/rmail /usr/local/news/bin/rnews
port TCP
On spécifie dans ce fichier le nom de la machine serveur. Le
script de chat
envoie notre nom
d'utilisateur et notre mot de passe pour établir la
connexion (ce mot de passe est en clair, attention aux
permissions de ce fichier !). On indique également
les commandes qui s'appliqueront aux batchs reçus :
rmail pour le courrier et
rnews (la commande dont nous avons déjà
parlé) pour les articles. Enfin, on indique le port
(défini dans le fichier port) qui
sera utilisé par cette connexion.
Attention : avec INN 2.3, les droits
de rnews ont été modifiés : cela
peut poser problème pour une utilisation avec UUCP. Pour
corriger cela vous pouvez configurer INN avec l'option
adéquate (--enable-uucp-rnews) ou
rétablir les anciens droits manuellement. Il en va de
même, d'ailleurs pour inews qui vous
permet de poster sur votre serveur local : les
droits par défaut ne vous permettent plus de le
faire... Pensez à les rétablir si besoin est.
C'est tout pour la configuration de UUCP proprement
dit...
Vous pouvez tester votre configuration à l'aide de la commande
uuchk (à exécuter sous le compte
root).
Configuration de INN pour utilisation avec UUCP
UUCP étant configuré, il reste à faire de même pour
INN.
Lorsque votre fournisseur d'accès vous a donné votre
compte et votre mot de passe, il vous a également donné (ou demandé)
un identificateur pour votre serveur : c'est celui que vous avez
indiqué ou que vous indiquerez dans la variable
pathhost de votre fichier
inn.conf.
Si vous ne souhaitez utiliser UUCP que pour recevoir les
articles, c'est tout ce que vous avez à faire. Cela dit, ce
serait dommage de ne pas faire de même pour leur envoi... Pour
cela, il faut indiquer à INN qu'il
doit construire des batchs UUCP à partir des articles que vous
écrivez et que vous souhaitez diffuser sur le serveur de votre
fournisseur et, pour cela, il faut modifier le paramètre
correspondant au type de feed dans l'entrée du fichier
newsfeeds correspondant à ce feed. Si
vous utilisez rpost, ce paramètre est
Wnm (m
comme articles
multiples
). Pour UUCP, il doit
valoir Wnb (b
comme
batch
).
À titre d'exemple, la ligne de mon fichier
newsfeeds est, actuellement :
teaser/teaser.fr::Tf,Wnb:
Ceux qui utilisent un feed UUCP de frmug utiliseront :
frmug/frmug.org::Tf,Wfb,B4096/1024:
C'est tout...
Il reste maintenant à écrire un script permettant, comme
précédemment, d'envoyer et de recevoir les batchs UUCP :
#! /bin/sh
# On prepare le batch des articles a envoyer
/usr/local/news/bin/send-uucp teaser
# On recupere les batchs sur Teaser
/usr/libexec/uucp/uucico -f -s teaser
Le paramètre teaser fait ici référence à
l'entrée correspondante du fichier
/etc/uucp/sys.
Remarque : ce même script vous permettra de
récupérer vos courriers si vous disposez également d'une boîte
UUCP mais, comme dirait Kipling, c'est une autre histoire...
Annexe 1 : 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 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, notamment si
l'utilisation de ctlinnd doit modifier ne serait-ce
qu'un fichier de configuration de
INN : si vous étiez sous
root, la commande fonctionnerait, mais les fichiers
modifiés deviendraient alors la propriété de ce dernier ce qui
provoquerait un arrêt de INN.
Vérification du fonctionnement de <productname>INN</productname>
<command>ctlinnd mode</command>
L'argument mode de la commande offre une
sorte de tableau de bord de l'état du serveur en fonctionnement.
Invoquez ctlinnd mode, qui produira si tout
va bien un message commençant par :
Server running
Allowing remote connections
Si ce n'est pas le cas, utilisez inncheck
(voir ci-après) afin de corriger les fichiers de configuration, puis
relancez le serveur.
<command>ctlinnd checkfile</command>
La commande ctlinnd checkfile vérifie la
syntaxe du fichier newsfeeds (opération qu'il
vaut mieux faire avant de recharger ce fichier en mémoire à la suite
de l'ajout d'un nouveau feed). Normalement, cela doit simplement vous
répondre Ok.
Pour recharger newsfeeds en mémoire,
exécutez la commande ctlinnd reload newsfeeds "rechargement
du fichier newsfeeds".
Modification du fichier <filename>active</filename>
Ajout et retrait de groupes
Comme nous le disions plus haut, il ne faut pas modifier
manuellement le fichier active. À la place, on
utilisera la commande ctlinnd newgroup
nom_du_forum pour ajouter un forum non modéré ou
ctlinnd newgroup nom_du_forum m pour ajouter
un forum modéré.
Pour supprimer une entrée du fichier
active, on utilisera la commande
ctlinnd rmgroup nom_du_forum.
Attention : La manipulation du fichier
active nécessite de stopper au préalable l'activité
du serveur de news à l'aide de la commande ctlinnd pause
"modification du fichier active".
Les modifications terminées, on peut vérifier la cohérence de la
configuration avec la commande inncheck (voir plus
bas).
Si cette vérification s'est bien passée, il reste à demander au
serveur de reprendre son rôle après avoir rechargé le fichier
active en mémoire :
ctlinnd reload active "rechargement du fichier active"
ctlinnd go "modification du fichier active"
Attention : Le message associé à
ctlinnd go doit être le même que celui de
ctlinnd pause...
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...
Mise à jour du fichier <filename>active</filename> à l'aide de
<command>docheckgroups</command>
La méthode décrite plus haut convient pour l'ajout ou le retrait
occasionnel de quelques groupes (par exemple, lors de la création ou
la suppression de forums dans une hiérarchie). Lorsque vous aurez
pratiqué pendant quelque temps Usenet, vous vous apercevrez que votre
configuration est incomplète : souvent, lorsqu'on répond à un
article posté dans un groupe A, on souhaite faire suivre la discussion
dans un groupe B car l'on estime que ce dernier est plus approprié
pour traiter de ce sujet. Par exemple, on peut répondre à un article
posté dans fr.comp.os.unix traitant d'un problème
de programmation Perl et vouloir détourner la suite de la discussion
vers le groupe fr.comp.lang.perl, consacré à ce
langage. Cette pratique a plusieurs avantages et devrait être employée
systématiquement :
elle détourne d'un groupe un fil de discussion qui n'a
rien à y faire et allège donc la pollution de ce groupe
;
elle
replace cette discussion dans un contexte mieux adapté et donc mieux
susceptible de fournir des réponses adéquates.
Cette possibilité est offerte par tous les lecteurs de news et
s'appelle faire un Follow Up To
ou
(à ne pas confondre avec le terme Follow
Up
qui, pour certains logiciels, signifie
simplement répondre à cet article dans ce même
groupe
). Ce qui est important ici c'est le
To
qui indique bien que l'on fait
suivre ailleurs : un champ Followup-To:
fr.toto.titi invitera l'auteur d'une réponse à votre article
à publier celle-ci dans le forum fr.toto.titi. Une
utilisation intéressante est le Followup-To: junk
qui empêchera, normalement, que votre article soit le point de départ
d'un fil de discussion (cela dit, certains indélicats peuvent très
bien choisir de ne pas honorer cette demande). Une autre utilisation
est le Followup-To: poster qui demande à ce que la
discussion se poursuive par courrier privé. Usenet aimant bien les
abréviations, vous verrez souvant le terme Fu2...
Mais, pour faire un fu2 vers un groupe donné, il faut que ce
groupe soit dans notre fichier active et, à
priori, nous ne sommes pas abonnés à tous les groupes existants... Si
vous vous posez cette question, c'est que vous n'avez pas compris le
rôle du fichier active : celui-ci n'a rien à
voir avec les notions d'abonnement aux groupes, il indique simplement
les forums que connaît votre serveur (et accessoirement, le nombre
d'articles de chaque groupe présent sur le serveur pour ceux auxquels
vous êtes abonnés : voir plus haut).
Afin de résoudre ce problème, il faut donc simplement faire en
sorte que notre fichier active contienne tous les
groupes (en tous cas, tous les groupes auxquels nous sommes abonnés et
tous ceux vers lesquels nous sommes susceptibles de faire suivre). Par
exemple, il est souhaitable que notre serveur connaisse au moins tous
les groupes de la hiérarchie fr... Or celle-ci
compte plus de 200 forums !
Certains FAI mettent à disposition leurs fichiers
active et newsgroups :
il suffit alors de les télécharger. Mais
attention :/ les fichiers ainsi récupérés
reflètent l'état du serveur de votre FAI, pas celui du vôtre !
Ceci signifie que les numéros d'articles qui s'y trouvent ne
correspondent pas aux numéros d'articles sur votre serveur... (voir la
section sur la commande getlist pour résoudre
ce problème).
Heureusement, la distribution de INN
offre un outil permettant d'automatiser ce processus : il s'agit
du script ~news/lib/docheckgroups (cet
emplacement est celui de INN 2.2). De plus,
le forum fr.usenet.forums.annonces poste
régulièrement un fichier au format adéquat qu'il nous suffira de
traiter de la façon suivante :
Nous supposons que vous avez sauvegardé dans un
fichier le contenu de l'article en question. À titre d'exemple, voici
les premières lignes du dernier article :
From: fufa@teaser.fr (Usenet FR)
Subject: [ANNONCE] Liste des groupes fr.* au format checkgroups
Summary: Fr.* docheckgroups lists.
Keywords: usenet liste fr checkgroups inn.
Date: 1 Nov 2000 03:51:01 -0000
Message-ID: <liste-groupes-fr-1-973050661@sortilege.frmug.org>
(je saute les autres en-têtes...)
Posted-By: auto-faq 3.3.1 beta (Perl 5.005)
Archive-name: fr/liste-groupes
Posting-Frequency: 1 and 15 of each month.
X-No-Productlinks: yes
Ceci est une liste technique maintenue par
This is a technical list maintained by :
liste-fr <liste-fr@sortilege.frmug.org>
Dernier article checkgroup officiel
Last official checkgroup post :
<fr-checkgroups-september-0-1@usenet-fr.news.eu.org>
Liste disponible sur le web à l'adresse :
This doc is available on www :
http://www.usenet-fr.news.eu.org/liste-groupes.html
[ Version Francophone ]
Une autre maintenue par Philippe Ladame <philippe.ladame@wanadoo.fr>,
moins compacte, dite "Table des forums fr." est disponible
sur news:fr.bienvenue, et, pourvue de liens vers les chartes des forums,
sur le Web en http://www.citeweb.net/aminaute/forums/tablefr.html.
Si votre site transporte la totalité des groupes "fr" alors chacun
des groupes listés ci-dessous devrait s'y trouver. Vous pouvez
passer le script ci-dessous à votre checkgroups afin de vérifier si
tous les groupes existent et ont le bon statut. Le script ci-dessous
est à utiliser avec INN en ayant les privilèges de l'utilisateur
gérant les news (en général news ou usenet).
(je coupe le texte en anglais)
Il y a 278 groupes dans fr.* à la date du 01/11/2000
---------- snip ---------- snip ---------- snip ---------- snip ----------
/usr/local/news/bin/control/docheckgroups <<PASGLOP
fr.announce.divers Annonces diverses (pas petites annonces). (Moderated)
fr.announce.important Annonces importantes concernant fr. (Moderated)
fr.announce.newgroups Annonces de nouveaux groupes / discussions. (Moderated)
fr.announce.seminaires Annonces de conferences et seminaires. (Moderated)
fr.bienvenue Aider les nouveaux venus dans leurs premiers pas sur Usenet. (Moderated)
fr.bienvenue.questions Les premieres questions sur Usenet (Ou, Comment).
...
Après avoir sauvegardé ce fichier, éditez-le pour supprimer tout
ce qui précède la ligne
/usr/local/news/bin/control/docheckgroups
<<PASGLOP, modifiez éventuellement le chemin de
docheckgroups pour qu'il corresponde à votre
système et sauvez-le sous le nom
/tmp/fufa.
Sous le compte news, arrêtez votre
serveur à l'aide d'une commande ctlinnd pause 'maj'
et lancez la commande :
sh /tmp/fufa > /tmp/maj-active
Ceci va vous créer le fichier
/tmp/maj-active que vous allez éditer pour
vérifier que tout est correct.
Ce fichier contient d'abord un ensemble de lignes en
commentaires indiquant les groupes qui manquent à votre fichier
active (la première fois, il risque d'y en avoir
beaucoup...). À la suite de ces commentaires, vous trouverez un
ensemble de lignes ctlinnd newgroup ... qui se
chargeront d'ajouter les groupes à votre fichier
active. Parcourez-les pour vérifier que tout est
correct (faites notamment attention au statut de groupe
modéré/modéré).
Vous trouverez à la fin de ce fichier les descriptions qu'il
faut ajouter à votre fichier newsgroups (ce n'est
pas fait automatiquement : n'ajoutez que les descriptions des
groupes auxquels vous êtes abonnés).
Lancez les commandes suivantes :
cp ~news/db/active ~news/db/active.save
sh /tmp/maj-active
La première commande est une précaution au cas où les choses
tourneraient mal...
Forcez le rechargement du fichier
active via une commande ctlinnd reload
all 'ok' (éventuellement, faites une vérification via
inncheck -a -v -pedantic) et relancez le serveur
par la commande ctlinnd go 'maj'
Voilà, vous avez un fichier active
contenant toute la hiérarchie fr ainsi que tous les
groupes que vous y aviez déjà mis. Supprimez les fichiers que vous
avez créés dans /tmp et le fichier
active.save.
Attention : ne vous connectez surtout pas
tout de suite si votre script de récupération des articles utilise
l'option -A de suck !!!
Vous lanceriez la récupération de tous les articles disponibles de
tous les groupes que vous venez d'ajouter !
Assurez-vous de supprimer cette option de votre
script.
Mise à jour du fichier <filename>active</filename> à
l'aide de <command>getlist</command>
La méthode précédente nécessite de disposer de fichiers au
format docheckgroups, elle est relativement
automatique et peut se faire hors connexion. Une autre méthode, plus
exhaustive, consiste à récupérer les informations directement auprès
de son fournisseur d'accès à l'aide du programme
getlist, fourni avec la distribution
INN (getlist(1)). Un des
désavantages majeurs de cette méthode est, bien sûr, qu'elle implique
une connexion qui peut être très longue (mais cette opération ne doit
être faite qu'une fois).
Le programme getlist, livré avec
INN (et normalement placé dans
~news/bin/) permet de récupérer certains
fichiers de configuration exploités par un serveur
distant. Notamment, active et
newsgroups.
Voici, par exemple, comment créer un fichier contenant une copie
de l'active du serveur de news de notre
fournisseur d'accès :
getlist -h news.fai.fr active > active_new
On peut aussi préciser, après le mot-clé désignant le fichier à
récupérer, un filtre de sélection :
getlist -h news.fai.fr active 'fr.*' > active_fr_new
Attention : Ne remplacez surtout pas votre
active local directement par le fichier ainsi
engendré, car celui-ci contient les numéros des articles gérés par le
serveur distant. Par contre, en étant sous le compte
news, vous pouvez remplacer directement votre
fichier newsgroups par la commande :
getlist -h news.fai.fr newsgroups > ~news/db/newsgroups
(mieux vaut au préalable stopper le serveur).
Pour mettre à jour notre fichier active,
nous allons utiliser la méthode du polytechnicien
et
donc créer un fichier qui pourra ensuite être traité par
docheckgroups. Pour ce faire, on exécutera les
commandes suivantes :
echo "/usr/local/news/lib/docheckgroups <<PASGLOP" >/tmp/active_check
cut -f1,4 -d' ' active_new | /tmp/check.pl >>/tmp/active_check
echo "PASGLOP" >>/tmp/active_check
où /tmp/check.pl est le script Perl suivant
(faites un chmod +x pour le rendre exécutable) :
#!/usr/bin/perl
while (<STDIN>)
{
(s/^(.*) y$/$1/) || (s/^(.*) m$/$1 \. \(Moderated\)/);
print ;
}
Le fichier /tmp/active_check/ ainsi créé va
permettre à docheckgroups de comparer notre fichier
active avec la liste des groupes du fichier de
notre FAI. Pour ce faire, il suffit, sous le compte
news de lancer la commande :
sh /tmp/active_check > /tmp/active_2_vrfy
Attention, cette commande risque d'être plutôt longue :
chez moi, elle a pris plus d'un quart d'heure (il faut dire que
l'active de mon fournisseur comportait 22765 entrées...). Un ps
ax vous confirmera que la commande continue de s'exécuter.
Lorsque cette commande est terminée, éditez le fichier
/tmp/active_2_vrfy qui a été créé : il doit
contenir un certain nombre de commandes de création de
groupes. Supprimez celles qui ne vous intéressent pas, vérifiez les
autres (les commandes de suppression de groupes ou de changement de
statut de modération). Stoppez votre serveur et lancez la commande
(toujours sous le compte news) :
cp /var/lib/news/active /var/lib/news/active.save
sh /tmp/active_2_vrfy
Reportez vous à la section précédente pour le rechargement du
fichier active et le redémarrage du serveur.
Remarque : Avec un fichier
active conséquent, et si votre logiciel de
lecture dispose de cette option, il peut être nécessaire de le
configurer afin qu'il ne relise pas systématiquement le fichier
active à chaque démarrage... Avec
Gnus, par exemple, on pourra utiliser avec
profit les variables gnus-read-active-file et
gnus-check-new-newsgroups.
Annexe 2 : Vérification du serveur et expiration des
articles
Utilisation d'<command>inncheck</command>
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 /usr/local/news/db/active...
Looking at /usr/local/news/etc/control.ctl...
Looking at /usr/local/news/etc/expire.ctl...
Looking at /usr/local/news/etc/incoming.conf...
Looking at /usr/local/news/etc/inn.conf...
/usr/local/news/etc/inn.conf:16: modmailer has bad address
Looking at /usr/local/news/etc/moderators...
Looking at /usr/local/news/etc/newsfeeds...
ME, crosspost, overview!, teaser, /usr/local/news/etc/newsfeeds:0: warning you accept all incoming article distributions
done.
Looking at /usr/local/news/etc/nnrp.access...
Looking at /usr/local/news/etc/nntpsend.ctl...
Looking at /usr/local/news/etc/overview.fmt...
Looking at /usr/local/news/etc/passwd.nntp...
Ce qui n'est déjà pas si mal... Un avertissement
(warning
) pour l'entrée ME du
fichier newsfeeds révèle que j'accepte toutes les
distributions, et un autre m'indique que je n'ai pas renseigné le
champ modmailer dans le fichier
inn.conf (ce qui est inutile puisque j'utilise un
fichier moderators).
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, cela aidera forcément ceux qui veulent vous
répondre...
À ce propos, 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 (cf. les pages de manuel
expire(8) et
fastrm(8)). L'administrateur doit donc veiller à ce
que cette commande soit lancée régulièrement (quotidiennement) :
le script news.daily est fait pour
cela. Pour que cette opération ait lieu tous les jours à un heure où
votre machine fonctionne, le plus simple consiste à créer une
tâche cron pour l'utilisateur
news. Pour cela, il suffit, à partir du
compte news d'exécuter la commande
crontab -e et d'ajouter la ligne
suivante :
40 20 * * * /usr/local/news/bin/news.daily
Désormais, les tâches de maintenances quotidienne de
INN auront lieu tous les jours, à
20 heures 40 (cf. crontab(5) pour la
syntaxe de cette ligne sur votre système).
Sinon, une façon plus brutale
de forcer cette
expiration est de lancer sous le compte news, la
commande /usr/local/news/bin/expire -v1, suivie
d'un /usr/local/news/bin/ctlinnd renumber ''. Mais
je ne vous le conseille pas. De plus, news.daily se
charge de poster un rapport contenant des statistiques sur
l'utilisation de votre serveur, ce qui peut permettre de détecter
d'éventuels dysfonctionnements. Ce rapport étant adressé à
l'administrateur du serveur (le newsmaster
), il est
préférable de créer un alias de celui-ci vers un compte
utilisateur : le vôtre, par exemple.
La commande expire utilise le fichier
expire.ctl déjà évoqué, qui permet de paramétrer
les durées d'expiration des articles. La syntaxe de ce fichier est
décrite dans expire.ctl(5).
Annexe 3 : Filtrage des articles avec 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
/usr/local/etc/suck doit se trouver un fichier
suckkillfile qui est le fichier de filtrage
maître. Voici un exemple de contenu :
HILINES=10000
#LOWLINES=10
NRGRPS=7
From:aaaa@bbb.fr
From:cccc@ddd.fr
QUOTE=\
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 :
Type mot-clé : HILINES, LOWLINES, QUOTE,
GROUP : ils définissent un comportement
général
;
Type header : 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
forums 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 forums est suspect. Cette entrée
n'apparaît qu'à partir de la version 3.8 de
Suck. Attention à ne pas vouloir trop en
faire : j'avais d'abord mis cette valeur à 5 et, par analyse du
fichier /tmp/suck.killlog, je me suis aperçu que
certains articles avaient été rejetés car, dans certains forums
(notamment ceux traitant d'emacs), le cross-postage
est une coutume... Je l'ai donc ramené à 7.
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 forum particulier : ce comportement est soit
delete soit keep. Il s'applique
au forum 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.usenet.logiciels et
fr.comp.mail. Tous les deux sont filtrés selon les
règles définies dans le fichier de filtrage
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 forums dans lesquels ils ont été postés. Cela
permet, notamment, d'éliminer les trolleurs
ou les
spammers
déjà repérés (mais cela ne filtrera pas les
réponses que certains pourraient leur faire).
Les entrées de type header décrites dans le fichier
suckkillfile s'appliquent à
tous les forums et, pour définir un comportement
particulier pour un forum donné, on utilisera une entrée
GROUP. Le fichier
suckkillfile.no_ms pourrait ainsi contenir 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 Microsoft.
À la place de delete, on peut indiquer
keep, qui ne conservera que
les articles correspondants aux critères fixés.
Une entrée de type :
GROUP=keep fr.* suckkeepfile.moi
et un fichier suckkeepfile.moi contenant
simplement :
From:.*jaco@teaser\.fr
aurait le mérite de restreindre le nombre d'articles récupérés pour
les forums de la hiérarchie fr, mais je
n'apprendrais plus grand chose...
À chaque fois qu'il rejette un article,
Suck l'indique dans le fichier
/tmp/suck.killlog (ou
/usr/local/etc/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, il utilise le format long. On peut
le forcer à utiliser un format court, mais je le trouve peu
explicite... On peut même le configurer pour qu'il ne crée pas ce
fichier : ce serait une mauvaise idée, selon moi. Jetez toujours
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 tout cas, pensez à vider ce fichier périodiquement car
il a tendance à grossir assez vite (sauf s'il se trouve dans
/tmp et que vous avez configuré votre système
pour qu'il vide ce répertoire à chaque démarrage).
Comme nous l'avons évoqué plus haut, ce mécanisme de filtrage
s'effectue en examinant le contenu des messages, ce qui induit
nécessairement un temps de traitement supplémentaire. Les
dernières versions de Suck permettent
d'utiliser un fichier suckxover, plus
rapide à traiter car n'utilisant pas le même mécanisme
d'examen. Ce dernier type de filtrage ne dispose pas de toutes
les fonctionnalités du précédent mais suffit dans la plupart des
cas (cf. suck(1)).
Bibliographie
Le contenu de ce document est, en grande partie, tiré de
mon expérience personnelle et notamment des différents déboires que j'ai
rencontrés. Toutefois, cette expérience s'est principalement forgée grâce à
l'aide des personnes que je remercie dans la section suivante.
La lecture du forum fr.usenet.logiciels est
une source inestimable de renseignements précieux pour tout ce qui
touche à la configuration des logiciels traités ici. Si vous avez un
problème concernant INN,
Suck ou Newsx
ne le postez pas dans un forum destiné à votre système
d'exploitation.... Ces logiciels existent sur tous les Unix
et ne sont pas liés à un système particulier.
Certains documents sont disponibles librement sur
l'Internet :
J'ai parcouru Administration Réseau sous
Linux
(aka NAG : Network Administration
Guide
d'Olaf Kirch. Bien que disponible par téléchargement, ce
livre est aussi édité par les éditions O'Reilly, pour ceux qui
préfèrent les beaux livres... La première édition de ce livre est un
peu ancienne (1995), et traite surtout de
Cnews. La section sur
INN est assez limitée et le problème des
connexions occasionnelles via PPP n'est pas
abordé. Il n'empêche : il constitue une source de renseignements
inestimable sur le fonctionnement d'Usenet et des réseaux en
général. Une seconde édition a vu le jour (je ne l'ai pas encore
consultée) et sa traduction française est en cours.
La FAQ
INN de Fabien Tassin est une mine de renseignements, bien
qu'elle commence sérieusement à dater... Grâce à elle, j'ai notamment
récupéré un document écrit par Gilles Rech, intitulé Guide
d'administration d'un serveur de news INN, guide d'administration de
NNTPLINK. Cette documentation, elle aussi ancienne, décrit
clairement les problèmes et les fichiers de configurations de
INN bien que, là encore, le problème de la
récupération et de l'envoi d'articles par PPP ne
soit pas traité.
Évidemment, les documentations, les fichiers
README ou INSTALL,
les pages man des programmes cités sont
les références absolues.
Honnêtement, je n'ai pas lu de livres commerciaux,
tout simplement parce que je n'en connaissais pas et que je n'ai pas
eu l'occasion d'en parcourir. Les éditions O'Reilly ont publié
Managing Usenet
, qui a même été traduit en français,
mais je m'y suis pris trop tard : la première édition
n'est plus disponible. Gageons qu'une nouvelle édition
verra bientôt le jour.
La suite au prochain numéro...
Cette doc grossit à vue d'oeil. Il faudra probablement que je la
réorganise mais je préfère pour l'instant livrer les informations dont
je dispose...
Beaucoup de choses manquent, qui seront intégrées au fil de vos
remarques et de mon temps disponible, le rôle des messages de
contrôle, l'utilisation de PGP et de filtres Perl, notamment, est en
cours de gestation.
Remerciements
L'idée de ce document vient d'un échange E-épistolaire avec
Nat Makarévitch qui s'est patiemment escrimé à
répondre aux problèmes que je rencontrais lors de la configuration de
INN sur ma machine. Je le remercie pour
cette aide, pour ses relectures et ses ajouts à ce document et pour
avoir créé <linux-france.org>.
Je remercie aussi Emmanuel Chantreau pour
avoir répondu au problème de la récupération des articles sur leur
numéro plutôt que sur leur Message-Id avec
Suck, ainsi que pour sa relecture et sa
participation à ce document. Toute la partie sur
Newsx, notamment, est de sa plume.
Merci à Stéphane Lee Chip Hing pour ses
suggestions sur l'utilisation de ctlinnd pour les
modifications du fichier active.
Merci à ceux qui m'ont écrit pour mettre en évidence les lacunes
et/ou erreurs de la version précédente : D. Braussen,
N. Chuche, A. Derogis, P. Dorgueil... Ils m'ont servi,
malgré eux, de cobayes et ont du mérite.
Merci à François Ranchin pour la
méthode Fyr
, pour avoir passé un week-end de
Pentecôte avec moi ;-) et pour ses commentaires avisés sur ce
document.
Toute l'équipe de Teaser m'a permis de configurer sans trop
peiner UUCP afin que je puisse bénéficier de ce formidable moyen
de transport.
Merci à Olivier Tharan, qui a assuré la
relecture de cette version.
Enfin, merci à tous ceux qui continuent à fournir des réponses
dans fr.usenet.logiciels.
Termes d'utilisation
La redistribution du code source (XML), modifié ou non,
et compilé (HTML, PostScript, etc.) est soumise aux
conditions suivantes :
Le copyright ci-dessus, la présente liste de conditions et
l'avertissement qui la suit doivent figurer dans le code
source.
Le code source distribué sous forme compilée doit
faire apparaître le copyright ci-dessus, la présente
liste de conditions et l'avertissement qui la suit.
CE DOCUMENT EST FOURNI « TEL QUEL » ET IL N'EST DONNÉ
AUCUNE GARANTIE, IMPLICITE OU EXPLICITE, QUANT À SON UTILISATION
COMMERCIALE, PROFESSIONNELLE OU AUTRE. L'AUTEUR NE PEUT EN AUCUN CAS ÊTRE
TENU POUR RESPONSABLE DE QUELQUE DOMMAGE OU PRÉJUDICE DIRECT,
INDIRECT, SECONDAIRE OU ACCESSOIRE (Y COMPRIS LES PERTES FINANCIÈRES
DUES AU MANQUE À GAGNER, À L'INTERRUPTION D'ACTIVITÉS,
OU LA PERTE D'INFORMATIONS ET AUTRES) DÉCOULANT DE L'UTILISATION DE
LA DOCUMENTATION OU DE L'IMPOSSIBILITÉ D'UTILISER CELLE-CI, ET DONT
L'UTILISATEUR ACCEPTE L'ENTIÈRE RESPONSABILITÉ.