News

Le BR fournit aux élèves environ 250 newsgroups. Dans la plupart des autres école les mailings lists ont été privilégiées mais ici une grande partie de la vie promo se déroule sur des forums. On en trouve de toutes les formes (pour les sections, les binets, les nouveaux bâtiments, l'enseignement, les communautés...).

Présentation des newsgroups

Utilité

Les différents newsgroups sont regroupés par catégories qui permet une plus grande lisibilité. Chaque catégorie de newsgroup a son rôle propre.

• br.binet.* : les newsgroups des binets, pour la com interne et externe des binets
• br.communaute.* : pour regrouper les gens autour de leurs passions, hors des cadres des binets.
• br.section.*, br.promo.*, br.bat.* : pour refléter l'organisation de l'école, et permettre la communication facilement entre les différents groupes constitués par le découpage géographique et administratifs des élèves
• br.informatique.* : pour le dépannage informatique... Il faut bien insister que le BR n'est pas réparateur informatique, et que donc br.binet.br n'est pas adapté pour le dépannage ne dépendant pas du BR.
• br.media.* : pour le partage de medias (personnellement j'ai pas, c'est un peu de l'incitation au piratage)
• br.pa.* : pour les petites annonces, 'ping machin', 'vend truc'...
• br.enseignement.* : pour tout ce qui a rapport à l'enseignement, y compris les 'ping projet machin'
• br.eleves : pour tout ce qu'on ne peut pas ranger autre part.
• br.* : tous les autres newsgroups
• public.* : newsgroups fournit par la DSI dont le BR assure un miroir. Ces newsgroups sont accessible à tout le personnel de l'Ecole
• private.*, control.cancel : newsgroups privés du BR.

Crossposts

Les crossposts sont le seul moyen acceptable de poster un même message sur différents newsgroups. Leur intérêt est de simplifier l'envoi et la lecture des posts :

• Il n'y a besoin que de poster un seul message pour qu'il apparaisse sur plusieurs newsgroups
• Il n'y a besoin de le lire que sur un seul newsgroup
• Toutes les réponses aboutissent au même endroit
• Les newsmestres sont contents
• Les lecteurs sont contens
• Le posteur est content

Il faut tout de même faire attention... il y a une facheuse tendance sur les newsgroups à faire un crosspost sur 50 newsgroups pour 1 message de merde (genre ping clope)...

Faire un crosspost nécessite juste de :

• définir plusieurs newsgroups de destination
• définir un newsgroups de réponse (Follow-up, Transmettre)

Les fups

Les fups, c'est l'art et la manière de forcer quelqu'un à répondre sur le mauvais newsgroups... ça fait bien rire selui qui a fuppé, et ça agace celui qui s'est fait fupper. Il faut en particulier se méfier des vagues de fup (pâles, arrivée des TOS...) qui on tendance à pourir des newsgroups qui hébergent des discussion sérieuses.

Les fups sont bien sûr désactivables via les scripts du serveur.

br.kes

Suite à l'AG Kès de juin et aux trolls qui on pourrit br.kes à l'issue, la Kès a demandé à ce que br.kes ait un régime spéciale :

• tout le monde peut initier une discussion
• les fups vers br.kes sont interdits
• les kessiers peuvent faire ce qu'ils veulent.

Gestion du serveur de news

Le serveur de news est hébergé sur le serveur désigné par l'alias DNS newsgroups. La machine actuelle est Frankiz.

Le serveur news utilisé est inn2. Bien qu'inn soit présent dans l'arbre portage, on a jamais réussi à faire fonctionner la version de Gentoo. Inn est donc installé manuellement à partir d'un tar des sources de la version 2.3.5 (la dernière version en date est la 2.4.2).

Il est fortement conseillé aux newsmestres et aux roots de rajouter /usr/lib/news/bin dans leur PATH

Installation

Pour installer inn, il faut compiler ses sources proprement :

cp ~fruneau/inn-2.3.5.tar.gz
tar -xvvzf inn-2.3.5.tar.gz
cd inn-2.3.5
CFLAGS="-O3 -s -pipe -march=pentium4 -fomit-frame-pointer" ./configure --prefix=/usr/lib/news --with-perl --with-spool-dir=/var/spool/news --with-sendmail=/usr/sbin/sendmail
make -j2
sudo make install

TODO : il y a aussi un patch pour inn qui permet d'avoir entre autre un assouplissement de la règle sur le format des email pour que login@poly soit valable et d'avoir des messages d'erreur en français. Actuellement ce patch est pour inn 2.4.1 et ne semble pas fonctionner sur les sources de inn 2.3.5. Donc il faudrait faire un package des sources prépatchées.

Pour rendre la configuration pratique, on peut également rajouter quelques liens symboliques :

/etc/news -> /usr/lib/news/etc
/var/spool/news/bin -> /usr/lib/news/bin
/var/lib/news -> /var/spool/news/db
/usr/lib/news/db -> /var/spool/news/db

runscript et crontab pour inn

La compilation à la main de inn ne fournit pas la mise en place automatique de la crontab et du script de lancement de inn.

Le runscript qu'on utilise (/etc/init.d/innd) est adapté de celui fournit par Gentoo dans la version d'inn qui se trouve dans portage :

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-news/inn/files/innd,v 1.7 2004/09/07 22:29:04 swegener Exp $

depend() {
        need net
}

start() {
        ebegin "Starting innd"
        su - news -c /usr/lib/news/bin/rc.news
        eend $?
}

stop() {
        ebegin "Stopping innd"
        su - news -c '/usr/lib/news/bin/rc.news stop'
        sleep 2
        eend $?
}

La crontab contient des utilitaires qui assurent la maintenance du spool et la génération de statistiques pour Frankiz.

• Crontab du user news (ATTENTION ce script doit impérativement être exécuter avec les droits news)

0 3 * * * /usr/lib/news/bin/news.daily expireover lowmark

• Crontab du user root :

# Stats news
#graphe:
*/30 * * * * /home/news/bin/stat_graphe/main.sh
#stats plus gros posteurs:
0 5 * * * /home/frankiz2/bin/news_stats_gros_posteurs.pl

#stats 'funny'
30 6 * * * /home/frankiz2/bin/news_stats_premiers_posteurs.pl 1>/dev/null
0 7 * * * /home/frankiz2/bin/news_stats_premiers_posteurs.pl 1>/dev/null
15 7 * * * /home/frankiz2/bin/news_stats_premiers_posteurs.pl 1>/dev/null
30 7 * * * /home/frankiz2/bin/news_stats_premiers_posteurs.pl 1>/dev/null
45 7 * * * /home/frankiz2/bin/news_stats_premiers_posteurs.pl 1>/dev/null
30 8 * * * /home/frankiz2/bin/news_stats_premiers_posteurs.pl 1>/dev/null

Configuration

Installation initiale

Toute la configuration des news se trouve sur la CVS dans le module news qui n'est accessible qu'aux newsmestres et aux roots. Lors d'une installation de inn en partant de 0, à partir de la configuration précédente, pour installer la configuration, il suffit d'écraser /usr/lib/news avec le contenu de ce module :

cd /usr/lib
/etc/init.d/innd stop
mv news news-save
sudo -u news cvs -d $login$@gwz:/home/cvs co news
/etc/init.d/innd start

Si ça marche, rien d'autre à faire, sinon il faut chercher d'où vient l'erreur. En particulier attention à certains droits sur des scripts qui au lieu d'être news:news, sont root:news avec +s :

-r-sr-x---  1 root news  67K 2005-06-01 20:56 inndstart*
-r-sr-x---  1 root news  35K 2005-06-01 20:56 startinnfeed*

Tous les autres fichiers doivent impérativement être avec des droits news:news.

Modification de la configuration

Pour modifier la configuration des news, il faut impérativement le faire via la CVS. Ceci se fait en 2 étapes :

Tout d'abord, il faut récupérer le module news sur sa machine :

cvs -d $login$@gwz:/home/cvs co news

Ensuite, il faut faire les modifications nécessaire, puis commité ces modifications

cvs ci fichier_modifié

Une fois la modification sur la CVS, il faut updater la conf du serveur. Pour ceci il y a un script dans les binaires disponibles sur la CVS (donc si l'installation a été faite comme indiqué au dessus, il est dans le /usr/lib/news/bin). Il suffit alors de faire :

sudo -u news /usr/lib/news/bin/fetch_cvs_news $logingwz$

Attention, il arrive qu'il y ait des conflits CVS lors des fetch sans pourtant avoir eu de modification sur la version du serveur (sans doute à cause de problème dans les droits d'écriture). Il faut alors supprimer le fichier en cause et refaire un fetch.

Et la dernière chose à faire, est de toujours vérifier que tout se passe bien avec un

tail -f /var/log/news/news.err

Migration/Récupération du spool

Il peut y avoir des cas où le spool est corrompu. Ca intervient soit à la suite d'une réinstallation, soit après une coupure brutale du serveur de news. Il faut alors reconstruire l'historique. Avec l'installation faite comme précédemment l'historique se trouve physiquement avec le spool, ce qui simplifie la migration de spool.

Pour migrer un spool, il suffit donc de copier /var/spool/news à sa nouvelle destination.

Dans le cas d'une installation différente, la plupart du temps, l'historique est séparé du spool, il faut alors copier /var/lib/news et /var/spool/news

Dans le cas où l'historique est corrompu (serveur fonctionnel, mais impossible de poster de nouveau message) :

/etc/init.d/innd stop
sudo -u news
cd /var/lib/news
makehistory -b -f history.n -O -l 30000 -I
awk 'NF == 2 { print }' < history >> history.n
makedbz -s `wc -l < history`-f history.n
mv history.n history
mv history.n.dir history.dir
mv history.n.hash history.hash
mv history.n.index history.index
/etc/init.d/innd start

Si des problèmes apparaissent encore (en particulier sur Outlook Express), il sera parfois nécessaire de lancer le script de maintenance :

sudo -u news
cd /usr/lib/news/bin
./news.daily

Documentation

Une bonne doc se trouve ici

Configuration et Administration du serveur de news

Toute la configuration du serveur de news est sur la SVN. Les modifications doivent donc être faites offline sur un checkout de la SVN, commitées puis appliquées à la version de prod. Il est donc fortement conseillé d'avoir un serveur INN sur la machine d'un newsmestre pour faire des tests !!!

Un peu de culture...

Inn est un programme relativement complexe, mais extrêmement complet. Le plus dur est de l'installé (mais ça c'est expliquer au dessus ;), ensuite tout se fait relativement facilement. Il est tout de même conseillé de connaître un minimum la structure de inn.

Globalement inn est composé de plusieurs programmes :

• innd est le démon. Il écoute et centralise... c'est le coeur du programme en gros :)
• nnrpd est un programme qui gère une connexion. En gros à chaque fois que quelqu'un se connecte au serveur (donc à innd), innd fork et créant un nnrpd. Ce nnrpd est alors initialisé en utilisant la configuration qui existe lors de sa création (filtres, readers.conf...). Donc il ne faut pas s'inquiéter si la modification de la configuration n'est pas prise en compte immédiatement... De toute façon nnrpd a une durée de vie très limitée.
• innfeed est le programme qui fait le pont avec les autres serveurs news. C'est lui qui permet la synchronisation avec polynews.
• innwatch vérifie que inn est encore en vie...
• ctlinnd est le programme d'administration du serveur. Il permet de supprimer/créer des newsgroups, mettre le serveur en veille, annuler des messages, des/activer les filtres sur les messages...

Lorsque inn est arrêté, ces programmes fils ne meurts pas immédiatement. En particulier innwatch et les nnrpd lui survivent plus ou moins une minute.

Lors d'une modification de la configuration, il est fortement conseillé d'attendre 5 minutes en lançant un tail -f /var/log/news/news.err. En particulier lorsque le filtre perl est mauvais, inn continue à fonctionner de manière transparente sans filtre...

Utilisation de ctlinnd

Pour plus de simplicité d'utilisation, il est conseillé de mettre /usr/lib/news/bin dans son path... ce qui donne un accès direct à innd.

L'utilisation de cltinnd est très simple :

• ctlinnd newgroup machin.truc pour créer un nouveau newsgroup
• ctlinnd rmgroup machin.truc pour supprimer un newsgroup
• ctlinnd cancel 'message-id' pour supprimer un message. Le message id est le contenu de l'en-tête Message-ID, sans les < >... Et puis il faut bien se rappeller que les clients news ont un cache des messages... et donc c'est normal si après annulation on peut encore voir le message (le mieux est de tenter de le revoir avec un autre client news, genre slrn sur un serveur).
• ctlinnd throttle "raison" met en pause le serveur qui n'acceptera plus de message. Inn passe automatiquement en mode throttle lorsque la charge du serveur devient trop importante.
• ctlinnd go "raison" réactive le serveur
• ctlinnd -h pour toutes les commandes ;)

