Installer et configurer un serveur de nouvelles

De Wiki Usenet-fr
Aller à : navigation, rechercher


Préambule

Cette page a pour but d'expliquer les processus d'installation et de configuration d'un serveur de nouvelles INN 2.5 sur un système Linux Debian (écrit pour Squeeze mais applicable avec des petites modifications pour Wheezy et Jessie).

INN 2.6 apportant son lot de modifications, quelques détails de cette documentation devront probablement être adaptés pour arriver à faire le fonctionner comme vous le souhaitez. cf : Annonce de la publication d'INN 2.6.0

Si certaines parties de ces explications ne vous semblent pas claires ou douteuses, préférez vous en 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 Debian Squeeze (6.0) à jour. Les versions ultérieures de Debian apportant elles aussi leur lot de modifications, il vous faudra probablement adapter cette documentation à votre système en vous référant aux points 12 et 13 de cette documentation.

Néanmoins que ce soit dans le cas de INN ou de Debian, quelques que soient leur versions respectives, cette documentation devrait rester utilisable dans les grandes lignes.

Bien que globalement générique, cette page ne traite pas de l'installation ou de la configuration du serveur de nouvelles INN sur un autre système que Debian.

Cependant, hormis quelques subtilités sur l'emplacement de certains fichiers de configuration, vous pouvez très largement vous en inspirer et l'adapter à votre système d'exploitation de prédilection.

De la même manière, 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.

Les configurations des autres méthodes de stockage, de distributions ou de filtrages ne seront pas traitées ici.

Enfin, les utilisateurs de Raspberry Pi trouveront des informations techniques et quelques conseils spécifiques leur permettant d'installer un serveur de nouvelles sur leur matériel

Conventions

Certaines commandes stipulées dans cette page sont à exécuter en tant qu'administrateur du système (root').

Toutes ces commandes sont précédées du symbole #.

Les commandes à exécuter en tant qu'utilisateur non privilégié sont précédées du symbole $ lui même précédé du nom de l'utilisateur concerné.

Exemple :

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

est une commande à exécuter en tant qu'administrateur (le symbole # ne fait pas partie de la commande et ne doit pas être saisi).

(news)$ cp /mon/fichier /mon/nouveau/fichier

est une commande à exécuter en tant qu'utilisateur news (le symbole $ ne fait pas partie de la commande et ne doit pas être saisi).

Mise à jour de votre 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.

# apt-get update

suivi de :

# apt-get upgrade

Comme pour le refroidissement du fût du canon, la mise à jour de votre système peut prendre un certain temps et vous pourrez avoir besoin de redémarrer votre ordinateur pour la compléter.


Installation d'INN

L'installation du serveur de nouvelles INN est largement facilitée par le gestionnaire de paquet du système Debian. Pour ce faire, exécuter la commande suivante :

# apt-get install inn2

Attention à bien installer le paquet inn2 et non 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 qui va de la configuration de la réception à celle du filtrage des articles en passant par celle de leur stockage sans oublier leur distribution. Mais 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 Debian 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 /etc/news/inn.conf.

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

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

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

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: /var/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 leur répertoires.

Exemple :

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

N'hésitez pas à vous reporter à la liste des chemins de temps à autres 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


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 qu'on trouve généralement dans les shells des système UNIX comme 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é.

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 :

* (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 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 exclus 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 identifiants 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 champs X-Complaints-To: des entêtes de chaque article publié depuis votre serveur. Une valeur typique est une adresse de courriel du type abuse@mondomaine.com.

hiscachesize

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) est 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 champs Organization: des entêtes des articles publiés depuis votre serveur dont ce champs ne serait pas déjà renseigné par son expéditeur. Ce champs est totalement libre.

pathhost

Accepte une chaîne de caractères qui sera utilisée dans le champs 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.

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 champs 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 en référer à la page de manuel de newsfeeds (man newsfeeds).

Le troisième paramètres 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 certains nombres 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 leur 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 en 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 avoir été accepté par votre serveur. Il 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 distributions 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. Ainsi il est inutile de préciser pour chacun d'entre eux

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 que vous en avez besoin et, comme toujours, man infeed.conf pour plus d'information ;-)

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 ses 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 la bande passante utilisée 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) à leurs valeur par défaut.

Afin d'éviter tous problèmes il est vivement conseillé de ne PAS mettre d'espace entre les différents wildmats du champs 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.

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

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

# mkdir /var/spool/news/cycbuff

Assurons nous maintenant que l'utisateur news pourra bien écrire dans ce répertoire.

# chown -R news:news /var/spool/news/cycbuff
# 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éthode 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 tel qu'on en trouve dans un système de fichier 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, à 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écent. 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 aient expirés.

