Retrouvez cet article dans : Linux Magazine Hors série 21

 

Parmi tous les moyens et méthodes de communication qu’offre le Net, il en est un qui fait se croiser la souplesse du mail avec l’interactivité des forums. Il s’agit des groupes de discussion Usenet. Une fois que vous y aurez pris goût, l’accès vous paraîtra sans doute trop lent ou trop contraignant. Alors pourquoi ne pas dédier une machine pour régler le problème ?

 

Un peu d’histoire

Retour en été 1979. En ce temps-là, une nouvelle version du système Unix venait d’arriver (version 7) et était livrée avec bon nombre d’utilitaires puissants qui existent encore aujourd’hui (awk, sed, bourne shell, etc.). Autre nouveauté, Unix version 7 utilisait le protocole de communication UUCP (Unix to Unix CoPy) permettant de standardiser la communication entre systèmes. Fin 1979, une émulation se forme entre deux utilisateurs d’Unix Version 7. Nous avons d’un coté Tom Truscott et de l’autre Jim Ellis, un étudiant qui vient d’installer un Unix Version 7. Suite à cette installation, quelques programmes ne fonctionnent plus et en particulier celui qui fournissait un service de tableaux d’annonces partagé entre utilisateurs. Une conversation entre Tom Truscott et Jim Ellis et l’idée de créer un réseau mondial d’annonces entre plusieurs ordinateurs jaillit : Netnews venait d’être imaginé. Deux autres étudiants rejoignirent nos compères : Dennis Rockwell et Steve Bellovin. Tous les quatre se mirent d’accord sur le format des fichiers à échanger et l’utilisation du protocole UUCP. Le premier système était un simple script shell qui fonctionnait parfaitement avec 2 ou 3 messages par jours. C’est Steve Daniel rejoignant le groupe qui l’idée de structurer les forums d’annonces en une hiérarchie. A ce moment le réseau d’annonces est composé de trois ordinateurs dont deux sous Unix Version 7. Après une conférence de deux membres du groupe, d’autres utilisateurs et ordinateurs se joignent au réseau : Netnews devient alors Usenet pour Unix uSErs NETwork ou USEr’s NETwork (bien que le premier acronyme soit plus logique). Le réseau devient plus important et il faut récrire le script. Steve Daniel et Tom Trustcott créent alors A-News. Le réseau relie maintenant 8 ordinateurs. Et, par chance, l’une de ces machines, l’ucbvax (University of California at Berkeley), est reliée à Arpanet. C’est ainsi que l’ucbvax devient le point de relais entre Arpanet et les autres machines Usenet. Usenet connaît un succès sans cesse croissant. A plusieurs reprises, le réseau devient instable. Le trafic et le volume de Usenet augmentent et commencent à coûter cher. En 1983, de tous côtés, des administrateurs système dédient des machines au transport des informations Usenet en dépit du coût des communications : le backbone voit le jour. Son objectif est de transférer les données le plus rapidement possible d’un point du backbone à l’autre pour répartir les données moins rapidement. Les administrateurs des machines du backbone acquièrent ainsi un contrôle sur Usenet. Si un utilisateur crée un groupe qui ne plaît pas aux grands maîtres administrateurs, celui-ci ne passe tout simplement pas sur le backbone. En 1986, un nouveau protocole est créé pour Usenet : NNTP. Ce protocole à pour but de standardiser le transport des messages (ou articles) sur le réseau Arpanet qui utilise TCP/IP et non pas UUCP. NNTP est conçu pour les forums Usenet afin d’obtenir une diffusion rapide et moins lourde. C’est toujours ce protocole qui est utilisé pour les forums Usenet de nos jours sur Internet.

Accès à Usenet

