6. 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 ?

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

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

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

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