Page suivante Page précédente Table des matières

6. Utilisation d'INN

6.1 Utilisation avec la méthode Fyr

Si vous avez pris la peine de demander la génération automatique de votre fichier batch, vous allez pouvoir maintenant alimenter directement votre serveur (entre la première demande de création du batch et la première récupération, il faut compter 12 heures).

Connectez vous, et faites la commande finger identificateur@news.dial.oleane.com. Normalement, les messages suivants doivent s'afficher :

[news.dial.oleane.com]
Les news pour identificateur seront envoyees a .
nntpsend: [5901] start
nntpsend: [5901] stop
identificateur
votre-adresse-email
nntpsend: [5901:5918] begin identificateur Tue Jun  2 15:18:55 CEST 1998
nntpsend: [5901:5918] innxmit -a -d -t60 votre-adresse-email ...
< 200 identificateur InterNetNews server INN 1.7 16-Oct-1997 ready
>mode stream
< 203 StreamOK.
> check <3573FA72.41C6@kai.com>
> check <3573F9D5.CE5AE9B7@UU.NET>
> check <3573F8B4.E4688243@univ-rennes1.fr>
> check <6l0t18$bue$1@nnrp1.dejanews.com>
> check <aqgwwb0kl1j.fsf@desilles.loria.fr>
> check <3576c91f.3587862@news.club-internet.fr>
> check <6l0t44$2n9@matho.enserb.u-bordeaux.fr>
< 238 <3573FA72.41C6@kai.com>
> takethis <3573FA72.41C6@kai.com>
> [ article 840 ]
...

Ce sont les articles qui arrivent et qui sont automatiquement pris en charge par votre serveur local...

6.2 Utilisation avec suck

Si vous utilisez suck, remettez-vous dans le répertoire de suck (/usr/lib/suck). Vous vous rappelez du fichier nouveau que l'on avait généré ? On va l'utiliser pour alimenter NOTRE serveur :

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

6.3 Poster des articles avec rpost

Quelle que soit la méthode de récupération utilisée, rpost (livré avec la distribution suck permet de poster vos articles sur le serveur distant.

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

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 (chez moi : /var/spool/news/out.going/news.easynet.fr) : 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.

6.4 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 : cet ordre me permet de recevoir les articles que j'ai envoyés (mode parano on...). Placez ce script dans /usr/bin et lancez-le sous root.

#!/bin/bash

SERVEUR_DISTANT=news.dial.oleane.com
OUT_GOING=oleane
PATH_SUCK=/usr/lib/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

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 en utilisant le programme 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 mon fichier /usr/lib/suck/entete :

#!/bin/bash
sed -e "/^NNTP-Posting-Host/d" -e "/^Xref/d" $1 > $2

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

6.5 Un script pour automatiser l'envoi et la réception avec la méthode Fyr

Lorsque j'ai présenté la méthode Fyr au début de ce document, j'ai insisté sur le fait que les deux serveurs, le vôtre et celui d'Oléane, fonctionnaient de façon presque syméique. Ce presque existe à cause des méthodes employées de part et d'autre pour poster les articles.

Ainsi que nous l'avons vu précédemment, Oléane nous envoie les articles par un nntpsend qui appelle lui-même innxmit : c'est la démarche normale de INN pour envoyer des articles à un autre site. Mais, pour que nntpsend puisse envoyer des articles à un serveur, ce dernier doit avior autorisé l'envoyeur à le feeder... Cette autorisation est faite par la présence d'une ligne concernant le serveur qui envoie dans le fichier hosts.nntp du serveur qui reçoit. Ainsi, sur mon serveur, ais-je dû ajouter la ligne

news.dial.oleane.com:

dans mon /etc/news/hosts.nntp : news.dial.oleane.com: est ainsi autorisé à alimenter mon serveur.

Le problème apparaît dans l'autre sens : pour que mon serveur puisse envoyer des articles au serveur d'Oléane en utilisant nntpsend, il faudrait que ce dernier ajoute une entrée correspondant à mon serveur dans son fichier hosts.nntp...

Mais mon serveur n'a pas d'IP fixe : celle-ci lui est attribuée dynamiquement à chaque connexion ce qui fait que titine.jacosoft.fr n'a pas d'existence réelle au dehors. D'autre part, une adresse IP qui m'a été octroyée à l'instant T, pourra être octroyée à un autre à un autre moment... On se rend compte que, sans adresse IP statique, tout cela n'est guère possible.

Un autre problème est que tous les abonnés d'Oléane n'utilisent pas INN... il faudrait donc que ceux-ci configurent correctement leurs logiciels pour que leurs articles soient acceptés par le serveur d'Oléane...(mais je pense que ce problème pourrait être surmonté).

Pour ces deux raisons, la belle symétrie est brisée : nous sommes obligés d'utiliser rpost pour envoyer les articles au serveur distant. Vu le faible volume relatif de ce que nous faisons remonter à ce serveur, le procédé n'est pas pénalisant, mais c'est vrai qu'il est frustant de ne pouvoir disposer d'une solution « tout INN »...

Le script reprend donc le script précédent en ce qui concerne l'envoi, mais, évidemment, toute la phase de récupération est réduite à une seule ligne...

#!/bin/bash

IDENTITE=identificateur
SERVEUR_DISTANT_POST=news.dial.oleane.com
OUT_GOING=oleane
SERVEUR_DISTANT_FEED=news.dial.oleane.com
PATH_SUCK=/usr/lib/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_POST)

echo Envoi des articles...
if test -s $NOM_BATCH
then
 rpost $SERVEUR_DISTANT_POST -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 "rpost pb rapport"
else
 echo "pas d'articles à poster..."
fi

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

echo Récupération des articles...
finger $IDENTITE@$SERVEUR_DISTANT_FEED

Pour présenter le cas le plus général possible, j'ai volontairement utilisé un nom de fichier différent du nom du serveur pour OUT_GOING, et j'ai dissocié la gestion du serveur où l'on poste de celui qui nous feede. Dans la majeure partie des cas, vous pourrez prendre le même nom, celui du serveur de news distant, pour ces trois noms : votre script s'en trouvera allégé.

6.6 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, fr.test, 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/lib/suck/active-ignore et suck les ignorera. Le contenu de ce fichier serait, ici :

control
junk
test
to
fr.test

Vous pouvez alors vous poser la question : « puisque cette option est si pratique, pourquoi ne pas avoir l'avoir utilisée dans le script ? ». Ahem, tout simplement parce que, jusqu'aujourd'hui, je l'ignorais... Comme disait le millionnaire : « Nobody's perfect ! ». Désormais la ligne invoquant suck dans mon script est :

suck $SERVEUR_DISTANT -c -n -A -hl localhost -br nouveau

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.


Page suivante Page précédente Table des matières