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

2. 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 le lisez. Et réciproquement, comment peut-on lire un article qui a été posté à l'autre bout du monde ?

2.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. Généralement, sous Linux, 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 assurez 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 : 

news:*:9:13:news:/var/spool/news:

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, vous pouvez utiliser l'utilitaire usercfg de la Red Hat à partir d'un xterm, ou groupadd et useradd en ligne de commande. Dans tous les cas, nous vous déconseillons de créer un groupe ou un utilisateur « à la main » (sauf 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.linux, il le place sous le répertoire /var/spool/news/fr/comp/os/linux 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 ce qu'abritent 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.

2.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 (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 Linux 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/news.fai.fr sous la forme d'un 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 du paquetage 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.

2.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 logiciel 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 Oléane automatise tout cela : une commande suffit pour tout faire (la génération du fichier batch et son traitement par innxmit 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) ;
  • lorsque l'on poste un article, le lecteur de news se charge de l'envoyer au serveur (avec un programme comme inews, par exemple) ;
  • lorsque l'on souhaite expédier au serveur de son FAI un article posté localement, on se connecte et on invoque un programme comme rpost ;
  • lorsque l'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
newsrun est généralement lancé automatiquement par cron.
 
                                 VSP/out.going/news.fai.fr 
  --------------  <--- rpost --- +                         <-------
 | Serveur NNTP |                VSP/fr/test/5214                  n
 | news.fai.fr  |                                                  e
 | du provider  |                                                  w
  --------------  ---- suck ----> /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)
  --------------

Comme nous le verrons, la méthode Fyr allège toute la partie concernant l'approvisionnement de notre serveur local (la branche suck -- rnews est supprimée)

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/out.going/news.fai.fr 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é seront réenvoyé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...

2.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 du FAI.

Connectez-vous tout d'abord à votre FAI.

Dans une fenêtre xterm, 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 port de connexion vous indiquez le protocole que vous utilisez. NNTP signifie Network 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 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 la commande : 

group fr.comp.os.linux

(ou bien le nom de tout autre forum distribué par ce serveur).

Vous devez obtenir une réponse du style : 

211 2260 31267 33570 fr.comp.os.linux

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.linux... (33570 signifie qu'il y a 33570 articles dans ce forum, et 31267 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 de news.

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 notre 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 titine.jacosoft.fr.
Escape character is '^]'.
200 titine.jacosoft.fr InterNetNews server INN 1.7 16-Oct-1997 ready

et toutes les opérations décrites plus haut s'appliquent évidemment de la même façon.

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