Usenet est aujourd’hui le plus gros système décentralisé d’information du monde. En d’autres termes, il forme un réseau de machines interconnectées au travers d’Internet pour former le plus gros système de forum ayant jamais existé. Chaque fournisseur d’accès à Internet possède normalement un lien avec Usenet. Il stocke donc une copie de tous les groupes et de leur contenu. En fonction de leur nom (reflétant leur contenu), le fournisseur d’accès peut refuser de fournir un groupe à ses clients. Ceci peut être fait arbitrairement, en raison de lois propres au pays où vous vous trouvez ou tout simplement pour des questions d’éthique. Dans tous les cas, le fournisseur d’accès précise l’adresse de son serveur Usenet dans sa documentation. Vous pouvez ainsi récupérer les articles et poster les vôtres. Pour cela, vous utilisez un lecteur de News qui accèdera directement au serveur du fournisseur (port 119). Avec un usage intensif des groupes de discussion, on arrive vite à perdre patience et ce, même avec une connexion Internet haut débit. En effet, à chaque lecture d’un article vous devrez le télécharger. Lorsqu’il s’agit de simples articles, cela reste supportable mais avec des images de taille conséquente (comme sur le serveur news.povray.org) chaque lecture est précédée d’un temps d’attente. Pire encore, dans le cas d’un réseau local domestique ou d’entreprise, plusieurs postes accédant aux mêmes articles vont devoir télécharger les informations... une consommation bien inutile de la connexion. Il est bien plus efficace de dédier une machine récupérant les articles des groupes préférés pour une consultation locale.

Principe et logiciels

Un serveur Usenet comme celui de votre fournisseur maintient une copie des articles et des groupes sur une machine locale. Cette même machine permet de procéder à l’opération inverse, c’est-à-dire, répercuter les articles que ses utilisateurs postent sur les autres serveurs Usenet. Installer une machine dédiée à Usenet chez vous revient quasiment au même. Le principe de base est le suivant : Votre machine récupèrera la liste des groupes et les articles des groupes qui vous intéressent. Inutile d’espérer récupérer l’intégralité des articles de tous les groupes si vous ne disposer pas d’un débit digne de celui d’un fournisseur d’accès ou d’une université ainsi que d’un espace disque plus de conséquent. La machine fera office de serveur Usenet local. Par défaut, seules les connexions du localhost sont autorisées. Il faudra une configuration spécifique pour permettre à d’autres machines d’utiliser votre serveur local. Quoi qu’il en soit, votre machine fournira ainsi les groupes et leur contenu sur simple demande, et ce, avec un débit bien plus intéressant qu’un téléchargement ponctuel sur le serveur de votre fournisseur. Votre serveur NNTP local acceptera également les articles que vous posterez. A sa charge ensuite de " remonter " ces articles au serveur de votre fournisseur lors de la récupération des articles. Vous l’aurez compris, afin de faciliter localement la consultation et l’utilisation des groupes de discussion, on concèdera un peu d’interactivité.

 

En effet, votre serveur ne sera pas connecté de manière permanente à celui du fournisseur d’accès mais procèdera à une synchronisation à intervalle régulier. Le contenu des groupes n’est ainsi actualisé qu’un certain nombre de fois par jour (ou par semaine) et vous obtenez un certain décalage temporel. On notera toutefois que l’interactivité n’est pas un élément clef des discussions sur Usenet même si, parfois, on a vraiment envie de répondre très vite ;). Il existe plusieurs solutions permettant de procéder comme décrit plus haut. Parmi les deux plus populaires, nous ne parlerons ici que du duo Leafnode et Fetchnews en oubliant délibérément le couple NNTPCache et INN. Comme avec bien des applications libres, il existe des utilisateurs défendant l’une et l’autre solution logicielle. Nous nous limitons ici à Leafnode pour plusieurs raisons dont le fait qu’il soit légèrement plus populaire et que le projet semble encore pleinement actif. Nous pouvons ajouter à cela que Leafnode est spécialement conçu pour les petits sites.

Installation