ctlinnd peut-être lancé de manière transparente depuis le compte news ou le compte root contraiment à pas mal d'autres utilitaires de inn

Changement de la taille maximale des posts

La taille maximale des posts est définie dans la configuration de base de Inn : /etc/news/inn.conf

keyartlimit:             taille max en octets
maxartsize:              taille max en octets

La taille habituelle est de 100ko maximum, mais en cas d'abus généralisés on passe à 20ko. L'intérêt est d'avoir la possibilité de poster facilement une image sur br.pa pour illustrer les annonces de vente.

Lien avec Polynews

Le lien avec polynews est une synchronisation des public.*. D'après les derniers tests que j'ai fait polynews récupère bien les posts qui sont sur Frankiz, mais j'ai un doute sur le sens inverse...

Le lien avec polynews est définie dans plusieurs fichier. Tout d'abord dans /etc/news/incoming.conf on indique que polynews va servir à nourir les public.*. Il suffit de laisser les options par défaut, et de rajouter le groupe :

peer polynews {
        hostname:         polynews.polytechnique.fr
        patterns:         public.*
}

Dans /etc/news/innfeed.conf, il faut lui dire explicitement d'aller chercher sur polynews en lui définissant le même genre de groupe :

peer polynews {
        hostname:               polynews.polytechnique.fr
}