En effet, il peut arriver que des articles expirés et effacés de votre serveur puisse 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 jour défini par le paramètre /remember/.

La valeur de ce paramètre doit toujours être au moins 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 discussions 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é au groupe de discussions 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 (mais aussi les connexions initiée 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 ou lighthttpd.

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

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

# htpasswd -nbd toto sesame >> /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 'httpasswd' 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ées, changer les permissions d'accès à ce fichier afin de permettre à nnrpd d'en extraire les informations dont il aura besoin.

# chown news:news /var/lib/news/users
# chmod 640 /var/lib/news/users

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

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

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 fournie avec votre système Debian.

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


Démarrer INN

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

Sur un système Debian, le plus simple sera d'utiliser la commande service.

# 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 c'est bien passé, vous devriez être en mesure de voir que votre port TCP 119 est ouvert en exécutant la commande suivante :

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

# 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 :

# mkdir /etc/news/pgp
# chown news:news /etc/news/pgp
# 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 :

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

Enfin, avec l'utilisateur news, créez 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 :

# su news
(news)$ gpg1 --allow-non-selfsigned-uid --import --homedir=/etc/news/pgp PGPKEYS

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 ne contient que 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.

Dans tous les cas, la manipulation est la même et se fait à partir du programme actsync qui doit être exécuté par l'utilisateur news.

Cependant, 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ésent 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 en référer à la page de manuel d'actsync (man actync).

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

c fr.*

Malheureusement, sur un système Debian, lorsque vous prenez l'identité de l'utilisateur news par la commande su news, le path de celui ne contient pas le répertoire des programmes exécutables d'INN. Pour remédier à cet inconvénient saisissez les commandes suivantes :

# su - news
(news)$ PATH=$PATH:/usr/lib/news/bin

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

Si vous préférez synchroniser votre serveur à partir d'un fichier, vous pouvez télécharger sur le serveur FTP de l'ISC (ftp://ftp.isc.org/pub/usenet/CONFIG/active) la liste complète des groupes distribués et l'utiliser de la manière suivante :

(news)$ actsync -o x -v 2 -p 0 -i /etc/news/actsync.ign /chemin/vers/active_de_l_ISC

Quelle que soit la méthode que vous avez sélectionné, la mise à jour de l'active de votre serveur est un processus qui prend un certain temps. La longueur de ce temps étant fonction du nombre de groupes à mettre à jour.

Your mileage may vary :-)


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.

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:

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

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

# 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:

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

Sur INN 2.6, pour éviter l'erreur :

innd: Perl function filter_art died on article <xxx@yyy.test>: Illegal modulus zero at /etc/news/filter/filter_innd.pl line 570.

Il faut installer la toute dernière version de cleanfeed :

mv /etc/news/filter/filter_innd.pl /etc/news/filter/filter_innd.pl.bad \
&& wget http://www.mixmin.net/cleanfeed/cleanfeed -O /etc/news/filter/filter_innd.pl

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

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

Enfin accordez la variable $config_dir dans le fichier /etc/news/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 que le fichier /etc/news/filter/cleanfeed/etc/cleanfeed.local, qui contient quelques paramètres dont certains sont redondants avec ceux trouvés dans /etc/news/filter/filter_innd.pl, soit renseigné conformément à vos désirs.

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

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

# 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:

# 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 contentez 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 lesquels un article peut être considéré indésirable sont muliples 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:

(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ées 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 cette page.

Redémarrez votre serveur 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

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


Évidemment vous pouvez remplacer ce traitement par n'importe quel 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ée à 8. Les options spécifiques à spamc (l'hôte et le port sur lequel contacter spamd) sont également à adapter à votre configuration.


Ajuster 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:

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

Redémarrer INN pour que soit pris en compte votre nouveau "feed":

# service inn2 restart


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 sur Debian Wheezy

Il y a un bug qui touche le readers.conf : pour le contourner vous serez probablement amené à le modifier pour avoir :


auth all {
    auth: "ckpasswd -f /var/lib/news/users"
    auth: "ckpasswd -s"
#    perlfilter: false
}

access full {
    users: *
    newsgroups: *
    perlfilter: false
    access: RPA
}

Particularités sur Debian Jessie

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'infos 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

Particularités pour Raspberry Pi

La page dédiée au Raspberry Pi reprend un certain nombre de conseils et astuces concernant l'installation d'INN sur ce matériel spécifique.

Pour finir

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

# /usr/lib/news/bin/inncheck

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 afin de parfaire votre connaissance et de peaufiner la configuration de votre nouveau serveur.