Installer et configurer un serveur de nouvelles INN2

Préambule

Cette page a pour but d’expliquer les processus d’installation et de configuration d’un serveur de nouvelles INN 2.7 sur un système Linux.

N’hésitez pas à remonter toute erreur ou incompréhension sur fr.comp.usenet.serveurs ou news.software.nntp si vous ne maîtrisez pas la langue de Molière.

Si certaines parties de ces explications vous semblent peu claires ou douteuses, préférez vous référer à la page de la documentation officielle du serveur de nouvelles INN (en anglais) dont la présente page s’est largement inspirée.

Cette page suppose que vous disposez d’un accès complet (root) à un ordinateur connecté à Internet et équipé d’un système d’exploitation Linux à jour. Notez toutefois que la plupart des commandes sont à exécuter sous l’utilisateur news.

Cette page vous expliquera comment installer un serveur INN utilisant un système de stockage principal tradspool auquel sera adjoint un tampon CNFS, utilisant innfeed comme vecteur d’échange entre serveurs et ayant pour systèmes de filtrage Cleanfeed et NoCeM.

Pour des raisons de clarté, les configurations des autres méthodes de stockage, de distribution ou de filtrage ne seront pas traitées ici. En effet, INN2 est tellement souple qu’un débutant devra se limiter dans les potentialités de ce programme un peu trop riche en fonctionnalités !

Cette page est le fruit d’un travail collectif, Doug Le Tough en a écrit une très grande partie, Marc Schaefer a continué, Julien Élie a expliqué les arcances d’INN2 et j’ai (yamo’) participé à toutes les étapes.

Actuellement la version de référence est hébergée par Doug Le Tough et il existe deux miroirs, un hébergé chez DV et le dernier sur pasdenom.info.

Conventions

Les commandes à exécuter sont précédées du symbole $ lui même précédé du nom de l’utilisateur concerné. Lorsque l’utilisateur root est nécessaire, le prompt se terminera par #.

Exemple :

root# cp /mon/fichier /mon/nouveau/fichier

est une commande à exécuter en tant qu’administrateur (utilisateur root).

news ~$ cp /mon/fichier /mon/nouveau/fichier

est une commande à exécuter en tant qu’utilisateur news.

Le symbole $ ou # et tout ce qui le précède ne fait pas partie de la commande et ne doit pas être saisi.

Mise à jour du système

La mise à jour d’un système est toujours une opération sensible. Avant d’exécuter les deux commandes suivantes, assurez-vous de la nécessité de cette action. Il est toutefois recommandé de planifier des mises à jour régulières ou lors d’annonces de sécurité de la distribution.

root# apt-get update && apt-get -u dist-upgrade

Lisez bien les messages d’erreur si tout à coup la mise à jour n’avait pas fonctionné.

Installation d’INN

Sur Debian, le gestionnaire de paquet facilite l’installation d’INN2 et la gestion des fichiers de configuration (il reste toutefois recommandé de sauvegarder les versions fonctionnelles comme référence ou pour utiliser la commande diff – ou carrément mettre l’ensemble du répertoire de configuration sous GIT) mais d’autres systèmes ont aussi leurs gestionnaires de paquets qu’il faudra privilégier pour installer INN2.

Pour ce faire, exécuter la commande suivante :

root#  apt-get install inn2

Attention à bien installer le paquet inn2 et non pas le paquet inn qui est également proposé par Debian mais dont la configuration est bien différente.

D’autres paquets comme inn2-lfs, inn2-dev ne sont pas non plus nécessaires.

Toutefois, une collection de dépendances peut accompagner l’installation d’INN. Contentez-vous d’acquiescer à l’installation de ces dernières.

Voilà, c’est fait !

Configuration d’INN

INN se configure à l’aide de plusieurs fichiers de configuration jouant chacun un rôle bien précis allant de la configuration de la réception à celle du filtrage des articles en passant par celle de leur stockage sans oublier leur distribution.

Malgré l’apparente complexité et l’enchevêtrement de ces fichiers, le système reste tout à fait accessible à celui qui s’en donne la peine.

Une liste des fichiers de configuration est disponible sur la page de la documentation officielle.

Sur un système Linux les fichiers de configuration sont stockés dans le répertoire /etc/news/ et vous retrouverez facilement les chemins d’accès au différents type de fichiers dans le fichier de configuration principal d’INN pathetc/inn.conf. Veuillez quand-même vérifier si c’est le cas pour votre système.

Exécutez la commande suivante pour visualiser la liste de ces différents chemins d’accès :

root#  grep path /etc/news/inn.conf | grep -v \#

Vraisemblablement, vous devriez obtenir une liste ressemblant à celle-ci :

Variable Valeur
pathhost server.example.net
pathnews /usr/lib/news
patharchive /var/spool/news/archive
patharticles /var/spool/news/articles
pathbin /usr/lib/news/bin
pathcontrol /usr/lib/news/bin/control
pathdb /var/lib/news
pathetc /etc/news
pathfilter /etc/news/filter
pathhttp /var/www/inn
pathincoming /var/spool/news/incoming
pathlog /var/log/news
pathoutgoing /var/spool/news/outgoing
pathoverview /var/spool/news/overview
pathrun /run/news
pathspool /var/spool/news
pathtmp /var/spool/news/incoming/tmp

Sans être exhaustif, il vous faut savoir que le chemin vers les fichiers de configuration est défini par la variable pathetc, que celui vers le répertoires de stockage des articles par pathspool, celui vers les bases de données par pathdb, celui des filtres par pathfilter et que celui vers les sous-programmes du serveur par pathbin.

Pas de panique, toutes ces notions seront expliquées au fur et à mesure des besoins de la configuration.

Cependant, afin d’éviter toute confusion, les noms des fichiers de configuration seront précédés de celui de leur répertoire.

Exemple :

La notation pathetc/incoming.conf signifie /etc/news/incoming.conf.

N’hésitez pas à vous reporter à la liste des chemins de temps à autre pour vous assurer que vous éditez le bon fichier.

Par ailleurs, chacun des fichiers de configuration d’INN possède sa page de manuel dans laquelle vous trouverez une explication et bien souvent un exemple de l’utilisation de chacun des paramètres.

Ainsi, la commande suivante affichera la page de manuel du fichier de configuration pathetc/cycbuff.conf :

~$ man cycbuff.conf

Remarque : dans la liste donnée par la commande grep, vous aurez peut-être aussi tlscapath qui sert pour configurer le NNTPS. Ceci n’est pas encore évoqué dans cette documentation.

Syntaxe des motifs wildmat

La plupart des fichiers de configuration d’INN utilisent des expressions permettant de retrouver facilement des motifs dans des chaînes de caractères. Ces motifs sont comparables à ceux que l’on trouve généralement dans les shells des systèmes UNIX tels que Bash.

