7. Installation et configuration de Suck

Suck vous permet de récupérer par vous même les articles sur un serveur NNTP distant.

Toutes les manipulations qui suivent doivent se faire sous le compte root.

7.1 Installation de Suck

Suck peut être récupéré sous la forme d'un paquetage précompilé pour les différentes distributions Linux à base de paquetages (rpm ou deb). Vous pouvez aussi préférer récupérer les sources sous la forme d'un fichier tgz et les compiler pour votre système. La première solution est, évidemment la plus simple mais la distribution source vient avec tout ce qu'il faut pour permettre une configuration adaptée à vos besoins. À l'heure où ces lignes sont écrites, la version la plus récente est la 4.2.3.

Un argument en faveur de cette mise à jour est que les nouvelles versions permettent désormais de ne récupérer que les en-têtes des messages afin de marquer ceux qui nous intéressent pour en récupérer le corps (option -g). Cette option, ainsi qu'un script Perl/Tk (header.pl) et une application Java (Suck.java) permettent de sélectionner les articles à télécharger via une interface graphique X.

Je n'ai personnellement pas testé ces interfaces graphiques et toute expérience est donc la bienvenue bien que, personnellement, je suis plutôt sceptique sur ces récupérations en deux temps (en-têtes, puis corps des articles sélectionnés) : le mécanisme des killfiles de Suck me semble, à ce point de vue, plus efficace... D'autre part, l'un des grands avantages de Suck, pour moi, est de pouvoir l'appeler à travers des scripts : l'utilisation d'une interface graphique annule cette fonctionnalité (mais il est vrai que l'on n'est pas obligé de l'utiliser).

L'installation de Suck via les paquetages précompilés de Linux nécessite d'avoir auparavant installé le paquetage INN. En effet, par défaut, Suck est prévu pour fonctionner avec lui. Vous avez donc le choix : forcer l'installation de Suck sans INN en utilisant l'option adéquate de votre gestionnaire de paquetages ou installer INN avant (cette dernière solution est préférable puisqu'il faudra, de toutes façons, l'installer...). Si vous utilisez une distribution Debian, le mieux est d'installer le paquetage via la commande apt-get install suck qui résoudra toutes les dépendances et installera les paquetages correctement. Comme avec l'option --nodeps de rpm, vous pouvez aussi utiliser l'option --force-depends de dpkg pour ignorer les dépendances. Reportez-vous à la section sur l'installation et la configuration de INN.

Si vous utilisez un paquetage rpm ou deb, pas de problème : vous l'installez avec les outils de maintenance des paquetages de votre système (consultez la documentation de votre distribution).

Si vous partez des sources, faites en sorte de placer les binaires (lmove, rpost, suck, testhost) dans /usr/local/bin, les pages de manuel iront dans /usr/local/man/man1 et les scripts et fichiers de configuration (get.news.innxmit, get.news.rnews,put.news, sucknewsrc, suckkillfile) dans /usr/local/etc/suck. Ce sont, en tous cas, les emplacements préconisés mais vous pouvez en choisir d'autres en fonction des us et coutumes en vigueur sur votre système...

Dans la suite de ce document, nous utiliserons ces emplacements : effectuez les adaptations nécessaires en fonction de votre système.

7.2 Premiers tests

Maintenant, on peut tester la récupération (on suppose que le telnet news.fai.fr nntp, décrit plus haut, a été testé...). Pour ce faire, on édite le fichier sucknewsrc (ou on le crée, s'il n'existe pas) qui abritera les noms des forums qui nous intéressent. L'exemplaire livré (/usr/local/share/examples/suck/sucknewsrc.sample pour FreeBSD) contient plusieurs lignes que l'on supprime. À des fins de test, on ajoute une seule ligne :

fr.comp.os.unix -10
pour indiquer à suck qu'il devra, sitôt lancé, récupérer les 10 derniers articles du forum fr.comp.os.unix. N'oubliez pas le 10 car, sinon, vous risquez de récupérer tous les articles de ce forum disponibles sur le serveur !

Vérifiez que le sous-répertoire /usr/local/etc/suck/Msgs existe, sinon créez-le (attention à bien respecter les minuscules et les majuscules).

Placez-vous dans /usr/local/etc/suck et tapez la commande suivante (après établissement de la connexion PPP...) :

suck news.fai.fr -m -H -K
  • L'option -m permet d'invoquer suck en mode multi-fichiers : il créera autant de fichiers qu'il récupère d'articles. Si vous omettez cette option, les articles seront simplement affichés à l'écran au fur et à mesure de leur récupération.

  • Les options -H -K demandent à suck d'ignorer les fichiers d'historique et le kill-file (cf. plus loin)...

Normalement, l'affichage vous apprend que vous êtes connecté au serveur de news distant, puis vous indique que le nombre d'articles à récupérer dans fr.comp.os.unix est limité à 10. Enfin, la récupération commence : le nombre d'articles restant à récupérer et la vitesse de transfert s'affiche. Lorsque cela est terminé, vous pouvez couper votre connexion PPP : les articles sont sur votre machine...

Plusieurs choses ont dû se passer :

  • les fichiers /tmp/suck.newrc et /tmp/suck.sorted ont été créés (éventuellement à un autre emplacement selon le système que vous utilisez...) ;

  • le sous-répertoire /usr/local/etc/suck/Msgs contient désormais des fichiers portant des noms étranges (par défaut, c'est là que le mode multi-fichiers sauve les fichiers articles). Chacun de ces fichiers correspond à l'un des 10 articles que vous avez récupérés et vous pouvez les visualiser avec votre éditeur de texte favori (rassurez-vous, il existe des moyens bien meilleurs de consulter les articles...).

Détaillons un peu :

  • /tmp/suck.newrc est une mise à jour de sucknewsrc : éditez-le et vous verrez que la ligne concernant fr.comp.os.unix a remplacé -10 par une autre valeur, le numéro du dernier article lu.

  • /tmp/suck.sorted contient les en-têtes des articles récupérés. Ce fichier ne sert pas à grand chose sauf lorsqu'on veut pister d'éventuels dysfonctionnements.

Le problème est que sucknewsrc n'a pas été modifié, or suck n'utilise que ce dernier pour stocker le numéro du dernier article récupéré afin de pouvoir, lors de la session suivante, ne télécharger que les nouveaux. Cela signifie donc que si vous relanciez suck maintenant, il récupérerait exactement les mêmes articles...

Pour éviter cela, il faut détruire l'ancien sucknewsrc, et renommer /tmp/suck.newrc en sucknewsrc... Fastidieux, non ?

Heureusement, l'option -c (comme clean), passée à suck effectue cela automatiquement :

  • elle renomme sucknewsrc en sucknewsrc.old (ce qui permet de revenir en arrière, si nécessaire) ;

  • elle renomme /tmp/suck.newsrc en /usr/local/etc/suck/sucknewsrc ;

  • elle détruit /tmp/suck.sorted (et d'autres fichiers utilisés temporairement par suck).

Nous vous conseillons de n'utiliser cette option que lorsque vous aurez bien vérifié que tout fonctionne correctement : en effet, les différents fichiers sont autant de traces de fonctionnement.

Bon, on a supposé que tout avait marché comme sur des roulettes... Ce serait trop simple : votre premier lancement de suck a très bien pu ne pas se dérouler comme prévu... Notamment, vous pouvez avoir eu des erreurs du style :

430 No such article
..........

Si ces erreurs sont rares (1 sur 10, par exemple) ce n'est pas trop grave, il faudra quand même surveiller les sessions suivantes. Si, par contre, il y en a beaucoup (au pire, 10 sur 10) alors bienvenue à notre premier problème...

Chaque article porte un champ d'immatriculation. C'est l'en-tête («header») appelé «Message-id», établi lors de la publication de l'article de façon à être (très vraisemblablement) unique.

Comme nous l'avons vu dans la section 2, sur toute machine utilisant un logiciel serveur de news classique (INN, par exemple) chaque article est stocké dans un fichier nommé d'après son numéro d'arrivée, lui-même placé dans un répertoire le plus souvent placé sous /var/spool/news et au nom établi d'après celui du forum. Le premier article arrivé sur un serveur donné pour le forum fr.comp.os.unix, par exemple, sera stocké dans un fichier appelé /var/spool/news/fr/comp/os/unix/1 (ceci pour un INN 1.7... Pour un INN 2.2, il s'agira plutôt de /var/spool/news/articles/fr/comp/os/unix/1).

Attention : par «premier article arrivé», il ne faut pas entendre «premier article paru dans le groupe», car un nouveau serveur récupère, sitôt connecté, les articles circulant à ce moment et non les anciens.

Le «Message-id» d'un article donné est le même sur tous les serveurs, mais son «numéro» sur deux serveurs distincts sera très probablement différent.

suck récupère les articles par leur Message-id, or certains serveurs de news dont ceux d'isdnet.net, utilisé par de nombreux fournisseurs d'accès, ont configuré leur système pour que la récupération ait lieu sur le numéro d'article... La récupération classique par suck ne fonctionne donc plus, d'où ces erreurs...

Heureusement, Emmanuel Chantreau a corrigé ce problème en modifiant le code de suck pour lui ajouter une option -n lui permettant de récupérer les articles par leur numéro sur le serveur plutôt que sur leur Message-id. Cette modification a été intégrée à suck à partir de la version 3.8.0.

Cette option a un autre effet, il se trouve qu'elle surcharge moins le serveur distant, je vous conseille donc de l'utiliser systématiquement. Passé d'HOL à Easynet, qui autorise la récupération sur le Message-id, j'ai remarqué que celle-ci provoquait de fréquents «time-out» (tous les 10 articles, environ). L'ajout de l'option -n a corrigé ce problème.

À partir de là, on suppose donc que suck a bien récupéré vos articles. Si ce n'est pas le cas, n'allez pas plus loin, recommencez tout depuis le début : ce ne sera pas une perte de temps...

Pour vous aider dans le dépistage des problèmes, vous pouvez utiliser l'option -D qui créera un fichier debug.suck contenant les traces d'exécution du programme.

7.3 Tests supplémentaires : préparation à l'utilisation de rnews

Si les tests précédents ont donné satisfaction, on peut passer à l'étape suivante pour préparer l'installation de INN et la lecture des articles avec un lecteur de news digne de ce nom...

Au lieu de sauvegarder chaque article dans un fichier séparé comme c'était le cas jusqu'alors, on va créer un fichier de traitement par lots («batch») qui pourra ensuite être traité par le programme rnews de INN (cf. plus loin).

La commande permettant de réaliser cela est la suivante (elle doit être invoquée à partir du répertoire /usr/lib/suck) :

suck news.fai.fr -c -n -H -K -br nouveau

Les options -c -n -H -K ont déjà été décrites plus haut...

L'option -br nouveau indique à suck de créer un fichier dit «batch», qui s'appellera nouveau, contenant tous les articles reçus afin qu'ils puissent ensuite être envoyés à votre serveur de news local via rnews (il existe aussi une option -bi réalisant la même chose en vue d'un traitement par innxmit : toutes les informations sur les formats de ces fichiers batch sont disponibles par la commande man rnews et man innxmit et ne seront donc pas traitées ici).

Attention : Pour une raison que je ne m'explique pas encore, suck dans sa version 3.9.0 refuse de mettre à jour le fichier de batch si celui-ci existe déjà... La seule solution que j'ai trouvé pour l'instant est de renommer celui-ci en nouveau.old avant d'appeler suck. À noter que ce problème n'apparaissait pas avec la version précédente mais qu'il est, de toutes façons, préférable de conserver une version du batch précédent, au cas où...

On va d'abord faire en sorte de récupérer des articles : éditez le fichier /usr/local/etc/suck/sucknewsrc, ôtez la deuxième valeur en face de fr.comp.os.linux et modifiez le chiffre restant (numéro du dernier article récupéré de ce groupe) en lui ôtant 10 : vous devriez donc récupérer au moins 10 articles... Lancez la commande décrite plus haut.

Les choses ont changé par rapport aux premiers tests :

  • le répertoire /usr/local/etc/suck/Msgs est vide ;

  • un fichier nouveau a été créé dans /usr/local/etc/suck

Éditez le fichier nouveau et vérifiez qu'il contient bien les articles reçus (séparés par des champs #! rnews xxxxxxxx est la taille de l'article). Tant que vous n'avez pas installé INN (et donc rnews) vous ne pouvez pas en faire grand chose hormis le parcourir...

Ce qui est important c'est que, si vous êtes arrivés là, vous êtes prêts pour la suite... Sinon, ne continuez pas : assurez-vous que tout ce qui a été décrit plus haut fonctionne correctement !

À noter que suck dispose de l'option -a, lui permettant de mettre en batch tous les articles récupérés même si, pour une raison ou une autre (une déconnexion intempestive, par exemple), il n'a pu terminer la récupération totale. En ce cas, les articles déjà récupérés pourront donc être traités par rnews (sans cette option, suck ne construit le batch qu'après s'être terminé normalement).

Nous allons maintenant passer à l'installation de INN. Certains aspects de suck ont été omis : c'est volontaire car ils n'ont aucun sens tant que notre serveur de news n'est pas installé...