Avec ça, innfeed sait qu'il doit aller chercher les posts sur polynews et les stocker dans public.*... il ne reste plus qu'à lui dire d'utiliser innfeed. Pour ceci il faut définir une règle dans /etc/newsfeeds :

polynews:public.*:Tc,Wnm*,S30000:/usr/lib/news/bin/startinnfeed

Droits d'accès aux newsgroups

Un fichier readers.conf illégal (mauvais droits d'accès, erreur de syntaxe) est bloquant et empêche tout le monde de se connecter au serveur de news, toute modification doit être donc faite proprement sur SVN et le fetch doit être fait avec le droit news (et pas les droits root !!!)

Les droits d'accès sont gérés par le fichier /etc/news/readers.conf. Ce fichier a une structure relativement simple :

1. on défini des groupes de personnes
2. on applique des règles à ces groupes

Lorsqu'une personne se connecte à Inn, le serveur va rechercher dans le fichier readers.conf la dernière règle qui correspond à cette IP. Donc il faut bien faire attention à ce que les actions par défaut se trouvent en début de liste, et les cas particuliers (ban, accès privés...) vers la fin.

Les groupes sont de la forme :

auth "nom_du_group" {
        hosts: "liste des ips"
        default: "<petitnom>"
}

La liste des ip peut contenir des patterns de la forme 129.104.201.* ou 129.104.201.0/24. Les différents éléments de cette liste sont séparés par des , (virgule).

Les règles sont de la forme :

 access "nom_de_la_regle" {
        users: "liste des groupes"
        [droits d'accès]
}

La liste de groupes contient une liste des <petitnom> séparés par des virgules.

Les droits d'accès peuvent être de différentes formes...

• Gestion sépérée des droits de lecture et écritures. Par exemple :

read: "br.*, public.*"
post: "public.*"

• Définition globale des droits d'accès :

newsgroups: "br.*, public.*"
access: "RPN" # en cas d'absense de access, RPN est la règle par défaut (Read, Post, New)

Donc, pour être simple, pour banner quelqu'un il suffit :

1. de rajouter un groupe (si il n'existe pas encore) <banned> :

auth "banned" {
       hosts: "129.104.209.131"
       default: "<banned>"
}

1. de rajouter la règle en dernière position

access "banned" {
       users: "<banned>"
       newsgroups: ""
}

Les règles existent déjà dans la version actuelle mais son juste commentées... en attente de réutilisation.

La modification du reader.conf ne nécessite pas le redémarrage de Inn, le fichier est lu à chaque connexion de client

Les filtres perls

Lorsque qu'une personne poste sur un newsgroup, son message n'est pas immédiatement accepté. Il doit d'abord passé par un filtre qui va analyser/modifier les en-têtes pour que le post soit conforme à ce qu'on attend. Les actuels font :

• Homogénisation de l'heure du post à celle du serveur
• Vérification des crossposts et rajout de [=> newsgroup] le cas échéant
• Filtrage de br.kes

Chaque composant de Inn peut appelé des scripts de la forme filter_composant.pl. Le BR utilise 2 des filtres. Ceux-ci sont stockés dans /usr/lib/news/bin/filter.

1. filter_innd.pl : définie des règles générales à appliquer aux message. Ce script est lancé avec innd.
2. filter_nnrpd.pl : définie des règles de filtrage sur le message

De manière générale, ces fonctions fichiers reçoivent pour chaque fichier un %hash des en-têtes du fichier, peuvent modifier le contenu de ce %hash, et doivent retourner en ayant mis auparavant la valeur qui va bien dans $rval : si $rval est vide ("") le message est accepté, si au contraire il est non vide, le message est refusé et son contenu est envoyé comme message d'erreur au posteur.

filter_nnrpd.pl

Analyse le message et applique les changement comme indiqués ci-dessus. La plupart des règles sont relativement simple, il suffit de comparer les en-têtes Followup-To et Newsgroups et pour ça les expressions régulières de perl sont vraiment très puissant.

La partie critique de ce fichier est la gestion de br.kes. Cette partie a été mise en place ne juin 2003 suit à la demande la Kès dans le but d'éviter les trolls sur br.kes. Ce filtre analyse l'origine du post, les newsgroups de destination et de followup de manière à donner les accès qui vont bien aux kessiers. Globalement :

• N'importe qui peut poster un message à la racine (à condition qu'il ne contiennet pas Re : ou Ans : ...
• Les fups vers br.kes sont interdit, de même que les crossposts
• Les kessiers peuvent faire ce qu'ils veulent avec br.kes

Ce filtre fonctionne à partir de la liste des IP des kessiers stockées en dur dans le fichier, il faut donc mettre à jour cette liste au changement de Kès !!!

filter_innd.pl

Ce filtre défini les règles à appliquer au message en fonction du résultat de filter_nnrpd.pl.

Dans sa version actuelle, ce script stocke les en-tête des messages acceptés dans une base SQL (ce qui permet en particulier de simplifier les statistiques news...

Après une modification des filtres, il faut les recharger. Ceci est fait automatiquement par le script de fetch, mais en cas de besoin il faut utiliser le script qui suit :

#!/bin/sh
ctlinnd reload all ""
ctlinnd reload filter.perl ""
ctlinnd perl y
ctlinnd mode

La moitié de ce script ne sert à rien mais c'est toujours important de tout refaire pour être sûr que c'est bien activer (et d'aller voir /var/log/news/news.err)

Sur la SVN, les scripts existent en 2 version stable et testing, il y a les scripts bascule et restore qui permettent de passer de stable à testing et inversement. Dans l'état actuel des choses ces scripts n'ont pas grand chose de différent (si ce n'est que le filtrage br.kes est encore en testing).

Voilà, je ne pense pas avoir oublié grand chose... Have fun