Dans la plupart des cas, ces motifs wildmat peuvent être mis en forme de liste dont les éléments sont séparés par une virgule. De cette manière, chaque motif composant cette liste est vérifié un par un et le dernier motif correspondant est alors utilisé (last win).

Ce principe est particulièrement utile pour appliquer un traitement à certains groupes de discussion tout en excluant certains autres de ce traitement.

Les principaux symboles sont :

Symbole Signification
* tous
! aucun
@ et aucun

Exemple :

*,!comp.*,comp.os.*

permettra de toucher tous les groupes (*) sauf ceux de comp.* (!comp.*) hormis s’ils sont situés dans la branche comp.os.* (comp.os.*).

Toutefois, il faut bien comprendre que seul le dernier motif applicable sera pris en considération (ici, comp.os.*).

Ainsi, dans notre exemple, les groupes situés dans d’autres branches (sci, talk, soc, …) ne seront pas non plus touchés par cette expression bien qu’ils correspondent au premier motif (*).

Dans le cas d’une publication croisée entre un groupe de discussion situé dans comp.os et un groupe situé dans comp.bugs, le traitement associé à ce motif sera applicable car au moins un des groupes y correspond.

Le symbole @ (poison) est particulier et employé sur un nom de groupe seul il aura le même effet que le symbole !.

Quand il est employé sur une liste de groupes (cas des publications croisées), il permettra d’éviter que le traitement soit applicable y compris si un des groupes correspond au motif.

Exemple :

misc.*,!misc.bar

Si un article est publié à la fois sur misc.foo et sur misc.bar, le traitement associé à cette règle sera appliqué à cet article car l’un des groupes de destination de cet article correspond à ce motif.

misc.*,@misc.bar

Si un article est publié à la fois sur misc.foo et sur misc.bar, le traitement associé à cette règle ne sera pas appliqué à cet article car un des groupes de destination est exclu par ce motif (@misc.bar). De la même manière un article publié sur misc.bar seul sera également exclu du traitement.

Le fichier inn.conf

Le fichier principal de configuration d’INN est pathetc/inn.conf. Ce fichier contient quelques dizaines de paramètres mais la plupart d’entre eux ayant déjà une valeur par défaut satisfaisante, nous ne parlerons ici que des paramètres nécessaires à la configuration basique.

allownewnews

Accepte une valeur booléenne (true, 1 ou encore on pour une valeur positionnée à vrai et false, 0 ou encore off pour une valeur positionnée à faux).

Sa valeur par défaut est true et permet à INN d’accepter les demandes de lecture de nouvelles faites par certains logiciels de lecture de nouvelles ne récupérant les articles que par leur identifiant unique (et non pas par leur numéro).

Cette valeur pourra également être outrepassée par le paramétrage du paramètre access situé dans le fichier pathetc/readers.conf (voir plus bas).

Si vous souhaitez que des utilisateurs puissent envoyer des articles depuis votre serveur (le contraire serait étonnant), laissez la valeur par défaut (true).

complaints

Accepte une chaîne de caractères qui sera utilisée pour renseigner le champ Injection-Info des entêtes de chaque article publié depuis votre serveur. Une valeur typique est une adresse de courriel du type abuse@example.com.

hiscachesize

Ce paramètre permet de définir la taille du cache des fichiers d’historique (fichiers history). Le cache des historiques permet d’augmenter significativement les performances de votre serveur. Une valeur telle que 256 (valeur par défaut), exprimée en kilo-octets, est un bon choix.

logipaddr

Accepte une valeur booléenne et permet de définir si l’adresse IP (ou le nom qualifié s’il est renseigné dans le fichier pathetc/incoming.conf) de l’hôte distant depuis lequel vous recevez des articles à publier. Dans notre contexte, cette valeur doit être laissée à true.

organization

Accepte une chaîne de caractères qui servira à renseigner le champ Organization des entêtes des articles publiés depuis votre serveur dont ce champ ne serait pas déjà renseigné par son expéditeur. Ce champ est totalement libre.

pathhost

Accepte une chaîne de caractères qui sera utilisée dans le champ Path des entêtes de tous les articles transitant par ou publiés depuis votre serveur. Il est très vivement conseillé d’y mettre le nom de domaine complètement qualifié (FQDN) de votre serveur.

domain

Accepte une chaîne de caractères, vous pouvez y mettre votre nom de domaine.

Vous pouvez laisser les autres paramètres tels qu’ils vous sont fournis par le fichier par défaut.

Le fichier newsfeeds

pathetc/newsfeeds est le fichier grâce auquel vous configurerez la manière dont seront distribués aux autres serveurs les fichiers qui vous sont envoyés.

Ce fichier est organisé comme une série de feeds (les connexions entre serveurs). Chacun de ces feeds est composé de 4 paramètres séparés par le symbole de ponctuation deux-points (:). Vous pouvez écrire un feed sur plusieurs lignes à condition de le stipuler par un symbole \ qui indiquera que la ligne suivante est une continuation de la ligne en cours.

Le premier des 4 paramètres d’un feed est son nom.

Il se doit d’être unique et, afin de faciliter la maintenance de votre configuration, il vous est conseillé de le faire correspondre au nom d’hôte du serveur distant correspondant. Ce nom peut optionnellement être suivi d’un symbole / précédant une liste d’exclusion.

De cette manière si le nom du feed ou l’un des noms contenus dans cette liste d’exclusion se trouve dans le path d’un article, cet article ne sera pas envoyé à l’hôte distant puisque logiquement considéré comme étant déjà passé par ce serveur. Cette liste d’exclusion est particulièrement pratique lorsque un serveur indique un nom différent de son nom de domaine dans le champ Path des articles qu’il envoie (voir le paramètre pathhost dans le fichier de configuration pathetc/inn.conf).

Le second de ces 4 paramètres est la définition des groupes qui seront envoyés au serveur pair.

Ce paramètre prend la forme d’un motif utilisant la syntaxe des motifs wildmat. Ce paramètre peut occasionnellement être accompagné d’une liste de distribution mais ce point ne sera pas évoqué ici et bien que ces listes de distribution soient peu utilisées, si vous désirez en savoir plus, veuillez vous référer à la page de manuel de newsfeeds (man newsfeeds).

Le troisième paramètre est une liste de drapeaux

Ces drapeaux séparés par des virgules définissant le type de feed dont il s’agit ainsi qu’un certain nombre d’autres drapeaux dont la valeur et le nombre dépendent du type de feed concerné. Il serait trop long d’expliquer l’ensemble de ces drapeaux et leurs combinaisons. Le but de ce tutoriel étant de vous aider à monter rapidement un serveur de nouvelles, seul les drapeaux nécessaires à la configuration de base seront détaillés. Pour plus d’information sur ces drapeaux, veuillez vous référer à la page du manuel de newsfeed (man newsfeed).

