|
|
| (23 versions intermédiaires par 7 utilisateurs non affichées) |
| Ligne 1 : |
Ligne 1 : |
| | {{Archive|Les newsgroups ont été enterrés par le br2010. Aucun besoin n'en est ressenti. (janvier 2013)}} |
| | {{menu services}} |
| 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...). | | 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 == | | == Configuration == |
| | Depuis l'extérieur comme depuis l'intérieur, on peut se connecter aux news avec les paramètres suivants: |
| | * serveur : '''news.frankiz.net''' |
| | * port : '''563''' (Connection '''ssl''') |
| | * authentification: '''prenom.nom.x''' / mdp de frankiz |
|
| |
|
| === Utilité ===
| | Selon les clients, la tolérance par rapport au certificat est plus ou moins grande. Pour trouver le certificat du BR, aller sur http://frankiz.net/ca-br.crt. Sous thunderbird, il faut aller l'ajouter dans préférences->avancé->certificats->voir les certificats->authorités. |
| | |
| | [[Configuration des brs sur iPhone]] |
| | |
| | == Utilité des Newsgroups == |
|
| |
|
| 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. | | 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.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.communaute.*''' : pour regrouper les ''gens'' autour de leurs passions, hors des cadres des binets. |
| | * '''br.evts.*''' : pour favoriser la communication lors d'un événement ponctuel. Pour toute demande de création de newsgroup temporaire contacter [mailto:news@frankiz.polytechnique.fr les newsmestres]. |
| * '''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.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.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.informatique.media.*''' : pour le partage de medias |
| * '''br.pa.*''' : pour les petites annonces, 'ping machin', 'vend truc'... | | * '''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.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.eleves''' : pour tout ce qui concerne tous les élèves, ou au moins une grosse partie. |
| * '''br.*''' : tous les autres newsgroups | | * '''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 | | * '''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. | | * '''private.*''' : newsgroups privés appartenant aux binets hébergés par le BR. Ces newsgroups ne sont pas modérés par le BR. Le président du binet est responsable de la bonne utilisation du newsgroup. Pour la création d'un private remplir une fiche de demande à la Kès dans la case du BR et envoyer la liste des personnes ayant accès au newsgroup privé [mailto:news@frankiz.polytechnique.fr aux newsmestres]. |
|
| |
|
| === Crossposts ===
| | == 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 : | | 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 : |
| Ligne 28 : |
Ligne 39 : |
| * Le posteur est content | | * 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)...
| | {{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 : | | Faire un crosspost nécessite juste de : |
| Ligne 34 : |
Ligne 45 : |
| * définir un newsgroups de réponse (Follow-up, Transmettre) | | * définir un newsgroups de réponse (Follow-up, Transmettre) |
|
| |
|
| === Les fups ===
| | == 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, c'est l'art et la manière de forcer quelqu'un à répondre sur le mauvais newsgroups... ça fait bien rire celui 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 à pourrir des newsgroups qui hébergent des discussion sérieuses. |
|
| |
|
| Les fups sont bien sûr désactivables via les scripts du serveur. | | Les fups sont bien sûr désactivables via les scripts du serveur. |
|
| |
|
| | == Historique == |
| === br.kes === | | === br.kes === |
| | | Suite à l'AG Kès de juin 2005 et aux trolls qui on pourrit br.kes à l'issue, la Kès a demandé à ce que br.kes ait un régime spécial : |
| 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 | | * tout le monde peut initier une discussion |
| * les fups vers br.kes sont interdits | | * les fups vers br.kes sont interdits |
| * les kessiers peuvent faire ce qu'ils veulent. | | * les kessiers peuvent faire ce qu'ils veulent. |
|
| |
|
| == Gestion du serveur de news ==
| | Cette disposition a été retirée à l'automne 2007, n'étant plus vraiment nécessaire. Il est bien sûr possible de la remettre en place à tout moment sur demande de la Kès si les pourrissages recommencent. |
| | |
| 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 [[FrankizII|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 [http://absolut.taket.org/?page=inn2 ici]
| |
| | |
| | |
| == Configuration et Administration du serveur de news ==
| |
| | |
| Toute la configuration du serveur de news est sur la [[Subversion|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 ;)
| |
| | |
| <div style="border: 1px solid #6f8f9f; padding: .2em .5em .2em .5em; background-color: #EAF5FB">
| |
| ctlinnd peut-être lancé de manière transparente depuis le compte news ou le compte root contraiment à pas mal d'autres utilitaires de inn
| |
| </div>
| |
| | |
| === 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 ===
| |
| | |
| <div style="border: 1px solid #6f8f9f; padding: .2em .5em .2em .5em; background-color: #EAF5FB">
| |
| 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 !!!)
| |
| </div>
| |
| | |
| Les droits d'accès sont gérés par le fichier /etc/news/readers.conf. Ce fichier a une structure relativement simple :
| |
| # on défini des groupes de personnes
| |
| # 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 :
| |
| # de rajouter un groupe (si il n'existe pas encore) <banned> :
| |
| auth "banned" {
| |
| hosts: "129.104.209.131"
| |
| default: "<banned>"
| |
| }
| |
| # 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.
| |
| | |
| <div style="border: 1px solid #6f8f9f; padding: .2em .5em .2em .5em; background-color: #EAF5FB">
| |
| La modification du reader.conf ne nécessite pas le redémarrage de Inn, le fichier est lu à chaque connexion de client
| |
| </div>
| |
| | |
| === 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.
| |
| # '''filter_innd.pl''' : définie des règles générales à appliquer aux message. Ce script est lancé avec innd.
| |
| # '''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
| |
| | |
| <div style="border: 1px solid #6f8f9f; padding: .2em .5em .2em .5em; background-color: #EAF5FB">
| |
| 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 !!!
| |
| </div>
| |
| | |
| '''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
| |
Nos services