Cette documentation présente le serveur de news INN. Certaines parties sont spécifiques aux dernières versions, c'est à dire 2.3 et supérieures au moment de sa rédaction.
Elle s'adresse aux personnes désirant mettre en place un serveur de nouvelles pour le mettre en communication sur le réseau Usenet. Il s'agit d'une activité fort différente de la lecture des groupes de disucssion ; si c'est ce dernier sujet qui vous intéresse, à part contraintes très particulières, un lecteur de news sera plus simple à mettre en place. D'autres documentations les détaillent ; leurs références sont reprises en annexe à ce document, point #x#.
Une version web de cette documentation est trouvable ici : #xxx#.
(Extrait traduit de la documentation écrite par Russ Alberty et Katsuhiro Kondou.)
INN (InterNetNews), écrit à l'origine par Rich Salz, est un serveur extrêmement flexible et configurable de nouvelles Usenet. Pour une description complète des protocoles qui régissent Usenet, consultez la RFC 1036 et la RFC 977 (et leur remplacements, NDT : on peut y ajouter la RFC 2980). En bref, Usenet est basé sur un groupe de protocoles pour échanger des messages entre un réseau décentralisé de serveurs de nouvelles. Les articles sont organisés en groupes de nouvelles, qui sont eux-même organisés en hiérarchies. Chaque serveur individuel stocke localement les articles qu'il reçoit pour un groupe donné, permettant un accès extrêmement rapide aux messages stockés. Les nouvelles ne nécéssitent pas de serveur central. Au lieu de cela, chaque serveur transmet les articles qu'il reçoit à tous les serveurs dits "pairs", ces serveurs passant les articles à leurs propres pairs, et ainsi de suite, donnant une propagation dite "par innondation" des messages.
Un serveur de nouvelles remplit trois fonctions de base : il accepte les articles des autres serveurs et les stocke en local, il envoie les articles qu'il a reçus aux autres serveurs, et offre les articles stockés aux lecteurs, à la demande. De plus, il doit effectuer quelques tâches de maintenance périodiques, comme par exemple supprimer les articles anciens pour laisser la place aux nouveaux.
...
INN est un logiciel libre et gratuit, supporté par l'Internet Software Consortium et des volontaires partout dans le monde.
INN fonctionne sur une grande variété de plateformes de type Unix et assimilées relativement récents (notamment les distributions Linux et les divers BSD #*# en théorie aussi Mac OS X, je suppose ? une idée là dessus ? #*#). Il semblerait que certaines personnes aient pu faire fonctionner INN sur des plateformes Windows, mais cela demande une certaine gymnastique, et cela n'est ni supporté, ni recommandé...
Au niveau du matériel, de nouveau, la palette disponible est très large et dépend grandement des besoins. Tout matériel relativement neuf (entendez par là vieux de moins de cinq ans) peut techniquement faire fonctionner le système mais le traffic de Usenet peut être extrêmement important selon le nombre de groupes de discussion distribués...
Cela signifie également qu'un serveur de news impose généralement une charge non négligeable à une machine. De plus, il vous faut impérativement les droits d'administration sur le serveur...
Une bonne connaissance de la plateforme qui va héberger le serveur est indispensable.
Une bonne connaissance du fonctionnement de Usenet est préférable, autant au niveau organisationnel que la base de la technique, comme par exemple la manière dont se présente un article, les diverses en-têtes et leur signfication, etc.
Il est aussi indispensable de connaître un minimum le protocole NNTP...
Là aussi, tout dépend du nombre d'articles diffusés. Le plus important est sans doute d'avoir une adresse IP fixe (on peut faire sans, mais ce n'est pas l'objectif de ce document, cfr le point #x# pour des liens plus utiles) et, parfois même, l'accord de votre fournisseur de connectivité...
Il est aussi important d'avoir un accord avec un autre serveur de news pour procéder à l'échange d'articles. De nouveau, il est possible de greffer un serveur de news sur un autre sans accord de ce type, mais uniquement pour un très faible traffic, et ce n'est pas non plus l'objectif de cette FAQ (cfr le point #x#).
Voici, dans l'ordre qui m'a semblé le plus logique, un résumé des concepts les plus importants utilisés partout dans la documentation. Certains de ces termes sont spécifiques à INN (d'où l'étiquette 'spécifique' à côté des titres), d'autres sont standards au système Usenet.
Network News Transfer Protocol. Le protocole de base du transfert de news, défini dans un premier temps dans les RFC 977, étendu dans la RFC 2980. Depuis peu, les RFC 3977 et suivantes sont apparues pour concrétiser l'évolution des serveurs de nouvelles, mais elles ne sont pas encore largement appliquées ((en tout cas pas encore intégralement dans la pré-version d'INN 2.5 au moment de l'écriture de ce document).
Normalement ~news/bin/innd, c'est le démon principal de INN, chargé de la réception des articles, de leur propagation et de leur stockage. Il supporte un nombre restreint de commandes du protocole NNTP, uniquement axées propagation d'articles.
Normalemment trouvé en ~news/bin/ctlinnd, c'est le système de contrôle du serveur INN, qui permet entres autres de mettre celui-ci en pause, ou de lui faire recharger sa configuration.
Situé en ~news/bin/nnrpd, c'est le démon qui répondra aux utilisateurs finaux, gérant toutes les commandes du protocole NNTP utiles à la lecture et au postage d'articles. (NNRP pour Network News Reading Protocol.)
L'active est le fichier qui reprend la liste des divers groupes qui sont présents sur le serveur, les numéros minimum et maximum des articles, et le statut du groupe (modéré, non modéré, lecture seule, ...).
Champ d'article qui identifie celui-ci de manière globalement (à tout Usenet) unique.
Un serveur de news qui va échanger des articles avec le vôtre. On désigne aussi par peering le fait d'établir un échange d'articles.
Flux d'articles entre deux serveurs peers. Quand un serveur reçoit un article (depuis un autre serveur ou depuis un client), il le propose à tous ses peers, d'où le terme fréquemment utilisé d'innondation.
Le démon normalement chargé de la gestion des feeds sortants ; ~news/bin/innfeed.
Mode de feed qui permet l'échange d'articles de manière plus souple, en évitant les temps d'attentes entre la proposition d'un article et sa transmission réelle. Ce mode implémente les commandes CHECK et puis TAKETHIS (RFC 2980), qui fonctionnent de manière asynchrone. Hors streaming, l'envoi se fait via un IHAVE (RFC 977), qui, lui, impose un dialogue synchrone.
Champ d'article qui indique le cheminement du message et les serveurs qu'il a traversé depuis son entrée dans le réseau. Permet d'éviter de reproposer un article à un pair qui vient de le soumettre, notamment.
L'historique est un fichier qui contient les identifiants de messages (message-id) de tous les articles récemment soumis au serveur (acceptés ou non), qui permet refuser rapidement une soumission du même article depuis plusieurs sources, et autres opérations.
Zone locale sur laquelle sont stockés les articles. INN propose plusieurs types de spools (qui peuvent être utilisés simultanément en fonction des groupes sur une même machine) :
L'overview est une sorte d'index des articles, utilisé, dans INN, par NNRPd pour présenter très rapidement aux lecteurs les en-têtes de base (sujet, date, message-id, ...) dans les groupes de discussions sans ouvrir pour cela chaque article. Il y a aussi plusieurs manières d'organiser l'overview de INN :
Si le serveur n'utilise pas de systèmes de stockage cycliques (spool CNFS et overview buffindexed), il doit périodiquement nettoyer le disque des articles les plus vieux pour récupérer de l'espace. Ce processus se nomme l'expiration. Habituellement, il est lancé via une crontab pendant la nuit. Ce processus peut être long (de quelques minutes à plusieurs heures), en fonction du nombre d'articles et de la qualité de votre matériel.
Champ d'article renseigné par chaque serveur qui indique un identifiant local unique du message dans le (ou les groupes) où il est publié.
Quand un groupe est marqué modéré dans l'active, les articles postés vers ce groupe ne sont pas transmis via le mécanisme standard de feeds etc, mais envoyés à un modérateur par e-mail. Celui-ci, s'il accepte l'article, le réinjecte sur Usenet en garnissant le champ approved.
Champ rempli par le modérateur qui permet à l'article de ne pas retourner par mail à l'envoyeur, mais bien de se propager normalement.
INN permet le filtrage de deux manières : un filtre qui examine et éventuellement modifie les articles postés en local par NNRPd, et un filtre qui accepte ou rejette des articles qui arrivent via les feeds. Ces filtres peuvent être écrits en perl ou python, et, pour certaines versions, tcl.
Quand le serveur rencontre un problème grave (manque d'espace disque ou incapacité d'écrire des fichiers par exemple), il bascule en mode étranglé, c'est-à-dire qu'il ferme toute connexion ouverte et refuse toutes les nouvelles.
Le serveur peut également se mettre en pause, mode dans lequel il refuse les nouvelles connexions, mais ne referme pas les connexions existantes.
Démon qui surveille divers paramètres extérieurs au serveur (charge processeur, espace disque, etc) et qui peut intéragier avec celui-ci (souvent en l'étranglant) en cas de problème.
Expression qui permet de sélectionner des groupes, à l'instar des jokers de la ligne de commande. On peut y trouver, entre des élements de texte à comparer, une étoile *, qui indique une série de indeterminée de caractères, un point d'interrogation ? pour un seul caractère, plus des crochets [ et ] qui entourent des classes de caractères (ces dernières options sont rarement utiles). Par exemple, fr.* correspondra à tous les groupes de la hiérarchie fr, alors que fr*.securite incluera un groupe qui finit par .securite dans fr, mais aussi dans free ou france... Pour la documentation détaillée, référez-vous à la page de manuel (man 3 wildmat).
La compilation et l'installation des binaires du système INN ne sont pas (encore ?) couverts par ce document. Il est habituellement conseillé de réaliser l'installation à partir des sources, un certain nombre de fichiers d'aide étant disséminés dans le répertoire de sources, et donc souvent oublié lors de l'installation par d'autres méthodes (rpm par exemple).
De manière générale, suivez les instructions présentes dans le fichier INSTALL de l'arbre de sources pour avoir un premier système fonctionnel (donc, créer les fichiers historique, les répertoires, etc).
Notez que, pour un serveur voyant passer un nombre important d'articles, une bonne gestion des systèmes de fichiers est importante (partitionnement des disques, répartition de la charge sur plusieurs disques et contrôleurs, etc). Cet aspect est étudié plus loin, au chapitre #*#.
Il est impératif d'avoir un utilisateur news appartenant à un groupe news pour faire fonctionner le serveur. Cet utilisateur devrait disposer d'un shell et d'une configuration agréable (notamment en incluant le chemin des binaires de INN dans le PATH) - en effet, il est indispensable, une fois les binaires installés, d'effectuer toutes les opérations en tant qu'utilisateur news. Autrement, vous aurez inévitablement des problèmes étranges... Vous aurez été prévenus !
INN étant un programme très paramétrable, il peut être configuré de manière à tenir pas mal de rôles dans la diffusion de Usenet (serveur complet, serveur de transit, serveur de lecture, archiveur même). Dans un premier temps, nous allons examiner le cas du serveur complet. Les autres configurations seront esquissées plus loin dans la documentation (chapitre #4?#).
Dans les version 2.3 et 2.4, le serveur innd est généralement lancé par le programme inndstart (setuid root, ce qui lui permet de s'attacher au port 119 ; man 8 inndstart).
Dans la version 2.5, innd lui-même fait appel au programme innbind pour jouer ce rôle (man 8 innbind).
Inndstart démarre inn avec les flags qui lui sont donnés sur la ligne de commande.
Les plus importants sont :
Pour une liste complète, consultez la page de manuel (man 8 innd).
C'est la pierre angulaire du système. Les options présentes sont documentées dans la page de manuel (man 5 inn.conf). Ne sont présentées ici que les options les plus importantes.
Le format général du fichier présente soit des lignes de commentaires commençant par un cardinal (#), soit un ligne comprenenant une clé, suivie de deux-points, suivie d'une valeur. Des espaces (ou tabulations) peuvent être rajoutés après les deux-points. Sepuis la version 2.4, si la valeur contient les caractères espaces, <, >, [, ], " ou \, il est nécéssaire de l'entourer de guillemets ("), et eventuellement d'échapper tout guillemet ou slash arrière (\) avec le même slash arrière. Les valeurs booléenes peuvent prendre les valeurs 'true', 'on' ou 'yes' pour enclencher, et 'false', 'off' ou 'no' pour débrancher.
Toutes les clés sont en minuscules et doient être écrites de cette manière. Mêmes si elles sont laissées vides, il est préférable que toutes les clés soient présentes dans le fichier.
Tout changement dans ce fichier demande le redémarrage du serveur. Pour ce faire, utilisez la commande ctlinnd xexec innd.
Ce fichier permet de déterminer, en fonction des groupes, la méthode de stockage à utiliser. Comme tous les fichiers de INN, il a sa propre page de manuel (man 5 storage.conf).
Les lignes commençant par le symbole cardinal (#) sont des commentaires. Le fichier se décompose en groupes, chacun faisant référence à un type de stockage et à une série de groupes. Un groupe commence par le mot clé 'method' suivi de la méthode utilisée puis d'un bloc délimité par des accolades ({}) qui comprend les paramètres, sous la forme clé deux-points valeur, un par ligne.
Les méthodes sont tradspool, cnfs, timehash, timecaf et trash.
Cette méthode est la plus simple à comprendre et à gérer. Les articles sont stockés dans une hiérarche sur disque qui correspond au newsgroup, dans un fichier du numéro de l'article (des articles crosspostés donnent lieu à des liens en dur sur le disque dans chaque dossier de groupe). L'expiration se fait simplement en examinant l'âge des fichiers sur le disque. Aucun paramètre supplémentaire n'est nécéssaire pour cette méthode.
Le côté positif de cette méthode est sa simplicité, et son ouverture par rapport aux programmes extérieurs qui peuvent lire et analyser facilement le spool.
Le côté négatif vient de la gestion de petits fichiers sur le disque. Non seulement chaque article demande l'overture et la fermeture d'un fichier, mais certains groupes forment des répertoires de plusieurs milliers de fichiers, ce qui peut poser problèmes en fonction du système d'exploitation. D'autres permettent de règler le système de fichiers pour attendre un nombre importants de fichiers par répertoires, ce qui peut être une piste intéressante. Il faut aussi noter que l'administrateur n'a pas de réel contrôle sur l'espace disque utilisé par les groupes.
Cette méthode est extrêmement rapide. Les articles sont stockés dans un nombre limité de grands buffers, par ordre d'arrivée. Les buffers sont de taille fixe, et cycliques. La gestion des buffers (cycbuffs) en eux-même est précisée dans un fichier de configuration cycbuff.conf (man 5 cycbuff.conf). Le paramètre options devrait spécifier le metacycbuff qui contiendra les articles.
Les avantages et inconvénients de cette méthode sont pratiquement les opposés du tradspool : les entrés-sorties sur le disques sont simplifiées au maximum, la taille des fichiers est fixe et connue ; d'un autre côté, les scripts et autres ne peuvent pas lire les articles directement. Il faut noter aussi que l'expiration échappe totalement au contrôle de l'administrateur, ce qui rend le système vulnérable aux attaques par flood notamment.
Cette méthode est un compromis entre les deux précédentes. Elle permet de stocker les articles dans un fichier chacun, donc de les expirer de la même manière qu'en tradspool, mais ces fichiers sont stockés dans des répertoires nommés en fonction du moment d'arrivée du fichier, pour limiter la taille des répertoires.
Au niveau des avantages ou inconvénients, on perd un peu de la lisibilité de tradspool, sans pour autant perdre tout à fait le contrôle sur le spool, tout en obtenant une meilleure gestion des fichiers sur le disque.
Encore un compromis, cette méthode a les mêmes objectifs que la précédente, mais en stockant les articles dans un seul fichier par répertoire.
Clairement, on perd encore un peu plus de flexibilité par rapport aux autres méthodes qui stockent un article par fichier, mais on gagne par contre pas mal de performances (autant au niveau des écritures que de l'expiration).
Comme son nom l'indique, cette méthode met à la poubelle tous les articles entrants.
C'est à l'évidence la méthode la plus rapide. Cet avantage considérable est tempéré par le fait que, hé bien, elle ne stocke rien...
Ce fichier dicte la manière dont les articles présents dans le spool vont être purgés après un certain temps. Les lignes commençant par un cardinal (#) sont des commentaires, et les lignes vides sont ignorées. Il existe deux types de lignes : le paramètre remember et les expirations. A noter que la ligne qui correspond en dernier est choisie, il faut donc mettre les valeurs par défaut en premier.
Une unique ligne au format spécial /remember/:nnn se trouve dans ce fichier. Le nnn représente le nombre de jours qu'un article va rester présent dans la base de données historique du serveur. Il est généralement conseillé de conserver ce paramètre à une valeur supérieure à l'âge maximum des articles acceptés (paramètre c de la ligne de commande, ou artcutoff dans inn.conf), pour ne pas accepter deux fois les mêmes articles.
Ce sont des lignes qui sont composées de champs séparés pas des deux-points. Au début, on trouve un sélecteur de groupe, qui peut avoir deux formats en fonction du paramètre groupbasedexpiry de inn.conf. A la fin, il y a trois champs qui indiquent les temps de rétention. Les champs sont les suivants (dans l'ordre, suivant les deux syntaxes) :
Les trois derniers champs peuvent contenir un nombre de jours (généralement un entier), ou le mot 'never', pour jamais. A noter qu'en l'absence de champ 'Expires' dans un article, seul le deuxième champ est utilisé ; c'est donc de loin le plus important. Ils sont :