Le quatrième paramètre est à usage multiple

Son usage dépend du type de drapeaux défini par le troisième paramètre. Pour un feed de type fichier (drapeau Tf), il s’agira du nom du fichier dans lequel écrire. Pour un feed de type funnel (drapeau Tm), il s’agira du nom du funnel (cette notion est expliquée plus bas) à emprunter. Pour un feed de type canal (drapeau Tc), il s’agira du nom du programme à exécuter ainsi que la référence des articles à traiter.

Passons maintenant au fichier lui-même.

L’entrée ME est une entrée spéciale et nécessaire dont l’utilité est double. C’est grâce à elle que vous déciderez la liste des groupes à distribuer et quels groupes vous acceptez de recevoir.

ME:!*/!local,!collabra-internal::

Les valeurs par défaut de l’entrée ME sont suffisantes pour commencer.

Il nous faut maintenant définir un feed de sortie. Nous considérerons que le serveur loin.ailleurs.com est disposé à recevoir nos messages et que nous les enverrons par le biais d’un funnel.

Ainsi son entrée devient :

loin.ailleurs.com\
    :*,!junk,@control,@control.*\
    :Tm:innfeed!

Dans cet exemple, le feed loin.ailleurs.com est de type funnel (drapeau Tm) et se chargera de fournir tous les groupes disponibles sur le serveur à l’exception des hiérarchies junk (la poubelle) et control à un autre feed nommé innfeed!.

Vous pouvez définir autant de feeds de ce type que vous avez de serveurs pairs et définir pour chacun d’eux les groupes que vous avez envie ou non de leur distribuer.

Nous devons maintenant définir innfeed!.

Pour ce faire, enlevez les symboles # en tête des lignes suivantes :

innfeed!\
    :!*\
    :Tc,Wnm*:/usr/lib/news/bin/innfeed

Ce feed est de type canal (drapeau Tc) et utilisera le programme /usr/lib/news/bin/innfeed à qui sera passé en argument l’identifiant de chaque article (drapeau n) ainsi que le jeton de l’API de stockage (drapeau m).

Théoriquement, le programme /usr/lib/news/bin/innfeed devrait correspondre à pathbin/innfeed et l’utiliser permet de distribuer un article immédiatement après qu’il a été accepté par votre serveur. innfeed accepte un certain nombre de paramètres qui ne seront pas détaillés ici (man innfeed pour plus d’information).

D’autres moyens de distribution existent. Veuillez vous référer à la page de manuel de newsfeeds pour plus de détails (man newsfeeds).

Enfin, à moins que vous ne vouliez honorer aucun message de contrôle, vous devez impérativement avoir une entrée controlchan! qui les traitera spécifiquement.

controlchan!\
    :!*,control,control.*,!control.cancel\
    :AC,Tc,Wnsm:/usr/lib/news/bin/controlchan

Le fichier innfeed.conf

Le fichier pathetc/innfeed.conf vous permettra de configurer innfeed pour chacun des peers que vous venez de définir dans pathetc/newsfeeds.

Typiquement les valeurs globales situées en début de fichier ont des valeurs par défaut largement suffisantes, vous pouvez néanmoins adapter les valeurs de certaines d’entre elles, notamment celles concernant les fichiers de log (log-file), la génération d’un fichier de log en HTML (gen-html et status-file)

Ensuite il vous faudra définir un par un l’ensemble des serveurs distants vers lesquels vous souhaitez distribuer les articles que vous recevez. Pour chacun d’entre eux vous pouvez redéfinir chacun des paramètres globaux.

Pour un serveur loin.ailleurs.com dont l’accès se fait par le port TCP/443 et qui n’autorise au maximum 2 connexions, ajoutez le bloc suivant à la fin du fichier:

peer loin.ailleurs.com {
    ip-name: loin.ailleurs.com
    port-number: 443
    max-connections: 2
    streaming: true 
}

Dans cet exemple nous paramétrons innfeed pour qu’il envoie en mode stream les articles qu’il reçoit sur le port TCP/443 du serveur distant loin.ailleurs.com (et uniquement lui) en ne sollicitant que 2 connexions.

Vous pouvez créer autant de peers dont vous avez besoin et, comme toujours, man innfeed.conf pour plus d’information ;-) À chaque modification, il est conseillé de vérifier avec inncheck si c’est correct. Si le serveur est déjà fonctionnel, l’application des modifications se fait avec la commande suivante :

news ~$ ctlinnd reload newsfeeds 'message pour les logs'

Le fichier incoming.conf

C’est dans le fichier pathetc/incoming.conf que vous définirez les serveurs autorisés à alimenter votre serveur et pour chacun d’eux la liste des groupes qu’ils sont autorisés à vous fournir.

peer loin.ailleurs.com {
    patterns: "*,@local.*"
    hostname: "loin.ailleurs.com, news.ailleurs.com"
}

Dans cet exemple nous autorisons le serveur loin.ailleurs.com ainsi que le serveur news.ailleurs.com à nous envoyer leurs articles dont seuls les articles qui n’auront pas fait l’objet d’une publication croisée avec l’un des groupes de la hiérarchie local.* seront acceptés.

Notez bien que cette restriction ne diminuera en rien le débit utilisé par votre serveur qui vous enverra malgré tous les articles que vous ne voulez pas recevoir, votre serveur se contentant de refuser de les enregistrer sur le disque.

Vous pouvez créer autant de peers que vous en avez besoin ou même créer des groupes de peers (man incoming.conf pour plus d’information).

Laissez les autres paramètres (streaming et max-connections) à leur valeur par défaut.

Afin d’éviter tous problèmes il est vivement conseillé de ne PAS mettre d’espace entre les différents motifs wildmat du champ patterns.

Le fichier cycbuff.conf

Une partie des articles de votre serveur sera stockée dans un fichier particulier dont la traduction approximative pourrait être tampon cyclique (cycbuff).

L’intérêt de ces tampons cycliques réside dans le fait qu’ils occupent un espace disque fixe. Ainsi les articles qui y sont stockés ne le sont que jusqu’à ce que le tampon soit plein auquel cas les premiers articles sont écrasés par les nouveaux (FIFO).

Nous utiliserons donc un tampon cyclique pour l’ensemble des articles envoyés au groupe fr.test et nous le placerons dans pathspool/cycbuff et sa taille sera de 500 méga-octets.

Commencez par créer le répertoire pathspool/cycbuff

root# mkdir /var/spool/news/cycbuff

Assurons-nous maintenant que l’utilisateur news pourra bien écrire dans ce répertoire.

root# chown -R news:news /var/spool/news/cycbuff
root# chmod -R 775 /var/spool/news/cycbuff

Déclarez ensuite le tampon cyclique dans le fichier pathetc/cycbuff.conf.

