8. Installation et configuration de INN

8.1 Installation à partir d'un paquetage précompilé

Certains diront qu'il faut mieux partir des sources de INN et les compiler : cela permet de mieux maîtriser toutes les options de fonctionnement. C'est vrai, mais les paquetages précompilés pour Linux s'avèrent si faciles à installer que beaucoup choisissent la solution des paquetages...

Dans cette section, nous ne parlerons pas de la compilation de INN mais de son installation au moyen des différents systèmes de paquetages précompilés existants sur Linux et FreeBSD.

La dernière version de INN existe dans toutes les bonnes distributions Linux (Debian, Red Hat, Slackware, etc.), sinon la version précédente doit se trouver sur le CD-ROM. Il en va de même pour FreeBSD. Reportez-vous aux manuel du gestionnaire de paquetage que vous utilisez (rpm pour RedHat Linux, apt-get pour Debian Linux, ou pkg_add pour FreeBSD).

8.2 Installation à partir des sources

La procédure est on ne peut plus classique : décompactez le fichier archive dans un répertoire temporaire, placez-vous dans celui-ci et exécutez les commandes magiques : ./configure et make. Si tout ce passe bien, il vous reste à faire make install pour que les différentes parties du logiciel aillent se placer à leurs emplacements définitifs.

8.3 Fichiers et répertoires de INN 1.7

