Qu'est-ce que Usenet au juste
?
Usenet est le terme générique employé pour parler
de ce qu'on nomme le plus souvent ``les forums de discussion'' ou ``News''
(ou, comme les appellent certains magazines, les "infogroupes").
Usenet diffère du courrier électronique parce qu'il permet
des discussions de N vers N, et non plus de 1 vers 1 (ou de 1 vers N
dans le cas des listes de discussion). Si le courrier électronique
est un dialogue, et les listes de diffusion sont une table ronde, Usenet
est une série de salles de réunions publiques thématiques
ouvertes à tous.
Le terme Usenet englobe tous les espaces publics de discussion "en
différé", c'est à dire dans lesquels un intervenant
poste un article qui sera lu par tous, et auquel il pourra être
répondu plus tard (à l'inverse de l'IRC par exemple) par
n'importe qui, qui utilisent le protocole NNTP (Network News Transfer
Protocol).
Ces espaces publics, salles de réunions thématiques virtuelles,
sont réunis selon différentes langues ou différentes
organisations. On parle de "hiérarchies" 1 différentes
pour séparer ces ensembles.
Chaque hiérarchie est organisée en forums thématiques.
L'usage veut que le nom de chaque forum soit formé de plusieurs
mots séparés par des points. Le premier mot est commun à toute
la hiérarchie (c'est d'ailleurs le plus souvent le nom donné à la
hiérarchie: on parle de la hiérarchie "fr" pour
l'ensemble des forums dont le nom commence par "fr.", le second
spécifie le cadre général des discussions dans ce
forum (social, informatique, artistique ou autre), les mots suivants
définissent plus ou moins précisément selon leur
numéro d'ordre le thème particulier du forum 2
Un forum dont le nom serait, par exemple, fr.rec.sport.voile.planche
fera partie de la hiérarchie "fr" (et sera donc régi
par les règles d'usage générales définies
pour cette hiérarchie), dans le domaine RECréatif, et traitera
plus spécifiquement des SPORTs de VOILE utilisant une PLANCHE,
autrement dit de la planche à voile. Une courte description est
en général associée à un nom de forum. Pour
notre exemple, la description pourrait être "Discussions sur
la planche à voile", ce qui ne laissera aucun doute quant
au thème abordé par les utilisateurs du forum.
Dans chacun de ces forums se déroulent donc des conversations
dont le thème dépend du titre et de la description du forum.
Il peut y avoir un grand nombre de discussions séparées
les unes des autres à l'intérieur d'un seul et même
forum, chacune étant distincte des autres grâce aux titres
des articles postés dans cette discussion, et grâce aux
références techniques qui sont présentes dans les
champs techniques prévus à cet effet dans chaque article
3
Au niveau du forum, tout utilisateur est soit un lecteur passif, qui
se contente de suivre les débats, soit un utilisateur actif, qui
poste des articles. Ce sont ces articles qui constituent le contenu du
forum et qui, lorsqu'ils participent d'une seule conversation, sont regroupés
sous forme de [thread/fil/enfilade].
Un article posté dans un forum peut être lu par n'importe
qui, à n'importe quel moment sur le serveur tant que la date d'expiration
de l'article n'est pas dépassée. Cette "date d'expiration" varie
selon les serveurs qui stockent les articles du forum, mais certains
systèmes comme http://www.deja.com/ permettent de lire des articles
postés depuis plus de 2 ans.
Comment ça fonctionne ?
Côté serveur
* Prenez un ordinateur (nommons-le "1"), et ses utilisateurs.
* Créez sur cette machine un 'tableau noir' sur lequel tout utilisateur
peut laisser un message aux autres, et y répondre.
* Ajoutez un second ordinateur doté du même outil, et ses
utilisateurs. (Penser à relier le second au premier). Nommons-le "2".
* Développez un protocole d'échange permettant au 'tableau
noir' du premier d'envoyer les messages qui sont écrits sur "1" vers "2",
et réciproquement.
A ce stade nous disposons de deux "espaces" séparés
mais dont le contenu est identique à tout instant, contenu formé par
les articles postés indifféremment sur l'un ou sur l'autre.
* Ajoutons une troisième machine, reliée aux deux autres
pour former un triangle (avec deux liens, un par machine, donc) et doté du
même outil. Nous l'appellerons "3" pour faire preuve
d'originalité.
Le protocole développé doit maintenant permettre un échange
de messages à trois:
"1" envoie un message à "2".
"
3" envoie un message à "1".
"1" et "2" ont donc reçu chacun un message.
Le premier est commun à "1" et "2", le second
est commun à "1" et "3". Or nous voulons que
tous les messages soient reçus par tous les ordinateurs. Il y
a plusieurs solutions:
"2" peut décider d'envoyer le message reçu de "1" à "3".
Ou "1" peut décider de renvoyer son message à "3" juste
après l'avoir envoyé à "2". De même, "3" peut
envoyer son message à "2" comme "1" peut l'envoyer
au même "2" à tout instant. Ça fait un
bel embrouillamini, il faut mettre des étiquettes aux messages:
puisque "2" risque de recevoir un message de "1" à la
fois de "3" et de "1", alors il va regarder l'étiquette
de chaque message qu'il reçoit, et refuser de recevoir un message
dont l'étiquette est déjà présente sur son
tableau. "1" et "3" feront de même.
Le protocole une fois bien construit pour éviter les messages
en doubles tout en assurant la bonne diffusion desdits messages, ajoutez
autant d'ordinateurs que nécessaire pour le nombre de convives
envisagé. Vous avez terminé votre NNTP, et Usenet est né.
Côté client
Lorsque votre lecteur de News va se connecter pour la première
fois à votre serveur local (en général celui de
votre fournisseur d'accès à Internet, le plus couramment
nommé news.nom-de-votre-fournisseur.fr), il va lui demander la
liste des forums de discussion dont celui-ci dispose: un serveur peut
en effet ne recevoir qu'une partie des différentes arborescences
(hiérarchies) décrites plus haut, ou seulement certaines
parties de certaines hiérarchies.
Vous aurez alors à votre disposition une liste de thèmes,
donc de forums, que vous pourrez parcourir au hasard de vos intérêts.
Ou bien encore parmi lesquels vous allez faire votre choix et sélectionner
uniquement les groupes qui recouvrent vos intérêt, de
manière à ce que votre lecteur ne vous présente
par la suite que la liste de ces groupes choisis. Cette opération
est abusivement appelée 'abonnement' ou 'désabonnement' à un
groupe ('subscribe' ou 'unsubscribe'). En réalité il
ne s'agit que de constituer la liste des forums dont votre lecteur
ira chercher le contenu sur son serveur.
Une fois cette liste établie, lorsque vous ouvrirez l'un de
'vos' groupes, votre lecteur affichera les différentes discussions
en cours dans ce groupe. A vous alors d'y participer, en simple lecteur
ou en participant actif. En règle générale, il
est conseillé, avant d'intervenir activement dans un tel forum,
de n'agir qu'en simple lecteur durant un certain temps, variable selon
les personnes et les groupes, mais suffisant pour vous faire une idée
des thèmes et des débatteurs. Comme lorsqu'on débute
en société, il vaut mieux attendre de savoir un peu à qui
l'on s'adresse et de quoi l'on cause avant de l'ouvrir: il n'est pas
rare par exemple qu'un nouvel utilisateur inattentif poste une question
technique sur le fonctionnement de son traitement de texte dans le
groupe fr.usenet.logiciels, qui s'il traite bien de logiciels, ne traite
que des logiciels en rapport avec Usenet, tels que serveurs ou lecteurs
de news.
Si vous décidez d'intervenir, vous pouvez alors soit répondre
directement à l'auteur d'un article, s'il s'agit par exemple
d'une question technique dont vous connaissez la réponse c'est
même conseillé: c'est à l'auteur de la question
de poster une synthèse des réponses qu'il aura reçu
en public, de façon à éviter que chacun, pensant
se rendre utile, poste en X exemplaires la même réponse.
Vous pouvez aussi décider de poursuivre en public une discussion,
ou d'en lancer une vous-même (voir ci-dessous: Lisibilité).
Dans ce cas, il s'agira d'un 'follow-up' et l'article sera posté sur
votre serveur puis propagé par ce dernier à tous les
serveurs du monde qui hébergent ce même forum sur lequel
vous intervenez.
Ce type de règles, en réalité relevant le plus
souvent de la simple courtoisie mais qui tiennent aussi compte de la
spécificité d'un espace de débats ouvert à tous,
il s'agit par exemple pour les plus élémentaires:
Lisibilité
Choisissez un sujet précis et concis lorsque vous ouvrez une
discussion. Limitez la taille de vos lignes à 70 caractères
de manière à ce que votre texte puisse être décalé à droite
sous forme de citation par celui qui vous répondra sans que
cette citation ne déborde des 80 caractères qui limitent
bon nombre de terminaux. Faites le plus possible attention à votre
orthographe, puisque vous vous exprimez en public. Lorsque vous citez
un article ne citez que les quelques lignes auxquelles vous répondez
plutôt que l'article en entier...
Utilité
Souvenez-vous que, contrairement au courrier électronique,
un article posté sur Usenet sera potentiellement lu par un nombre
considérable de personnes. N'entretenez pas de conversations
privées dans un groupe public (le courrier électronique
est fait pour ça). Évitez de réagir trop violemment,
ce qui ne peut que dégénérer en engueulades
(flame-war) publiques et inutiles. Éviter de poser une question
qui à l'évidence
aura déjà été posée des centaines
de fois sur ce groupe, parce que trop générique. Il
existe pour chaque groupe une FAQ (Foire Aux Questions), document
reprenant
ces questions par trop habituelles et y répondant (voir Terminologie).
Courtoisie
Ne publiez pas en public un message reçu en privé sans
l'accord de son auteur. Même s'il vous semble que votre article
est particulièrement important, ne le postez pas dans chacun
des groupes que vous lisez: il ne correspondrait sûrement par à la
charte de chacun de ces groupes. Lorsque vous voulez malgré tout
poster un article identique dans plusieurs groupes (pas plus de 3
ou 4, en tout état de cause, au delà ce serait considéré comme
un abus des ressources du réseau), utilisez un "cross-post" (voir
Terminologie) plutôt que de poster l'article séparément
dans chacun des groupes (multi-post), et ajoutez un champ "Followup-To" pour
que la discussion qu'engendrera votre article n'ait lieu que dans
un seul groupe, le plus adéquat.
Ce savoir-vivre a peu à peu acquis une réalité tangible,
et ces règles sont réunies sous le nom de 'nétiquette',
dont une grande partie traite des règles de comportement à utiliser
sur Usenet. Un tel média ouvert à tous est en effet un écosystème
fragile qui ne peut fonctionner bien que si chacun y met un peu du
sien. En particulier, depuis peu, on peut trouver pour presque chaque
forum francophone une "charte", initialement rédigée
lors de la création du forum, et qui rappelle les règles
en usage sur ce forum précis. Ces chartes sont postées
régulièrement deux fois par semaine sur chacun des forums
francophone ainsi que dans le forum fr.usenet.reponses: il vous sera
donc facile de la trouver et de la lire avant tout autre chose lorsque
vous découvrirez un forum parlant d'un thème qui vous
concerne. Ces chartes sont aussi disponibles sur un site Web qui les
regroupe toutes: http://www.usenet-fr.news.eu.org/. Vous y trouverez
aussi différents documents, tels que la 'nétiquette',
en rapport avec le bon usage d'Usenet.
Un article
Désossage d'un article typique:
Path: jussieu.fr!freenix!ecole.fr!not-for-mail
From: Dave Null <dave@nowhere.fr>
Newsgroups: fr.usenet.divers
Subject: Re: Cours Usenet
Date: 22 Jun 1999 18:30:00 +0200
Organization: Ecole Ouverte
Lines: 10
Message-ID: <85n1xqkpbz.fsf@serveur.ecole.fr>
References: <7kri05$etv$1@serveur.ecole.fr>
NNTP-Posting-Host: news.ecole.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
NNTP-Posting-Date: 22 Jun 1999 18:30:00 GMT
"Olivier Ricou" <ricou@ecole.fr> disait:
> Ce cours est trop long.
C'est vrai, mais on essaye d'aborder Usenet dans un peu tous ses aspects
sans pour autant négliger d'entrer dans le détail, alors
c'est long,
forcément.
--
Dave Null
4
On voit qu'avant l'article proprement dit, un certain nombre de champs
techniques sont présents. Certains servent à identifier
l'auteur, l'heure, la date, l'organisation et le format du contenu.
Ces champs seront utilisés par le logiciel de lecture pour présenter
l'article. D'autres sont utilisés par les serveurs, pour retransmettre
ou pour stocker l'article dans la base des articles courants.
Le champ 'Path' est utilisé par le serveur. Il indique que
l'article a été posté sur le serveur "ecole.fr".
Que ce serveur l'a envoyé au serveur "freenix" qui
lui-même l'a envoyé au serveur "jussieu.fr",
serveur sur lequel on a lu l'article ainsi présenté.
Ce champ aura une autre valeur sur un autre serveur, qui l'aura reçu
par d'autres voies. Le serveur qui reçoit un article peut se
baser sur ce champ pour éviter de proposer cet article aux serveurs
par lesquels il est déjà passé, même s'il
dispose d'une voie directe vers ces serveurs.
Le champ 'From' est l'adresse e-mail de l'auteur de l'article. Il
ne sert qu'aux outils de lecture des news et à leurs utilisateurs
pour identifier l'auteur d'un article. Certains utilisent, pour éviter
l'abondance de courriers publicitaires, une adresse maquillée.
Mon opinion est que non seulement c'est inutile (un spammeur dispose
de bien des moyens pour connaitre votre adresse, pas seulement sur
Usenet) et qu'il est plus efficace de lutter contre le spam plutôt
que de se contenter d'essayer de s'en protéger, mais qu'en plus
c'est une technique assez discourtoise: les outils de lecture des News
permettent de répondre en privé via le courrier électronique.
En maquillant votre adresse, vous risquez surtout de voir une réponse
privée ne jamais arriver parce que votre correspondant ne se
sera pas aperçu dudit maquillage, ou, dans le cas ou vous indiquez
clairement un tel maquillage, de contraindre un correspondant à éditer
manuellement l'adresse pour pouvoir vous répondre, ce qui prend
du temps et comporte des risques d'erreur manuelle. Ne comptez pas
sur moi pour faire autant d'efforts: si vous voulez une réponse
c'est à vous de simplifier le travail de ceux qui voudront bien
vous aider. Et si vous êtes spammés pour avoir utilisé en
public votre adresse, rejoignez ceux qui luttent contre le spam (un
bon site anglophone traitant du spam est http://spam.abuse.net/spam/).
Le champ 'Newsgroups' est utilisé par le serveur pour plusieurs
raisons.
Lorsque le serveur reçoit l'article, il le stocke physiquement
là où il pourra le retrouver lorsqu'un client lui demandera
les articles du ou des forums indiqués. 5 Le nom du ou des forums
correspond donc souvent à un répertoire particulier sur
le disque dur du serveur.
Lorsque le serveur a stocké l'article, il va le proposer à tous
ses voisins (du moins à ceux qui n'apparaissent pas dans le
champ 'Path') à condition que l'administrateur des voisins aient
demandé à l'administrateur du serveur local de lui envoyer
les articles du forum (ou d'un des forums) en question.
Pour la hiérarchie francophone, en règle générale,
les serveurs s'échangent tous les forums. Mais ça n'a
rien d'obligatoire.
Le champ 'Subject' permet au client Usenet de présenter l'article
avant sa lecture. En association avec le champ 'References', il permet
aussi au client de regrouper les articles d'une même discussion
sous une forme plus agréable à lire.
Les champs 'Date, Organization et Lines' sont utilisés par
les clients et n'ont pas besoin d'être expliqués.
Le champ 'Message-ID' est l'étiquette de ce message. Elle est
unique à cet article et permet de le retrouver via les différents
moteurs de recherche si nécessaire. C'est aussi cette étiquette
qui va être présentée aux serveurs voisins (peers)
qui diront s'ils ont déjà reçu l'article par d'autres
voies ou s'ils l'acceptent.
Le champ 'References' est utilisé par le client. Il fournit
l'étiquette de l'article auquel celui-ci répond. Il peut
y avoir plusieurs étiquettes: si un article est une réponse à une
réponse, on aura alors les Messages-ID de ces deux articles
en référence. Ce champ permet au lecteur de news de présenter
une discussion sous une forme arborescente, plus facile à suivre.
Les champ 'NNTP-Posting-Host' et 'NNTP-Posting-Date' indiquent nom
du serveur sur lequel l'article a été posté et
la date à laquelle il a été posté. C'est
le serveur qui ajoute ces champs, qui ne sont pas modifiables par un
utilisateur.
Les champs 'Mime-Version', 'Content-Type' et 'Content-Transfer-Encoding'
permettent au lecteur Usenet de savoir dans quel format l'article a été écrit.
Dans la hiérarchie fr, le seul format autorisé est le
texte seul, sans autre codage que le codage 8 bits Iso-Latin (iso-8859-1
ou iso-8859-15 pour les plus modernes). Veillez à régler
votre lecteur de news pour qu'il utilise ce format (et donc ni le Quoted-Printable,
ni le HTML, ni aucun autre format propriétaire, ni aucun attachements
- y compris les VCARD) avant de poster dans fr.*.
Le contenu de l'article commence après la première ligne
vide suivant les champs techniques.
Lorsqu'on répond à un autre article, comme c'est le
cas ci-dessus, il est d'usage de citer ce à quoi on répond
(les symboles '> ' commençant une ligne indiquent une citation).
Les clients de lecture Usenet savent présenter les lignes de
ce type dans une forme différente pour indiquer qu'il s'agit
d'un simple rappel de l'article auquel on répond. Il ne sert à rien
de citer à nouveau l'article en entier: il suffit de citer la
ou les 2 ou 3 lignes qui suscitent une réaction de votre part.
Ceux qui voudront lire l'article auquel vous répondez en entier
iront le lire directement. En aucun cas les citations ne doivent être
plus longues que le texte de votre réponse: c'est une bonne
règle à appliquer. Caricaturalement (mais hélas
on voit trop souvent de telles caricatures) le pire article possible
est un article qui cite entièrement les 200 lignes d'un article
précédent auquel est ajouté une ligne disant "Moi
aussi".
En règle générale, et contrairement à ce à quoi
certains outils vous poussent, il est bien vu de citer ce à quoi
on répond avant d'y répondre. Ca peut vous sembler naturel,
comme à moi, mais ça va mieux en le disant.
A la suite de votre article, votre client va ajouter une signature
qui vous est propre. A vous de configurer votre outil pour que cette
signature soit courte (jamais plus de 4 lignes, de préférence
1 ou 2) et représentative. Votre nom peut suffire, ou une citation
que vous appréciez particulièrement.
La signature est signalée par une ligne spéciale, ajoutée
normalement par votre lecteur de news et qui contient exactement les
caractères '- ' (notez l'espace) suivis d'un retour chariot.
Les outils de lecture reconnaissent cette ligne et vous présentent
la signature sous une forme différente du contenu original ou
des citations. De même lorsque vous répondez à un
article, les outils bien conçus ne laisseront pas la signature
précédente dans les citations possibles (il est inutile
de citer une signature).
Si votre outil ne permet pas de faire tout ce qui est indiqué dans
ce chapitre, ou s'il le fait mal, changez d'outil.
Aspects sociaux
La 'sociologie' d'Usenet présuppose qu'il existe une société.
Pour ma part, je considère dans la suite qu'une organisation
humaine dotée de principes presque invariants (disons constitutionnels),
de règles de vie en commun et d'usages établis par
le temps (disons une culture) et concernant un ensemble humain dont
le
nombre dépasse de loin le microcosme peut être appelé une
'société', et qu'on peut tenter d'en analyser le fonctionnement.
Ce qui est d'autant plus aisé que ce fonctionnement fait l'objet
de nombreux débats, souvent animés, ce qui prouve si
besoin était l'existence réelle de la 'société Usenet" (car
quel humain s'intéresserait au fonctionnement et aux règles
d'un système dont il ne se considérerait pas comme membre,
ou 'citoyen'?).
Pour pousser encore l'analogie avec les groupes humains réunis
par des organisations plus 'physiques', on doit aussi considérer
que différentes histoires ont conduit à différentes
structures, dont les usages, les rites et le règlements sont
différents les uns des autres. On retrouve sous l'aspect sociologique
les différentiations techniques qu'on a nommé jusque
là des 'hiérarchies'.
L'analyse qui suit concerne plus spécifiquement la hiérarchie
'fr', à ce jour la hiérarchie francophone la mieux distribuée,
la plus active, et la plus ancienne aussi.
Qui est le chef d'Usenet
C'est un classique. Aussi étrange que cette question puisse
sembler lorsqu'on connaît un peu Usenet, j'affirme qu'il s'agit
d'une des premières questions posées par tous les responsables
associatifs et/ou politiques auxquels j'ai parlé d'Usenet
durant ces dernières années. Le plus souvent, elle
est posée
sous les formes plus modérées "Qui est responsable
de tout ça" ou "A qui appartient Usenet" ou
encore "Qui
fournit ce service".
Cette dernière forme est sans doute la plus adaptée
au média, mais le fait que cette question soit si importante
pour ceux qu'on nomme en général des "acteurs de
la vie publique" n'est pas innocent. Il n'est pas si facile d'imaginer
qu'un tel outil existe sans qu'une autorité unique ne soit derrière,
quelque part, lorsqu'on a connu dans le passé aucun autre phénomène
de cette envergure. La question revient d'ailleurs, mais moins souvent
(parce que son existence est moins souvent remise en question et qu'on
néglige donc de s'inquiéter du nom du responsable, probablement)
au sujet d'Internet.
Usenet est un service proposé par une communauté de
personnes, physiques ou morales, qui ont passé entre elles des
accords permettant la diffusion des articles sur tous leurs serveurs.
N'importe qui peut faire partie de cette communauté (il suffit
d'ouvrir un serveur, ce qui ne demande que quelques connaissances techniques
et fort peu d'argent: un budget de moins de 2000 francs par an, communications
comprises, est suffisant pour transporter la hiérarchie fr).
A ce titre, Usenet "appartient", au moins physiquement, à cet
ensemble de personnes. Mais ce n'est pas parce qu'on possède
une feuille blanche destinée à recevoir les écrits
de n'importe qui qu'on possède ces écrits, à fortiori
lorsque la possession de cette feuille est partagée par un grand
nombre de personnes.
S'il est certain que les administrateurs des différents serveurs
de news ont un certain pouvoir sur leur propre serveur, leur permettant
par exemple de choisir si ce serveur recevra ou non les article d'un
forum particulier, il n'existe pas d'autorité centrale sur Usenet.
La création d'un forum, par exemple, ne relève de l'autorité de
personne: il s'agit d'un processus selon lequel, après que n'importe
quel utilisateur aie relevé et formalisé un besoin, une
discussion va s'engager sur l'existence de ce besoin, sur le sujet
du nouveau forum et sa place dans l'arborescence. Cette discussion,
qui se tient dans un forum prévu pour (fr.usenet.forums.evolution
pour la hiérarchie francophone) mais dont l'annonce est postée
(AAD: Appel à Discussion) dans les forums les plus concernés,
est ouverte à tous, et chacun peut donner son avis, participer à la
rédaction de la charte, s'opposer à l'utilité du
groupe, etc. Lorsque la plupart des intervenants sont d'accord pour
estimer qu'un consensus a été atteint, un vote est lancé,
et le groupe est créé à l'issue de ce vote s'il
est positif.
Pour ce faire, un "message de contrôle" est posté,
dont le but est de demander à tous les administrateurs des serveurs
qui le recevront de créer ce groupe. Cette création peut être
soit automatisée au niveau du serveur (qui pourra authentifier
la demande grâce à une signature PGP), soit faite manuellement
par l'administrateur. Un tel article peut être posté par
n'importe qui, mais il va de soi que les administrateurs des serveurs
de news préfèrent ne créer que ceux qui ont passé avec
succès l'étape du vote.
Il existe cependant une hiérarchie mondiale particulière
(alt.*) dans laquelle n'importe qui peut créer un groupe sans
en passer par un vote. Cette hiérarchie comporte donc des groupes
plus ou moins fantaisistes et n'est que rarement transportée
entièrement par les différents serveurs de news. Elle
a notamment été exclue de nombreux serveurs universitaires
depuis quelques années, eut égard aux contenus illégaux
qu'elle permet trop aisément de diffuser.
De même, n'importe qui peut poster un "message de contrôle" (cancel)
qui aura pour effet d'effacer un article de tous les serveurs qui le
reçoivent. Cette spécificité permet donc à n'importe
qui d'effacer n'importe quoi, à tout instant. Si Usenet n'est
pas devenu un vaste champ de bataille sur lequel chacun efface les
articles de ses contradicteurs, c'est sans doute parce que l'être
humain n'est pas si mauvais qu'on le pense, ou parce que la plupart
des utilisateurs ignorent ou préfèrent ignorer leur pouvoir: à chacun
d'entre nous ne se faire sa propre opinion sur ce point.
La liste des abus potentiels est longue. Outre les abus 'techniques'
décrits ci-dessus, il faut savoir qu'on évalue à près
de la moitié du trafic le nombre de cancels envoyés pour
effacer les articles qui ne respectent pas les chartes (articles identiques
postés dans tous les forums existants, articles binaires postés
dans des forums dans lesquels ils sont interdits etc.). Dans ce cadre,
le remède est devenu équivalent au mal, voire pire. La
technique tente d'y répondre, grâce à des outils
comme cleanfeed dont le but est de rejeter à la source (au niveau
de chaque serveur qui va alors refuser les articles de ses clients
s'ils sont manifestement hors limites) les pollutions les plus évidentes.
On notera toutefois qu'il existe des processus de régulation
apparemment méta sociaux qui interviennent pour punir les abus
les plus flagrants. La plainte au fournisseur de service, lorsqu'un
utilisateur s'estime victime d'un abus (spam, insultes à répétition...)
est souvent prise en compte par le fournisseur du vilain, qui demandera à son
client de cesser ses abus.
Cette méthode (et les autres techniques consistant à faire
pression sur celui qui fournit la connectivité du 'délinquant')
est un recours à une entité à priori extérieure à la
société. En pratique pourtant, le recours aboutit d'une
manière ou d'une autre à l'administrateur d'un serveur
de news, soit parce que ce dernier aura l'autorité suffisante
pour intervenir auprès de son client, soit parce que son patron
lui demandera pourquoi il reçoit des plaintes et ce qu'il doit
en penser. Dans ce cas là le patron saura le plus souvent faire
la part du feu, entre les représailles possibles de la société Usenet
contre son entreprise et la perte potentielle d'un client.
Dans ce cadre, on s'aperçoit qu'en fait la société Usenet
est en fait assez forte pour faire pression sur une entité extérieure
lorsqu'un ressortissant de cette entité agit mal au sein d'Usenet.
Ce n'est donc pas un recours à une autorité externe,
mais bel et bien la démonstration d'un rapport de force entre
deux sociétés. Usenet se défend des agressions
sans attaquer l'agresseur, mais en menaçant celui dont il dépend.
Somme toute une forme de guerre économique tout à fait
moderne. On peut citer comme forme de dissuasion ultime la menace d'UDP
(Usenet Death Penalty), très rarement utilisée, qui consiste à refuser
(par des cancels systématiques qui peuvent être ignorés
par ceux qui le désirent) tous les articles postés depuis
un serveur dont le propriétaire ignore totalement les requêtes
qui lui sont adressées.
La hiérarchie des hiérarchies
Usenet est donc une société sans dirigeants. Mais cette
société connaît quand même une certaine
forme de hiérarchie et de promotion sociale. On n'y côtoie
pas que des égaux.
D'abord, on l'a vu, ceux qui fournissent le service (les administrateurs
des serveurs de news, pour résumer) ont des moyens d'action
dont les autres utilisateurs ne disposent pas nécessairement.
Mais ces moyens s'appliquent la plupart du temps à leurs seuls
utilisateurs, qui disposent à leur tour de moyens de pressions
sur leur fournisseur en dehors du cadre de la 'société Usenet'.
De ce point de vue, on peut penser qu'il existe un équilibre.
Équilibre d'autant plus grand que les administrateurs ne souhaitant
pas, pour des raisons évidentes, avoir la moindre responsabilité légale
quant au contenu des forums dont ils permettent l'existence ont tendance,
de manière raisonnée ou non, à n'utiliser leur
pouvoir que de manière très prudente: une démonstration
de force de leur part risquant de démontrer d'abord qu'ils ont
des moyens d'action quant au contenus, ce que la Justice risquerait
de considérer à leur détriment en cas de poursuites
légales. On peut voir là une des raisons qui ont conduit à un
fonctionnement qui présente un aspect plus ou moins démocratique:
les administrateurs préférant laisser à leurs
utilisateurs le pouvoir de choisir ce qui sera ou non transporté,
et n'intervenant que lorsqu'un de ces choix risquerait de poser des
problèmes légaux évidents (ce qui n'est à ce
jour jamais arrivé sur fr).
Il est donc plus que rare qu'un administrateur soit considéré différemment,
dans le strict cadre d'Usenet, de n'importe quel autre utilisateur.
La hiérarchie sociale, si elle existe, n'est pas là.
Longtemps (et c'est toujours un conseil de bon aloi) il a été conseillé aux
nouveaux venus sur Usenet de ne rien poster dans les forums qu'ils
lisaient avant d'avoir passé "un certain temps", dans
un ordre de grandeur variant autour du mois, à lire seulement.
Ce conseil reposait surtout sur le simple savoir-vivre: il n'est pas
d'usage en société d'intervenir dans une discussion sans écouter
d'abord ce que disent ceux qui ont entamé ladite discussion
sans vous. Quand quelqu'un qui n'écoutait pas rebondit sur un
mot lancé un peu plus fort pour donner son avis, en général,
il tombe à plat.
Il m'apparaît que ce conseil a d'autres raisons d'être,
non moins valables, et en particulier le fait qu'en écoutant
d'abord, on apprend beaucoup sur ceux qui vont devenir ses interlocuteurs,
en plus de savoir de quoi on cause.
Il est utile, en effet, de remarquer que les articles de tel intervenant
sont généralement considérés par tous comme étant
de haute valeur. En général on le remarque au moins en
constatant que les avis du monsieur terminent le débat en cours:
c'est la marque la plus évidente. Mais il en existe d'autres
aisément identifiables (les 'mitou' (me too) qui suivent, ou
les remerciements, par exemple).
Il est utile aussi bien de savoir qui est le petit rigolo du groupe,
qui préfère rire de tout et ne prend rien au sérieux. Ça
permet d'éviter de tomber dans un "troll" (ce mot
désigne tout à la fois l'auteur et le contenu d'un article
dont l'objet est de pure provocation).
Et petit à petit, d'abord à l'intérieur de chaque
forum, puis souvent à l'intérieur de toute la hiérarchie
(car aucun humain équilibré ne s'intéresse qu'à un
seul sujet, si ?) on s'apercevra que certains avis sont plus respectés
que d'autres lorsque des débats sont en cours. Voire même
que certains avis ont une valeur décisionnelle à eux
seuls lorsqu'ils sont émis par une personne unanimement respectée
(pour ce qu'elle a fait dans le passé pour la communauté,
par exemple).
Voilà la hiérarchie des hiérarchies: basée
sur une espèce de méritocratie, ou comme je préfère
la nommer de 'respectocratie'. Plus une personne aura accumulé le
respect d'autrui, plus son opinion ou son apport technique aura de
valeur.
Et en général, sauf à vouloir se faire instantanément
beaucoup d'ennemis, il vaut mieux réfléchir à deux
fois avant de contredire ces gens. Mais c'est aussi une façon
parfois habile de se faire soi-même une réputation, même
négative, rapidement. Certains excellent à ce jeu-là,
comme dans toute société.
Les règles technico/sociales
Nous avons vu dans la première partie qu'il n'y avait pas de "chef
d'Usenet". Le processus conduisant à la création
d'un groupe permet à chacun de donner son avis et de voter
pour ou contre cette création. Bien entendu, puisque personne
n'est nommé pour s'assurer que chaque nouveau groupe s'insère
plus ou moins bien dans une hiérarchie dont on souhaite la
cohérence,
toute personne qui souhaite disposer d'un forum dédié au
thème qui le concerne est à même de proposer
le nom qu'il veut donner à "son" forum: l'étape
du vote étant supposée trier le bon grain de l'ivraie.
Pour qu'un nouveau forum "passe" l'étape du vote,
il fallait jusqu'en 1997 qu'au moins 30 votes soient positifs, et qu'il
y ait moins de la moitié des votes négatifs. Avec de
telles règles, le nombre d'utilisateurs d'Usenet grandissant,
il devint évident que tout nouveau forum proposé serait
adopté, quelle que soit son sujet, son public, ou la place choisie
pour le créer. Ce fut le cas lorsqu'on vit près de 50
personnes, votant depuis moins de 10 laboratoires de biologie différents,
voter comme un seul homme la création d'un forum dédié aux
canaux-ioniques, thème dont nul n'ignore l'intérêt
qu'il présente pour la majorité de la population et en
particulier pour celui qui avait demandé la création
de ce forum. La règle fut donc transformée pour devenir "80
OUI DE PLUS QUE DE NON et 3 FOIS PLUS DE OUI QUE DE NON".
Il est à noter, que le mot "vote" est chargé d'un
poids très lourd dans nos pays démocratiques, poids qui
fait qu'on préfèrera parler, sur Usenet de "scrutin" ou
de "sondage" pour ce qui n'existe que dans cette 'société'
là.
Le "vote" en question mesure en effet deux choses distinctes, à la
manière d'un sondage dans lequel deux questions seraient posées
qui s'excluraient mutuellement (si on répond OUI à la
première, on ne peut répondre à la seconde, et
inversement). Le système OUI/NON sur Usenet correspond dans
la réalité à deux questions séparées
qui sont:
1.
Souhaitez vous la création de ce forum, soit parce que son thème
vous intéresse (et donc que vous y participez) soit parce que
sa création aidera à désengorger un forum que
vous utilisez ?
2.
Pensez-vous que la création de ce forum est une mauvaise idée
pour l'organisation générale de la hiérarchie,
soit parce que son thème est trop spécifique, ou pas
assez, soit parce que sa création risquerait de porter tort à un
forum que vous utilisez ?
On voit que ces deux questions, si elles sont antinomiques, ne sont
pas un simple choix OUI/NON comme le laissent supposer à la
fois le mot "vote" et le système de vote lui-même:
en réalité le vote NON correspond à un OUI à la
seconde question, et pas à un vote NON à la première.
Cette ambiguïté pose souvent des problèmes lorsqu'un
vote échoue, les votants OUI ne comprenant pas les raisons pour
lesquelles le poids des NON est plus important. Il est pourtant normal
que la cohérence globale de la hiérarchie soit considérée
comme plus importante que la création d'un forum particulier,
et ce système à fait ses preuves depuis longtemps.
Le cas particulier du forum sur les canaux ioniques nous montre à l'évidence
la faiblesse principale d'Usenet: si chacun est à même
de comprendre son fonctionnement et les raisons qui devraient conduire à n'y
créer que des forums intéressant une bonne partie de
la population, alors nul ne proposera, ni ne fera passer en force la
création d'un forum qui ne concernera qu'une population déjà bien
identifiée et localisée, qui aura plutôt intérêt à utiliser
une liste de discussion. Mais puisqu'il n'y existe aucune autorité centrale,
nul ne peut empêcher les dérives, quelles que soient les
règles de création que se choisiront les quelques personnes
qui se préoccupent du média dans son ensemble.
A l'opposé, il faut comprendre que c'est justement cette faiblesse
qui fait la force du média: tout média public, sur lequel
un intervenant est à même d'être lu ou écouté par
un grand nombre de gens, est, lorsqu'il repose sur une structure centralisée
et un pouvoir quelconque, soumis au minimum à une autocensure:
l'autorité centrale risquant d'être tenu pour responsable
des propos tenus sur le média dont il a la charge, il va logiquement
se mettre à faire des choix non seulement quant aux thèmes
abordés, mais aussi sur le contenu des émission ou des
articles. Si aucune autorité centrale n'est identifiable, si
nul ne peut ni imposer les thèmes ni choisir les contenus, alors
le seul responsable d'un propos tenu en public est celui qui tient
ces propos, et nulle censure ne peut lui être imposée
par quelqu'un d'autre.
Usenet, parce qu'il ne connaît aucune espèce d'autorité centrale,
acquiert donc des spécificités toutes différentes
de tous les autres médias, y compris de ceux qui utilisent aussi
l'infrastructure d'Internet.
* La diffusion des articles par inondation (tout serveur retransmet à tous
ses pairs l'information qu'il reçoit de l'un d'entre eux) interdit
de facto toute censure préalable d'un contenu puisque ce contenu
ne dépend d'aucun lien particulier pour être diffusé partout.
Parallèlement, le fait que le procédé de diffusion
ne repose pas sur la demande mais sur l'offre systématique impose
une charge au réseau qui implique que les forums ainsi distribués
fassent l'objet d'un intérêt suffisant en tout point du
réseau ainsi inondé. C'est la raison d'être principale
de la procédure, considérée comme trop complexe
par beaucoup de ceux qui ignorent cet aspect, de création d'un
nouveau forum.
* La gestion d'une hiérarchie organisée nécessite
un travail certain, de réflexion, de rédaction, d'aide.
Tout ce travail est basé, en l'absence de tout financement global,
sur le volontariat et le bénévolat de ceux qui se sentent
suffisamment concernés par l'existence du média. Le réseau
des serveurs de Usenet est structuré de façon à empêcher
tout lieu de pouvoir, ce qui interdit que ces bénévoles
s'approprient de facto un pouvoir autre que celui que le reste des
utilisateurs veut bien leur déléguer.
C'est un avantage et un inconvénient. Le bénévolat
se soucie peu des capacités réelles des personnes, par
exemple. Et le risque de voir se constituer une caste de ceux qui s'investissent
dans la gestion d'une hiérarchie et qui prennent les décisions
pour les autres est très réel: dans les faits, pour intervenir
dans le processus de décision, il faut connaître les règles,
l'histoire et les positions "politiques" des différents
intervenants. Un tel travail nécessite du temps, dont chacun
ne dispose pas obligatoirement. Un autre risque est de voir un petit
groupe de personnes organisées et décidées prendre
place au centre des lieux de décision communs, et profiter du
fait que, proportionnellement au nombre des utilisateurs, ceux qui
s'intéressent à la hiérarchie au point de débattre
et de voter son développement sont peu nombreux pour imposer
un point de vue qui ne prendra en compte que ses propres bénéfices,
et s'approprier le bien commun.
Mais l'équilibre est solide, et repose en définitive
sur le fait qu'au delà des utilisateurs, ceux qui gèrent
des serveurs disposent toujours d'un "droit de veto" sur
toute décision qui irait contre l'intérêt du plus
grand nombre, intérêt bien compris par ces gestionnaires,
puisque c'est eux qui sont en position de juger du coût de toute
décision. Eux-mêmes n'ayant aucun intérêt à imposer
une décision qui risquerait de les transformer de facto en responsables
de tout ou partie du contenu de la hiérarchie, au delà du
rôle de simples transporteurs. Leurs veto pour ne pas leur imposer
de responsabilité légale ne doivent donc reposer que
sur des aspects purement technique, les décisions "politiques" étant
réservées aux utilisateurs, et la responsabilité légale
diluée au point de ne plus reposer que sur l'auteur de chaque
article.
Sauf sur les forums modérés
Un type particulier de forum se situe à la limite du lieu d'expression
public ouvert à tous, il s'agit du forum modéré.
Le forum modéré (et décidé comme tel lors
de la discussion, et du vote, qui précèdent son existence)
fonctionne, pour le lecteur, de la même façon que le forum
moyen. La différence n'apparaît que lorsqu'on souhaite
poster un article sur un tel forum: le serveur sur lequel l'article
est envoyé va, au lieu de stocker l'article et de le diffuser,
envoyer l'article, par courrier électronique, à un "modérateur" (lui
aussi nommé lors de la création du forum).
C'est ce "modérateur", et lui seul, qui pourra rendre
public l'article, en le postant avec une ligne spéciale ("Approved:" suivi
de l'adresse e-mail du modérateur) ajoutée au header
de l'article. Sa décision, dans la très grande majorité des
cas, repose uniquement sur l'adéquation entre le contenu de
l'article et la charte du forum auquel l'article est destiné.
Les articles n'ayant aucun rapport avec cette charte seront, avec droit,
rejetés. Ceux qui ne respectent pas entièrement ladite
charte pourront faire l'objet d'un dialogue entre le modérateur
et l'auteur de l'article, si c'est le choix du modérateur.
Il faut revenir sur quelques points qui viennent à l'esprit:
il ne s'agit en aucun cas de censure: Usenet dispose de suffisamment
de forums non modérés pour qu'un article, quel qu'il
soit, puisse être posté en public. Le modérateur,
dans ses choix, ne fait qu'appliquer une règle décidée
par ceux qui ont voulu le forum qu'il modère, et rien d'autre.
Sa décision ne concerne donc que le contenu de ce forum particulier.
Cette décision n'est (normalement) jamais motivée par
le contenu idéologique d'un article (On peut d'ailleurs noter
que, jusqu'à ce jour, aucun forum à thème idéologique
n'est modéré sur la hiérarchie francophone. Il
ne s'agit pas là d'une règle, mais du résultat
des différents débats qui ont eu lieu lorsque de telles
propositions ont été faites).. Si l'article respecte
la charte du forum, il sera posté, même s'il ne correspond
pas aux opinions du modérateur: il ne s'agit donc pas non plus
de décision éditoriale, mais seulement de décision
quant à la forme d'un article particulier et quant à son
adéquation au thème du forum.
La modération n'est donc ni une censure ni une décision éditoriale.
On pourrait plutôt la comparer avec le jury de lecture qui valide
(ou non) la publication d'un article scientifique dans les journaux
spécialisés. Le terme même de "modérateur" est à prendre
plus comme une traduction littérale du terme anglo-saxon "moderator" qui
indique plutôt celui qui, lors d'un débat, distribue le
temps de parole que celui qui souhaite "modérer" les
propos des intervenants.
Notons enfin l'apparition récente de trois nouveaux types de
forums modérés, dits "rétro-modérés", "auto-modérés" et "robot-modérés".
Le premier type permet à chacun d'y poster ce que bon lui semble
sans en passer par la décision à priori d'un modérateur,
mais fait l'objet d'une surveillance régulière qui conduit
le modérateur à effacer, après coup, tout article
qui ne respecte pas le thème du forum. Le modérateur
doit rendre compte de tout effacement dans un forum spécialisé (et
lui-même "auto-modéré": toute personne
qui y poste doit "approuver" elle-même son propre article)
: fr.usenet.abus.rapports. Le dernier ("robot"modéré")
est laissé à la charge d'un logiciel, qui se charge de
valider les articles qui lui sont soumis par e-mail, comme un modérateur
humain, lorsque ceux-ci respectent une forme précisée
dans la charte. Ce type de forum n'est donc pas à l'abri des
articles hors thème, aucun logiciel n'étant capable de
juger d'un tel point.
Aspect technique
NNTP et UUCP
Usenet préexiste à Internet. En fait, Usenet étant
un média asynchrone, il est à même d'utiliser n'importe
quel moyen de transport permettant à un ordinateur de lire des
fichiers écrits sur un autre. Et presque tous les moyens de
transports possibles, jusqu'au transport de bandes en voiture, ont été utilisés
pour transporter Usenet.
Mais les méthodes purement informatiques sont plus rapides
et plus simples. Je pense qu'UUCP a été le premier des
protocoles utilisés avant qu'Internet et NNTP n'arrivent à ce
qu'on connaît aujourd'hui.
UUCP (Unix to Unix Copy Protocol) est simple d'emploi et ne nécessite
rien de plus qu'un modem et un contact disposant lui aussi d'un modem.
Aucune couche réseau n'est nécessaire en dehors de la
seule liaison physique. Le principe est rudimentairemais solide: on
se connecte à heure fixe sur un autre serveur, et on transfère
sur ce serveur tout ce qu'on a stocké localement depuis la dernière
connexion. A l'inverse, on reçoit tout ce que cet autre serveur
a reçu depuis notre dernière visite.
Une "carte", largement distribuée et signalant, pour
chaque machine du 'réseau virtuel' ainsi constitué les
fréquences d'appel et le nom des machines appelée permet à un
programme assez simple de reconstituer la 'route' la plus courte entre
deux machines. Ces cartes ont une raison d'être lorsqu'on souhaite
faire parvenir un message à un ordinateur particulier. Dans
le cadre d'Usenet et de sa procédure d'inondation, elles sont
inutiles.
Il est intéressant de savoir cependant que ces cartes existent
toujours, et qu'il faudrait peu d'efforts pour reconstituer un réseau
tombé en désuétude mais toujours prêt à prendre
le relais en cas de besoin. Mais UUCP sur TCP est encore aujourd'hui
assez souvent utilisé.
INN
INN est resté longtemps le logiciel (libre) le plus utilisé pour
gérer un serveur Usenet. Il est capable d'échanger des
articles avec ses partenaires en UUCP comme en NNTP, et dans le cas
des serveurs qui ne disposent que de connexions temporaires à Internet
(dial-up), UUCP est une solution qui coûte moins cher que n'importe
quel autre moyen de transport plus moderne (voir annexe).
L'installation d'INN est cependant assez complexe, mais grâce
aux distributions récentes de Linux on peut 'monter' son propre
serveur sans grandes difficultés (la plus grande part de la
complexité d'INN étant la phase de configuration spécifique à chaque
système d'exploitation avant compilation, on profitera pour
une fois sans état d'âme des distributions binaires prévues
pour s'adapter directement à un système donné).
Phase pratique: configuration d'INN sur une machine Linux/Debian.
Après l'installation du package ('apt-get install inn' sur
une Debian récente) et la réponse aux quelques questions
qui vous seront posées par le script d'installation, il reste
vraiment très peu de travail pour finaliser un serveur fonctionnel.
Le détail d'une installation de ce genre suit, mais je ne saurais
trop vous conseiller de vous familiariser d'abord avec INN en lisant
entièrement la documentation ('zcat /usr/doc/inn/inn-Install.ms.gz
| nroff -ms' sur une Debian) et la FAQ en cas de problème (/usr/doc/inn/INN-faq*).
Le script d'installation va modifier le fichier /etc/news/inn.conf.
Pour ça, il va vous demander de décrire:
* votre organisation (quelques mots suffisent: ce sera l'organisation
utilisée par défaut lorsqu'un client postera sur votre
serveur sans spécifier sa propre organisation)
* le nom de votre serveur (sans importance réelle)
* le path de votre serveur: cette valeur est celle qu'INN ajoutera
au champ technique 'Path' des articles qu'il traitera. Cette valeur
permettra aux serveurs qui enverront des articles au votre d'éviter
de vous proposer des articles qui sont déjà passé par
votre serveur. Il doit donc être assez spécifique pour éviter
que deux serveurs utilisent le même identifiant et soient confondus
dans la diffusion des articles. Le nom FQDN de votre machine, ou celui
de votre domaine si votre serveur est le seul serveur de news de ce
domaine, est souvent un bon choix: il est unique.
* le domaine dont proviendront les articles postés localement.
Le script va ensuite lancer le démon innd. Votre serveur est
déjà fonctionnel mais ne dispose que d'un forum de test
local, et ne reçoit ni n'émet d'articles vers l'extérieur.
Restent à configurer les quelques fichiers installés
dans le répertoire /etc/news. Je n'aborde que ceux dont la configuration
est nécessaire à l'établissement d'un feed bidirectionnel
(de votre serveur vers un serveur peer, et de ce serveur vers le votre).
ATTENTION: toutes les configurations qui suivent doivent être
faites sous l'identité de 'news' (su - news).
/var/lib/news/active et /var/lib/news/newsgroups
Il vous faudra la liste des forums que vous allez recevoir. Pour obtenir
la liste complète au jour le jour de tous les forums existants
officiellement, vous pouvez aller sur ftp://ftp.isc.org/pub/usenet/CONFIG/
récupérer un fichier 'active' et un fichier 'newsgroups' à jour.
Contentez-vous de les copier dans /var/lib/news/. Si vous laissez
le fichier active complet, votre serveur proposera à ses utilisateurs
locaux la liste de tous les forums existants. Si vous ne souhaitez
en proposer qu'une partie (la hiérarchie fr par exemple) éditez
ce fichier pour ne conserver que les forums que vous allez recevoir
de vos feeds.
/etc/news/hosts.nntp
Ce fichier contient la liste des serveurs qui ont l'autorisation de
vous envoyer des articles. Il est possible de subordonner cet accès
en écriture à la fourniture d'un mot de passe, mais
cette option n'est que très rarement utilisée. ATTENTION:
ce fichier est remplacé par le fichier 'incoming.conf' dans
les versions d'INN supérieures à 2.0 (ce qui n'est
pas encore le cas de l'INN fourni dans la Debian par défaut).
La syntaxe utilisée pour incoming.conf est proche de cette
qu'on utilise dans innfeed.conf (voir plus bas) et donc toute différente
de celle utilisée pour hosts.nntp.
La première chose à faire est donc d'indiquer dans hosts.nntp
le nom du ou des serveurs (un par ligne) qui vont vous envoyer des
articles, dans le cas où vous serez feedés via NNTP.
ATTENTION: si vous êtes feedés par UUCP (ou si vous utilisez
une méthode quelconque mettant en jeu l'appel de 'rnews' pour
remplir vos forums locaux), il n'y a pas besoin de toucher à hosts.nntp.
Laissez le vide.
/etc/news/newsfeeds
C'est dans ce fichier que vous devez décrire ce que vous allez émettre,
et vers qui vous allez émettre. Entrer dans les détails
de la configuration ici prendrait trop de place, je vous renvoie aux
nombreux exemples contenus dans le fichier fourni par la Debian. Si
vous allez envoyer vos articles par NNTP directement, préférez
la solution 'innfeed' à tout autre choix possible:
* décommentez la ligne qui commence par 'innfeed!'.
* ajoutez une ligne pour chaque serveur vers lequel vous allez envoyer
vos articles, de la forme:
Nom.Du.Serveur/path-exclude:fr.*:Tm:innfeed!
Ou 'Nom.Du.Serveur' va correspondre à une entrée du
fichier innfeed.conf et où 'path-exclude' doit être la
chaîne ajoutée dans le champ technique Path: par le serveur
en question. 'fr.*' signifie que vous allez envoyer à ce serveur
tous les articles postés localement (ou reçus via un
autre serveur) dans la hiérarchie fr. 'Tm:innfeed!' indique à INN
qu'il doit utiliser le programme innfeed pour envoyer ses articles.
* configurez le serveur (peer) en question dans le fichier /etc/news/innfeed.conf
(si ce fichier n'existe pas, installez innfeed: <apt-get install
innfeed>):
peer Nom.Du.Serveur {
ip-name: Nom.Du.Serveur
}
doit être ajouté.
Ce type de configuration nécessite une connexion permanente.
Dans le cas ou vous utilisez une connexion de type dialup, préférez
la solution UUCP:
* ajoutez une ligne pour chaque serveur vers lequel vous allez envoyer
vos articles, de la forme:
Nom.Du.Serveur/path-exclude:fr.*:Tf:
Ou 'Nom.Du.Serveur' va correspondre à une entrée du
fichier send-uucp.cf et où 'path-exclude' doit être la
chaîne ajoutée dans le champ technique Path: par le serveur
en question. 'fr.*' signifie que vous allez envoyer à ce serveur
tous les articles postés localement (ou reçus via un
autre serveur) dans la hiérarchie fr. 'Tf:' indique à INN
qu'il doit stocker les articles à envoyer dans un fichier. Ce
fichier sera lu et exploité par une entrée dans la crontab
de l'utilisateur 'news' (crontab -e).
* décommentez dans la crontab de l'utilisateur 'news' (crontab
e pour éditer la crontab avec l'éditeur défini
par $EDITOR dans votre environnement) la ligne qui appelle
/usr/lib/news/bin/send-uucp.pl.
* éditez /etc/news/send-uucp.cf et ajoutez une ligne pour le
système UUCP du serveur vers lequel vous voulez envoyer les
articles. Ceci suppose que vous avez déjà configuré UUCP
pour que votre machine puisse appeller ce serveur. Il va de soit qu'il
faudra que votre fournisseur fasse l'inverse de ce qui est ici décrit
de son côté pour que vous receviez ses articles.
/etc/news/nnrp.access
Ce fichier décrit quelles machines pourront accéder à votre
serveur en tant que clients (NNRP). Ajoutez une ligne de la forme:
*.yourdomain.com:RP:::*
Où 'yourdomain.com' doit être remplacé par le
nom de domaine de votre réseau local. Si vous n'avez pas de
reverse DNS configuré pour ce réseau, indiquez directement
la classe d'adresse de votre réseau en lieu et place de '*.yourdomain.com'.
C'est tout. Jetez un oeil sur les fichiers 'organization' et 'expire.ctl'
pour modifier les paramètres par défaut si nécessaire,
puis toujours sous l'identité de 'news' tapez
</usr/lib/news/bin/ctlinnd reload "" "">
pour relancer INN avec votre nouvelle configuration.
Terminologie
Cancel: Annulation d'un article. L'annulation est normalement réservée à celui
qui a émis l'article original. Elle s'effectue en envoyant un
message spécial (message de contrôle) sur Usenet. Ces
messages ne sont pas destinés à être lus mais à être
traités automatiquement par les machines faisant transiter les
articles de Usenet. Par curiosité, on pourra aller consulter
le groupe "control.cancel" pour voir des messages de cancels.
Cross-Post: Consiste à envoyer un article en une seule fois
dans plusieurs groupes simultanément. Si vous désirez
envoyer un article dans plusieurs groupes c'est la technique qu'il
convient d'employer. S'oppose à "Multi-Poster", qu'il
ne faut jamais faire.
FAQ (Frequently Answer Questions) (ou Foire Aux Questions en français):
Document répondant aux questions les plus fréquemment
posées dans tel ou tel forum. Il est bien vu, et même
fortement recommandé, qu'une personne à la recherche
d'informations sur un sujet ait préalablement recherché si
une FAQ existait, et si oui l'ai lu, avant de poser une question dans
un groupe. Les FAQ en langue française sont régulièrement
postées dans le groupe "fr.usenet.reponses", groupe
auquel vous feriez bien de souscrire si vous faites vos premiers pas
sur Usenet ("news.answers" regroupe quant à lui l'ensemble
des FAQ en langue anglaise), tout comme vous devriez commencer par
lire fr.bienvenue.
Flame (Flame wars): Articles agressifs et généralement
sans aucun intérêt. Ne participez pas vous même à ce
genre de discussions (laissez-les moi!).
Message-ID: C'est l'étiquette qui identifie un article. Tout
article posté sur Usenet possède un Message-ID unique,
automatiquement généré par l'outil qui permet
d'écrire sur le serveur local. Cet identificateur est utilisé par
les logiciels lorsque vous répondez à un article pour
indiquer à quel article il est répondu, permettant ainsi
de classer les articles par fils de discussion (threads).
Modération: Un groupe est dit modéré lorsque
les articles doivent être préalablement agrée par
une ou plusieurs personnes (le ou les modérateurs) avant parution
dans le groupe. Le rôle du modérateur est de vérifier
la conformité des articles qui lui sont soumis (processus automatique) à la
charte du groupe, puis d'envoyer les articles conformes dans le groupe.
Seul le modérateur a le droit d'écrire dans le groupe.
Multi-Post: Envoyer un même article plusieurs fois dans des
groupes différents. Un envoi du même article est effectué pour
chaque groupe concerné. À ne jamais faire. Utilisez plutôt
le "cross-post" si vous devez envoyer un article qui concerne
plusieurs groupes. Un article "multi-posté" génère
autant d'articles qu'il y a de groupes destinataires, au contraire
d'un article "cross-posté" qui ne génère
qu'un seul article sur le serveur de news.
NNTP (Network News Transfer Protocol): Le protocole qui relie les
serveurs entre eux. Pour que deux serveurs soient reliés, il
faut un accord entre chacun des deux administrateurs de ces serveurs,
qui seront appelés entre eux des 'feeds'. Dans notre exemple "1","2" sont
des 'feeds' de "3", "2" et "3" sont des
'feeds' de "1" et ainsi de suite.
'Lecteur de news': C'est l'outil dont vous vous servez pour lire et écrire
dans un forum, qui à l'instar du 'lecteur de mail' permet de
taper un article puis de le poster sur son serveur local.
Serveur de 'news': le 'tableau noir' d'un réseau local sur
lequel tout utilisateur de ce réseau peut écrire directement.
Dans un second temps, l'article posté localement sur ce serveur
sera proposé, par ce serveur, à tous les serveurs avec
lesquels il est relié, et qui l'accepteront s'ils ne l'ont pas
encore reçu.
Spam: Abus consistant à envoyer un article dans un nombre de
groupes exagérés (non défini mais un nombre de
5 est généralement considéré comme un maximum).
Circonstances aggravantes si l'article est "multi-posté" plutôt
que "cruciposté".
Thread: Fil de discussion à l'intérieur d'un groupe.
Un fil de discussion est initié par un article original, abordant
un nouveau sujet, auquel il est répondu. L'ensemble de ces articles,
original et réponses, constitue le fil de discussion ou thread.
Usenet: Ensemble des réseaux, des machines et surtout des personnes
permettant une communication publique, électronique, d'essence
universelle qui s'appuie sur l'Internet (mais n'est pas limité à l'Internet).
Ce terme générique peut être employé dans
de multiples sens. Usenet c'est une communauté de personnes
(les lecteurs, les rédacteurs, les administrateurs des serveurs)
mais c'est aussi l'ensemble des machines qui véhiculent les
articles.
Annexes
Ce petit calcul a été fait en 1995. Il est toujours
d'actualité: la vitesse des modems a augmenté, mais ça
vaut aussi bien pour UUCP que pour PPP/NNTP.
L'objet de ce calcul est de démontrer qu'il revient moins cher,
dans tous les cas, de disposer de son propre serveur que de se connecter
par téléphone sur le serveur de son fournisseur d'accès.
Ce calcul ne concerne que les liaisons téléphoniques,
et n'est plus de mise dans le cas d'une liaison permanente ou forfaitaire.
A 14400 bauds:
Les article ont été compressés par UUCP pour
arriver à une taille de 16520 octets. Une petite règle
de 3 maintenant.
A raison d'une moyenne constatée de 1253 octets par article,
pour mille articles nous aurions 210s en UUCP contre 590s en PPP/NNTP à quoi
j'ajoute le temps de connexion de 30s. Soit:
Temps de connexion pour 1000: 4mn 9mn40s
Ceci pour 1000 articles. Il est donc évident que pour une personne
qui souhaite récupérer un groupe complet, UUCP n'est
pas dépassé. 1er point.
Maintenant partons du principe que l'utilisateur ne souhaite lire
que certains sujet qu'il aura pu choisir à partir d'une liste
rapatriée auparavant. J'ôte donc de mes 40 articles tout
ce qui n'est pas dans les headers: résultat 21093 octets (si,
si).
temps de connexion physique pour la liste: 30s
temps de transferts estimé pour 1000 headers moyens (527325
octets): 248.3s
(on est loin de la "minute et demie", désolé,
ce sont les chiffres)
[coupure]
temps de connexion physique pour les articles choisis: 30s
temps de connexion pour mes 40 articles (soit 4% des articles du groupe
seulement, ce qui à mon sens est un peu bas, compte tenu du
fait que si on
s'intéresse à un groupe, le ratio sera plus proche des
50%, mais admettons):
23.6s
total pour PPP/NNTP: 331.9s soit 5mn32s. A rapprocher pour ceux qui
ne suivent pas des 4mn pour 1000 articles en UUCP.
On aura donc passé plus de temps "on-line" pour rapatrier
les 40 articles intéressants que pour rapatrier les 1000 articles.
UUCP n'est pas dépassé pour une lecture sélective,
2ème point.
Pour résumer, donc, ce qui compte c'est que déjà rien
que les en-têtes représentent près d'un tiers de
la totalité du trafic d'un groupe, ce qui diminue fortement
l'intérêt de l'off-line, et qu'en y ajoutant le temps
de sélection on dépasse le temps total nécessaire
pour ramener le groupe entier en UUCP. Énervant, non? |