cycbuff:TEST:/var/spool/news/cycbuff/test:512000

Ici nous déclarons un tampon cyclique nommé TEST dont le fichier est /var/spool/news/cycbuff/test et dont la taille est 500 Mo (512000).

Nous avons également besoin d’un méta-tampon (que nous appellerons M_TEST) vers lequel nous dirigerons les articles qui sont destinés à aller dans le tampon cyclique TEST.

metacycbuff:M_TEST:TEST

Bien que ce ne soit pas le cas ici, un méta-tampon peut utiliser plusieurs tampons cycliques. Par ailleurs, la longueur du nom d’un méta-tampon (ici, M_TEST) ne doit pas excéder huit caractères. Pour en savoir plus à ce sujet, consultez la page de manuel de cycbuff.conf (man cycbuff.conf).

Pour finir, ajoutez un symbole # en tête des lignes suivantes :

#cycbuff:ONE:/export/cycbuffs/one:512000
#cycbuff:TWO:/export/cycbuffs/two:512000
#cycbuff:THREE:/export/cycbuffs/three:512000
#metacycbuff:BIG:ONE,TWO:SEQUENTIAL
#metacycbuff:SMALL:THREE

Le fichier storage.conf

Le fichier storage.conf permet de définir la manière dont seront stockés les articles que recevra le serveur.

Il existe plusieurs méthodes pour ce faire mais nous n’en utiliserons que deux:

CNFS qui correspond au type tampon cyclique que nous avons défini dans cycbuff.conf.

tradspool qui permet de stocker chaque article dans un fichier individuel, lui même stocké dans une arborescence de dossiers telle qu’on en trouve dans un système de fichiers traditionnel.

Pour qu’un article soit accepté par le serveur, il doit impérativement rentrer dans l’une des classes de stockage qui seront définies dans storage.conf. Si l’article ne correspond à aucune classe de stockage, il sera rejeté indépendamment des autres paramètres situés dans les autres fichiers de configuration.

Une classe de stockage est définie par sept paramètres dont certains sont optionnels.

Commençons par créer la classe de stockage de type tradspool vers laquelle nous allons rediriger tous les articles qui ne sont pas publiés dans le groupe de discussions fr.test.

method tradspool {
    newsgroups: *,!fr.test
    class: 0
}

Comme vous le voyez, cette classe de stockage est essentiellement définie par : - Son type (ici tradspool) - La liste des groupes qu’elle accepte. - Le paramètre class qui spécifie son numéro d’identifiant qui se doit d’être unique et compris en 0 et 255.

Nous avons maintenant besoin de déclarer la classe de stockage vers laquelle nous allons rediriger les articles publiés dans le groupe de discussions fr.test.

method cnfs {
    newsgroups: fr.test
    class: 1
    options: M_TEST
}

Rappelez-vous que nous avons décidé de stocker les articles à destination de fr.test dans un tampon cyclique et que nous avons déclaré ce dernier dans le fichier pathetc/cycbuff.conf.

La classe de stockage correspondante sera donc de type cnfs et, de ce fait, réclame une indication du méta-tampon qui devra être utilisé (options: M_TEST).

Vous trouverez dans la page de manuel de storage.conf des explications détaillées qui vous permettront d’affiner les paramètres en fonction de vos souhaits (man storage.conf).

Le fichier expire.ctl

Vous définirez dans le fichier pathetc/expire.ctl les différentes politiques d’expiration des articles.

Les classes de stockage de type cnfs n’ont, a priori, pas besoin d’une politique d’expiration puisque lorsque le tampon cyclique qui leur est associé est plein, celui-ci continue malgré tout de se remplir en écrasant les articles les plus anciens.

Cependant, vous pouvez malgré tout faire expirer des articles contenus dans un tampon cyclique avant que ceux-ci ne soient écrasés par des articles plus récents. Pour cela, référez vous à la page du manuel du fichier expire.ctl (man expire.ctl).

Le paramètre spécial /remember/ est obligatoirement défini dans le fichier pathetc/expire.ctl.

Il indique au serveur combien de temps doivent être gardés les identifiants d’articles après qu’il ont expirés.

En effet, il peut arriver que des articles expirés et effacés de votre serveur puissent vous être renvoyés par un autre serveur.

Afin de ne pas les stocker à nouveau, le serveur conserve les identifiants des articles (message-id) un certain nombre de jours défini par le paramètre /remember/.

La valeur de ce paramètre doit toujours être supérieure à la valeur du paramètre artcutoff situé dans le fichier pathetc/inn.conf.

La valeur par défaut du paramètre artcutoff est 10 (vous pouvez la laisser telle quelle) et signifie que tout article daté d’au moins 10 jours sera rejeté par le serveur.

En toute logique, votre paramètre /remember/ devrait ressembler à ceci :

/remember/:11

Il existe deux types de politiques d’expiration, l’une est basée sur les groupes, l’autre sur les classes de stockage.

Afin de gérer l’expiration par classe de stockage, il vous faudra vérifier que le paramètre groupbaseexpiry que vous trouverez dans pathetc/inn.conf a pour valeur false.

Dans le cas contraire, il vous faudra définir une politique d’expiration par groupes de discussion exprimée avec wildmat. Ce cas ne sera pas traité ici et vous êtes invité à lire la documentation (man expire.ctl).

Définissons maintenant la politique d’expiration des articles pour la classe de stockage 0 vers laquelle seront redirigés l’ensemble des articles qui ne sont pas destinés au groupe de discussion fr.test.

0:A:1:14:65

Ici la classe de stockage ayant pour identifiant 0, appliquera une politique de rétention des articles d’au moins un jour (1) et de quatorze jours au maximum (14) sauf pour les articles ayant un entête Expires définissant un délai supérieur auquel cas ces articles seront gardés au maximum soixante cinq jours (65), y compris si le délai stipulé par l’entête Expires est supérieur.

Il existe d’autres manières de définir des politiques d’expiration. Pour plus d’information à ce sujet, voyez la page du manuel du fichier expire.ctl (man expire ctl).

Le fichier readers.conf

À partir du moment où le paramètre noreader situé dans le fichier pathetc/inn.conf a pour valeur false (valeur par défaut), toutes les connexions initiées par des hôtes distants n’étant pas indiqués dans le fichier pathetc/incoming.conf ainsi que les connexions initiées par des hôtes distants y étant stipulés mais envoyant la commande MODE READER sont gérées par le démon d’authentification nnrpd.

Le fichier pathetc/readers.conf sert à nnrpd pour déterminer si une demande de lecture ou d’écriture sur le serveur est autorisée ou non.

L’authentification se fera à partir d’un fichier contenant l’ensemble des informations nécessaires (nom d’utilisateur et mot de passe). Pour créer ce fichier nous utiliserons le programme /usr/bin/htpasswd.