INN 1.7 utilise plusieurs répertoires (je donne ici ceux que ma distribution Linux de l'époque utilisaient : ce sera différent avec FreeBSD, voire avec une autre distribution Linux) :

  • /etc/news contient les fichiers de configuration :

    actsync.cfg         expire.ctl          innwatch.ctl        nnrp.access
    actsync.ign         hosts.nntp          moderators          nntpsend.ctl
    control.ctl         hosts.nntp.nolimit  motd.news           overview.fmt
    distrib.pats        inn.conf            newsfeeds           passwd.nntp
    

  • /var/lib/news contient les fichiers de travail :

    active         history        send-ihave     subscriptions
    active.times   history.dir    innlog.pl      send-nntp
    distributions  history.pag    newsgroups     send-uucp
    

  • /var/lib/news/innd contient les fichiers utilisés par innd :

    control  nntpin
    

  • /usr/lib/news contient les fichiers scripts nécessaires à l'exécution d'INN, ainsi que l'exécutable rnews déjà évoqué :

    innshellvars      innshellvars.pl   parsecontrol
    innshellvars.csh  innshellvars.tcl  rnews
    

  • /usr/lib/news/bin contient les exécutables :

    actmerge        ctlinnd         inncheck        news.daily      sendbatch
    actsync         ctlrun          innconfval      newsrequeue     sendxbatches
    actsyncd        cvtbatch        innmail         nntpget         shlock
    archive         expire          innstat         nntpsend        shrinkfile
    auth.dir        expireover      innwatch        overchan        tally.control
    batcher         expirerm        innxbatch       pgpverify       tally.unwanted
    buffchan        fastrm          innxmit         prunehistory    writelog
    control         filechan        makeactive      rnews
    convdate        getlist         makegroup       scanlogs
    crosspost       grephistory     makehistory     scanspool
    

  • /var/log/news contient les fichiers de trace d'activité :

    expire.log    news          news.err      nntpsend.log
    errlog        expire.rm     news.crit     news.notice   unwanted.log
    

8.4 Fichiers et répertoires de INN 2.x

Hormis les fichiers de trace qui, comme d'habitude, se trouvent sous /var/log/news, tous les fichiers de INN 2.x se trouvent sous l'arborescence de l'utilisateur news : ~news (/usr/local/news sur FreeBSD).

Cette arborescence se décompose en :

  • spool : arborescence du spool de news (équivalent de /var/spool/news de INN 1.7).

  • bin : contient tous les exécutables (c'est l'équivalent du répertoire /usr/lib/news/bin de INN 1.7). C'est là, notamment que se trouvent les programmes innd, ctlinnd, expire, rnews et le script de maintenance quotidienne que nous étudierons plus tard :news.daily.

  • db : contient les bases de données utilisées par INN : le fichier active, les fichiers de l'historique (history.*) et le fichier de description des forums (newsgroups).

  • etc : contient tous les fichiers de configuration, notamment les fichiers inn.conf, newsfeeds et moderators.

  • lib : contient les bibliothèques propres à INN ainsi que des scripts comme docheckgroups, innshellvars.

  • run : contient les fichiers pid correspondant à l'exécution de INN.

Il est hors de question de décrire le rôle de chacun de ces fichiers : nous ne traiterons que des plus importants (les descriptions des autres, ainsi que leurs rôles respectifs, sont décrits dans les pages du manuel en ligne).

8.5 Les fichiers de configuration

Tous ces fichiers, comme la plupart des fichiers de configuration de INN, débutent par une explication (parfois sibylline, il est vrai...) de leur syntaxe. Pour leurs modifications, mettez-vous sous le compte news, il est impératif que ces fichiers appartiennent à l'utilisateur et au groupe news pour que INN fonctionne correctement... D'autre part, avant de les modifier, sauvegardez leur contenu original (en faisant, par exemple, cp newsfeeds newsfeeds.orig).

  • inn.conf : Chaque ligne est de la forme : paramètre: valeur (attention, il y a un espace après le ':'). paramètre et valeur sont des chaînes de caractères (ne mettez pas de " autour...). Les différents paramètres valides et intéressants pour nous sont :

    • organization : comme valeur, mettez ce que vous voulez voir apparaître dans le champ ORGANIZATION des articles que vous posterez ;

    • fromhost : le nom de votre machine, qui apparaîtra après votre username@ dans le champ FROM des articles que vous posterez. En fait, normalement, c'est votre lecteur de news qui doit s'en charger, ce qui veut dire que si cette valeur est utilisée, c'est que votre lecteur est mal configuré... Pour cette raison, on met une valeur comme « un.lecteur.mal.configure » ce qui permettra de détecter rapidement ce problème ;

    • pathhost : le contenu de ce champ est important car c'est lui qui apparaîtra au début des champs Path: des articles que vous posterez. C'est l'identifiant unique de votre serveur sur tout Usenet. Il est inutile si vous utilisez simplement suck ou newsx pour vous approvisionner sur le serveur de votre FAI mais il est nécessaire si vous bénéficiez d'un système d'alimentation directe comme UUCP. Mettez ici ce que vous aura indiqué le newsmater lorsque vous aurez demandé à être feedé par cette méthode.

    • ovmethod : ce champ apparaît dans INN 2.3 qui, par rapport aux versions précédente, utilise une gestion différente des «overview». La méthode utilisée par défaut est tradindexed : il en existe d'autres... Voir man inn.conf.

    Les autres paramètres, s'ils ne sont pas mentionnés, prennent les valeurs des variables d'environnement : le paramètre server, par exemple, sera par défaut positionné à la même valeur que la variable d'environnement NNTPSERVER (qui, normalement doit être positionnée à localhost dans le fichier /etc/profile ou équivalent sur votre système).

    Certains paramètres permettent de configurer les ordres de grandeur de INN : nous ne les modifierons pas ici car ils conviennent à l'utilisation qui sera la nôtre. Certains autres permettent d'activer (valeur true ou de désactiver (valeur false) certains comportements. Pour un petit serveur, par exemple, il peut être préférable de désactiver doinnwatch.

    Si vous utilisez des répertoires différents de ceux considérés par défaut, c'est également dans ce fichier qu'il faudra le préciser.

    La page de manuel (man inn.conf) ainsi que le fichier INSTALL livré avec les sources indiquent la signification de tous ces paramètres : je vous invite fortement à consulter ces deux documents.

    Avec les lignes suivantes dans un inn.conf :

    organization:           Truc Bidule
    pathhost:               machin
    
    Un article posté sur ce serveur local aura les entêtes suivants :
    From: Eric Jacoboni <jaco@youpi.fr>
    Organization: Truc Bidule
    Subject: blah blah blah...
    Path: machin!not-for-mail
    ...
    

    De même, avec un système d'alimentation directe tous les articles reçus auront leur champ Path: commençant par machin!... (cela est configuré au niveau du fournisseur). Ainsi que nous le disions plus haut, le machin en première position correspond au champ pathhost configuré dans le fichier inn.conf de notre serveur, et ce champ Path: est, finalement, le résultat de la concaténation de tous les pathhost des serveurs NNTP par lesquels l'article est passé. Si l'on veut avoir plusieurs feeds, cela permet au fournisseur de ne pas reproposer les articles que l'on a déjà émis.

    On notera la contenu du champ From : l'adresse jaco@youpi.fr est formée à partir de la configuration de mon logiciel de news, pas à partir du contenu de l'entrée fromhost de inn.conf. En fait, il est préférable de définir cette adresse au niveau du fichier de configuration du lecteur de news. Avec gnus, par exemple, il suffit d'ajouter les lignes suivantes à son fichier ~/.gnus :

    (setq user-mail-address "jaco@youpi.fr")
    (setq user-full-name "Eric Jacoboni")
    (setq mail-default-reply-to "jaco@youpi.fr")
    (setq mail-host-address "youpi.fr")
    

    Soyez quand même conscient que mettre une adresse farfelue ne fera pas de vous un anonyme (d'ailleurs, pourquoi voudriez-vous l'être, hein ?) et qu'elle risque de vous priver de recevoir des réponses personnelles.

  • hosts.nntp (Uniquement pour INN 1.7 : voir incoming.conf pour INN 2.0). Il ne doit comporter qu'une ligne, localhost:. Attention à ne pas mettre d'espace après le ':', ni de ligne après celle-ci. Lorsque j'utilisais la méthode d'alimentation directe proposée par Oléane (aka «méthode Fyr»), j'avais dû rajouter une ligne pour que le serveur distant qui m'alimentait en articles soit reconnu par mon serveur local. Cette ligne était news.dial.oleane.com: car c'est lui qui m'envoyait les batchs. Dans ce cas précis, il avait également fallu ajouter une entrée correspondant à news.dial.oleane.com dans mon fichier /etc/hosts car INN a besoin de connaître l'adresse IP de toutes les entrées de hosts.nntp lors de son démarrage.

  • incoming.conf (Uniquement pour INN 2.x, voir hosts.nntp pour INN 1.7). Ce fichier, comme hosts.nntp pour les versions antérieures, permet d'indiquer les machines qui nous approvisionnent en articles. Le fichier livré avec les sources, ainsi que la page de manuel man incoming.conf décrivent toutes ses possibilités. Si l'on utilise suck ou newsx, seule la machine locale est habilitée à poster sur notre serveur, il n'y aura donc une entrée que pour elle :

    peer ME {
      hostname:         "localhost, 127.0.0.1"
    }
    

    Si l'on est approvisionné par l'équivalent de la méthode Fyr (proposée par Teaser), il faudra rajouter l'entrée :

    peer teaser {
      hostname:     "feed.teaser.net"
    }
    
    et mettre l'adresse de cette machine dans votre fichier /etc/hosts.

  • nnrp.access : Ce fichier liste les noms de machines qui auront le droit d'utiliser notre serveur de news ... et les autorisations (lecture et publication de nouveaux articles) associées. Le mien contient les lignes suivantes :

    # Default to no access
    *::::!*
    # Allow access from localhost
    localhost:Read Post:::*
    127.0.0.1:Read Post:::*
    stdin:Read Post:::* 
    192.168.2.*:Read Post:::*
    

    Consultez la page de manuel concernant ce fichier pour comprendre la signification de ces lignes qui consistent à énumérer les machines autorisées à utiliser notre serveur pour lire les articles (Read) et en poster (Post).

    Attention : avec INN 2.3, ce fichier a été remplacé par readers.conf (voir ci-dessous).

  • readers.conf (uniquement à partir de INN 2.3) : il joue le même rôle que le fichier nnrp.access des versions précédentes mais sa syntaxe a changé. Voici le contenu d'un readers.conf équivalent au nnrp.access donné plus haut :

    auth "localhost" {
        hosts: "localhost, 127.0.0.1, stdin, 192.168.2.0/24"
        default: "<localhost>"
    }
    
    access "localhost" {
        users: "<localhost>"
        newsgroups: "*"
    }
    

  • storage.conf (uniquement à partir de INN 2.3). Cette nouvelle version a modifié la gestion du spool d'articles et permet d'utiliser plusieurs méthodes pour les stocker. Ce fichier permet de préciser quelles sont les méthodes utilisées (on peut utiliser différentes méthodes pour différents groupes) et il doit être configuré avec INN 2.3 (alors que l'on pouvait se passer de le faire avec INN 2.2).

    Voici un exemple indiquant que l'on utilise un spool traditionnel pour tous les groupes :

    method tradspool {
            newsgroups: *
            class: 0
    }
    

    Un effet de bord désagréable de cette évolution est qu'il est désormais très peu pratique de récupérer un spool existant lorsque l'on passe d'un INN antérieur à 2.3 à un INN 2.3 et supérieur...

  • newsfeeds : Ce fichier décrit les sites que vous approvisionnez en news.

    Il faut donc y décrire celui de notre FAI afin de pouvoir lui expédier les articles que nous postons sur notre propre serveur. Le mien contenait les lignes suivantes lorsque mon fournisseur était HOL :

    ME:*,!junk,!control::
    
    crosspost:*:Tc,Ap,WR:/usr/lib/news/bin/crosspost -s -
    
    overview!:*:Tc,WO:/usr/lib/news/bin/overchan
    
    news.hol.fr/news1.isdnet.net,news2.isdnet.net,news3.isdnet.net,news4.isdnet.net\
            ::Tf,Wnm:
    

    La syntaxe complète de ce fichier est décrite dans le manuel en ligne. Il faut retenir que la ligne ME concerne notre machine. Ici elle récupère tous les groupes sauf junk et control.

    Les lignes crosspost et overview servent à gérer les articles cross-postés et l'historique. Elles ne sont plus nécessaires avec INN 2.3 car celui-ci dispose désormais d'un mécanisme interne permettant de les gérer.

    La ligne news.hol.fr nécessite plus d'explications : elle indique d'abord que les descriptions des articles que nous postons (via rpost, lorsque l'on utilise suck) seront placés dans le fichier /var/spool/news/out.going/news.hol.fr, c'est là que rpost ira chercher leurs noms afin de les expédier au serveur du FAI pour qu'ils circulent.

    D'autre part, normalement INN est conçu pour pouvoir fonctionner grâce à plusieurs sites « feeds », lui fournissant des articles. Il envoie donc à tous les serveurs listés dans le fichier newsfeeds une copie de chaque article reçu. Mais, ainsi que nous l'avons évoqué dans la section 2, il est inutile de renvoyer à un serveur donné les articles qu'il nous a lui-même expédiés (!) ainsi que ceux que avons récupérés grâce à un serveur avec lequel il est déjà lui-même en relation.

    Chaque article contient donc un champ Path: dressant peu à peu une liste des noms de serveurs sur lesquels il est «passé», chaque nom étant séparé du suivant par un point d'exclamation.

    Dans le fichier newsfeeds, on précise à INN ce qu'il doit faire des articles reçus. On y trouve une ligne pour chaque élément (pas obligatoirement un autre serveur de news) auquel INN doit passer des informations sur les articles reçus. Chaque ligne est composée de champs séparés par :.

    Ce fichier offre, par exemple, le moyen d'indiquer qu'on ne doit pas réexpédier à un serveur donné la copie d'un article déjà passé par tel ou tel serveur. Le tronçon de ligne news.hol.fr/news1.isdnet.net,news2.isdnet.net,news3.isdnet.net,news4.isdnet.net se lit ainsi : «il existe un serveur par commodité appelé ici news.hol.fr. Tu dois lui expédier les copies des articles, SAUF de ceux dont le champ Path: contient news1.isdnet.net ou news2.isdnet.net ou news3.isdnet.net ou news4.isdnet.net».

    Le tronçon de ligne ::Tf,Wnm: concerne aussi la déclaration destinée à informer INN de l'existence d'un serveur qu'il faut alimenter en articles. Ce serveur est appelé par commodité news.hol.fr. Il s'agit, en fait, de la même ligne que la précédente pour INN car le caractère antislash placé après le premier tronçon sert de «continuateur» (comme souvent sous UNIX). Ce tronçon se lit ainsi : «ceci est valable pour tous les groupes reçus ici, sauf junk et control». En effet, ce qui a été défini pour l'entrée ME s'applique ici aussi (:Tf,Wnm:) détermine le mode de transmission des articles. Nous verrons que si l'on utilise UUCP, cette partie devra être modifiée.

    Par défaut, le fichier utilisé pour garder la trace des articles sera donc /var/spool/news/out.going/news.hol.fr. Si vous désirez qu'il porte un autre nom, il suffit de le mentionner après le dernier :. De la même façon, les articles dont l'envoi à ce feed ont échoué seront mentionnés dans le fichier /var/spool/news/out.going/news.hol.fr.fail.

    On a ainsi créé un «feed» d'articles, c'est-à-dire un canal logique (on ne se soucie pas, pour le moment, de la façon dont les articles seront transportés) par lequel votre serveur peut en alimenter d'autres.

    À ce stade vous devez comprendre l'intérêt de créer des feeds lorsque votre machine est connectée à plusieurs autres (et participe donc au réseau, en interconnectant d'autres participants). Mais pourquoi le faire lorsque l'on est une «feuille» de l'arbre, une machine uniquement connectée à une seule autre, via une connexion PPP, comme dans le cas qui nous intéresse ?

    Eh bien créer ainsi un «feed» vers votre fournisseur vous permettra de voir circuler les articles que vous posterez, tout simplement !

    Mais tout article venant de news.hol.fr devrait ne pas être renvoyé vers news.hol.fr. Cela ne poserait pas de problème particulier car un serveur recevant un article commence par vérifier (grâce au Message-Id) s'il en dispose déjà, et le rejette si c'est le cas mais cela occasionne des transferts inutiles : vous verriez alors apparaître des messages vous informant que vous envoyez des messages dupliqués sur le serveur distant.

    Malheureusement (je vous ai prévenu, j'ai eu tous les problèmes possibles...), HOL faisait appel à un fournisseur de news externe (en l'occurrence isdnet) ce qui fait que news.hol.fr n'apparaissait jamais dans le champ Path: des articles et que ceux-ci étaient donc renvoyés lors du prochain appel de rpost (avec les messages qui en résultent...). Pour expliquer que les articles provenant des serveurs de news d'isdnet ne doivent pas être renvoyés, on l'indique entre le / et le :. Si ces exclusions n'étaient pas précisées, tous les articles reçus seraient décrits dans le fichier /var/spool/news/out.going/news.hol.fr car ils ne contiennent pas news.hol.fr dans leur champ Path:...

    Pour savoir quel est le serveur que votre FAI utilise (afin de l'exclure comme cela est décrit plus haut), deux méthodes sont possibles :

    • Faire un telnet news.fai.fr nntp qui vous renseignera sur le nom de la machine qui vous envoie les articles (le abcdef cité dans l'exemple de la section 2). Cette méthode nécessite, bien sûr, d'être connecté. Vous pouvez économiser une unité téléphonique en utilisant la deuxième possibilité...

    • À l'aide de votre lecteur de news, visualisez la totalité des en-têtes d'un article reçu. Le champ qui nous intéresse est Path: qui indique la route suivie par cet article pour arriver jusqu'à nous. Le nom qui suit celui de votre machine (ou qui suit le nom spécifié par l'entrée pathhost du fichier inn.conf) est le nom de la machine qui vous l'a envoyé. Prenons un exemple : depuis la première version de ce document, j'ai quitté HOL pour Easynet, puis pour Oléane, puis pour Free (avec les FAIs, comme avec le reste, il faut savoir faire jouer la concurrence). Voici le contenu du champ Path: de chaque article que je recevais d'Oléane :

      Path: jacoboni!dial.oleane.com!...!...
      

      dial.oleane.com doit donc être exclu, ce qui fait que mon fichier newsfeeds doit désormais contenir, à la place de la ligne news.hol.fr, la ligne suivante :

      oleane/dial.oleane.com\ 
              ::Tf,Wnm:
      

      Le fichier contenant les références des articles que j'envoie au site distant était alors /var/spool/news/out.going/oleane.

      Notez bien que cela suppose que mon entrée ME soit la suivante :

      ME\
              :*,!junk,!control::
      

    Ne vous fiez pas à l'examen d'un seul article car votre fournisseur d'accès peut disposer de plusieurs serveurs de news. Ajoutez chaque serveur en le séparant du précédent par une virgule (voir l'exemple plus haut, pour HOL).

    Attention : le fichier newsfeeds est chargé en mémoire au lancement de INN, donc toute modification de celui-ci implique son rechargement (cf. la section sur l'utilisation de ctlinnd et l'utilisation du paramètre reload).

  • moderators. Ce fichier est utilisé lorsqu'on désire poster un article dans un forum modéré (fr.comp.os.linux.annonces ou fr.usenet.logiciels, par exemple). La différence entre un forum non modéré et un forum modéré est que tout le monde peut poster n'importe quoi (et, malheureusement, certains en abusent...) dans le premier tandis que la parution d'un article dans le second est soumise à l'acceptation d'une ou plusieurs personnes : les modérateurs de ce forum.

    Ceci signifie que, pour poster un article dans un forum modéré, on doit d'abord l'envoyer au modérateur sous la forme d'un message email. Le modérateur recevra alors votre proposition d'article et décidera de le publier dans le forum, ou le rejettera s'il juge qu'il ne correspond pas à la charte.

    Toute cette démarche est inutile car, heureusement, INN s'occupe de tout. Il permet de publier dans les forums modérés comme dans les autres et se charge de transformer automatiquement l'article en message qu'il expédie aux modérateurs dont il trouve l'adresse électronique dans le fichier moderators. C'est également pour cette raison qu'il faut disposer d'un moyen d'envoyer du courrier...

    La page de manuel moderators(5) détaille la syntaxe du contenu de ce fichier. En résumé : un enregistrement par ligne, deux champs par enregistrement, séparés par le signe :. Le premier champ contient un «motif» de sélection de nom de forum (fr.*, par exemple, correspond à tous les forums de la hiérarchie fr). Le second champ contient l'adresse du modérateur de ce forum. Cas spécial : la paire de caractères %s, utilisée dans le second champ, est remplacée par le nom du forum visé.

    La dernière ligne de ce fichier devrait toujours être une entrée «par défaut» contenant *:%s@moderators.isc.org (ou *:%s@moderators.news.oleane.net, pour les abonnés d'Oléane) qui indique que tous les articles postés dans un forum modéré au nom non précédemment sélectionné par les entrées précédentes devront être envoyé à l'adresse nom_du_forum@moderators.isc.org. La machine destinatrice dispose toujours de la liste à jour des noms de forums et des adresses de leurs modérateurs.

    Dans l'absolu, cette règle (*:%s@moderators.isc.org) suffit donc : aucune autre n'est strictement nécessaire. Mais il est de bon ton de ménager les serveurs centraux... et cela accélère le service.

    Par exemple, pour pouvoir poster au plus vite dans un forum modéré de la hiérarchie fr (par exemple fr.usenet.logiciels), il suffit d'ajouter au début du fichier, juste après la dernière ligne de commentaires, l'entrée suivante :

    fr.*:%s@moderators.freenix.org
    

    Attention : Il faut bien entendu ajouter les entrées avant la ligne générique (*:%s@moderators.isc.org) et en étudiant aussi les autres entrées pour ne pas qu'elles correspondent au motif de la nouvelle ligne saisie, car INN prend en charge la première ligne satisfaisante rencontrée. La solution la plus sûre consiste à faire vos ajouts en tête de ce fichier.

  • expire.ctl. Ce fichier permet de configurer le mécanisme d'expiration de INN. Le contenu de ce fichier étant richement commenté (la commande man expire.ctl existe aussi...), nous ne le détaillerons pas ici : le principe général consiste à préciser le nombre de jours au-delà desquels les articles d'un groupe, ou d'un ensemble de groupes, seront supprimés de votre serveur.

8.6 Les fichiers de données : active, history, newsgroups

Comme les précédents, ces fichiers doivent appartenir à l'utilisateur news. Avec INN 2.2, ils se trouvent dans le répertoire ~news/db.

  • active. Ce fichier contient les noms des forums reçus par INN. Cela n'a rien à voir avec le fait de recevoir les articles : on peut très bien récupérer les articles d'un forum fr.bidon par suck, et ne pas les distribuer sur notre machine si le forum fr.bidon n'est pas décrit dans le fichier active... Les fournisseurs d'accès mettent, en général, leur fichier active à disposition, vous pouvez en récupérer un par FTP à ftp://ftp.oleane.net/pub/Oleane/active.

    Voici les premières lignes de mon fichier active, qui en contient 238 (en fait, il a beaucoup changé depuis la première version de ce document...) :

    control 0000001372 0000001085 y
    junk 0000000004 0000000005 y
    test 0000000000 0000000001 y
    to 0000000000 0000000001 y
    fr.comp.os.linux.annonces 0000000910 0000000887 m
    fr.comp.mail 0000015100 0000014624 y
    fr.usenet.logiciels 0000005972 0000005877 m
    fr.comp.text.tex 0000009863 0000009378 y
    fr.comp.applications.x11 0000005586 0000005308 y
    fr.comp.applications.emacs 0000003085 0000002965 y
    

    On a une ligne par forum, sachant que les 4 premiers sont obligatoires pour que INN fonctionne (il vous suffit de les désactiver dans votre lecteur de news si vous ne voulez pas les voir apparaître...).

    Attention, INN 2.3 ajoute les entrées control.cancel, control.checkgroups, control.newgroup et control.rmgroup à ces entrées obligatoires...

    Ne modifiez pas le fichier active manuellement, mais utilisez le programme ctlinnd (voir la section sur l'utilisation de ctlinnd).

    Pour la syntaxe, as usual, cf. les pages du manuel en ligne (man active)... Au départ, initialisez ce fichier afin que les champs numériques soient tous de la forme 0000000000 0000000001, ils seront mis à jour automatiquement à chaque appel de rnews (le «y» signifie que l'on autorise le postage d'article dans le forum, «m» signifie qu'il est modéré). Comme d'habitude, attention à ne pas placer de retour chariot après la dernière ligne...

    Nous le répétons une nouvelle fois :pour éviter de mauvaises manipulations, il est préférable de ne pas modifier manuellement le fichier active mais d'utiliser le programme ctlinnd (voir la section sur l'utilisation de ctlinnd).

  • history. Si vous avez utilisé un système de paquetages pour installer INN, ce dernier aura automatiquement créé ce fichier historique, qui sera ensuite géré par INN, vous n'avez pas donc à vous en occuper pour le moment... Sachez quand même que suck consulte ce fichier (sauf si vous utilisez l'option -H) afin d'éviter de récupérer un article déjà présent sur votre serveur.

    Si vous avez installé INN à partir des sources, il vous faudra créer l'historique initial en suivant ce qui est indiqué dans le fichier INSTALL : makehistory -i créera cet historique, il vous restera à renommer les fichiers history.n* créés par cette commande en history*. Enfin, n'oubliez pas de positionner les droits d'accès avec la commande chmod 0664 *.

  • newsgroups. Ce fichier permet d'associer une description lisible à chaque forum. Normalement il devrait donc contenir autant de lignes que le fichier active, mais ce n'est pas une obligation : tout dépend du courage de l'administrateur... Comme pour le fichier active, vous pouvez récupérer un fichier newsgroups complet par FTP à ftp://ftp.oleane.net/pub/Oleane/newsgroups. Le mien est plutôt spartiate :

    control   Usenet control messages - DO NOT REMOVE
    junk      Articles for missing newsgroups - DO NOT REMOVE
    test      A place for test posts - DO NOT REMOVE
    to        Special Group for INN use - DO NOT REMOVE
    fr.comp.text.tex            Discussions concernant TeX et LaTeX.
    fr.comp.applications.emacs  Editeur de textes Emacs et ses extensions.
    fr.comp.applications.libres Les solutions libres en informatique. (Moderated)
    fr.comp.applications.x11    Systeme de multifenetrage X11.
    fr.comp.lang.perl           Langage de programmation Perl.
    fr.comp.mail                Logiciels de messagerie electronique.
    fr.comp.os.linux.annonces   Annonces concernant Linux. (Moderated)
    fr.comp.os.linux.moderated  Discussions sur le systeme Linux (moderated).
    fr.network.modems           Discussions concernant les modems.
    fr.usenet.forums.evolution  Discussions sur la creation de nouveaux forums fr.
    fr.usenet.logiciels         Discussions sur les logiciels de News
    

    En fait, cela permet à votre lecteur de news d'afficher la description correspondante en face du nom du forum...

8.7 Derniers réglages

Si vous avez configuré les fichiers que nous venons de décrire, il ne reste plus qu'à soumettre votre configuration au programme de vérification livré avec INN. Pour cela, lancez la commande /usr/lib/news/bin/inncheck -a (ou ~news/bin/inncheck -a avec INN 2.2) et ne vous inquiétez pas de l'avertissement «/usr/local/news/etc/newsfeeds:0: warning you accept all incoming article distributions» qui est parfois produit.

  • Si vous utilisiez Leafnode auparavant, vérifiez bien que vous avez supprimé la ligne

    nntp    stream  tcp     nowait  news /usr/sbin/tcpd /usr/local/sbin/leafnode
    
    de votre fichier /etc/inetd.conf.

  • Il n'y a rien d'autre à faire : l'installation de INN par un des systèmes de paquetages déjà cités aura modifié pour vous les scripts de démarrage.

    Si vous êtes partis des sources, utilisez le mécanisme de lancement des services au démarrage propre à votre système : il s'agit principalement de lancer le script /usr/local/news/bin/rc.news :

    • Sur un système Linux, les scripts de démarrage se trouveront probablement sous le répertoire /etc/rc.d/. Chaque distribution n'en faisant qu'à sa tête, je vous fais confiance pour adapter ce démarrage à votre système.

    • Sur un système FreeBSD, on utilisera l'arborescence /usr/local/etc/rc.d et on utilisera le fichier innd.sh contenant les lignes suivantes (pour INN 2.2) :

      #!/bin/sh
      if [ $# -eq 0 -o x$1 = xstart ]; then
       if [ -x /usr/local/news/bin/rc.news -a -f /usr/local/news/db/history.pag ]; t
      hen
            limits -C news /usr/local/news/bin/rc.news && echo ' inn'
         fi
      fi
      if [ x$1 = xstop ]; then
         /usr/local/news/bin/ctlinnd shutdown machine is going down
      fi
      

    Dans le fichier inn.conf, recherchez la ligne commençant par doinnwatch: et remplacez la valeur true, qui est sûrement celle que l'installation par défaut a dû mettre, par false : cela évitera le lancement du programme innwatch qui ne sert à rien dans la situation particulière qui est la nôtre et évitera aussi une boucle de temporisation inutile (sleep 600). Je ne me rappelle plus si cette ligne existait dans le inn.conf de INN 1.7 mais, si ce n'est pas le cas, recherchez la ligne initialisant la variable DOINNWATCH dans le script rc.news et faites de même.

    innwatch sert à «surveiller» le bon fonctionnement du serveur : si le démon innd tombe, ou si un autre problème critique intervient, il se charge de prévenir l'administrateur par courrier. D'autre part, une mauvaise configuration de l'expiration des articles que vous stockez peut entraîner une saturation du disque : là aussi, innwatch interviendra en lançant à intervalles réguliers une commande comme df. Dans le cas d'une configuration comme la nôtre, son intérêt est donc quasi nul puisque nous maîtrisons l'ajout des nouveaux articles. Il sert surtout dans les cas où le serveur est alimenté en permanence.

  • En tant que root, lancez le script de lancement adapté à votre système, par exemple :

    /etc/rc.d/init.d/news start
    
    sur Red Hat Linux, ou
    /usr/local/etc/rc.d/innd.sh start
    
    sous FreeBSD.

    Le lancement de ce script doit normalement vous répondre innd (ou inn) pour vous informer que le démon est lancé...

  • Vérifiez par un ps axu qui doit comporter des entrées similaires à celles-ci :

    news       212  0.0  3.0  1912  1428  ?  S < 15:39   0:00 /usr/sbin/innd -p4 -i0 -L 
    news       236  0.0  0.6   888   308  ?  S < 15:39   0:00 /usr/lib/news/bin/crosspost -s - 
    news       237  0.0  0.6   888   312  ?  S < 15:39   0:00 /usr/lib/news/bin/overchan 
    
    pour INN 1.7 sur un système Linux ou
    news      285  0.0  2.1  2988 1992  ??  Is    8:50     0:02.63 /usr/local/news/bin/innd -p4 -L
    news      294  0.0  0.5   992  452  ??  IN    8:50     0:00.49 /usr/local/news/bin/crosspost
    news      295  0.0  0.5   996  464  ??  IN    8:50     0:00.40 /usr/local/news/bin/overchan
    
    pour INN 2.2 sur un système FreeBSD.

    Pour INN 2.3, sur le même système, on obtiendra :

    news   255  0.0  2.9  7548 2764  ??  Ss  11:11  0:02.69 /usr/local/news/bin/innd -p4
    

    On notera l'absence des entrées crosspost et overchan qui ne font plus l'objet de processus séparés.

Si vous obtenez cela, c'est que INN fonctionne, bravo...