9. Utilisation de INN

9.1 Utilisation avec Suck

Si vous utilisez Suck, remettez-vous dans le répertoire /usr/local/etc/suck. Vous vous rappelez du fichier nouveau que l'on avait généré ? On va maintenant l'utiliser pour alimenter NOTRE serveur en effectuant la commande suivante :

# rnews nouveau

Normalement, vous devriez ensuite pouvoir consulter les nouveaux articles à partir de votre lecteur de news favori (configuré pour admettre localhost comme serveur de news).

9.2 Poster des articles avec rpost

rpost (livré avec la distribution Suck permet de poster vos articles sur le serveur distant.

Vous ne pourrez poster des articles que dans les forums mentionnés dans le fichier active décrit plus haut (et pourvu que l'autorisation de postage (y) ait été positionnée pour ce forum...).

Ne postez pas d'article de test dans n'importe quel forum ! Pour cela, il existe le forum fr.test (d'où la présence de celui-ci dans mon fichier active...). Postez un article de test à l'aide de votre lecteur de news, puis vérifiez le contenu du fichier /var/spool/news/out.going/nom_du_feed (où nom_du_feed correspond à la partie gauche de l'entrée correspondante dans newsfeeds : il doit contenir une seule ligne indiquant où se trouve l'article à poster. S'il y a beaucoup de lignes, voir les remarques précédentes sur le fichier newsfeeds et les serveurs à exclure...

Connectez-vous à votre FAI et tapez la commande :

# rpost serveur_de_news_distant    

Normalement, votre article est posté... Cela dit, ce n'est pas pour cela qu'il sera accepté par le serveur distant : pour être conforme, l'en-tête de votre article a besoin d'être légèrement modifié. Cette opération est réalisée en passant celui-ci à travers un filtre avant de l'expédier par rpost. D'où l'intérêt de créer un script automatisant tout cela.

9.3 Un script pour automatiser l'envoi et la réception avec suck

J'ai écrit ce script (en m'inspirant d'autres scripts glanés ça et là...) pour poster mes articles et récupérer les nouveaux : rendez-le exécutable, placez-le dans /usr/local/bin et lancez-le sous root.

#!/bin/sh

SERVEUR_DISTANT=news.fai.fr
OUT_GOING=monfai
PATH_SUCK=/usr/local/etc/suck
PATH_SPOOL=/var/spool/news
NOM_BATCH=$PATH_SPOOL/out.going/$OUT_GOING
NOM_FILTRE=$PATH_SUCK/entete

# On commence par poster les articles (localhost->SERVEUR_DISTANT)

echo Envoi des articles...
if test -s $NOM_BATCH
then
 rpost $SERVEUR_DISTANT -b $NOM_BATCH -p $PATH_SPOOL \
       -f $NOM_FILTRE \$\$o=/tmp/filtres \$\$i /tmp/filtres && \
       cat /dev/null > $NOM_BATCH || \
       echo "probleme de postage" | mail news -s "probleme avec rpost"
else
 echo "pas d'articles à poster..."
fi

# puis on récupère les articles (SERVEUR_DISTANT->localhost)

echo Récupération des articles...
cd $PATH_SUCK
if test -f nouveau
then
  mv -f nouveau nouveau.old
fi
suck $SERVEUR_DISTANT -c -n -br nouveau
rnews nouveau

Ce modèle suppose que l'entrée correspondant au serveur distant est de la forme monfai/serveurs_exclus::Tf,Wnm: dans votre fichier newsfeeds.

Le fichier NOM_FILTRE permet de formater les articles. Normalement, la distribution de Suck a dû vous en fournir un... Classiquement, ce filtre a pour but de supprimer les champs NNTP-Posting-Host et Xref (ainsi que les champs X-Trace, X-Complaints -To et NNTP-Posting-Date dans le cas de INN 2.2) en utilisant la commande sed. Si cela n'est pas fait, il y a de gros risques pour que le serveur de news de votre F.A.I. refuse votre article.

Au cas où vous n'auriez pas un tel filtre, voici le contenu de /usr/local/etc/suck/entete pour INN 1.7 :

#!/bin/sh
sed -e "/^NNTP-Posting-Host/d" -e "/^Xref/d" $1 > $2
et le même pour INN 2.2 :
#!/bin/sh
sed -e "/^X-Trace/d" -e "/^NNTP-Posting-Host/d" -e "/^Xref/d"\
    -e "/^X-Complaints-To/d"  -e "/^NNTP-Posting-Date/d" $1 > $2

Ce fichier doit, naturellement, avoir les droits d'exécution positionnés par chmod +x entete.

9.4 Autres options de suck

suck dispose d'autres options lui permettant de mieux s'adapter à INN :

L'option -A, utilisée avec -hl localhost, indique à suck qu'il doit utiliser le fichier active de notre serveur pour créer et mettre à jour sucknewsrc. Ceci a un avantage évident : vous êtes sûr que les deux fichiers sont cohérents et, lorsque vous ajouterez un forum sur votre serveur, celui-ci sera automatiquement ajouté à la liste des forums à interroger par suck. De même, si vous supprimez un forum, la ligne qui lui correspond dans sucknewsrc sera détruite.

Mais alors, que se passera-t-il pour les forums comme control, junk, test, to, et tous ceux qui sont répertoriés dans active mais que l'on ne veut pas prendre en compte ? Cela aussi est prévu : il suffit de les mentionner dans le fichier /usr/local/etc/suck/active-ignore et suck les ignorera. Le contenu de ce fichier commencerait, par exemple, par :

control
junk
test
to
fr.test

Vous pouvez alors vous poser la question : «puisque cette option est si pratique, pourquoi ne pas l'avoir utilisée dans le script ?». Ahem, tout simplement parce que, à l'époque où j'ai écrit ce script, je l'ignorais... Comme disait le millionnaire : «Nobody's perfect !». De plus, je ne la trouve pas si pratique, moi, cette option puisqu'elle nécessite de tenir à jour le fichier active-ignore et qu'il me semble plus pratique de gérer directement le fichier sucknewsrc...

D'autres options existent encore : certaines permettent de modifier les répertoires de travail de suck, d'autres lui font adopter un comportement particulier dans le cas où certains serveurs distants produisent des erreurs de connexion, enfin, on peut même le faire parler en Français ! Nous ne pouvons toutes les énumérer ici et nous vous renvoyons donc à sa page de manuel pour des informations complètes.