Ce programme n’est pas fourni par le paquet inn2 et est installé sur votre système si vous y avez installé un serveur HTTP tel qu’Apache httpd ou lighthttpd.

Si vous ne souhaitez pas installer de serveur HTTP sur votre serveur, cet outil utilisable en ligne devrait vous être utile.

Qui qu’il en soit, ce fichier contiendra une ligne pour chacun des utilisateurs dont vous souhaitez autoriser l’accès.

news ~$ htpasswd -nbd toto sesame >> /var/lib/news/users
news ~$ chmod 640 /var/lib/news/users

La commande précédente ajoutera au fichier pathdb/users l’utilisateur toto qui aura pour mot de passe sesame.

Vous pouvez également éditer le fichier pathdb/users avec un simple éditeur de texte et y ajouter les informations d’authentification fournies par un générateur utilisable en ligne.

L’important étant qu’à chaque ligne du fichier corresponde un seul et unique couple utilisateur:mot_de_passe.

Malheureusement l’option ‘-d’ de htpasswd tronquera vos mots de passe à 8 caractères.

Attention donc à ne pas dépasser cette limite faute de quoi vos utilisateurs ne pourront pas être correctement authentifiés.

Une fois vos utilisateurs créés, changez les permissions d’accès à ce fichier afin de permettre à nnrpd d’en extraire les informations dont il aura besoin.

Maintenant que le fichier pathdb/users est créé et dûment rempli, nous pouvons nous attaquer à la configuration des autorisations en elles-mêmes.

Il est possible de gérer très finement et par différents moyens ces authentifications et autorisations, cependant nous allons nous contenter d’autoriser l’accès en lecture à tous les groupes disponibles sur votre serveur à qui que ce soit en faisant la demande et n’autoriser l’accès en écriture qu’aux utilisateurs authentifiés.

Pour ce faire nous allons créer une classe d’authentification et deux classes d’accès de la manière suivante :

auth all {
    auth: "ckpasswd -f /var/lib/news/users"
    default: "anonymous"
}

Ci-dessus nous indiquons à nnrpd que les authentifications se feront à l’aide du programme ckpasswd (auth: "ckpasswd -f /var/lib/news/users") qui vérifiera les informations d’authentification dans le fichier /var/lib/users que nous venons de créer. Toutefois, nous lui indiquons également qu’un utilisateur non authentifié aura pour nom anonymous (default: "anonymous").

access full {
    users: "*,!anonymous"
    newsgroups: "*,!control,!control.*,!junk"
}

Ensuite nous décrivons les autorisations d’accès dont disposeront tous les utilisateurs sauf anonymous (users: "*,!anonymous").

Ici nous autorisons l’accès à tous les groupes sauf control (ainsi que l’ensemble de ces sous-groupes) et junk (newsgroups: "*,!control,!control.*,!junk").

access read_only {
    users: anonymous
    newsgroups: "*,!control,!control.*,!junk"
    access: R
}

Enfin, nous définissons les autorisations d’accès pour l’utilisateur non authentifié anonymous.

Ici nous lui donnons accès aux mêmes groupes que s’il était authentifié mais en lecture seule (access: R).

Notez que si vous définissez plusieurs classes d’accès, seule la dernière classe correspondante sera prise en compte par nnrpd (last win).

Vous pouvez commenter toutes les autres lignes de ce fichier.

Vous trouverez toutes sortes d’informations utiles dans la page de manuel de readers.conf (man readers.conf).

Créer le tampon CNFS

Nous avons déclaré dans le fichier pathetc/cycbuff.conf un tampon cyclique qu’il nous faut maintenant créer.

Pour ce faire nous utiliserons la commande dd logiquement fournie avec votre système Linux.

news ~$ dd if=/dev/zero of=/var/spool/news/cycbuff/test bs=1k count=512000

Assurez-vous de bien lancer cette commande en tant qu’utilisateur news.

Si l’utilisateur news n’est pas autorisé à créer ce tampon cyclique, vérifiez qu’il dispose des autorisations suffisantes sur le répertoire pathdb/cycbuff (voir Le fichier pathetc/cycbuff.conf).

Enfin, modifiez les autorisations d’accès à ce fichier en exécutant la commande suivante

news ~$ chmod 664 /var/spool/news/cycbuff/test

Bien évidemment, le chemin du fichier /var/spool/news/cycbuff/test ainsi que sa taille doivent correspondre à ce qui a été précédemment déclaré dans le fichier pathetc/cycbuff.conf.

Vérifier la configuration et démarrer INN

inncheck

INN fournit un outil appelé inncheck qui vous permettra de vérifier que vos fichiers de configuration sont valides :

news ~$ /usr/lib/news/bin/inncheck -av --pedantic

On peut obtenir plus d’information avec les arguments -av --perm --pedantic.

Pour les permissions, inncheck est parfois trop pointilleux et il peut ne pas être d’accord avec les droits standards de votre distribution, il faut bien réfléchir avant de changer les droits UNIX.

Démarrer INN

À ce stade de la configuration de votre serveur, vous devriez être en mesure de le démarrer.

Toutefois en cas d’erreur soulignée par inncheck, il est fortement conseillé de les corriger avant le premier démarrage d’INN.

Sur un système Linux (ici testé sur Debian), le plus simple sera d’utiliser la commande systemctl ou service si votre système n’utilise pas systemd.

root# systemctl start inn2 ou root# service inn2 start

Cette commande se chargera de démarrer l’ensemble des programmes et sous-programmes nécessaires au bon fonctionnement de votre serveur sans que vous ayez à vous poser trop de questions.

Si tout s’est bien passé, vous devriez être en mesure de voir que votre port TCP/119 est ouvert en exécutant la commande suivante :

root# netstat -anpt | grep innd
tcp 0 0 0.0.0:119 0.0.0.0:* LISTEN 19167/innd

Cependant, vous pouvez vérifier que votre serveur a correctement démarré en lisant les fichiers de log situés dans pathlog.

Si le fichier pathlog/news.notice reste désespérément vide alors que vous constatez avec netstat -anpt que votre serveur est bien actif, n’hésitez pas à relancer rsyslog.

root# service rsyslog restart

Gérer les messages de contrôle

Les articles de contrôle sont des articles formatés de telle manière qu’ils permettent d’ordonner au serveur de nouvelles d’agir de différentes façons comme, par exemple, créer ou effacer des groupes.

Gérés par un controlchan, ils diffèrent des articles d’annulation (cancels) qui sont manipulés directement par INN.

Si vous voulez que votre serveur gère les articles de contrôle (ce qui est souhaitable), vous devez d’abord vérifier que la valeur du paramètre pgpverify que vous trouverez dans le fichier de configuration pathetc/inn.conf est true.