La distribution de référence ici est une Debian Sarge. Il s’agit d’un choix délibéré car pour un système " serveur ", cette distribution s’avère à la fois légère et administrable facilement. Bien sûr, d’autres distributions pourront être utilisées selon vos préférences et les explications devraient être relativement faciles à adapter. D’un point de vue matériel, la configuration peut être très petite. Selon le nombre de groupes et l’activité de ceux-ci, c’est en particulier au niveau de l’espace disque qu’il faudra être attentif. En effet, les articles sont massivement stockés sur le système de fichiers, mais le reste de la solution n’est pas très gourmande en termes de processeur ou de mémoire. Un simple Pentium ou compatible avec 16 ou 32Mo de mémoire devrait faire l’affaire. On préfèrera cependant un Pentium II et 64 ou 128 Mo de mémoire pour un plus grand confort d’utilisation et de maintenance du système. Les articles Usenet n’étant pas exempts de virus, spyware, bombes logiques et autres scripts fort nuisibles, il pourra être intéressant d’ajouter un système anti-virus comme ClamAV pour protéger d’éventuels postes Windows. L’installation de Leafnode est très simple puisqu’un simple apt-get install leafnode (ou son équivalent avec urpmi) fera l’affaire. Le système de configuration Debian (DebConf) prend en charge le paramétrage du système. Ainsi, plusieurs questions vous seront posées vous permettant de définir le serveur Usenet de votre fournisseur d’accès, etc. Notez qu’il existe des serveurs Usenet libres d’utilisation si celui de votre FAI ne vous satisfait pas. Vous pouvez également décider d’utiliser plusieurs serveurs simultanément. Cependant, dans ce cas précis, vous devrez vous passer des services de DebConf et modifier le fichier de configuration de Leafnode manuellement. On vous conseillera l’excellent Zoo-Logique (http://www.zoo-logique.org) contenant des groupes uniques (comme 3D.Pov-Ray). Enfin, signalons que certains serveurs demandent une authentification (Zoo-Logique par exemple) qui est parfaitement supportée par Fetchnews (l’élément récupérateur de Leafnode). D’autres serveurs Usenet de certains FAI n’autorisent que leurs clients via une petite astuce se basant sur la résolution de noms. En cas de problème d’accès, jeter donc un coup d’œil à votre /etc/resolv.conf et assurez-vous de la bonne configuration des DNS de votre fournisseur. Durant le processus d’installation/configuration du paquet, une question sur la " relève " des articles vous sera posée. Soit vous pouvez laisser le système s’en occuper automatiquement, soit vous le prenez en charge manuellement ou depuis une entrée personnalisée dans la crontab. Nous vous conseillons d’opter pour la seconde solution, car vous pourrez alors facilement adapter la fréquence des " relèves " en fonction de vos besoins et de la masse d’articles à télécharger. A ce stade de la configuration, vous pouvez lancer manuellement un fetchnews -vv qui provoquera la récupération de la liste des groupes disponibles sur le serveur distant. Cette opération est plus ou moins longue en fonction du nombre de groupes disponibles et de votre vitesse de connexion. Par la suite, nous n’aurons plus à passer par cette étape et nous synchroniserons simplement l’apparition et la disparition des groupes durant la récupération des articles. L’option -vv nous permet de rendre fetchnews plus bavard et ainsi de suivre la progression des opérations.

Interlude " sécurité "

Avant de poursuivre, nous allons traiter de la sécurité de la configuration. Le serveur Leafnode est normalement lancé par le super démon inetd lors d’une tentative de connexion au port 119. Dans un premier temps, on préfèrera xinetd au classique inetd. Offrant plus de finesse dans la configuration, il permettra de se protéger, par exemple, contre une éventuelle attaque de type DOS (Deny Of Service). Le serveur Leafnode est exécuté par le super démon via tcpd permettant ainsi d’autoriser ou non certaines connexions en fonction de la machine cliente. Par défaut avec Debian Sarge, tcpd est configuré de manière à n’autoriser les connexions à Leafnode que depuis le localhost (127.0.0.1). Si vous tentez, avec la configuration par défaut de vous connecter au port 119, tcpd vous coupera la route. Vérifiez donc les fichiers /etc/hosts.allow et /etc/hosts.deny contenant respectivement, à l’origine, les lignes leafnode: 127.0.0.1 et leafnode: ALL. On préfèrera, dans le cas d’un serveur local remplacer la ligne du /etc/hosts.deny par leafnode: ALL EXCEPT 192.168.0.0/24 autorisant ainsi les connexions depuis tout le réseau 192.168.0.0. Si vous optez pour xinetd, vous pouvez ajouter une couche permettant de vous prémunir encore d’avantage. Voici un exemple de fichier /etc/xinetd.d/nntp :

 

On retrouve des paramètres classiques pour xinetd et les éléments également présents dans le /etc/inetd.conf. On remarquera cependant les deux dernières lignes. La première permet de limiter le nombre d’instances de /usr/sbin/leafnode à lancer. La seconde permet de limiter les connexions depuis un hôte unique. Ces deux lignes offrent une protection minimale contre une attaque par dénis de service visant à surcharger votre serveur. Il est également possible, dans cette configuration de contrôler et de réguler l’accès en fonction de la source de la connexion. La directive only_from permettra ainsi de faire quelque chose d’équivalent à ce que propose tcpd dont nous parlons plus haut. Leafnode lui-même permet de gérer la provenance des connexions. Par défaut, seules les connexions dites " locales " sont autorisées. C’est l’adresse IP et le masque de sous-réseau qui seront utilisés pour déterminer si une connexion est locale ou distante. Si vous souhaitez ouvrir votre serveur à un réseau public (Internet), il vous faudra modifier le fichier de configuration de Leafnode. Vous décommenterez alors la ligne allowstrangers = 0 et la changerez en allowSTRANGERS = 42. La manipulation est délibérément " tordue " pour bien vous faire comprendre le risque qui en découle. Avant de faire une telle chose, assurez-vous de protéger le service via xinetd, tcpd ou encore Netfilter. Enfin, si vous tenez à ouvrir un accès à un poste client distant unique (avec un UNIX), la meilleure solution sera de ne pas toucher à la configuration de Leafnode et d’utiliser un tunnel SSH : Cette simple commande vous permet de vous connecter au serveur (192.168.0.68) tout en créant un tunnel entre le port 9119 de la machine cliente et le 119 du serveur. Le client n’aura alors qu’à configurer son lecteur Usenet de manière à accéder au serveur 127.0.0.1 sur le port 9119 et toutes les requêtes transiteront par le tunnel SSH. Bien sûr, il faudra recréer le tunnel à chaque connexion au serveur Leafnode.

Mise en œuvre et réglages

Maintenant que votre serveur est plus sûr et que vous avez procédé à la récupération de la liste des groupes, il ne vous reste plus qu’à vous connecter au serveur Leafnode avec un client Usenet. La connexion se fait exactement de la même manière qu’avec un serveur Usenet public. La seule différence provient du fait que votre FAI maintient la totalité des groupes à jour alors que cela ne vous est pas possible (du moins, pas raisonnablement). Ainsi lorsque, dans votre client Usenet, vous allez vous abonner pour la première fois à un groupe, le seul message que celui-ci contiendra sera un article du serveur Leafnode ayant pour sujet " Leafnode placeholder for group... ". Il s’agit d’un " article balise " qu’il vous faudra lire pour que Leafnode sache que ce groupe vous intéresse. Ainsi, lors de la prochaine synchronisation par Fetchnews, les articles les plus récents de ce groupe seront téléchargés depuis le serveur de votre FAI. Ce premier téléchargement d’articles apparaît clairement dans les informations affichées par la commande fetchnews –vv : La mention skipping articles nous apprend que tous les articles ne seront pas téléchargés mais uniquement ceux dans la plage précisée sur la seconde ligne (57660 à 57959). Vous l’aurez compris, les articles sont référencés par un numéro. C’est ce référencement qui permet de déterminer, à chaque synchronisation, la masse d’articles à récupérer sur le serveur. Le volume d’article à récupérer lors de la première synchronisation d’un groupe est déterminé par une directive particulière dans le fichier de configuration /etc/news/leafnode/config : C’est là l’un des rares paramètres à personnaliser en fonction de votre configuration. Voici, en guise d’exemple le contenu d’un fichier de configuration de Leafnode : Comme vous pouvez le voir, la configuration n’est pas très lourde. Deux directives sont obligatoires : expire qui détermine le nombre de jours après lesquels un article lu est effacé et server qui permet de renseigner sur le serveur Usenet à utiliser. Il est possible de définir plusieurs occurrences de cette directive afin d’utiliser plusieurs serveurs. Chaque occurrence de server débute une nouvelle configuration se basant sur les valeurs par défaut. Nous avons, dans cet exemple, trois serveurs Usenet utilisés. La directive initialfetch permet de définir le nombre d’articles à récupérer pour un nouvel abonnement à un groupe. Par défaut, en l’absence d’initialfetch, Fetchnews tentera de récupérer tous les articles disponibles (en fonction du serveur accédé, le nombre d’article est alors très très important). Nous sommes ainsi obligés de spécifier trois fois une valeur pour initialfetch car en l’absence de la directive pour le serveur news.wanadoo.fr, Fetchnews récupèrerait tous les articles et non 300 comme on pourrait le croire. Mieux vaut prendre en compte cette donné le plus tôt possible. Les articles de certains groupes peuvent inclure des pièces jointes de grande taille. On en arrive rapidement, sans contrôle préalable, à saturer le système de fichiers. Avant de vous lancer dans l’inscription en masse, évaluez le nombre de messages, leur taille moyenne et l’activité du groupe. Le dernier groupe de lignes utilise deux directives supplémentaires, username et password permettant, comme vous vous en doutez, de spécifier un nom d’utilisateur et un mot de passe pour les serveurs nécessitant une authentification. Il existe encore d’autres directives moins intéressantes et/ou utiles. On notera cependant, maxfetch qui s’avèrera important avec des systèmes utilisant un faible débit Internet. Cette directive permet de spécifier le nombre d’articles à télécharger en une seule fois. Ainsi, si quelques 7000 articles sont disponibles, Fetchnews ne tentera pas de les récupérer en une seule connexion en saturant l’accès Internet mais procèdera en plusieurs téléchargements successifs. Une fois votre configuration adaptée à vos besoins, vous pourrez procéder à quelques essais en lançant manuellement Fetchnews. Si tout se passe comme prévu, vous pourrez ajouter une entrée dans votre crontab en fonction de la fréquence de synchronisation souhaitée. On notera qu’en cas de conflit (lancement d’un Fetchnews alors qu’un autre est encore actif), le système saura gérer la situation et ne provoquera pas de perturbation ou de perte de données.

Inscription et désinscription

Nous venons de le voir, c’est la consultation d’un article fictif initial qui provoquera la récupération en masse des articles d’un groupe. Au bout du nombre de jours spécifié par la directive expire, le programme Texpire supprimera du serveur les articles considérés comme obsolètes. Ce système permet de garder une masse contrôlable d’articles stockés sur notre serveur. Texpire est lancé en même temps que Fetchnews et, normalement, en moyenne, les articles expirants sont remplacés par les nouveaux. La désinscription à un groupe est un peu plus délicate. Vos clients Usenet et Leafnode communiquent via le protocole NNTP. Celui-ci n’inclut pas de fonctionnalité permettant au client de spécifier l’inscription et la désinscription aux groupes. Il ne s’agit que de téléchargement. C’est donc la consultation des groupes (et non des articles) qui permet de justifier le maintien du téléchargement par Fetchnews. Lorsque plus aucun client n’accède à un groupe au-delà d’un délai par défaut de 7 jours, celui-ci est considéré comme inintéressant et n’est plus synchronisé. On pourra changer cette valeur par défaut en renseignant la directive timeout_long dans le fichier de configuration. Ainsi, comme vous le constatez, tout se fait de manière quasi automatique. Il est cependant possible, en cas de besoin (manque d’espace disque) de forcer l’expiration d’articles. En utilisant la commande texpire –fvv, vous pouvez " expirer " les articles sans vérifier s’ils ont été lus ou non. Ceci permet d’éliminer les vieux articles un peu plus tôt et ainsi, de gagner un peu de place. Selon le même objectif, si un groupe n’est plus consulté et que le délai de 7 jours (ou la valeur de timeout_long) n’est pas acceptable, il est possible de forcer l’expiration d’un groupe. Pour cela, après désinscription du ou des clients Usenet, il suffit de supprimer le fichier portant le nom du groupe dans /var/spool/news/interesting.groups/. Fetchnews arrêtera de récupérer les articles pour ce groupe et les articles déjà présents sur le disque vont expirer. Il faut bien comprendre que Leafnode n’est pas destiné à servir de véritable serveur Usenet. Il est conçu, à l’origine, pour maintenir localement à jour une petite quantité d’articles pour une grande quantité de groupes.

Conclusion

Avant de conclure, signalons que Leafnode ne sert pas seulement à récupérer le contenu des groupes, mais fait également l’interface pour l’envoi de vos articles. Ceux-ci, envoyés à Leafnode sont placés dans une file d’attente et sont expédiés lors de la synchronisation. Il reste beaucoup à dire sur ce système car la personnalisation permet d’obtenir une solution véritablement élégante. Il est ainsi possible d’archiver des articles pour les groupes que l’on aime ou encore de jouer sur quasiment tous les paramètres de synchronisation/récupération. Nous dirons que ceci vous est laissé en guise d’exercice afin de bien prendre en main le logiciel. Enfin, on notera que Leafnode n’est pas sous licence GNU GPL. Il s’agit, bien sûr d’un Logiciel libre mais les responsables n’aiment pas la philosophe de la FSF. La licence de Leafnode est ainsi beaucoup plus permissive que la GPL (absence de Copyleft) car, comme cela est dit dans la FAQ : " la liberté inclut aussi la liberté de ne pas être d’accord avec moi et de pouvoir, tout de même, utiliser mon logiciel ".

Retrouvez cet article dans : Linux Magazine Hors série 21