Le fichier pathetc/control.ctl contient l’ensemble des actions autorisées classées par hiérarchies. A priori, il est suffisant mais vous pouvez tout de même vérifier que les hiérarchies dont vous voulez assurer la distribution y sont notées.

Comme nous l’avons vu, les articles de contrôle peuvent donner des ordres qui ne sont pas sans conséquence. Pour cette raison et afin de s’assurer que les messages de contrôle que vous recevez sont authentiques, ils sont généralement numériquement signés.

Pour permettre à controlchan de vérifier les signatures des articles de contrôle, nous avons besoin de lui donner le porte-clef contenant l’ensemble des clefs publiques des expéditeurs autorisés à envoyer un tel article.

Nous stockerons ce porte-clef dans le répertoire pathetc/pgp que nous avons besoin de créer :

root# mkdir /etc/news/pgp
root# chown news:news /etc/news/pgp
root# chmod 700 /etc/news/pgp

Entrez ensuite dans le répertoire pathetc/pgp et téléchargez la dernière liste à jour des clefs publiques des expéditeurs autorisés à envoyer un article de contrôle :

news ~$ cd /etc/news/pgp
news ~$ wget ftp://ftp.isc.org/pub/pgpcontrol/PGPKEYS

Il faut ensuite créer le porte-clef numérique en lui donnant la liste des clefs.

Certaines de ces clefs utilisent un ancien format, qui n’est plus accepté par GnuPG 2, vous devrez donc utiliser explicitement GnuPG 1 avec une option particulière, en l’installant au besoin :

news ~$ gpg1 --allow-non-selfsigned-uid --import --homedir=/etc/news/pgp PGPKEYS

(il peut être nécessaire d’installer ce package, sous root: apt-get install gnupg1)

Vous pouvez vérifier que les clefs ont été correctement importées en tapant la commande suivante :

news ~$ gpg1 --homedir=/etc/news/pgp --list-keys

Mise à jour de la liste d’active

La liste d’active est la liste des groupes disponibles sur votre serveur. Par défaut, celle-ci ne comprend que la branche local.* qui contient deux groupes : local.test et local.general.

Si vous désirez pouvoir distribuer d’autres hiérarchies, il vous faudra synchroniser votre liste d’active soit avec un autre serveur les distribuant, soit à partir d’un fichier. Il y a deux méthodes l’une avec curl et l’autre avec actsync. La première est très rapide pour récupérer quelques hiérarchies, la deuxième beaucoup plus lente mais permettra de récupérer toutes les hiérarchies. Notons que vous pouvez dans un premier temps ne créer que quelques groupes et attendre que les autres soient créés magiquement par les messages de contrôle reçus via vos serveurs appairés.

Dans les deux cas, les manipulations doivent être exécutées par l’utilisateur news.

Méthode pour quelques hiérarchies

Pour le Big8 :

news ~$ curl "http://usenet.trigofacile.com/hierarchies/index.py?see=COMP,HUMANITIES,MISC,NEWS,REC,SCI,SOC,TALK&only=checkgroups" \
| /usr/lib/news/bin/docheckgroups -u | /usr/lib/news/bin/mod-active

Pour fr.* :

news ~$ curl "http://usenet.trigofacile.com/hierarchies/index.py?see=FR&only=checkgroups" \
| /usr/lib/news/bin/docheckgroups -u | /usr/lib/news/bin/mod-active

Notons qu’il suffit simplement d’éditer le paramètre dans la requête en GET pour avoir une autre hiérarchie. Attention : En cas de mauvaise URL, vous serez peut-être obligé de vous servir de kill…

Méthode pour toutes les hiérarchies

Vous n’avez probablement pas envie de distribuer toutes les hiérarchies existantes, et afin de notifier le programme actsync de la liste des groupes à synchroniser, il vous faut paramétrer le fichier pathetc/actsyn.ign.

Ce fichier n’est qu’une liste de groupes dont chaque entrée est précédée d’un caractère permettant de définir le type de synchronisation.

Le caractère i indiquera à actsync d’ignorer la liste des groupes qui le suivent quand un caractère c lui indiquera de vérifier la présence de ces groupes dans votre liste d’active.

Exemple :

i talk.*

vous permettra de ne pas synchroniser les groupes se situant sous la branche talk.

c comp.*

vous permettra de vérifier que la branche comp et l’ensemble de ses groupes sont bien présents sur votre serveur.

Les actions à prendre en cas de détection d’un groupe marqué c qui ne serait pas disponible sur votre serveur dépendent des paramètres passés à actsync qui ne seront pas détaillés ici. Pour de plus amples informations, veuillez vous référer à la page de manuel d’actsync (man actsync).

Si vous ne voulez transporter que la hiérarchie fr.*, votre fichier pathetc/actsync.ign devrait au moins contenir la ligne suivante :

c fr.*

La mise à jour de l’active de votre serveur avec actsync est un processus qui prend un certain temps. La longueur de ce temps étant fonction du nombre de groupes à mettre à jour et peut même se compter en jours !

Il y a deux sous-méthodes : soit avec un autre serveur les distribuant, soit à partir d’un fichier.

Avec un serveur distant

Pour synchroniser votre liste d’active avec celle du serveur loin.ailleurs.com, exécutez la commande suivante :

news ~$ actsync -o x -v 2 -p 0 -i /etc/news/actsync.ign loin.ailleurs.com

À partir d’un fichier

Si vous préférez synchroniser votre serveur à partir d’un fichier, vous pouvez télécharger sur le serveur FTP de l’ISC la liste complète des groupes distribués et l’utiliser de la manière suivante :

news ~$ wget https://ftp.isc.org/pub/usenet/CONFIG/active -O /chemin/vers/active_de_l_ISC
news ~$ actsync -o x -v 2 -p 0 -i /etc/news/actsync.ign /chemin/vers/active_de_l_ISC

Installer Cleanfeed

Cleanfeed est un programme de filtrage qui n’est pas fourni par INN et doit être téléchargé, installé et configuré de manière indépendante.

En cas de doute, veuillez vous référer à la documentation officielle : page sur mixmin.net

Il vous permettra d’éviter de distribuer inutilement les éventuels spams qui pourraient être envoyés par votre serveur.

Commencez par télécharger et décompresser Cleanfeed:

root# cd /root
root# wget https://www.mixmin.net/cleanfeed/cleanfeed.tar.gz
root# tar -xvzf cleanfeed.tar.gz

Copiez ensuite le fichier cleanfeed dans le répertoire des filtres d’INN (pathfilter dans inn.conf):

root# cp ./cleanfeed/cleanfeed /etc/news/filter

Avant de remplacer le fichier pathfilter/filter_innd.pl par cleanfeed et afin de conserver une copie de l’original, renommez-le:

root# mv /etc/news/filter/filter_innd.pl /etc/news/filter_innd.pl.old
root# mv /etc/news/filter/cleanfeed /etc/news/filter/filter_innd.pl

Déplacez ensuite le répertoire que vous venez de décompresser et qui contient les fichiers de configuration de cleanfeed dans le répertoire des filtres d’INN (pathfilter):

root# mv ./cleanfeed/ /etc/news/filter

Enfin accordez la variable $config_dir dans le fichier pathetc/filter/filter_innd.pl de manière à la faire pointer vers les fichiers de configuration de cleanfeed.

La ligne concernée devrait correspondre à celle-ci:

$config_dir = '/etc/news/filter/cleanfeed/etc';

Évidemment vérifiez que les autres paramètres correspondent bien à vos souhaits (oui c’est long mais c’est bien documenté). Vérifiez également que le fichier pathetc/filter/cleanfeed/etc/cleanfeed.local, qui contient quelques paramètres dont certains sont redondants avec ceux trouvés dans pathetc/filter/filter_innd.pl, soit renseigné conformément à vos désirs.

Vous pouvez maintenant vérifier votre configuration avec les deux commandes suivantes :

root# perl -wc /etc/news/filter/filter_innd.pl
/etc/news/filter/filter_innd.pl syntax OK

root# perl -wc /etc/news/filter/cleanfeed/etc/cleanfeed.local
/etc/news/filter/cleanfeed/etc/cleanfeed.local syntax OK

Pour la deuxième commande de vérification, vous pouvez ignorer les messages du type: Name "main::Moderated" used only once: possible typo at /etc/news/filter/cleanfeed/etc/cleanfeed.local line 205..

Redémarrez INN:

root# systemctl restart inn2

ou

root# service inn2 restart

Si votre installation de cleanfeed s’est bien déroulée vous devriez pouvoir redémarrer votre serveur sans avoir de notification d’erreur concernant cleanfeed dans votre fichier de log pathlog/news.notice.

Si vous ne voulez pas redémarrer votre serveur INN pour si peu, vous pouvez également vous contenter de recharger les filtres perl liés à Cleanfeed avec la commande suivante :

news ~$ ctlinnd reload filter.perl 'installation _Cleanfeed_'

Vous trouverez tous les détails nécessaires à la configuration sur la page de cleanfeed.

Configurer NoCeM

INN fournit un script de filtrage complémentaire appelé NoCeM dont le but est d’accepter de certains utilisateurs authentifiés des articles spécifiques annonçant que tel ou tel article peut être considéré comme indésirable.

Les raisons pour lesquelles un article peut être considéré indésirable sont multiples et peuvent être simplement techniques (cas d’une publication croisée vers un nombre trop important de groupes) ou liées au contenu de l’article incriminé (cas du spam).

Pour que les utilisateurs dont vous voulez honorer les articles NoCeM soient authentifiés par leurs signatures électroniques, vous devez en importer les clefs publiques. Une liste des principales clefs publiques est disponible sur cette page.

Ainsi pour importer la clef publique de Xavier Roche (créez le répertoire avec les bons droits si nécessaire avant, voir section Gérer les messages de contrôle):

news ~$ cd /etc/news/pgp
news ~$ touch ncmring.gpg
news ~$ wget http://home.httrack.net/~nocem/bleachbot.asc
news ~$ gpg --import --keyring /etc/news/pgp/ncmring.gpg --no-default-keyring bleachbot.asc

Une fois les clefs importées et afin que que les articles NoCeM soient traités par le script perl-nocem fourni avec INN, modifiez le fichier pathetc/newsfeeds:

nocem!:!*,alt.nocem.misc,news.lists.filters,fr.usenet.abus.nocem\
    :Tc,Wf,Ap:/usr/lib/news/bin/perl-nocem

Vous trouverez de plus amples informations à propos de NoCeM sur le lien ci-dessus et en ce qui concerne USENET-fr dans la FAQ NoCeM.

Redémarrez votre serveur (ou faites un simple ctlinnd reload newsfeeds nocem) et vérifiez que le filtre NoCeM est activé en retrouvant les lignes suivantes dans le fichier pathlog/news.notice:

innd: nocem! spawned nocem!:21:proc:1757
innd: SERVER perl filtering enabled
nocem: starting up

Voir aussi https://www.eyrie.org/~eagle/software/inn/docs-2.7/perl-nocem.html

Gérer les groupes modérés

Il y a deux techniques: les articles postés sont envoyés par e-mail au modérateur, qui ajoute le champ Approved, ou les utilisateurs le configurent eux-mêmes (par exemple pour l’auto-modération).

moderators et configuration INN moderatormailer

Ici, les articles postés sont envoyés par e-mail au modérateur, qui ajoute le champ `Approved’.

Pour chaque hiérarchie ou forum spécifique, l’adresse e-mail du modérateur est indiquée, éventuellement de manière dynamique, dans fichier pathetc/moderators. Il est possible d’ajouter un modérateur par défaut en configurant moderatormailer dans pathetc/inn.conf et de s’assurer que les mails sont bien envoyés en dehors du serveur.

Groupes modérés autrement

Pour les groupes qui ne sont pas modérés par mail, il n’y a pas besoin d’une configuration spécifique pour INN2. Dans certains cas, une configuration spécifique peut être faite dans le fichier assez compliqué pathetc/readers.conf.

Filtrer le spam avec SpamAssassin

En supposant que soit installé et configuré un SpamAssassin sur votre machine, vous pouvez envisager qu’il filtre le spam entrant sur votre serveur.

Pour ce faire nous utiliserons un feed de type programme nommé spamchk configuré dans le fichier pathetc/newsfeeds:

spamchk!\
 :*\
 :Tp,Ac\
 :/usr/local/bin/spamchk %s

Ensuite, il nous faut raccorder SpamAssassin à ce feed. Ce sera fait avec le script suivant que vous enregistrerez dans /usr/local/bin/spamchk.

#!/bin/sh
# -----------------------------------------------------------------
# File:        spamchk
# Purpose:     SPAMASSASSIN shell-based filter used with _INN_
# Location:    /usr/local/bin
# Author:      Doug Le Tough
# -----------------------------------------------------------------

# Variables
SM="/usr/lib/news/bin/sm"
BC="/usr/bin/bc -l"
AWK="/usr/bin/awk"
SPAMC_USER="news"
SPAMC="/usr/bin/spamc -d localhost -p 7137 -c"
LOG="/var/log/news/news.notice"
SPAMLOG_PATH="/var/tmp/spamchk"
# Spam max score
SPAM_LIMIT=5

# Pipe message to spamc
SPAM_VALUE=$($SM -S $1 |$SPAMC | $AWK -F '/' '{print $1}' )
if [ $(echo "$SPAM_VALUE>$SPAM_LIMIT" | $BC) -eq 1  ]
then
  HOST=$(hostname -s)
  MID=$($SM -S $1 | grep Message-ID)
  CLEAN_MID=$(echo $MID | $AWK -F "<" '{print $2}' | $AWK -F ">" '{print $1}')
  DATE=$(LANG=C date '+%b %d %H:%m:%S')
  echo "$DATE $HOST $0: Spam spotted: [$SPAM_VALUE > $SPAM_LIMIT]  ** $MID" >> $LOG
  # Move spam article to SPAMLOG_PATH 
  $SM -S $1 >> $SPAMLOG_PATH/$SPAM_VALUE.$CLEAN_MID
fi

Le script spamchk se contente de faire analyser par spamc les articles que lui envoie INN et si le score dépasse le niveau de tolérance déclaré, copie l’article dans SPAMLOG_PATH.

Le nom du fichier copié est du format <score>.<message-id> (exemple: 15.1.99d6027f-f18a-43a9-b417-930838d7b092@googlegroups.com) ce qui vous permettra de vérifier facilement la présence de faux positifs et d’éventuellement les réinjecter comme ham dans la base de données de SpamAssassin.

Évidemment vous pouvez remplacer ce traitement par n’importe quelle autre commande, comme celle qui supprimerait cet article de votre serveur.

Ajustez les variables à votre configuration, notamment les chemins vers les logs et programmes mais aussi le seuil de tolérance au spam (SPAM_LIMIT) qui est ici arbitrairement fixé à 8. Les options spécifiques à spamc (l’hôte et le port sur lequel contacter spamd) sont également à adapter à votre configuration.

Ajustez la valeur de SPAM_LIMIT en fonction de vos désirs tout en gardant à l’esprit que plus cette valeur est haute moins vous aurez de faux positifs mais plus vous prenez le risque de laisser passer un spam.

Tout est affaire de tests, de compromis et de nourrissage soigné de la base de données qui servira aux filtres bayesiens de SpamAssassin.

N’oubliez pas de donner au script les permissions en exécution nécessaires:

root# chmod +x /usr/local/bin/spamchk

Activez ce nouveau feed dans INN avec ctlinnd reload newsfeeds spamchk.

Il est inutile de redémarrer INN après avoir modifié les variables contenues dans /usr/local/bin/spamchk. Les nouvelles valeurs seront prises en compte au prochain appel du script (ce qui peut ne pas être tout à fait immédiat).

Particularités Debian

Si vous avez modifié le script de démarrage /etc/init.d/inn2, vous serez probablement amené à adopter celui proposé lors de la mise à jour avant de modifier ensuite ce script à votre convenance. Plus d’informations avec ces deux posts: explication et modification de /etc/init.d/inn2 pour avoir un deuxième démon nnrpd sur le port 563.

Pour des raisons de sécurité, on ne peut plus faire :

su news

Mais il faut faire :

su - news -s /bin/bash

Ou avec sudo :

sudo -u news bash

Afin de pouvoir correctement lancer les commandes en tant que news, le mieux est de taper ceci :

sudo -u news bash
. /etc/profile
PATH=$PATH:/usr/lib/news/bin

Personnellement, j’utilise screen pour ne pas avoir à taper ces commandes trop souvent…

Particularités d’autres versions d’INN

Particularités d’INN 2.5

Dans inn.conf, complaints accepte une chaîne de caractères qui sera utilisée pour renseigner le champ X-Complaints-To des entêtes de chaque article publié depuis votre serveur. Une valeur typique est une adresse de courriel du type abuse@example.com. Ce champ est déprécié et incorporé à Injection-Info dans les versions suivantes.

Particularités d’INN 2.6

Les entêtes NNTP-Posting-Date et NNTP-Posting-Host peuvent avantageusement être remplacés par les entêtes plus modernes Injection-Date et Injection-Info.

Voici ci-dessous des valeurs conseillées mais non obligatoires dans pathetc/inn.conf (après le commentaire #Posting) :

addinjectiondate: true
addinjectionpostingaccount: true
addinjectionpostinghost: true

Les valeurs suivantes peuvent être commentées si vous passez de INN 2.5 à INN 2.6 :

#nnrpdauthsender
#nnrpdposthost

Pour plus d’informations, veuillez vous référer à la documentation officielle INN 2.6.

Particularités d’INN 2.7

innreport

pathetc/innreport.conf a été modifié depuis la version 2.6 afin de faciliter la modification concernant l’affichage sans créer de bug dans ce module, il faut donc récupérer les éventuelles modifications de l’ancien fichier et les écrire dans /usr/lib/news/innreport-display.conf.

Cancels et Cancel-Lock

inn-secrets.conf est une autre nouveauté qui permet d’enfin gérer les Cancel-Lock sans module supplémentaire. Les modifications apportées dans cleanfeed.local ou un autre filtre peuvent être conservés mais le plus simple est de créer pathetc/inn-secrets.conf.

Ce fichier possède sa propre documentation officielle.

Vous pouvez récupérer votre ancien secret et le noter dans la variable canlockuser, vous bénéficiez d’un nouvel canlockadmin à créer pour bénéficier d’une suppression simplifiée pour le newsmaster.

Il est de la forme :

cancels {
        canlockadmin: [ "9kc3ZtAACpNZRGtmYiPlbfkDacqNwPbcEfzFodc5X48g" ]
        canlockuser:  [ "TSrg41qEbp6AyZuQoIIHo6sUzFkBLOocJYN3KsUVdgft" ]
    }

Les valeurs suivantes de docancels dans inn.conf permettent respectivement :

En cas d’absence de configuration de inn-secrets.conf, les valeurs require-auth et none ont le même effet ! require-auth est la valeur par défaut de docancels.

Autres changements :

Le drapeau -C pour innd n’est plus fonctionnel, il a été remplacé par docancels.

Les valeurs refusecybercancels et verifycancels dans inn.conf doivent être commentées.

Les valeurs de nolist et noresendid dans incoming.conf ont été remplacées par leurs exacts contraires : list et resendid, ne pas apporter les modifications correspondantes provoque des erreurs.

Les valeurs refusecybercancels et verifycancels dans inn.conf ne sont plus effectives (il semble qu’elles sont ignorées).

require_ssl si présent dans readers.conf est à modifier.

Pour plus d’informations, veuillez vous référer à la documentation officielle INN 2.7.

Pour finir

INN fournit un outil appelé inncheck qui vous permettra de vérifier que vos fichiers de configuration sont valides:

root# /usr/lib/news/bin/inncheck

On peut obtenir plus d’information avec les arguments -a --perm --pedantic.

Maintenant que nous avons largement dégrossi la configuration de votre serveur et que celui-ci est fonctionnel, vous pouvez relire l’intégralité de la page de la documentation officielle du serveur de nouvelles INN 2.7 afin de parfaire votre connaissance et de peaufiner la configuration de votre nouveau serveur.