L'Agenda du Libre

Le dimanche 29 septembre 2024, tout allait pour le mieux sur le serveur CLUB1, quand tout à coup, à 13h01, Nicolas nous informe sur le canal Matrix des membres:

Bon, on a eu un petit soucis avec les emails

Le mot de passe d'un compte CLUB1 a visiblement été récupéré par un attaquant. Il a été utilisé pour envoyer environ 1 mail par seconde sur environ 24h.

Bref, On s'est fait hackeeerrr!!!! 😱😱😱😱😱 Surtout, ne pas céder à la panique!!!! 🥴 On respire un bon coup et on essaye de comprendre ce qui s'est passé.

La cause

C'est difficile de savoir exactement comment cela s'est passé, mais on a tout de même des suppositions. On soupçonne une installation de CMS en friche: Un logiciel prévu pour le Web (forum, wiki, blog...) dont l'installation est incomplète, qui a été mal configuré ou qui n'est plus à jour depuis trop longtemps. Le Web est une porte ouverte sur le serveur. Hors nous ne somme pas les seuls à traîner sur le Web, il y a aussi des quantités de robots (des logiciels) qui parcourent le Web jour et nuit à la recherche de la moindre faille à exploiter. Ils toquent à toute les portes en espérant qu'on leur ouvre par erreur. En accédant à l'administration d'un CMS, on peut accéder à des codes et identifiants qui servent, par exemple, à configurer l'envoi de mail. C'est le scénario que l'on imagine.

Une entité à donc eu accès aux identifiants de connexion au service de mail.
Elle en a profité pour envoyer direct un MAX de SPAM!!!! Letzzgoo 📨 📨 📨 📨 📨 📨 📨

Comme les identifiants CLUB1 sont les mêmes pour les différents services, cela donne également accès à tout l'espace personnel! Heureusement, rien n'a été tenté de ce côté. l'intention n'était donc pas de mettre le bazar sur le serveur ou d'essayer d'en prendre le contrôle. La stratégie était peut-être plutôt la discrétion. Bon, sauf qu'à l'échelle de CLUB1, c'est cramé rapidement quand on envoie 3600 emails par heure.

La Découverte

C'est grâce au tableau de bord, qui permet de suivre le travail des serveurs emails, que l'envoi en masse a été repéré.

Ce graphique indique le nombre de messages dans la file d'attente au cours du temps. D'habitude, il n'y en a aucun (le volume d'email de CLUB1 est plutôt tranquille). Puis la quantité d'email envoyé est devenu trop forte et une belle file d'attente s'est crée.

La première réaction a donc été de changer le mot de passe pour bloquer l'accès au service de mail à ce compte. Et dans un second temps, de supprimer tous les messages de la file d'attente. C'est toujours ça de gagné!

Effet secondaires

Le mail est une activité difficile sur internet. En lançant ce service, on savait qu'on allait avoir des galères. La question était plutôt: quand est-ce que ça va arriver?

En fait, toute la difficulté vient de la grande guerre du SPAM. Cette dernière a justifié la création de nombreuses mesures pour écarter les fournisseurs d'emails jugés "à risque". Par exemple, si un serveur reçoit du mail identifié comme SPAM, il peut faire en sorte de bloquer l'adresse qui l'envoie. Mais souvent, c'est carrément tout le serveur qui est bloqué!

Et ça n'a pas manqué! Microsoft, le deuxième fournisseur d'email mondial, a bloqué l'adresse IP associée à club1.fr. Ce qui a pour effet de bloquer tout les emails qui ont pour destinataire une adresse ...@outlook.com ou ...@hotmail.com. Le serveur de Microsoft renvoie alors un message expliquant que le mail n'est pas arrivé (au moins on est au courant!)

On a donc contacté le support pour leur demander de sortir l'adresse IP de leur liste de blocage. Cela s'est passé sans encombre, même s'il a fallu insister un petit peu pour que la demande soit prise en compte.

💡 Pour plus d'information, voir le suivi du problème sur le forum

Il faut aussi se dire que, même s'il n'y a pas eu de blocage frontal avec les autres fournisseurs d'emails, cet envoi en masse a potentiellement eu un effet négatif. Par exemple, Google, le premier fournisseur mondial, attribue un score de réputation aux serveurs qui envoient des mails. Ce genre d'incident est typiquement ce qui fait baisser la réputation d'un serveur. Augmentant le risque pour les emails provenant de club1.fr d'aller dans le dossier SPAM de Gmail.

Conclusion

C'est un cas intéressant car il illustre bien les enjeux d'entretien d'un espace sur le Web, ainsi que la relation inégale entre les fournisseurs d'emails.

Ce n'est pas la facette la plus amusante d'Internet: Des robots qui cherchent la moindre faiblesse pour attaquer et des fournisseurs de mails qui peuvent nous rayer de la carte en un clin d'oeil.

Mais bon, ça permet de nous rendre compte des réalités d'Internet et de les partager! 😊 Et puis c'était intéressant de se rendre compte de la procédure pour sortir d'une liste de blocage. Pour le coup, ce n'est pas une action nécessitant des connaissances techniques. Elle peut donc facilement être effectuée par n'importe qui. Une note: Sortir des Blacklist a été créée pour documenter les procédures traversées. En cas de futur problème, cela pourra aider à se répartir les tâches.

Tous les articles CLUB1 concernant les emails:

• Le(s) serveur(s) emailLes membres de CLUB1 ont enfin une adresse email perso27/07/2021
• Transfert d'email & Sender Policy FrameworkSoit la configuration de SRS pour réparer ce que SPF a cassé28/08/2022
• Rapport d'incident #005La journée aux 30000 mails20/10/2024

Date et lieu

Le 15 octobre 2023 à la Cyberrance.

Personnes présentes:

• Aqua
• Audrey
• Fae
• Raphaël
• Melvyn
• Anais
• Alix
• Nicolas
• Morgane
• Armand
• Vincent

C'est la première réunion depuis la création du forum. Et ce n'est pas anodin, car ce dernier a été largement mis à contribution pour la préparation! Principalement via l'utilisation d'un tag associé, regroupant les sujets que l'on aimerait aborder. L'idée étant de mettre en relation les réflexions et contributions asynchrones avec les temps de prise de décisions synchrones (typiquement les réunions).

C'est aussi la première fois que des protocoles de réunion et un ordre du jour ont été établis. Une note a été produite à ce sujet.

Finalement, parmi la dizaine de sujets de l'ordre du jour, seuls trois de ces sujets ont eu le temps d'être abordés. La réunion étant un moment de rencontre pour les membres, elle a aussi simplement servi à passer du temps ensemble!

Enfin, on remercie Armand et la Cyberrance pour l'accueil bienveillant, dans un espace riche en plantes vertes et en tisanes!

1 - Inclusivité et légitimité

Fae a parlé du milieu de l’informatique comme peu mixte en terme de genre,
généralement associé aux hommes, même si ça change de plus en plus.
Elle s'est souvent retrouvée dans des situations où, malgré une parité, une majorité d’hommes cis occupaient le temps de parole. Les personnes qui se sentent moins à l'aise, moins légitimes par rapport au sujet, n’osent pas forcément prendre la parole. Ça peut passer par des façons de parler, d'appuyer ses idées, la précision des termes, la quantité de connaissances techniques...

Anaïs s'interroge sur comment travailler ce sujet au sein de Club1?

Fae parle de son envie de rassembler les minorités de genre pour obtenir des retours d’expérience, dans l'idée de pouvoir aborder ces situations différemment par la suite. Le partage d'expériences pourrait être le début de la réflexion collective, avant de chercher des solutions techniques, pratiques pour les moments de réunions.
Elle parle également de l'envie de se connecter avec des serveurs féministes qui ont déjà travaillé ces sujets.

Anais a parlé de son impression que Club1 est déjà inclusif d’une certaine manière, que ça lui a permis de faire son site web par ex. Elle pose la question de comment ouvrir le sujet informatique à celleux qui en sont repoussé·e·s:
Comment leur faire comprendre que c’est ouvert à elleux et pas réservé aux "geeks", mais aussi aux gens qui ne s’en sentent actuellement pas capables.
Elle pose également la question de rendre Club1 plus visible pour aller chercher des publics plus larges, moins proches de l'informatique.

Fae évoque l'émission de radio qu'elle a organisé pour son diplôme autour de témoignages sur la place d'Instagram dans les vies et pratiques artistiques d'étudiant·e·s en art. Elle remarque que ça a permis de parler de choses qui sont peu évoquées dans le quotidien, de créer un espace pour se rendre compte de choses, trouver des mots, voir des schémas qui se répètent dans nos expériences. Elle souligne le côté intime de ce mode d’expression. Avec l'arrivée de la webradio sur Club1 ça rend possible l'organisation de ce genre d'activité.

Melvyn exprime le fait qu'en écoutant Anaïs il s'est rendu compte qu'il se sentait comme membre externe, intéressé mais pas forcément légitime. Il a l’impression que c’est le cas de la majorité des gens de la réunion.

Cela a ouvert les questions d'inclusivité et de légitimité plus largement dans Club1.

Vincent aimerait que les personnes puissent s’investir comme elles le souhaitent sans ressentir de pression. Il parle du fonctionnement incrémental de Club1 qui est parti de deux personnes et s’étend petit à petit (...l'oiseau fait son nid! 🐣)

Alix se reconnait dans le flou d’être membre ou pas. Il voit Club1 comme une plateforme pour proposer des choses.

Aqua voit ça dans beaucoup de groupes, beaucoup de gens se voient comme des «pieces rapportées», alors que c’est ce qui fait la diversité du groupe d'après elle.

Melvyn se sent personnellement utilisateur des services. Ça répond à un besoin, ça lui fait plaisir, mais lui n’a pas l’impression de faire des choses pour Club1. Pas autant que ce qu’il voudrait.

Nicolas parle de la nuance entre membre et utilisateurice. Il est possible de s'investir mais ce n'est pas une condition pour être membre ou utilisateurice.

Aqua a découvert Club1 via Alix. Le fait d'en parler autour de soi est déjà une façon de participer, dit elle.

Audrey voit Club1 comme un jardin, avec des plantes qui poussent différemment. Plus il y a de gens plus ça va former des liens entre les gens.

Raphael aborde le sujet du partage de tâches, notamment au niveau logistique et maintenance.

Vincent répond que cette idée de membre est justement là pour ça: tenter de répartir les tâches et ne pas garder les expertises sur un petit nombre de personnes. Ce qui nous amène vers un point suivant de la réunion:

2 - Qu'est ce qu'on peut faire si on veut participer à CLUB1?

On a fait un petit tour d'où on en était en terme d'appropriation des différents outils internes par les membres du club. En fait c'était déjà l'occasion de présenter toutes ces facettes de CLUB1. Au final, plus que des avancées, on avait déjà besoin de faire circuler l'information sur les possibilités d'action.

Vincent et Nicolas évoquent le développement en cours d'un outil léger pour envoyer des newsletters. Son but est de faciliter l'envoi et la gestion sans avoir besoin d'installer un énorme outil dédié sur le serveur. C'est un exemple d'amélioration technique qui cherche à faciliter la participation.

Permissions: qui peut faire quoi?

Le droit d'accès à ces différents outils est basé sur des groupes UNIX. Chaque membre de CLUB1 peut appartenir à plusieurs groupes, donnant des droits pour l'administration du forum, du site web, l'envoi de la newsletter, etc... Seulement, cela nécessite souvent un usage avancé du serveur (pratique de la CLI), donc n'est pas très inclusif. La section "outils" de la doc vise à compenser cela en documentant l'usage de ces "outils internes". Elle a reçu plus d'attention récemment du fait que la section "service", qui était prioritaire, commence à être bien remplie.

Il nous reste à trouver une organisation qui nous plaise pour rebrasser les rôles, et régulièrement actualiser les droits. Pour l'instant, cela est fait de façon informelle, souvent au détours d'ateliers ou événements.

A quoi peut servir la newsletter

Elle s'adresse aux personnes qui se sont inscrites à la newsletter, les observateurices, mais n'ayant pas nécessairement envie de s'investir fortement. Elle est donc utile quand on a envie de partager quelque-chose qui ne touche pas que les membres de CLUB1.

• Annonce d'événements
• Informations relatives à la vie du serveur, souvent via le partage d'un article du journal qui sera plus conséquent.

Il faut éviter d'en envoyer des tonnes, donc accumuler des petits sujets avant d'en envoyer une. Pour l'instant, les propositions de newsletter se font via le forum avec le tag newsletter.

On se pose la question du caractère objectif de la newsletter: est-ce que ça ne devrait pas être un agglomérat de propositions subjectives?
Anais: On pourrait par exemple passer l'écriture de la newsletter aux membres chaque mois, en tout cas c'est cool de rendre visible les productions web de chacun, l'expression des membres.
Fae: la newsletter peut aussi partager les mises-à-jour dans les sites de chacun·e·s → Proposition de protocoliser la participation à la newsletter.

Le forum et la catégorie ticket

Ce système est un standard pour la collaboration sur des projets techniques Open source à travers internet. Or, c'est un monde qui n'est pas familier pour la majorité des membres du club.

La catégorie ticket dans le forum rend visible toutes les tâches relatives à la maintenance du serveur. Mais aussi pour les questions, suggestions ou propositions, qu'elles soient techniques ou non. C'est une unité de base qui couvre donc un large éventail de contenu, d'où la difficulté de le définir.

Edition du site web

Le site web est un wiki, c'est à dire que de nombreuses personnes peuvent l'éditer. Pour l'instant ce n'est pas trop mis en avant, c'est un point qui pourrait être amélioré. Par exemple en le documentant.

Journal de bord

Le journal, initialement, sert à mélanger les sujets techniques (maintenance, tâche de soin, adminsys), des récits d'ateliers, ainsi qu'à raconter des choses autour de CLUB1 (l'article de Fae, le mémoire de Alix).
→ Pour y participer: poster un message sur le forum comme note d'intention d'article avec le tag "journal"

La doc

Faire des retours sur le forum c'est très simple. Tandis qu'écrire de la doc est plus compliqué, car ça passe par Git et/ou GitHub.

La bibliothèque

Même problématique que pour l'édition du site Web, car c'est une page de ce dernier qui est utilisée pour stocker toutes les infos.

Pour ajouter ses livres, il faut avoir les accès à l'édition de la page bibliothèque. Actuellement, c'est Fae, Alix, Nicolas, Vincent et Leila que l'on peut contacter pour être ajouté.

Conclusion:

Le forum est un endroit central pour amorcer un désir d'investissement. Ne pas hésiter à poster quoi que ce soit, avec des erreurs et ne pas s'inquiéter de ne pas choisir correctement les tags et tout!

Remarque: Les notifications du forum mériteraient d'être mieux documentées (les différentes manières de se tenir informé·e·s)

3 - Point sur le serveur Matrix

À ce moment là on a déjà consommé une bonne partie de la capacité d'attention accordable par les personnes présentes. Le prochain sujet sera sûrement le dernier. Nicolas a un point qu'il aimerait ne pas remettre à plus tard: celui concernant le rếglagle de complexité max du serveur Matrix. En tant qu'administrateur système, il a récemment dû agir rapidement pour éviter au serveur d'être coulé par une activité bien trop importante pour lui. En effet, Synapse, le logiciel fournissant le service de messagerie instantannée Matrix s'est mis à consommer la plupart des ressources de calcul partagées entre les services de CLUB1. C'est un sujet important qui apparait de façon logique dans le cadre d'un serveur qui ne peut pas se changer d'échelle (scaler en anglais).

Résumé de la problématique

depuis le commentaire de Vincent:

On en arrive au choix de ce que l’on préfère héberger. En gros: plus de sites web ou plus de conversations Matrix? Grâce à la proposition de Nicolas, on a un peu plus de nuances possibles. Il est possible de réduire la partie Matrix, mais d’une façon spécifique (plus de comptes mais moins de conversations lourdes)

Conclusion

Après quelques discussions, un consensus émerge:
Si le serveur Matrix prend à nouveau trop de ressources et tend à saturer le serveur, on est d’accord pour baisser la limite de complexité.

4 - On parle des prochains événements

• Préparation du prochain atelier site Web, intitulé Workshop #008 qui devrait avoir lien en décembre. PS: On cherche un lieu! 🔍🏕️
• Une soirée de lancement pour le service de WebRadio

Toutes les réunions du Club:

• Réunion 00313/10/2022
• Réunion 00207/10/2021
• La première réunion du club05/02/2020

brouillon en cours de rédaction!

A l'occasion de l'arrivée du nouveau service sur Club1: La radio sur Internet, on a installé un studio radio de fortune à Ivry sur Seine chez Alix pour tester ce nouvel outil avec un goûter déguisé en émission de radio de 4 heures!

Au programme: des exclus musicales de Anaïs, les songes de Cosmes, des souvenirs du web de notre enfance, une galette des rois en live, une discussion sur la fragilité et la performance, la carrière d'un informaticien dans les boites de la tech à l'époque de Netscape, le jeu des questions, un texte sur l'informatique paysanne, des biscuits et des sodas, des blancs antenne, des soucis techniques et un super chat!!!

Un nouveau service

En fait, ce n'est pas CLUB1 qui se dote d'une Web-radio, mais bien chaque membre, qui peut maintenant diffuser sa petite émission depuis le serveur. Deux ans après l'arrivée des services email, la Web diffusion est donc le nouveau moyen de cyber-expression dont disposent les membres du club.

Un nouveau service, ça veut dire de nouveaux logiciels sur le serveur. En l'occurence, il s'agit de Icecast, un programme dont la première version date de 1999. C'est un projet de la fondation Xiph, une organisation spécialisée dans les outils numériques libres autour des formats audio et vidéo.

Pour s'y connecter en tant que diffuseur, le membre CLUB1 devra disposer d'un client sur son appareil personnel. Un des plus connus est Butt (acronyme de Broadcast Using This Tool).

📘 Page de doc de CLUB1 à propos du service de Web diffusion.

Radio CLUB1

Même si cette émission-goûter était une "preuve de concept", faire de la radio en tant que CLUB1 s'est avéré très rigolo! Donc peut-être qu'on aura envie de recommencer! C'est une façon de plus d'humaniser la vie d'un serveur communautaire. Donc pourquoi s'en priver?

On garde donc sous le coude cette page de diffusion:

Et si tout le monde avait sa propre radio?

Le principe de la radio, c'est qu'un émetteur central peut émettre vers pleins de recepteurs. Alors qu'internet, c'est plein d'émetteurs-récepteurs tous connectés les uns avec les autres. La WebRadio est donc une hybridation de ces deux techniques radicalement différentes.

La radio, cet appareil de distribution, doit être transformée en appareil de communication. La radio serait le plus fantastique appareil de communication de la vie publique, un immense système de chaînes, à la condition que celui-ci puisse non seulement émettre mais aussi recevoir; ainsi, l’auditeur ne ferait pas qu’écouter, il pourrait aussi parler, il ne faudrait pas l’isoler mais au contraire le mettre en relation. […] La radio doit permettre l’échange.

Bertolt Brecht -- La radiodiffusion comme appareil de communication tiré de l'article Bertolt Brecht et la radio

Dans cet extrait datant du début des années 30, Bertolt Brecht critique la radio, alors naissante. Même si internet peut apparaître comme un élément de réponse, ça ne restera toujours qu'une technique supplémentaire. Les questions de symétrie des échanges, de système centralisé ou décentralisé sont toujours des problématiques actuelles.

Plus de photos!!

La Smirnoff Ice et des canettes de 1664 font leur apparition sur la table: le signal commence à se dégrader 😄.

Émission à ré-écouter

Si vous avez manqué ce grand moment de Web-diffusion, ou que vous n'avez pas bien compris une blague, il est possible de ré-écouter l'émission!

Un des membres de CLUB1, Alix vient de passer son épreuve de diplôme à l'ENSCI, une école de design à Paris.

Une restitution a eu lieu devant un jury. L'événement était également ouvert au public, ce qui a permis aux ami·e·s et curieux·se d'y assister. C'était le lundi 9 octobre, entre 9h et 12h, à l'ENSCI, dans le 11ème arrondissement de Paris. Il a aussi été filmé dans son intégralité!

La première partie de la matinée est pensée comme un bilan: Alix nous raconte ce qu'il a fait dans cette école pendant 6 ans. Ensuite ça enchaîne sur la présentation de son mémoire: Le catalogue du Meatspace. Et pour finir, c'est la présentation d'un projet de dîplome, un peu en mode expo. Alix présente le projet Outdoor Computer Club qu'il a monté avec Morgane, un ancien étudiant de l'ENSCI et ami.

Le catalogue du Meatspace

Le mémoire d'Alix.
Spoiler: ça n'est pas un catalogue de solutions logistiques pour le stockage de viande.

C'est un livre. Une bonne vielle brique dans ce monde physique. Le mot meatspace (contraction des mots viande et espace) a été créé en réponse au terme de cyberspace. Si on en avait envie, on pourrait le traduire par Monde charnel, comme le suggère le Wiktionnaire.

Ça nous fait un object physique de plus à secouer de la main, à lancer, à offrir, lorsque l'on souhaite présenter ou découvrir internet et ses enjeux.

Il va bientôt y avoir un exemplaire dans la bibliothèque du Club, mais en attendant, il est possible de le télécharger au format PDF. À vous de l'amener dans le meatspace via une imprimante.

De quoi ça parle?
Le catalogue du meatspace est une tentative de définir le concept de technologie populaire, soit une technologie pensée par et pour les personnes qui l'adopteraient, qui répondrait à des besoins réel et pas à la demande d'un marché et qui serait adaptée à son milieu d'adoption et aux communautés qui l'habiteraient! Ce travail s'interesse particulierement aux technologies de l'information et de la communication. On y parle d'Internet, de réseaux communautaires, de radio, de chaines HIFI, de web, de capitalisme, de resistance. On y trouve aussi des fictions dans lesquelles s'incarne cette technologie populaire

Outdoor computer Club

Alix nous raconte différentes expériences qui ont eu lieu dans le cadre du Outdoor computer Club, un projet créé en collaboration avec Morgan. La plupart du temps il s'agit d'ateliers visant à démystifier des technologies qui nous entourent de façon hyper ludique. On le suit dans la salle où sont exposées les travaux. Il y a quelques îlots correspondant chacun à un dispositif de transmission de savoir, entourant un îlot central un peu plus massif: la Data Foire.

Alix nous raconte les ateliers où ces dispositifs ont été déployés. Il l'a à chaque fois fait en s'accroupissant! Ici un atelier pour construire et expérimenter avec des transmetteurs de vidéo analogique.

Il insiste bien sur le fait que ce n'est pas toujours facile et que le résultat n'est pas toujours parfaitement fonctionnel (voir pas du tout!). Mais le fait de galérer ensemble, avec les personnes présentes à l'atelier, est peut être le plus important. Ils profitent ainsi de leur position de non-expert pour se confronter avec le groupe aux aléas du Do It Yourself.

Est-ce que vous avez reconnu?
C'est un internet miniature! Le serveur est dans son placard blanc (un distributeur de papier toilette? 🤔) tandis que des ordinateurs personnels y sont reliés par des fils colorés. Ici, tout est fait pour rendre visible l'infrastructure. Ce dispositif permet de matérialiser les relations entre les différents appareils qui consituent un petit réseau. En extrapolant un peu, ça nous donne une bonne représentation de ce qu'est l'internet.

Qui aurait cru que le "cloud" pouvait être en fait transporté sur un caddie?

Data foire

C'est un peu le clou(d) du spectacle.
La data foire est un concept rétro-futuriste de partage de contenu numérique convivial. Concrètement, c'est un stand comportant une ou plusieurs bornes numériques. Ces dernières vous permettent de brancher votre clef USB personnelle et d'y échanger des fichiers avec un support de stockage intégré. C'est une façon de partager et recevoir des données numérique qui peut paraitre désuette. Elle a tout de même une sacré valeur ajoutée: le fun! Eh oui, c'est un plaisir de traîner autour et de rencontrer les humains derrière les fichiers, de causer arborescence avec des inconnu·e·s. Le tour de force de la data foire, c'est de s'intégrer dans des pratiques traditionnellement non-numériques, comme des marchés ou des fêtes.

Si vous en rêvez mais que vous n'avez pas encore eu la chance d'en croiser une, le fascicule de présentation vous explique même comment créer votre propre data foire!

Notre bilan

A la rédaction: on adore! C'est le genre d'expérience de diplôme qu'on aimerait vivre tout les jours! Enfin sauf le week-end;)

Les +

• La boisson fraîche en mode ginger beer maison

Les -

• Les bulles de la boisson fraîche en mode ginger beer maison n'ont pas duré longtemps.

🍾 Bravo Alix! 🍾 Et Morgane aussi! (qui semble approuver la situation) 🍾

Bonus: la captation 📺

Captation vidéo intégrale réalisée par l'ENSCI

Cet article est le dernier d'une série de trois. Il raconte le déroulement de la migration effective de Ubuntu vers Debian.

Étapes de la migration

Pour rappel, cette migration a été découpée en trois étapes.

La première était de préparer le dossier de configuration du serveur afin de permettre sa transplantation dans une distribution Linux différente. L'article Migration de Ubuntu à Debian (Phase 1) fait le récit de cette première partie.

La deuxième était de préparer les sauvegardes du serveur pour être certains qu'elles contiennent toutes les données nécessaires et qu'elles s'appliquent correctement sur le nouveau système. Elle est détaillée dans l'article Migration de Ubuntu à Debian (Phase 2).

La dernière partie, ici présente, fait un point sur la migration du serveur CLUB1 en tant que telle.

Dernières préparations

Cette fois-ci c'est le grand jour, la migration aura enfin lieu. Quelques jours avant, nous nous sommes dits que c'était tout de même un peu tenter le diable que d'écraser le disque comportant le système actuel lors de la migration. Nous avons jugé plus sage d'acheter un SSD supplémentaire afin de conserver l'ancien intact et pouvoir le réutiliser tel quel en cas de fiasco. Nous nous sommes également dits que quitte à acheter un nouveau matériel, autant profiter du port M.2 présent sur la carte mère, permettant un meilleur débit que le SATA 3 et jusqu'alors inutilisé. Nous achetons donc, un peu en urgence, un SSD Samsung de 1 To chez LDLC.

Au moment de l'écriture de l'article de la phase 2 il restait encore quelques problèmes à résoudre, notamment empêcher les services tout juste installés de se lancer automatiquement. C'est là qu'intervient la fonctionnalité de preset de Systemd, parfaitement adaptée à notre besoin. Nous nous étions aussi rendus compte que la clé de vérification du dépôt de Grafana était périmée dans extrepo, un outil permettant d'ajouter de manière sécurisée des dépôts Debian externes. Heureusement notre proposition de mise à jour a été acceptée juste à temps.

Nous avions prévu d'utiliser les sauvegardes pour réaliser la migration, mais celles-ci se font la nuit, à 5 heures. Pour ne pas perdre les données de la matinée, nous redémarrons le serveur en mode récupération, afin qu'aucun service ne soit lancé, et nous lançons à 12:30 une sauvegarde du système et des bases de données. À partir de cet instant, CLUB1 est inaccessible pour une durée de 9 heures.

Installation de Debian

Une fois la sauvegarde terminée, nous déconnectons l'ancien SSD et installons le nouveau. Les choses sérieuses peuvent commencer.

Les problèmes commencent

Le protocole de restaurations des sauvegardes ayant été bien éprouvé, il n'y a pas eu de grosse surprise lors de la migration. Cependant, tous les services n'avaient pas vraiment été testés lors des exercices, car nous nous sentions capables de finaliser les réparations le moment venu. Il y a donc évidemment eu quelques soucis:

• Un certain temps a été dédié à réparer un problème qui n'en était pas vraiment un avec l'annuaire LDAP. Sa base de données semblait vide alors qu'il suffisait de redémarrer nslcd. Et la raison pour laquelle ldapfinger ne nous renvoyait aucun résultat était dû à son fichier de mot de passe corrompu lors de la fusion du dossier etc.
• Les bases de données SQL étaient bien toutes sauvegardées sauf une: mysql, automatiquement exclue par le logiciel de sauvegarde. Elle contenanait les utilisateurs et leurs permissions qu'il n'a pas été trop compliqué de recréer avec les scripts de CLUB1. Mais il faudra trouver un moyen de sauvegarder ces données proprement.
• Pour une raison mystérieuse, Icecast était impossible à démarrer avant d'avoir relancé la configuration automatique du paquet Debian. Le script InitV appelait systemctl, mais aucune unit n'est présente.
• Le plugin LDAP pour Tiny Tiny RSS nécessitait de créer un lien symbolique dans /usr/share/tt-rss/www/plugins/.
• La version de Roundcube avait changé et le dossier vers lequel faire pointer le virtual host aussi.

Il aurait été possible d'éviter ces soucis en amont en testant bien tous les services et en réparant leur configuration à l'avance, mais tout ce travail à faire au préalable est long et épuisant et retarde d'autant plus la migration dont la préparation commençait à s'éterniser.

Enfin fini!

Le MOTD (Message Of The Day ou message du jour), un des rares endroits où l'on peut vraiment percevoir une différence en tant qu'utilisateur.

On y décèle également l'arrivée du nouveau SSD système de 1 To.

Il reste encore quelques détails à peaufiner sur le protocole de restauration, mais dans l'ensemble la migration s'est plutôt bien déroulée.

Le découpage en phase a permis de rendre plus appréhendable ce processus long et fastidieux. La phase de fusion du dossier /etc était particulièrement satisfaisante grâce à la puissance de l'outil Git, notamment la possibilité de facilement intégrer les évolutions de la configuration de CLUB1 au cours du temps, en lançant à nouveau la commande de fusion.

Ce chapitre maintenant clos, il va enfin être possible pour CLUB1 de mettre à jour certains logiciels, car pendant toute la période de préparation, les versions des logiciels sur le serveur étaient gelées, pour éviter des imprévus supplémentaires.
Stay tuned pour la prochaine mise-à-jour vers Debian Stable.

Et finalement, nous avons maintenant la certitude que nos sauvegardes nous permettent bien de restaurer l'ensemble du serveur CLUB1 en cas de panne matérielle sur le disque système.

Tous les articles de cette migration

• Migration de Ubuntu à Debian (Phase 1)Premier récit d'une migration épique01/08/2023
• Migration de Ubuntu à Debian (Phase 2)Exercices de restauration de sauvegardes14/11/2023
• Migration de Ubuntu à Debian (Phase 3)La migration en tant que telle30/11/2023

Cet article est le deuxième d'une série de trois. Il raconte la préparation de la migration de Ubuntu vers Debian, en particulier les exercices de restauration de sauvegarde.

Étapes de la migration

Pour rappel, cette migration a été découpée en trois étapes.

La première était de préparer le dossier de configuration du serveur afin de permettre sa transplantation dans une distribution Linux différente. L'article Migration de Ubuntu à Debian (Phase 1) fait le récit de cette première partie.

La deuxième, détaillée dans le présent article, était de préparer les sauvegardes du serveur pour être certains qu'elles contiennent toutes les données nécessaires et qu'elles s'appliquent correctement sur le nouveau système.

La dernière partie consistera en la migration effective du serveur CLUB1.

🚧 Cette migration aura lieu le Samedi 25 Novembre après-midi et durera au moins 6 heures, pendant lesquelles le serveur CLUB1 ne sera plus disponible.

Sauvegardes de CLUB1

Les données du serveur sont sauvegardées une fois par jour (voir la page de la documentation des sauvegardes). Ces sauvegardes nous permettent par exemple de restaurer des données dans le cas où elles auraient été supprimées par erreur, mais surtout de restaurer l'ensemble du système en cas de panne matérielle.

Le premier cas d'usage avait déjà été mis en application, mais le deuxième n'avait jamais vraiment été testé. En effet, nous n'avons pas encore eu de défaillance au niveau du matériel du serveur. Toutefois, il ne faut évidemment pas attendre une panne avant de vérifier que les sauvegardes fonctionnent correctement. C'est pourquoi il est important de faire des tests en amont, afin d'être certains que les sauvegardes nous permettront de rétablir le service après un incident majeur.

Exercices de restauration

Entre la fin de la première phase et aujourd'hui, plusieurs tests de restauration de sauvegardes ont été réalisés. Chacun de ces tests nous ont permis de réviser et étoffer le protocole de restauration, détaillé dans un post sur le forum (plus tard dans une page de la documentation).

Comme on pouvait s'y attendre, les premières restaurations ne se sont pas tout à fait déroulées comme prévu. Voilà une partie des problèmes qui ont été rencontrés et corrigés au fil des exercices:

• Certaines données n'étaient pas correctement sauvegardées, comme c'était le cas pour la base de données de l'annuaire LDAP.
• L'ordre dans lequel les différentes données doivent être restaurées a été peaufiné.
• Le protocole de restauration était dépendant de certaines données liées au compte de Nicolas, l'administrateur système de CLUB1. Dans le but de permettre à d'autres personnes de rejoindre l'équipe d'administration, l'ensemble des données nécessaires a été ajouté aux sauvegardes.
• La sauvegarde système a été divisée en trois afin de pouvoir plus rapidement restaurer le système de base. En particulier, les bases de données PostgreSQL font maintenant l'objet de leur propre sauvegarde.
• Il a été convenu de restaurer les sauvegardes depuis le dépôt externe, ce qui permet d'avoir le même protocole lors des exercices et de la véritable migration.

Conclusion

Une fois encore, beaucoup de travail a été réalisé lors de cette deuxième phase, mais ce travail n'est pas seulement utile pour la migration, il permet également de valider que nos sauvegardes sont réellement efficaces et qu'elles nous permettent bien de restaurer le serveur CLUB1 après une panne majeure.

De plus, une grande partie de ces exercices n'ont pas été réalisés par Nicolas seul, Etienne (qui héberge d'ailleurs le dépôt externe des sauvegardes CLUB1) y a aussi participé. Ce, pour lui permettre de prendre en main l'architecture de CLUB1 en prévision de sa prochaine inclusion dans l'équipe d'administration système (oui, c'est une annonce en avant-première pour ceux qui ont lu jusqu'au bout).

Ajourd'hui à 13h le serveur n'était plus accessible. C'est en allant voir nos emails d'alerte que la situation s'éclaircit, ll s'agit en fait d'une coupure d'électricité prolongée à la Cyb­errance:

Comme on peut le voir, l'onduleur a très bien rempli son rôle. Il a réussi à encaisser la première coupure de 12h22 à 12h48 sans broncher. Mais peu après, une nouvelle coupure est venue à bout de la capacité de sa batterie, il a donc envoyé au serveur un signal d'arrêt, afin qu'il séteigne de lui-même, proprement.
C'était la première fois que ce scénario se produisait et qu'il mettait à l'épreuve notre configuration d'arrêt automatique et tout s'est déroulé comme prévu!

Après avoir contacté des personnes sur place, nous apprenons que la coupure risque de perdurer encore quelque temps et nous n'étions pas certains du temps qu'il faudrait pour rétablir le courant.

Pour rappel, l'hébergement du serveur à la Cyb­errance nous avait été proposé en dépannage lorsque la connexion Internet à Pantin était coupée. Il était prévu pour être temporaire, le temps que l'infrastructure fibre soit réparée. Celle-ci a finalement été réparée le 13 septembre (soit un peu plus de 3 mois après le début de la panne et presque 2 mois après le déménagement), mais nous n'étions pas non-plus particulièrement pressés pour rapatrier le serveur dans son placard.

La coupure de courant a finalement joué le rôle d'élément déclencheur, car aujourd'hui étant un jour férié, nous étions justement disponibles pour déménager à nouveau le serveur:

• 15h30: On se met en route pour Romainville.
• 16h00: Déconnexion et chargement du serveur dans la camionette.
• 16h30: Remontage du serveur dans son armoire rack.
• 17h00: Reconfiguration du serveur à cause du changement d'adresses IP.
• 17h30: Configuration terminée, reste à attendre la "propagation" de nos modification DNS.
• 22h00: Les informations DNS de club1.fr sont globalement cohérentes et le service est entièrement rétabli.

Cet article est le premier d'une série de trois. Il raconte la première phase d'une migration de la distribution Linux utilisé sur le serveur CLUB1, ainsi que les raisons qui ont motivé cette opération.

Un peu de contexte

Pour rappel, l'infrastructure de CLUB1 est basée sur un serveur unique, auto-hébergé à Pantin (enfin en ce moment à Romainville). Dans une optique de simplicité et de retour au sources, aucune virtualisation n'est mise en œuvre. Il n'y a donc pas d'hyperviseur, de machines virtuelles, ni même de conteneurs. Le système d'exploitation est ainsi directement installé sur la machine physique et les programmes au niveau du système, à l'aide du gestionnaire de paquets intégré.

Cette simplicité a, entre autres, l'avantage de mieux transmettre la sensation d'ordinateur partagé que l'on met en avant, car les ressources de la machine sont réellement mises en commun entre tous les membres et services, au lieu de segmenter et séparer les utilisateurs dans des boites qui ne peuvent pas influer l'une sur l'autre comme le font les techniques de virtualisation. On se rapproche en se sens de l'esprit du tildeverse, comme on peut le lire sur tilde.club (le serveur à l'origine de ce courant) :

tilde.club is not a social network it is one tiny totally standard unix computer that people respectfully use together in their shared quest to build awesome web pages

tilde.club n'est pas un réseau social c'est un petit ordinateur unix totalement standard que les gens utilisent respectueusement ensemble dans leur quête commune de farication de superbes pages web

L'une des conséquences de ce mode de fonctionnement est que l'administration du système devient plus fortement dépendante du système d'exploitation utilisé et plus particulièrement de la distribution Linux.

Une distribution Linux [...] est un ensemble cohérent de logiciels, la plupart étant des logiciels libres, assemblés autour du noyau Linux, et formant un système d'exploitation pleinement opérationnel.

Une distribution apporte de nombreux avantages. Elle fournit notamment des logiciels compatibles entre eux, c'est-à-dire qu'en mettant à jour le système, on ne risque pas de se retrouver avec des versions incompatibles. Cela permet également de mettre en commun les dépendances de tous ces logiciels. En plus de ça, les mainteneurs d'une distribution se chargent d'appliquer les correctifs de sécurité au plus vite. La charge de maintenance des administrateurs système s'en trouve ainsi nettement réduite.

Bien que souvent proches, les différentes distributions Linux existantes ne sont pas compatibles entre elles. La pile logicielle utilisée est souvent légèrement différente, les fichiers de configuration ne se trouvent pas forcément exactement au même endroit, etc. Passer de l'une à l'autre demande donc toujours d'adapter plus ou moins la configuration du système en fonction de leur éloignement.

Le graphe ci-contre (cliquer pour voir en taille réelle) représente l'ensemble des distributions Linux et leurs liens de parenté. Un arbre (ou plutôt une forêt) phylogénique pourraient dire les biologistes. Plus les branches divergent, plus il risque d'y avoir des différences entre elles.

Pourquoi faire cette migration?

La distribution utilisée jusqu'à maintenant chez CLUB1 est Ubuntu. Elle est souvent recommandée pour les débutants car simple à installer et très répandue, ce qui permet de facilement trouver des infos en cas de pépin. Elle est directement issue de Debian, l'une des trois premières distributions Linux, elles ont donc un grand nombre de points communs. Une différence notable entre Ubuntu et Debian est que la première est dirigée par une entreprise, tandis que la seconde est entièrement communautaire, il s'agit donc d'un projet qui résonne mieux avec notre démarche.

Connaissant bien Debian du fait qu'il l'utilise tout les jours sur son PC, Nicolas, administrateur système de CLUB1, a pu petit à petit noter les différences avec Ubuntu. Hors, ses goût allaient en général pour les parti-pris de Debian, ce qui lui donne envie de les retrouver sur le serveur. Voici les avantages qu'il y trouve:

• Le gros du travail est réalisé en amont par la communauté de Debian. C'est donc là qu'on peut suivre le travail des nombreux mainteneurs.
• Toutes les informations et prises de décision sont publiques et les différents outils Web sont plus détaillés et plus agréables à utiliser que leurs équivalents sur Ubuntu (tracker, manpages, security-tracker, etc.).
• Il n'y a pas besoin de "compte Debian" pour intéragir avec les différents mainteneurs (report de bugs, questions, etc.), une simple adresse email suffit.
• Ubuntu pousse de plus son propre gestionnaire de paquets Snap qui va à l'encontre des principes d'empaquetage Debian.
• La séparation entre les dépôts libres et non-libres est plus claire.

Étapes de la migration

Cette migration a été découpée en trois grandes étapes afin de la rendre plus appréhendable:

1. Merge du dossier de configuration (/etc/):

   Ubuntu et Debian sont deux distributions Linux très proches, mais simplement copier l'ancien dossier de configuration de l'une a l'autre ne produirait pas le résultat attendu, car l'idée en faisant cette migration est de se rapprocher le plus possible d'une Debian pure, pas de se retrouver avec un genre de FrankenDebian. Le plan est donc de fusionner les deux dossiers de configuration, en ne gardant de l'ancien que les configurations spécifiques à CLUB1 et en se débarrassant des modifications d'Ubuntu. Pour cela nous allons tirer parti de Git car ce dossier est déjà versionné à l'aide de etckeeper.

2. Tests de restauration de sauvegarde:

   Une fois le dossier de configuration proprement fusionné, la suite du plan consiste à restaurer le reste des sauvegardes directement sur le nouveau système. Afin de s'assurer que tout se passera bien au moment de réaliser cette opération en production, nous ferons des tests de restauration en amont. Ce sera d'ailleurs l'occasion de vérifier que l'on est bien capable de restaurer les sauvegardes automatiquement sur un nouveau système car ce test n'a pas encore été réalisé.

3. Migration en production:

   Normalement, une fois que les deux premières étapes sont passées, il ne reste plus grand chose à faire, si ce n'est la véritable migration. Comme le terrain aura été bien préparé il ne devrait pas y avoir trop d'imprévus, mais on ne sait jamais ... il se peut donc que ça soit plus compliqué que prévu. Il y aura de toute façon une interruption de service dont nous communiquerons la date en avance (dans l'article de la phase 2).

L'avancée globale peut être suivie sur le fil #9 du forum.

Récit de la première étape

Le dossier /etc/ contient l'ensemble des configurations du système. On peut séparer les fichiers de configuration en deux grandes catégories:

• Ceux qui sont gérés par le gestionnaire de paquet (apt dans notre cas) et qui sont installés en même temps que les logiciels. Il est tout de même possible de les éditer, mais cela risque de créer des conflits lors des mises-à-jour.
• Les autres, ceux que les administrateurs système ajoutent eux-même. Les distributions prévoient en général un dossier ***.d pour chaque logiciel dans lequel il est possible d'ajouter ses propres fichiers de configuration. Ces fichiers ne risquent pas de générer de conflit.

Entre Ubuntu et Debian, c'est parmi la première catégorie de fichiers de configuration qu'il peut y avoir des différences. Le but de ce merge est dans un premier temps d'identifier et d'annuler ces différence-ci, pour ne garder que les configurations vraiment propres à CLUB1.

L'idée pour ce faire, est d'utiliser la fonctionnalité de merge de Git avec l'option --allow-unrelated-histories qui permet de fusionner deux dossier similaires tout en identifiant les conflits. En installant tous les logiciels utilisés par CLUB1 sur une installation fraîche de Debian, on obtient dans le dossier /etc/ les configurations d'origine de la distribution. C'est ce dossier qui va servir de base pour la fusion. La dernière piece manquante est la liste des paquets installés. Celle-ci ne fait (pour le moment) pas partie des sauvegardes, car elle ne se trouve pas dans le dossier de configuration. Il est prévu de l'ajouter dans les sauvegardes qui suivront la migration.

Récupérer la liste des paquets installés

Sur Debian et ses dérivées, les paquets installés peuvent se diviser en deux catérogies (encore! 😅) :

• Ceux qui sont installés manuellement, parce qu'explicitement demandés par les administrateurs système.
• Ceux qui le sont automatiquement, parce qu'ils sont requis par des paquets installés manuellement. Ce sont les dépendances.

Les seuls qui nous intéressent sont ceux qui sont installés manuellement. Les dépendances seront de toute façon installées automatiquement et il est aussi possible qu'elles changent entre les différentes versions. Pour récupérer cette liste des paquets installés manuellement on utilise la commande suivante.

Et pour les installer sur le nouveau système:

Mais cette liste est encore incorrecte. Elle contient notamment certains paquets propres à Ubuntu, qui ne sont pas présents dans Debian. Certains paquets ont également changé de nom. On reçoit donc plusieurs erreurs de ce style:

Une fois la liste nettoyée de ces paquets incorrects, on obtient une liste réellement installable, mais elle peut encore être améliorée. En effet lors de l'installation on obtient ce genre de messages:

On remarque que certains paquets ont été installés en mode manuel alors qu'ils n'auraient pas dû. C'est une erreur qui a été faite à cause d'un manque d'expérience lors d'une mise-à-jour du système. Pour nous en débarrasser, une passe de filtrage supplémentaire est réalisée à partir de ces messages d'erreur et de quelques commandes awk et grep.

Finalement la liste est réduite à son stricte nécessaire. Et on peut l'installer, toujours avec la même commande, pour obtenir un dossier /etc/ contenant toutes les configurations d'origines de Debian de l'ensembles des paquets utilisés chez CLUB1.

La fusion

Vient enfin le moment du merge tant attendu. Comme dit précedemment, celui-ci se fait à l'aide de Git. Voilà ci-dessous un script commenté présentant les différentes étapes de cette fusion.

Bien que le nombre de fichiers en conflit fût très élevé (581), l'utilisation combinée de Git en mode intéractif et vim en tant que mergetool ont rendu cette tâche relativement agréable. Le fait de pouvoir le faire tranquilement en amont a aussi permis de bien prendre le temps de résoudre tous ces conflits.

Après avoir vérifié 581 fichiers en conflits et pas loin de 900 fichiers ajoutés, On se retrouve finalement avec 275 nouveaux fichers à conserver, 82 fichiers modifiés et 622 fichiers supprimés. Ça fait un bon petit nettoyage des anciennes configurations du serveur. Reste encore à vérifier que ça fonctionne. 🤓 Mais l'un des énormes avantages de cette technique de fusion est justement que tous les fichiers sont conservés dans l'historique de Git, ainsi que l'ensemble des modifications précédentes (824 commits). Si on se rend compte plus tard que l'un d'entre eux était en fait nécessaire il nous suffira de retourner l'y chercher.

Nous voilà enfin avec un dossier de configuration /etc/ contenant les configurations spécifiques à CLUB1 tout en restant le plus proche possible d'une Debian pure et en conservant l'historique des modifications effectuées précédemment. Nous sommes fins prêts pour la suite de l'aventure: les tests de restauration de sauvegardes.

Félicitation pour avoir lu ce (trop?) long article jusqu'au bout et à bientôt pour le résumé de la phase 2! 😎

[PC]: Personal Computer (Ordinateur Personnel)

Jeudi 20 Juillet, sur un coup de tête, lui même influencé par un raz-le-bol, on s'est décidé à déménager le serveur CLUB1 le temps d'une errance cybernétique à Romainville, pendant que la coupure Internet à Pantin persiste.

Il se trouve dorénavant à la Cyberrance, lieu alternatif accueillant des ateliers d'artistes, quelques habitants, ainsi que des événements, le tout dans une ambiance mi-chalet, mi-hangar industriel. Profitons-en pour remercier les membres de la Cyb' et tout particulièrement Armand pour cet accueil spontané!

C'est une belle histoire dans laquelle le réseau humain a pris le relais sur le réseau technique. Et où les muscles et le moteur thermique (déjà un peu low-tech?), ont remplacé l'infrastructure électronique permettant d'habitude le transit de données sur Internet. C'est aussi l'expression d'un choix: celui de préferer s'investir dans des relations avec des personnes et des lieux qui nous sont chers et auxquels on croit, plutôt que de subir un faux dialogue avec une entreprise du CAC40 qui ne nous respecte pas.

Et qui aurait pu prédire qu'un jour la Cyberrance porterait si bien son nom en acceuillant une parcelle d'Internet en son sein?

Diaporama photos

Comme nous utilisons maintenant du matériel rackable (Voir l'article Un nouveau boitier), pour rendre le serveur déménageable, il lui faut une coquille de voyage. Il se trouve que l'on a sous la main un Flycase SKB 4U rotomoulé. C'est plus qu'il n'en faut car notre configuration de voyage ne nécessite que 3U (2U pour le serveur + 1U pour l'onduleur).

Même si l'installation consiste essentiellement à rebrancher quelques câbles, le déménagement nécessite tout de même quelques actions d'administration du système. Le nom de domaine club1.fr était dirigé vers l'ancienne adresse IP, il faut indiquer à toute personne surfant sur le web que le serveur CLUB1 a déménagé! Pour cela on remplace l'ancienne adresse par l'adresse IP actuelle de la Cyberrance. Cette mise-à-jour n'est pas immédiate car il faut le temps que la nouvelle s'ébruite (on appelle cela la propagation DNS).

🎉 Comme d'habitude en informatique, tout s'est bien passé du premier coup et le serveur est disponible sur Internet à peine une demi heure après son réveil.

Conclusion

Cette expérience s'est déroulée de façon si agréable qu'elle ouvre la voie à une nouvelle piste d'exploration: celle d'un serveur un peu plus nomade. On peut se laisser aller à imaginer le serveur rendre visite à différents membres de CLUB1. On se rapprocherait ainsi de la notion d'entre-hébergement développée par DeuxFleurs. Cela rappelle aussi les réflexions du groupe de travail charavane, découvertes lors du dernier camp CHATONS. Bien-sûr, cela apporte son lot de problèmes techniques (on peut s'inquiéter de la crédibilité des emails provenant d'adresses IP trop variées), mais cette nouvelle aptitude apporte tout de même une certaine indépendance vis à vis des FAI.

Finalement le plus long était de trouver la bonne disposition du placard à chaussures.
On prévient Armand qu'il risque d'y avoir quelques interférences au niveau de ses rêves, vu qu'il ne dort pas très loin. En tant qu'habitant de la Cyberrance, il semble totalement préparé à ce genre d'éventualité. Si les interactions entre les mondes virtuels et physiques sont souvent bénéfiques, on espère cependant que les sites web n'auront pas trop une odeur de pied vu leur proximité nouvelle avec des chaussures.

Schéma de l'infrastructure fibre optique autour du serveur CLUB1.
Les lignes orange correspondent à l'infrastructure mutualisée, gérée par l'opérateur d'infrastructure (du PM au PRI, inclus). Tout ce qui est bleu est géré par Bouygues télécoms et en rose par CLUB1. Les PBO sont sous la responsabilité de l'immeuble et les PTO sous celle des FAI (aussi appelés opérateurs commerciaux).
Schéma d'origine provenant du blog uniformatic.

Le lundi 5 juin à 9h00 nous recevons une alerte de notre système de monitoring nous informant que l'ensemble des systèmes de CLUB1 sont interrompus. Comme c'est souvent le cas, il s'agit d'une panne au niveau de la connexion à Internet, l'ensemble du materiel et du logiciel du serveur se comportant correctement. Habitués à ce genre de panne, nous espérions un retour à la normale après quelques heures.

Mais après 5 heures la connexion n'était toujours pas rétablie. Nous décidons de tenter de redémmarrer plusieurs fois la box de notre FAI (Bouygues télécoms) et le point de terminaison fibre mais rien n'y fait. Nous contactons alors Bouygues pour déclarer l'incident et obtenir plus d'informations.

Sur le portail de gestion de la ligne, Bouygues nous informent qu'ils sont déjà au courant de l'incident:

Un incident impactant l'ensemble de vos services est en cours. Nos équipes sont mobilisées pour le résoudre. Merci de laisser vos équipements branchés.

Lors de la déclaration, plus d'informations nous sont ensuites présentés. Il s'agit visiblement d'un incident généralisé au quartier, comme l'indique le site de Bouygues:

Détection d'un incident global

Un dysfonctionnement collectif a été déclaré sur votre zone. Merci de laisser vos équipements branchés.

Le traitement du dysfonctionnement collectif est en cours. Vous serez bientôt informés de la prochaine étape.

Nous recevons également le SMS suivant apportant quelques informations supplémentaires:

L'incident sur votre Bbox ne vient pas de chez vous, mais nécessite une intervention sur notre réseau. Nos techniciens sont mobilisés et vos services devraient etre rétablis le 19-06-2023 00:00:00. Pensez à laisser vos équipements branchés pour leurs diagnostics.

La date de rétablissement annoncée du 19 juin, soit deux semaines plus tard n'augurait rien de bon. Le lendemain, nous avons donc contacté notre FAI par téléphone pour obtenir plus d'informations.

Il s'agit en fait d'une panne au niveau de l'opérateur d'infrastructure fibre, sur laquelle Bouygues n'ont donc pas la capacité d'agir directement. Notre interlocuteur nous a également confirmé que la date donnée pour dans deux semaine était arbitraire et qu'il était possible que l'incident se résolve plus rapidement. Quoi qu'il en soit, toute l'infrastructure fibre du quartier était belle et bien hors-service ce qui affecte donc tous les FAI commerciaux qui l'exploitent.

Un petit tour sur la carte des déploiements fibre de l'ARCEP nous permet de vérifier qui est l'opérateur d'infrastructure dans notre quartier. Dans notre cas, il s'agit d'Orange.

Mise-à-jour par Nicolas (17/06 21:27)

Le mercredi 14 nous recontactons Bouygues télécoms pour essayer à nouveau d'obtenir un peu plus d'informations car l'attente commençait à se faire longue. Cette fois le conseiller nous a certifié que la connexion ne serait pas rétablie avant le 19. Nous espérions qu'il puisse au moins nous donner l'état d'avancement de la réparation, mais il n'avait pas beaucoup plus d'informations que nous n'en avions déjà, mis à part que l'incident affectait 58 clients Bouygues et qu'elle était causée par la panne de deux points de mutualisation (PM) au niveau d'Orange.

Il nous explique néanmoins que l'on recevra un SMS le 19 lorsque l'incident sera résolu et qu'il faudra à ce moment-là répondre si oui ou non la connexion est bien rétablie.

Mise-à-jour par Nicolas (19/06 18:51)

Finalement, le lundi 19 toujours rien. Pas de SMS non plus. À 18h30 je décide de contacter à nouveau le service client par téléphone. On me dit cette fois que la date butoir est en fait le 23. Je répond que ça commence à bien faire et que je n'ai reçu aucune notification de ce changement de date. Mon interlocuteur me conseille alors de redémarrer l'ONT et la box. Après ce redémarrage, l'ONT semble en meilleure forme car son voyant LOS n'est plus allumé en rouge et les trois autres sont verts, la box n'arrive cependant toujours pas à recevoir une adresse IP. Il m'explique alors qu'il prend en charge mon dossier et qu'il me rappellera plus tard dans la journée.

Mise-à-jour par Nicolas (20/06 15:44)

Pas de nouvelles du précédent technicien. J'ai décidé d'appeler Bouygues tous les jours à partir de maintenant pour qu'ils se bougent un peu. Au téléphone toujours pas d'info plus précise que "il y a eu des complications", j'ai cette fois poussé une petite gueulante parce que ça fait du bien. Elle semble avoir eu son petit effet puisque je suis sensé être rappelé plus tard par un supérieur.
Quand? On verra bien.

Mise-à-jour par Nicolas (21/06 16:29)

Un nouvel appel, le technicien Bouygues commence à me connaître. Cette fois il me donne la date du 26 Juin, tout en me confirmant que c'est bien Orange qui fait glisser la date de cette façon. Il m'explique que d'après Orange, le signal obtenu après réparation était de trop mauvaise qualité et qu'il fallait donc rerouter les fibres. Je lui demande si il pourra me fournir un rapport technique de l'incident tel que devrait le fournir Orange. Il me dit qu'il n'y a rien de prévu pour ça mais qu'il essaiera de faire remonter cette demande. Il me dit aussi que dorénavant je recevrai un appel directement à chaque mise-à-jour de leurs informations (exactement ce que je voulais depuis le début en fait). Espérons que ces appels ne se perdent pas dans les limbes comme les précédents appels promis.

Mise-à-jour par Nicolas (27/06 16:53)

Hier j'apprend que notre voisin du dessous, qui lui a souscrit son offre fibre chez Orange, a pu récupérer sa connexion fibre dès le 21 Juin. J'appelle donc Bouygues aujourd'hui une fois de plus, cette fois j'entend une musique d'attente au moment ou le technicien décroche, et c'est finalement une autre personne qui répond. J'en déduis que le technicien en a eu marre de mes appels et qu'il m'a directement transféré à un autre service.

Cette fois je leur explique, furieux, la situation de mon voisin. Mon interlocutrice me dit que si mon voisin a eu sa connexion rétablie avant la mienne c'est parce qu'il est abonné Orange et que l'opérateur d'infrastructure a donc priorisé ses propres abonnés lors de la réparation. Je lui explique une fois de plus qu'un serveur est hébergé sur cette connexion, que ce n'est pas juste une personne qui est impactée par cette coupure et je menace de passer chez Orange si c'est ce qu'il faut faire pour rétablir la connexion (en réalité ce sont des menaces en l'air, Orange est le pire opérateur pour s'auto-héberger). Elle me donne alors la date du 3 Juillet (est-ce que je crois encore à ces dates? Je ne crois pas non) et me garantit qu'elle me rappellera le 3 au matin pour vérifier que la connexion est bien rétablie (même question pour les appels Bouygues). Elle me dit qu'elle laisse une note sur mon dossier et qu'elle fera ce qu'elle peut pour augmenter sa priorité.

La journée placard ouvert à été organisée dans le cadre de l'International Trans★Feminist Digital Depletion Strike le mercredi 8 mars 2023. C'est Alix qui nous a fait part de cet événement lors d'un message sur notre forum. On a pu partager du Grog au beurre 😵, du jus de gingembre (maison 😎) et un cake banane chocolat, avec la vingtaine de personnes qui ont bravé la pluie pour nous rejoindre.

Placard ouvert?

Lorsque suffisament de personnes s'accumulent dans la file d'attente (à partir de deux), une visite guidée du serveur est lancée. Il faut alors suivre Nicolas jusqu'au placard, patienter un peu lors de l'ouverture de la porte, puis diriger son regard vers la partie haute des étagères. S'ensuit une présentation complète de l'infrastructure technique, riche en anecdotes et détails croustillants. Elle aidera les curieux·ses à sentir les relations subtiles entre le fond (software) et la forme (hardware) qui sont à l'œuvre dans cet assemblage.

À part ça, pas trop d'autres activités formelles. C'était surtout pleins de petits moments de discussions, échanges d'idées, racontage de projets et partages de ressentis.

❤️ On remercie toutes les personnes qui ont participé à ce moment chaleureux! ❤️

Les enjeux du goûter

Lorsqu'on a planifié cette entrevue, il etait question de mener des ateliers de customisation de clefs usb comme support manuel à des discussions sur nos relations au cloud. Alix pensait qu'il etait important de vraiment adresser cette question de manière précise, alors que Vincent était plus concentré sur la confection de boissons chaudes, froides, alcoolisées et non alcoolisées et de cakes salés et sucrés. À la fin de la journée, après avoir mis de côté l'activité planifiée et préféré des discussions informelles, pas necessairement sur le cloud on s'est rendu compte que c'etait déjà pas mal d'avoir pu rassembler autant de personnes et passer un moment aussi convivial.

Finalement les gâteaux et les boissons étaient tout aussi importantes, voire d'avantage, que la précision des activités proposées. Face à un sujet aussi rugueux que la technologie de communication et d'information et avec une population encore majoritairement masculine, la question de l'accueil et du soin prenait tout son sens. Les gâteaux salés et sucrés et les boissons chaudes et froides et alcooliques et non alcooliques etaient garant·es de l'inclusivité de la réunion. Alors on a peut-être pas beaucoup parlé de cloud, mais au moins tout le monde s'est senti à l'aise et aura peut-être envie de revenir la prochaine fois!

Album photo

Projection du film "Les stagiaires"

La journée s'est terminée devant la projection du film Les Stagiaires. Le film met en scène deux boomers, dépeints comme loosers car n'ayant pas de carrière professionnelle stable ni de vie de famille. Google est montré comme une terre d'accueil pour toustes, un peu comme MacDo, mais ayant en plus l'avantage de donner du sens à la vie de celles et ceux qui y travaillent.

L'entreprise est même qualifiée de "jardin d'Eden" par Owen Wilson lorsque son ami ose vouloir arrêter son stage chez Google. Le film est donc clairement une longue publicitée à peine camouflée en comédie populaire. Ce qui frappe, c'est l'aspect omniprésent et officiel de la marque, qui dépasse largement le placement de produit habituel ou encore le soft power américain diffu des films hollywoodiens. C'est la métonymie d'un monde dystopique où l'on irait voir les films Amazon, Uber ou Gaz de France.

Même si cette forme de long-métrage-publicitaire peut paraître grotesque, c'est un rappel clair que la domination s'exerce à travers de nombreux vecteurs et que l'art est très loin d'y échapper.

Si la ré-appropriation des formes artistiques par les boîtes de la Silicon Valley vous intéresse, on vous invite à écouter l'inverview de Fred Turner sur France Culture, auteur du livre L'usage de l'Art (Dispo dans la bibliothèque CLUB1 😉)

- Petite clarification, quand tu dis "sur la ligne", tu veux dire "en ligne" ?

Cet extrait illustre le fossé générationnel qui sépare les protagonistes principaux, qui ont la quarantaine, du reste de leur équipe. À CLUB1, cette expression nous a tout de même charmés et on n'hésitera pas à l'utiliser. Peut-être parce que c'est une façon de plus de ne pas faire comme Google?

Un peu de contexte

Cet article est le fruit des réflexions d'une membre de CLUB1, Guilhem, qu'elle a originellement écrit sur son site perso. On est plusieurs membres de CLUB1 à avoir aimé lire l'article lorsqu'il a été partagée sur le forum. On lui a donc proposé de le partager au sein du journal de bord du serveur!

C'est aussi un premier pas vers l'ouverture de ce journal à d'autres formes que les récits techniques, présentations de nouvelles fonctionnalités ou comptes rendus de réunions. On se dit que ça pourra aider à inclure et mettre en avant d'autres voix au sein de CLUB1.

Cette réflexion sensible de Guilhem nous donne également plein de pistes pour de futurs ateliers concernant l'inclusivité.

Ça m'intéresse de proposer des moments où parler d’informatique et de technologies par le prisme des émotions, des ressentis. J’ai l’impression qu'on parle souvent de ce qui se passe dans les espaces virtuels par rapport au contenu qu’on y trouve, pas trop comment on se sent en étant dans ces espaces. Je crois que je ressens ces espaces comme quelque chose de très concret quand je suis dedans, et en même temps particulièrement difficiles à cerner, à décrire. Quand j’étais sur Facebook il y a cinq ans je me sentais mal à l’aise parfois. Pour m'aider à comprendre ce que je ressentais j’ai trouvé une image qui me parlait, qui rendrait plus concrète une situation que je vivais souvent.

Je suis sur Messenger, je parle avec quelqu’un, je vois d’autres personnes connectées, je ne leur parle pas mais je sens qu’elles sont là et elles savent aussi que je suis là.

En voyant les personnes connectées sur Messenger en même temps que moi c’était comme si j’étais dans une très grande pièce blanche sans limite, avec une foule de personnes dispersées un peu partout. Je parle avec quelqu’un et je vois en même temps les autres personnes. Elles savent que je suis là et elles me regardent. Elles peuvent être plus ou moins loin de moi mais il n’y a rien qui arrête le regard dans cet espace. Tout le monde peut se regarder, sans directement voir le regard des autres.

Pour moi il y a une sorte de dispositif, d’agencement, de ce moyen de communication qui recréait de la pression sociale. Et c'est difficile à démêler d’autres choses qui apportent de la satisfaction ou du plaisir. J’ai beaucoup entendu mes ami·e·s dire ça par rapport à Instagram, parler de la confusion qu'iels ressentaient devant un espace-outil qui impacte beaucoup leur vie. Et j'ai l'impression que ce sentiment de confusion est peut-être plus dur à démêler dans un espace virtuel que dans un espace physique en trois dimensions: ça pourrait être lié à une volonté des entreprises qui fabriquent ces outils, de nous garder dans un état de demi-conscience dans leurs espaces, mais aussi lié à l’aspect récent des espaces virtuels dans nos vies / cultures / langages.

Ça m’a pris du temps de comprendre le malaise qui m’a poussé à quitter Facebook. J’ai dû trouver des images comme celle de la grande pièce blanche pour rendre physique quelque chose qui ne l’était pas assez pour moi. C’est difficile d’expliquer pourquoi une interface graphique, des choix de design des fonctionnalités, m’apportent du malaise. Je comprends pourquoi passer par des représentations d’espaces physiques m’a aidé.

Le fait d’être souvent seule dans les moments où je suis dans un espace virtuel rend encore plus dur le fait d’en parler au moment où je vis l’expérience. Ou même après, comme si ça avait moins existé que si ça s’était déroulé avec d’autres personnes dans un espace physique en trois dimensions.

J’ai l’impression qu’il y a une volonté d’isoler les individus dans la façon dont est conçu le matériel informatique, comme l’idée du PC = personal computer, par rapport par exemple à comment est pensée une console de jeu-vidéo, qui permet souvent de jouer à plusieurs. Je ne sais pas à quoi pourrait ressembler une expérience de bureautique à plusieurs (devant le même écran ou plusieurs écrans, plusieurs claviers plusieurs souris?) mais en tout cas j’ai pas l’impression que ç'ait déjà été une volonté d’explorer ça comme quelque chose de viable, qui pourrait devenir une norme.

Les moments où je suis avec d’autres personnes devant un ordinateur me font souvent un truc assez particulier de «oh c’est inhabituel», et c’est souvent agréable, quand c’est avec des personnes avec qui je me sens bien. Je me rappelle d’une conversation téléphonique de plusieurs heures avec un ami où l’on explorait chacun·e de son côté des sites web tout en les commentant et en se proposant des choses à aller voir. C’était agréable et excitant, et je ressentais aussi ce truc de «oh c’est nouveau». Je pense qu’il y a des pratiques collectives de l’informatique à inventer et que ça peut être très agréable. Les ateliers de codage de site web à plusieurs, d’apprentissage de langages, mettent vachement en avant le plaisir d’être ensemble je trouve. Comme si c'était quelque chose d'assez précieux ou qui peut manquer quand on est seul·e face à un écran. C’était un fantasme assez puissant dans les fictions des années 90 j’ai l’impression, la communion humain·e machine et groupe social, comme dans le film Hackers de 1995...

...où des informaticien·nes geeks nerds hackeurs·euses se retrouvent à des fêtes underground techno et se lancent dans des combats contre le système qui cherche à les faire taire. Il y a un truc assez fort dans ce film de mettre ces technologies en mouvement, à l'inverse de l'idée qu'elles nous garderaient dans une forme d’apathie ou de retrait du corps. Le film essaye de créer le plus de mouvements et d’énergie de déplacements possibles dans les espaces physiques tout en restant relié à l'informatique. C’est lié je pense à cette vision de l’informatique où les personnages sont tous acteur·rices par leur position de hackeurs·euses qui les poussent à être dans l’action, dans une sorte de fête et combat permanent.

C’est intéressant comment cette vision, ce fantasme lié au hacking était vendu au grand public comme si ça pouvait être ça l’informatique, alors que dans les volontés commerciales des GAFAM en cours de création il y avait déjà l’idée de donner de moins en moins de liberté dans ce qu’on peut faire avec un ordinateur, loin du hacking et de l’expérimentation quotidiennne. Ça ressemble aussi à cette mécanique du capitalisme qui fait fantasmer des modes de vie pour vendre des objets, sans pour autant que ces objets permettent d’accéder à ces modes de vie.

L’exemple du Metavers est aussi intéressant comme une expérience collective de l’informatique qui pourrait permettre de retrouver du mouvement physique de déplacement à l’intérieur des espaces virtuels, et pour l’instant c’est un gros flop, la magie prend pas. Comme si notre rapport aux espaces physiques en trois dimensions n’était pas aussi facilement transposables dans des espaces virtuels.

L’invention du bureau d’ordinateur, l’interface graphique qui a remplacé le terminal de commande par le WIMP (window, icon, menu and pointing device), a aussi poussé l’informatique du côté de la reproduction d’interactions familières qu'on avait l'habitude d'avoir dans des espaces physiques: comme avec le bureau sur lequel on a nos papiers nos dossiers, nos ciseaux et notre colle. La première entreprise à avoir commercialisé des ordinateurs avec une interface graphique inspirée du bureau raconte leur invention dans cette vidéo:

J’étais hyper surprise (et en même temps pas du tout) de voir à quel point les interactions avec les ordinateurs que j’avais découverte au début de ma vie avaient été conditionnées très précisément par la création de l’interface graphique de Xerox. En regardant la vidéo je me disais «wah mais quasiment tout était déjà là», et en même temps «ils ont juste reproduit un bureau numériquement quoi». Je me sentais autant fascinée par la force de créer un premier espace virtuel accessible au grand publique qu’en colère que ça soit devenu une norme aussi fermée de ce que peut être l’informatique. Si on se détache d’une tentative de ressemblance avec les espaces physiques issus du monde du travail et de la productivité, à quoi pourraient ressembler nos interfaces graphiques et espaces virtuels?

Je trouve que la place des émotions dans l’expérience de l’informatique est un truc qui est compliqué au même titre que pour les espaces physiques quand les deux sont pensés pour nous garder dans un état de demi-conscience, en conditionnant nos corps pour favoriser certaines activités (par ex la consommation comme activité principale du mode de vie urbain). Les grandes places publiques que sont les réseaux sociaux des GAFAMS ne sont pas très différentes des grandes places publiques des grandes villes je trouve. Il y a un vrai enjeu d’arriver à créer des espaces virtuels et physiques respectueux de notre consentement qui nous laisse du libre arbitre et de l’espace pour se sentir libre de questionner ce qu’on ressent face au contenu que l’on reçoit.

J'imagine des ateliers, des cercles de parole où l’on pourrait exprimer des ressentis, des questionnements, des doutes par rapport aux espaces virtuels, comme  on pourrait essayer de mettre des mots sur ce qui nous fait du bien dans ces espaces, ce qu’on aime et qu’on aimerait voir plus souvent. L’idée de pouvoir proposer de créer aussi ensemble des espaces virtuels comme des sites web à partir de ces échanges me paraît grave chouette.

J'ai l'impression qu'avoir ressenti des émotions devant l'informatique c'est quelque chose qu'on peut partager beaucoup plus facilement, peu importe le niveau d'aisance technique.

Il y aura toujours des facteurs qui influent sur la spécificité des émotions ressenties ou la capacité à pouvoir les exprimer mais il y a quelque chose que j'aime bien dans cette approche. Elle peut remettre en question la hiérarchie technique et déplacer la problématique à un autre endroit, le terrain des émotions, qui d'ailleurs peut être vu culturellement et historiquement comme étant lié à la féminité, en opposition à la rationalité masculine et le contrôle des savoirs scientifiques et techniques (en Occident en tout cas).

C'est quelque chose que j'ai pu voir dans des moments de discussions autour de l'informatique: la précision des termes, la complexité des notions, le vécu commun, excluent souvent des personnes qui ont été sociabilisées en tant que femmes, pour des raisons assez badantes et injustifiés. Les personnes sociabilisées en tant qu'hommes ne sont pas non plus protégées d'être exclues de discussions: j'ai été sociabilisée en tant qu'homme et je me suis déjà sentie mise de côté dans des discussions sur l'informatique alors que je me sens plutôt à l'aise pour discuter de ce sujet. Il y a toujours des personnes qui ont plus de savoir technique et c'est ok je pense: ça peut être cool de faire attention à prévenir quand les discussions deviennent plus complexes, demander comment les personnes autour de nous se sentent par rapport à ça.

Même pour une réunion technique où la raison de se retrouver est de parler technique ça peut être intéressant de prendre le temps de faire un point sur les ressentis de chacun·e, en général et par rapport au sujet de la réunion. Ça peut aider des personnes moins à l'aise sur ces sujets à prendre du temps pour s'exprimer d'une façon avec laquelle elles sont plus à l'aise, et peut-être se sentir plus légitimes ensuite de participer aux débats et donner leur point de vue.

La problématique du genre et de la sociabilité différentielle est super importante je pense quand on parle d'un sujet qui a connu l'hégémonie par un genre ou une classe sociale. C'est quelque chose à prendre en compte mais aussi à mettre au centre de certains moments, discussions, expériences collectives. Le partage des savoirs, même si bienveillant, peut aussi reproduire des rapports de force qui gardent cette hiérarchie technique au cœur des moments collectifs autour de l'informatique.

Donner plus de place aux émotions et aux ressentis peut rééquilibrer certaines choses, et aussi permettre aux personnes qui n'ont pas l'habitude d'exprimer leurs émotions sur des sujets qu'elles connaissent bien de s'y essayer (et potentiellement de se retrouver dans une position plus proche de celle des personnes qui ont dû mal à prendre la parole sur ces sujets).

Quand j'avais organisé une émission de radio à l'école d'arts de Cergy où je proposais de venir parler de notre rapport aux réseaux sociaux (notamment Instagram) en relation avec nos pratiques artistiques, les personnes qui se sont rendues disponibles et ont participé étaient uniquement des femmes et des personnes queer. L'invitation était ouverte à toute l'école et axée sur les ressentis, les émotions, les témoignages en lien avec des problématiques politiques. C'était trop agréable de sentir ce truc de "oh c'est nouveau" et "ça nous fait du bien" et "c'est possible".

Nous avons mis en place un forum de discussion à l'adresse https://forum.club1.fr. Il sera utilisé pour la gestion des tickets (lister les problèmes ou propositions), les discussions quand aux activités du club et aux prises de déçisions légères. Mais c'est aussi un espace d'expression des envies ou idées, ainsi que de partage des projets sur lesquels on travaille.

Les inscription sont ouvertes à tous·tes. Pour celles et ceux qui ont un compte CLUB1, il est possible de s'y connecter directement en sélectionnant: "connexion via CLUB1" en haut à droite. Vous gagnerez ainsi un petit badge sur votre profil permettant de vous identifier.

Le choix de la mise en place d'un tel outil fait suite à plusieurs réflexions. En voici un aperçu:

Modes de communication

Il existe de nombreuses façons de communiquer au sein d'une communauté. Aucune n'est bonne ou mauvaise mais chacune a ses avantages et inconvénients.
Au sein de ces possibilités, on peut distinguer deux grandes familles:

• Les communications synchrones
• Les communciations asynchrones

La communication est synchrone, par exemple, lorsque l'on se parle IRL, au téléphone, en visioconférence ou via une messagerie instantanée. Elle est dite synchrone car les échanges s'enchaînent en temps réel. Elle a pour avantage principal la rapidité et permet aux échanges de rebondir spontanément.

La communication asynchrone, c'est tout le reste. Par exemple les lettres et leurs version numérique: les emails. Mais aussi les tableaux d'affichages d'annonces (Bulletin Board System) et leur équivalent numérique: les forums.

Jusqu'alors, on disposait principalement d'un canal de discussion instantanée (via Matrix), donc synchrone. Or, notre fonctionnement semble privilégier la discussion asynchrone. Nous laissons chacun libre de s'investir comme iel le souhaite et donc il est habituel de ne pas attendre de réponse instantané. Des discussions asynchrones avaient également lieux dans un mélange de français et d'anglais, à travers des issues GitHub. Cependant, elles étaient centrés autour du code, ne couvrant pas tout les aspect dont on pouvait discuter, au sein d'un site déroutant pour les non-informaticiens.

Cela ne veut pas non plus dire que nous allons abandonner la messagerie instantanée! Souvent, il est plus confortable de combiner plusieurs modes de communications plutôt que de vouloir tout faire tenir sur un seul. Il est donc probable que l'usage de Matrix se transforme pour compléter celui du forum. L'email va lui aussi rester un vecteur de communication pour sa spécificité unique: tout le monde a une adresse email.

Archives parcourables

Un autre axe qui nous importe est de rendre "parcourables" les discussions.
Le pire mode de discussion à cet égard est la discussion informelle autour de la machine à café. Elle n'est pas enregistrée ou numérisée, ni résumée lors d'un compte rendu. Elle ne laisse aucune trace.

Une discussion dans un canal de messagerie intantannée permet en théorie d'être recherchée et relue, mais ce n'est souvent pas très agréable et décourageant. Même si, sur Matrix, nous nous efforcions de ne pas flooder de messages intempestif, c'est très peu probable que des personnes prennent plaisir à se balader dans l'historique de la conversation.
Quand aux emails, il est possible de publier sur le web le contenu d'une liste de discussion, mais malheureusement, cette forme est peu connue et un peu rebutante au premier abord.

La forme du forum de discussion permet une expérience de parcours relativement agréable et sans nécessiter de compte (contrairement aux messagerie instantanés).

Indépendance

À travers la création d'un petit serveur indépendant et communautaire tel que le notre, il y a aussi la critique d'un internet réduit à une poigné de multinationales. Beaucoup de nos propositions mettent en avant le fait qu'il soit possible de participer au cyberespace en le construisant soi-même, sans passer par l'intermédiaire d'une grosse plateforme.

Actuellement il reste encore des parties de notre organisation utilisant des services de GAFAM et non-libre. C'est un sujet que l'on suit avec attention, mais qui ne doit pas nous étouffer.
L'une d'elle était la gestion des tickets. Celle-ci se faisait via GitHub, une plateforme de partage de code, propriétaire et proporiété de Microsoft. Le sujet à d'ailleurs été mis sur la table lors de la récente candidature CHATONS.

Utiliser un forum hébergé par notre propre serveur, c'est donc une façon de plus d'illustrer le plaisir qu'on peut avoir à construire ses propres outils et espaces numériques.

À ce titre il est aussi important pour nous de personnaliser ces espaces. C'est entre autre pourquoi nous avons choisis Flarum comme logiciel de forum. Ce dernier a une approche très modulaire et laisse très facilement accès à des modification de CSS.

Depuis 3 jours, le badge d'état des sauvegardes indique qu'elles sont down, soit «en panne». Il s'agit d'une panne d'un des deux dépôts où sont stockées les sauvegardes CLUB1: le dépôt externe, qui se trouve sur un serveur distant. Le serveur distant en question ne veut plus démarrer, il n'est donc plus utilisable.

L'autre dépôt est local, donc directement sur le serveur CLUB1, mais sur un autre disque dur et ce dernier fonctionne toujours. Les sauvegardes ne sont donc pas totalement à plat, il est toujours possible de récuperer les données si l'un des disques plante. Cependant cette situation n'est pas optimale et nous sommes en train de voir pour déplacer le dépôt distant sur un autre serveur.

L'avancée de cette tâche peut être suivie sur ce fil.

le premier octobre 2022 à 16h15

• Audrey
• Etienne
• Guilhem
• Leïla
• Nicolas
• Vincent

La réunion a commencé par l'annonce de la nouvelle version de W, avec désormais la possibilité de faire des flux RSS! Cela va permettre de créer un flux RSS pour le journal de bord de CLUB1.

Nous avons ensuite parlé du sujet de la gouvernance, en s'appuyant notamment sur l'article Refonder la gouvernance associative de Pica­soft.

Pour remercier Etienne Le Louët de sa participation au projet en hébergeant des backups, il est proposé de lui faire un compte membre sur le serveur sans qu'il ait à s'aquitter de la participation d'inscription (les fameux 35€ à vie). Ce qui n'a pas créé d'opposition. Donc: Bienvenue Etienne 🎉 !

1 - Forges logicielles

La question épineuse mais passionnante des forges logicielles.

Evocation des enjeux: Github n'est n'est ni libre ni open source, ce qui ne correspond pas tellement aux valeurs que l'on a envie de propager. Pour autant, ce n'est pas non plus un logiciel que l'on a installé et qui "tourne" sur le serveur. À quel point pourrait t'on s'en passer? Est ce que ça oblige de potentiel·e·s contributeur·rice·s à se faire un compte sur un service non-libre (Github) ? Que gagne t'on en visibilité?

Pourquoi on utilise Github actuellement?

• Fonctionnalisme
• Visibilité
• Simplicité
• Habitude

Quelques pistes:

• Inconvénient majeur des forges logiciel auto-hébergées: pas de fédération. Work in progress: https://forgefriends.org/
• Il est facile de déménager le code, mais pas les métadonnés (discussions, issues, etc...). Cela car Git reste indépendant de Github au sens où il est totalement fonctionnel uniquement avec les emails, Github n'est qu'une surcouche confortable.

Question: est-ce qu'on devrait héberger une version cannonique des repo de l'organisation CLUB1 sur le serveur?
Ces repos seraient un mirror de Github. Pour se préparer à ce que Microsoft nous tire le tapis sous les pates.
Tout le monde a l'air à peu près d'accord là dessus!

2 - Site web de Saint Claude

Abordage de la question d'Alix, concernant le site de Sainte Claude: Est ce que CLUB1 est responsable légalement des contenu des sites web de ses membres?

C'est la question de frontière entre hébergeurs et éditeurs nous rappelle Leïla.

• La loi: l'éditeur est responsable de son contenu
• L'éditeur: doit avoir des mentions légales, disant qui édite et qui héberge

Texte officiel concernant les mentions légales sur un site Web. Même si c'est reservé aux "sites pro", ça peut valoir le coup d'utiliser cette forme officielle pour insister sur la séparation hébergeur/éditeur.

Le manquement à l'une de ces obligations peut être sanctionné jusqu'à un an d'emprisonnement, 75 000€ d'amende pour les personnes physiques et 375 000€ pour les personnes morales.

De plus les mentions-légales du site de CLUB1 explicitent bien qu'elles sont limitées au site https://club1.fr, ce qui devrait clarifier le fait que nous ne sommes pas responsables par défaut des sous-domaines:

Ces mentions légales s'appliquent uniquement au site https://club1.fr.

Une autre piste est la non-indexation par les robots des moteurs de recherche (avec noindex) ou le fait de demander de ne pas suivre un lien (avec nofollow). Cela ne change rien à la légalitée du contenu, mais conditionne le rapport à la publication.

3 - Bibliothèque

On se demande si on peut prêter des eBooks sur la bibliothèque CLUB1:

Par exemple, Cybestructure a la licence Édition Équitable.

Le lecteur/lectrice a le droit de faire circuler le document édité au sein de son cercle de proximité (y compris élargi à ses amis proches). Toutefois, cette liberté ne permet pas de rompre l’équilibre et l’équité en diffusant massivement ou à des inconnus.

On pourrait par exemple indiquer que l'eBook est prêtable via contact. On évoque alors la notion d'arpentage qui est une méthode de lecture à plusieurs qui facilite / accélère la compréhension d'un texte long / difficile, qui s'inscrit dans l'éducation populaire. Cela donne des idées d'outils numériques, peut être une idée pour un prochain Workshop!

4 - Candidature C.H.A.T.O.N.S.

Où en est-on? Il est possible d'éditer et de suivre notre avancé grâce à cette page du wiki: Avancée de la candidature CHATONS

Il reste quelques point à fignoler avant qu'on soit bon. Ils ont étés évoqués sur les issues Github de la Doc avec le tag:CGU

La date de début d'analyse de la candidature est le 15 octobre.

5 - Inclusivité: compte membre gratos pour les jeun's

Proposition de clarification du paiment des frais d'inscription CLUB1. Pour l'instant, on était sur un système informel: On laisse les membres payer cette cotisation quant ils ou elles le veulent.

Un paiment obligatoire au bout de 3 ans permettrait aux plus jeunes de se faire un compte en attendant de rassembler la somme, tandis que les plus âgés pourraient prendre leur temps tranquillement. Les plus radins pourraient même profiter gratos d'un hébergement pendant 3 ans.
On imagine un système de rappel par email annuel.

6 - Site Web

Il a été question de modifications du site club1.fr (notamment, où mettre la page annuaire 🤔) :

• Modifier l'organisation du site (ex: Onglet ressource qui joint bibliothèque, annuaire, calendrier...) afin qu'il n'y ait pas trop d'onglets en haut de page
• Page membres: problème de resize lié au code de la page. Pour rappel, celui ci est stocké dans un repo sur Github

Validation de l'utilisation de la licence CC-BY-SA sauf contre-indication, et du Copyright © 2018-2022 Membres de CLUB1 pour le contenu du site.

7 - Sous-sous domaines et certificats

Problématique actuelle: club1.fr et ses sous-domaines sont certifiés par 1 seul certificat, mais celui-ci ne couvre pas les sous-sous domaines.

Actuellement, les certificats sont fournis gratuitement par Let's Encrypt. Pour indication, l'équivalent chez Gandi coûte autour de 200€/an. C'est donc compréhensible qu'ils essayent de limiter la charge de leur serveur.

Plusieurs méthodes:

1. Étendre le certificat: le defaut est que ces sous.sous.domaines seront listés et retrouvables depuis le certificat de CLUB1.
2. Créer un nouveau certificat par sous.sous.domaines. C'est la solution choisie actuellement.
3. Convertir un sous.domaine affilié au certificat de CLUB1 en sous.domaine disposant de son propre certificat, lui permettant par la suite de créer une infinitée de sous.sous.domaines bénéficiants de ce certificat.

Comme Nico avait grave vendu le fait de pouvoir créer des sous.sous.domaines à Alix, il s'est senti obligé de corriger rapidement un bug dans les scripts en utilisant la deuxième méthode.

Après de longues reflexions, on trouve que l'option 3 est plus intéressante

Toutes les réunions du Club:

• Réunion 003Compte rendu13/10/2022
• Réunion 002Compte rendu07/10/2021
• La première réunion du clubC'est la première fois que ça se fait05/02/2020

Du 18 au 22 Août 2022 s'est déroulé la deux­ième édition du camp CHATONS. Pour info, le collectif CHATONS est constitué d'une centaine d'hébergeurs francophones indépendants. Il existe depuis 2015 et a été initié par Framasoft.

Comme cette édition était située pas trop loin de Paris, dans un lieu communautaire appelé Le Moulin Bleu, une petite escouade de membres CLUB1 est partie à l'aventure dans le Loir et Cher. On connaissais déjà pas mal le collectif à travers le forum des CHATONS, mais cette fois, nous allions rencontrer les humains derrière les pseudos!

Candidature CHATONS

Pour ne pas trop débarquer en inconnus, et du fait que nous avions décidé lors de notre deuxième réunion que ça serrait pas mal de candidater, et bien on en a profité pour lancer la procédure! 🎉

Il est possible de candidater sur deux périodes par an au collectif. Chaque session de candidature est appellée une portée. Nous avons donc candidaté à la portée #15.

• post sur le Forum CHATONS déclarant officiellement notre candidature.

Que se passe-t-il lors d'un camp CHATONS?

Le camp CHATONS est basé sur un système d'ateliers. Chacun·e est libre d'en proposer, soit en amont via une note collaborative, soit pendant le camp. Lors de la pleinière du matin, il s'agit d'agencer la journée. Il y a souvent deux ou trois ateliers par crénaux, ce qui oblige à faire des choix! Heureusement, comme nous étions plusieurs, on a pu se répartir pour choper un max d'infos. Les ateliers sont principalement des partages d'expériences, rencontres de points de vue ou des présentations d'outils, applicables aux communautés liés à chaques CHATONS ou concernant le collectif lui même.

On a notamment pu y parler d'inclusivité, de capitalisme, de surveillance, de pureté militante, d'éducation populaire, des enjeux du bénévolat, de gouvernance et bien sûr des logiciels libres et des communs numériques.

La particularité d'un tel camp, est que c'est un rassemblement de collectifs, ce qui peut être un peu déroutant au premier abord. Bien que chaqun·e·s viennent d'horizons différentes, il y a un sujet commun très présent, connu et maîtrisé par la plupart des personnes rassemblés. Cela a pour effet de faire ressortir les nuances au sein d'un monde que l'on pourrait croire homogène de l'extérieur. On arrive très vite sur des questions éthiques et politiques, où l'on va découvrir les spécificités et subtilités de chacun·e·s vis à vis de leurs pratiques d'hébergement.

Le lieu et l'ambiance

Le Moulin Bleu est situé sur une petite île au milieu du Loir et héberge une communuté de personnes qui œuvrent pour avoir un mode de vie plus sobre et résilient. Ils cultivent par exemple un grand jardin où a été organisé un atelier découverte des plantations et aide aux travaux du moment!

Durant le camp, les repas (vegan) étaient cuisinés par plusieurs habitants du Moulin. Mais il était également possible de faire notre propre cuisine, ce que nous avons fait sur toute la première partie du séjour.

L'hébergement s'est fait quant à lui dans des chambres et dortoirs au moulin, ou dans un espace camping pas très loin du jardin. C'est d'ailleurs devant sa tente qu'un des chatons nous a présenté son équipement permettant d'alimenter en électricité son hacker space nomade (le Distrilab) à l'aide de paneaux solaires, c'était passionnant!

Enfin, nous avons assisté un soir à "les chatons ont du talent", avec numéro de jonglage à plusieurs, et expériences scientifiques de fusées à air et à eau très amusantes.

Quelques liens pour aller plus loin

• partager les souvenirs du camp CHATONS discussion sur le forum du collectif.
• carnet de notes collectif document de travail commun pour la préparation et les comptes rendus de chaques ateliers.
• article de deux fleurs Quentin raconte le camp CHATONS (avec plus de photos!).

La première mise en place des emails n'était déjà pas une mince affaire. En effet, le système de courrier éléctronique se rapproche plus d'un patchwork de RFC qu'à un protocole tant il est rapiécé de toutes part. Il est vrai qu'on pourrait le dire d'un certain nombre de protocole d'internet, après tout c'est la manière dont ils sont créés, par itérations successives. Mais les emails conservent tout de même une place particulière.

Prenons par exemple le Web, utilisant le protocole HTTP. Comme pour SMTP, l'authentification n'a pas du tout été prise en compte dans les premières itérations du protocole, ce n'est qu'en passant à HTTPS que les réponses sont authentifiées. Mais une fois que HTTPS est configuré dans les options du serveur Web, c'est bon, le protocole est correctement sécurisé.

Pour SMTP il ne suffit pas de passer à une version sécurisée, il faut configurer plusieurs mécanismes d'authentification, les fameux SPF, DKIM et DMARC évoqués dans l'article [email]. Or aucun de ces mécanismes n'est intégré aux serveurs SMTP classiques, il faut les installer et les configurer chacun séparément.

Après avoir configuré ces trois mécanismes on peut enfin prétendre à un système d'authentification fonctionnel (après-tout il a correctement fonctionné jusqu'à aujourd'hui), mais c'est au moment de documenter une fonctionnalité de redirection que l'on s'est rendu compte d'un problème.

Pour faire simple:

• SPF permet de lister les adresses IP des serveurs autorisés à envoyer des emails au nom d'un domaine.
• DKIM permet de signer les emails pour garantir leur provenance (on peut déjà se poser la question de l'utilité de SPF lorsque les emails sont signés avec DKIM).
• DMARC permet d'indiquer aux autres serveurs ce qu'ils doivent faire lorsque l'une ou l'autre de ces authentifications est invalide.

Tout cela fonctionne très bien dans les cas simples où le serveur qui envoie l'email est celui de l'auteur. Dans le cas d'une redirection en revanche, l'email passe par un serveur intermédiaire.

Ça ne pose aucun problème pour DKIM, car le serveur intermédiaire n'a pas à toucher au contenu du message, ni à sa signature. Au contraire, DKIM apporte ici un avantage supplémentaire permettant de garantir que le message n'a pas été altéré lors de sa redirection en plus de garantir qu'il a bien été émis par le bon serveur.

SPF par contre va échouer lamentablement, car le serveur intermédiaire n'est évidemment pas autorisé à envoyer des emails au nom des autres domaines. Comme ils le disent eux-même:

SPF "breaks" email forwarding.

SPF "casse" la redirection d'email.

OK.

SRS is a way to fix it.

SRS est un moyen d'y remédier.

Voilà autre chose, Yet Another Patch pour SMTP...

Bon en gros il s'agit presque d'un hack qui consiste à créer à la volée des adresses en @club1.fr pour tous les emails transférés, ce qui permet de faire croire que le message provient bien du bon serveur. Et il s'agit de la solution officiellement proposée par open-spf.org. De mon point de vue la solution serait plutôt de laisser tomber SPF et de ne garder que DKIM. Pour ceux qui voudraient une explicaiton plus détaillée (avec des jolies illustrations) voici un article (en anglais) qui explique SPF, SRS (et même DKIM).

Heureusement, l'installation et la configuration de SRS est plutôt aisée de nos jours, comme le montre cet article de Debian Facile. En résumé (le tout en root) :

C'est pas très joli, mais au moins ça fonctionne, ce qui permet de profiter de la fonctionnalité nouvellement documentée du fichier .forward!

Tous les articles CLUB1 concernant les emails:

• Le(s) serveur(s) emailLes membres de CLUB1 ont enfin une adresse email perso27/07/2021
• Transfert d'email & Sender Policy FrameworkSoit la configuration de SRS pour réparer ce que SPF a cassé28/08/2022

L'incident

TL;DR ↓

Tout commence le 7 Aout 2022 à 17h, lorsque je me rends compte via le système de monitoring CLUB1, mis en place grâce à Up­time­Ro­bot, que le serveur n'a pas été accessible pendant une quinzaine de minutes, de 15h20 à 15h35.

La première hypothèse fut que le routeur fourni par Bouy­gues Télé­coms avait dû faire une mise-à-jour, ce qui aurait pu occasionner une telle coupure. Mais après vérification sur le dashboard, pas de doute, c'est bien le serveur lui-même qui a eu un problème sur cette tranche horaire, c'est là que le mystère commence.

Après vérification de tous les logs (journaux) du serveur, en particulier kern.log.* et syslog.* le mystère ne fait que s'épaissir. Aucune ligne ne semble indiquer d'erreur et le log s'arrête brusquement avec une ligne remplie de "caractères nuls", pour reprende une quinzaine de minutes plus tard avec un log de démarrage de Linux.

Ce log suggère que le serveur aurait subit un arrêt brutal, potentiellement causé par une coupure de courant. Le fait qu'il ait redémarré plus tard aurait pu être expliqué par la politique Start on Power selectionnée dans le BIOS. Cependant le serveur est censé communiquer avec l'UPS via NUT pour s'arrêter proprement avant que la batterie soit épuisée et des messages d'avertissement auraient dû être émis tout au long de la coupure de courant. Or rien de tout ça n'est arrivé. Personne n'était présent pour débrancher physiquement le serveur, donc une panne de l'UPS est suspectée, mais le fait que le serveur ait par la suite redémarré écarte également cette hypothèse.

J'ai finalement eu l'idée de vérifier les potentiels logs disponibles au niveau de l'IPMI, et ces deux messages étaient présents:

Une rapide recherche m'amène sur un post du forum TrueNas qui me permet de comprendre qu'il s'agit d'une fonctionnalité de la carte-mère:

The watchdog is intended to automatically reset the system if it detects that the OS has frozen/crashed. If you have a Su­per­micro board, please check if you have a jumper on the motherboard for the watchdog, this might affect it.

Le chien de garde (watchdog) est destiné à réinitialiser automatiquement le système s'il détecte que le système d'exploitation s'est figé/crashé. Si vous avez une carte Su­per­micro, veuillez vérifier si vous avez un cavalier sur la carte mère pour le chien de garde, cela pourrait l'affecter.

Les éléments commencent donc enfin à s'assembler de manière cohérente. Le décalage horaire des entrées du log de l'IPMI provenait d'un réglage incorrect de son horloge interne et le compte à rebours était effectivement réglé sur 15 minutes (900 secondes). C'est donc bien le Watchdog du BMC (le composant principal de l'IPMI) qui a déclenché le redémarrage du serveur.

Le scénario serait donc le suivant: le serveur aurait complètement arrêté de répondre, probablement à cause d'un blocage complet du noyau, il aurait ainsi arrêté d'envoyer son heartbeat au BMC, qui aurait décidé de le redémarrer au bout de 15 minutes.
Une fois encore, une rapide recherche m'a mis sur la piste d'autres occurences de problèmes similaires. Il semblerait donc qu'il y ait un problème avec la version 5.4.0-122.138 du noyau Linux utilisé par Ubuntu.

TL;DR: Le noyau Linux 5.4.0-122.138 s'est visiblement bloqué en cours d'exécution ce qui a mis complètement hors-service le serveur, qui s'est finalement automatiquement redémarré au bout de 15 minutes.

La réparation

Pour réparer ce problème, le plus simple était pour le moment de retourner sur une version antérieure du noyau. Heureusement, la plupart des distributions Linux conservent les versions installées précédemment, ce qui permet de les réutiliser le cas échéant. Cependant, la méthode habituelle pour selectionner la version à utiliser se fait lors du démarrage, au niveau du menu de GRUB, lequel n'est pas accessible à distance. L'IPMI aurait pu me permettre de le faire mais je n'avais pas la possibilité d'accéder au réseau local à ce moment-là. Et de toute façon, je préférais trouver une solution plus durable que de devoir sélectionner la bonne version à chaque redémarrage.

Un post du forum Ubuntu m'a permis de découvrir une technique très pratique pour sélectionner l'entrée par défaut de GRUB depuis Linux. Mais comme il y a quelques petites erreurs dans celui-ci, voilà la procédure que je recommande:

1. Récupération de la liste des entrées du menu de GRUB à l'aide de la commande suivante.

   awk -F"'" '/(menuentry|submenu) / { print $2 }' /boot/grub/grub.cfg

   Voilà un exemple de retour possible. Il faut connaitre un minimum le menu de GRUB sur Ubuntu, pour savoir que Advanced options for Ubuntu est en fait un sous-menu contenant les 4 entrées suivantes.

   Ubuntu Advanced options for Ubuntu Ubuntu, with Linux 5.4.0-122-generic Ubuntu, with Linux 5.4.0-122-generic (recovery mode) Ubuntu, with Linux 5.4.0-121-generic Ubuntu, with Linux 5.4.0-121-generic (recovery mode) UEFI Firmware Settings

2. Configuration de la valeur par défaut dans un nouveau fichier. L'entrée qui nous intéresse dans notre cas est Ubuntu, with Linux 5.4.0-121-generic, mais elle se trouve dans un menu, il faut donc aussi le spécifier en utilisant > pour les séparer.

   echo 'GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.4.0-121-generic"' \ | sudo tee /etc/default/grub.d/default-5.4.0-121.cfg

3. Mise-à-jour de GRUB avec cette nouvelle configuration:

   sudo update-grub

   Pour annuler ce changement, il suffit de supprimer le fichier ajouté et de réitérer cette dernière étape.

Conclusion

Cette panne mystérieuse nous aura finalement permis de découvrir une fonctionnalité de notre carte-mère que nous ignorions jusqu'ici, et nous sommes bien contents qu'elle soit présente. C'est une confirmation de plus que le choix du matériel est important et que celui qui a été choisi est adapté à notre cas d'usage. Sans cette fonctionnalité de Watchdog BMC nous n'aurions eu aucun moyen de reprendre la main sur le serveur à distance, ce qui aurait entrainé une interruption de service bien plus longue.

Pour le moment la version du noyau utilisée par CLUB1 sera donc gelée à 5.4.0-121. Elle sera mise-à-jour plus tard, en espérant que le bug sera résolu d'ici là.

Dans le but de compiler toutes les informations relatives à CLUB1, une documentation toute neuve a été créée. Son but est de devenir la source de référence des information techniques sur le serveur. En effet, auparavant, les informations étaient réparties entre plusieurs pages du site, un dépôt GitHub et des articles du journal. L'idée était donc premièrement de rassembler toutes ces informations au même endroit. Deu­xième­ment, elle devait être versionnée (avec Git bien-sûr) pour pouvoir travailler sérieusement dessus à plusieurs et pour être certains de ne jamais perdre de données, grâce au fonctionnement distribué de Git. Finale­ment, il fallait que le language de rédaction de la documentation soit le Mark­down, car il est très simple à apprendre et à lire et que c'est le plus utilisé dans le reste des projets de CLUB1.

Rassurez-vous, l'idée avec cette nouvelle doc n'est pas d'arrêter d'alimenter le journal. Nous continuerons d'ajouter des nouvelles sur le site lorsque certaines avancées auront été réalisées (comme dans le cas présent 😉). En fait la grosse différence entre la documentation et le journal, c'est que la doc a pour but d'évoluer et d'être tout le temps à jour, tandis qu'un article du journal décrit une information à un instant t et n'est pas vraiment voué à être mis à jour.

La petite histoire

Une fois que le cahier des charges de cette documentation a été défini, il restait encore à choisir la solution technique pour le mettre en œuvre.
Pour avoir passé un certain temps à lire de la doc technique en ligne, nous avions déjà en tête le logiciel Sphinx qui, allié au thème Read­The­Docs, produit des documentations plutôt agréables à lire. C'est notamment ce combo qui permet de générer la documentation du kernel Linux (assez conséquente), celle de Web­late ou encore de Cert­bot.

En plus de l'esthétique de la documentation Web produite, plusieurs aspects de Sphinx nous avaient attiré. Tout d'abord la version HTML qu'il génère est entièrement statique mais propose tout de même une barre de recherche (la recherche se fait donc entièrement côté client, à l'aide d'un index, généré en même temps que le site). Ensuite, il a la capacité de compiler la documentation dans tout un tas de formats de sortie (finalement ce n'était pas si important que ça 😅). Les admonitions—des blocs de notes ou d'avertissements—que Sphinx permet d'insérer dans le contenu ont retenu notre attention pour les tutoriels que l'on comptait inclure dans cette documentation. La possibilité de traduire le contenu à l'aide de gettext nous permettait d'envisager une version anglaise. Et finalement, la maturité du projet et son utilisation très répandue nous rassurait sur son efficacité et sa pérénité.

Site web et version physique

Finalement, de tous les formats de sortie possibles seuls deux seront réellement utilisés: Le format HTML pour la version Web et le format PDF­LaTeX pour un export PDF.
Ce dernier n'est pas anodin. En effet, le but d'avoir une version PDF n'est pas vraiment de permettre aux gens de la télécharger et la consulter avec leur lecteur de PDF favori (même si c'est très cool). Le réel intérêt de ce format réside dans son imprimabilité!
Comme les expériences des différents workshop ont pu nous l'apprendre, la transmission de connaissances liés à internet fonctionne 710% mieux lorsqu'il y a rencontre physique. Pour aller dans ce sens, comme pour le fait d'avoir sous la mains les bouquins de la bibliothèque, on pourra maintenant tendre la Doc à un·e autre membre CLUB1, tout en lui adressant un large sourir (ce qu'un site Web ne pourra jamais faire, malgré tous les smileys du monde).

Customisation à l'extrème

Bien que Sphinx ne soit prévu à l'origine que pour fonctionner avec re­Stru­ctu­red­Text, l'extension MyST recommandée par la documentation officielle, permet de lui ajouter le support de Mark­down. Et, malgré quelques écueils comme les liens vers un titre d'une page qu'il faut activer, ça fonctionne globalement bien. Mais reST proposant plus de fonctionnalités que Mark­down, MyST se voit forcé d'étendre la syntaxe de Mark­down afin d'en combler les lacunes, ce qui la complexifie un peu.

Très rapidement, le Makefile et le fichier de conf sont fortement customisés, principalement pour que le système de build permette de facilement gérer plusieurs langues, car bien que Sphinx supporte la traduction du contenu, rien n'est prévu de base pour pouvoir générer toutes les langues d'un coup, il faut le scripter soi-même. Qu'à cela ne tienne, c'est rigolo de faire le Makefile ultime 😁.

Le template LaTeX aura lui aussi été lourdement customisé afin que le rendu se rapproche plus de la version Web. Le support des emojis, par exemple, aura nécessité une certaine quantité de recherches et de temps. Un petit paquet d'extensions Sphinx aura également été codé pour ajouter certaines fonctionnalités importantes à nos yeux, en particulier des infobulles au survol pour les termes de glossaire (mots colorés en bleu et soulignés en pointillé). Et cerise sur le gâteau, l'ensemble de la documentation est automatiquement compilé et publié à chaque fois qu'une modification est mergée dans la branche princiale. Maintenant que tout ça est fait, il ne reste plus qu'à améliorer le contenu de la documentation! 🤓

Modifiable

Bien-sûr, tout le monde peut y participer, c'est tout de même ce que l'utilisation de Git nous offre de base. GitHub quant à lui permet de faciliter ces modifications pour les non-infor­ma­ti­ciens, mais il est évidemment toujours possible de s'en passer (git send-email, dépôt accessible en lecture via HTTP, etc.). Toutes les informations à propos de comment participer à la documentation se trouvent… dans la doc elle-même, dans la section meta-do­cu­men­ta­tion!

Ce qu'on peut y trouver

Comme expliqué précedemment, le but principal est de regrouper toutes les informations techniques concernant le serveur CLUB1. Le premier chapitre est pour l'instant reservé aux informations générales. L'ensemble des services qu'il propose sont décrits et expliqués en détail dans le chapitre deux. En plus de fournir des informations sur les services, cette nouvelle documentation devait contenir des tutoriels pour en guider l'apprentissage, ils se trouvent dans le troisième chapitre. Le quatrième chapitre est prévu pour contenir tous les sujets techniques de CLUB1 qui ne concernent pas directement les membres, il s'appelle pour le moment "documentation interne". On y trouve notamment la meta-do­cu­men­ta­tion dont on parlait plus haut. Pour finir, le dernier chapitre est un glossaire global contenant des définitions concises de certains termes importants et un index généré par Sphinx offre encore un autre moyen de naviguer dans la documentation (il est surtout utile pour la version imprimée).

Nous espérons que cette nouvelle documentation sera pour vous un plaisir à naviguer, que ce soit la version Web ou la version physique, qu'elle vous apportera les informations que vous cherchiez et vous permettra même d'en découvrir.

Lors de sa construction du serveur, pour des raisons économiques 😅, nous avons recyclés des disques durs et SSD que nous avions en stock. Le choix à été fait de mettre le système sur le seul SSD qu'on avait sous la main: Un SSD de 256Go réccupéré d'un ordinateur portable.

Cependant, on a pu se rendre compte d'une chose: mettre les données des utilisateur·trice·s sur le même support que le système et les bases de données apporte plusieurs problèmes.
Par exemple, si une personne sature de SSD avec ses données, le serveur ne va tout simplement plus fonctionner 💥.
Pour éviter ça, la solution est plutôt simple: Il faut séparer physiquement (ou logiquement) ces deux types de stockages. C'est ce qu'on à fait récemment grâce à un SSD de 1To généreusement mis à disposition par Guilhem ❤️.

Le changement est transparent pour les membres de CLUB1, à part biensûr, l'espace supplémentaire! L'espace total et le remplissage du nouveau SSD est visible lorsque l'on se connecte en SSH via le terminal.

Ou sur le drive.

Même si ce dernier semble moins préçis 😄

⚙️ Configuration

Le serveur comporte maintenant deux SSD:

• SSD système
• SSD home

SSD système

Ce SSD de 256Go n'est autre que le premier SSD installé sur le serveur. Il stocke les paquets Debian installés, les fichiers de configs et les bases de données. Ces dernières peuvent être importantes, par exemple, la base de données du serveur Matrix représente actuellement une vingtaine de gigas.

Lorsque l'on affiche la racine du serveur (en se connectant en SSH par exemple), on peut voir la liste des dossiers principaux. La plupart sont stockés sur ce SSD système, mais le dossier home correspond en fait au deuxième SSD.

SSD home

Le nouveau SSD qui contient le home des membres. Chaque membre à un dossier à son nom contenant tout ses fichiers. Ces dossiers correspondent à l'espace personnel.

🧱 Un espace commun

Pour l'instant, cet espace est en autogestion. C'est à dire qu'aucun quota n'a été défini pour les utilisateur·trice·s. A chaqun·une·s d'être responsable de la place qu'il ou elle prend sur ce stockage de 1To.

📷 Quelques images

Bien que le changement ne soit pas très impressionant, voici quelques images du nouveau SSD dans son tirroir.

Il s'agit d'un SSD Samsung EVO 860 au format 2,5".

Voici une sélection de photos souvenirs du workshop #003 qui a eu lieu les trois jours du 7 au 9 Février 2022.

C'est un peu la plus grosse organisation de workshop dans l'histoire de CLUB1 pour l'instant. Le lieu était si chouette que ça donne envie d'y ré-organiser quelque chose avant qu'il ne soit plus disponible (c.a.d. fin de l'année scolaire).

Mise en ligne des travaux

On a mis en place un utilisateur FTP temporaire pour le workshop, histoire de permettre à tout le monde de ressentir l'exitation de la mise en ligne de ses premères pages web.

En suivant cette pratique, cela permettrait de constituer une archive des différents petits projets et exercices réalisés aux cours de ces ateliers.

Découvrir les pages web crées lors de ce workshop

Merci à tout le monde d'avoir participé!

Un heureux évenement a rendu indisponible le serveur dans la soirée du 27 novembre 2021. Voici le récit de ce qu'il s'est passé.

Lorsque l'on a commencé l'aventure Club1, des choix techniques de matériels ont été fait. Certains étaient très pertinent et sont toujours parfaitement valides, d'autres sont améliorables ou ont déjà été revus. C'est notamment le cas de l'onduleur, qui a été remplacé par un modèle plus performant, mieux dimensionné après une panne du précédent. Une panne d'un tel element, alors qu'il est sensé au contraire, apporter de la fiabilitée, nous avait incité à monter en gamme pour espérer gagner en qualitée de construction. Et c'est là, qu'on a commencé à réfléchir en rack.

LE RACK

Le rack 19" (19 pouces), est un standard que l'on retrouve dans l'informatique, l'audiovisuel ou l'industrie en général. Il définit une largeur et des hauteurs possibles pour les équipements électroniques afin qu'ils puissent être encastrés de manière optimale dans une armoire compatible.

article Wikipedia

La plupart des composants informatiques pour serveurs, lorsque l'on monte en gamme, vont être compatibles avec ce standard. Il est donc naturel que ce nouvel onduleur soit rackable. Mais lorsque l'on entre dans l'univers du rack, il est difficile d'en sortir... Vu que l'infrastructure derrière Club1 est un ensemble de composants informatiques, cela parrait souhaitable qu'ils soient tous rackables, de manière à les encastrer proprement. En effet, un des points forts du rack, c'est que les appareils ne sont pas simplement empilés, mais vissé à la structure du meuble qui les contient. De cette façon, on peut presque dire que l'on a créé un nouvel objet, résultant de cet assemblage verrouillé.

A partir de là, nous prennons la déçision de ne plus acheter que des composants rackables, en attendant le jour où l'on basculera vers cette méthode de rangement. Les achats suivants sont un switch, un petit boîtier servant de gare de trillage aux flux de données et un routeur qui laisse imaginer un futur remplacement de la box du FAI. Ces nouveaux élements étant rackables, il ne reste maintenant plus qu'à remplacer le boitier du serveur lui même.

Ancien boîtier

C'est un boitier de la marque Chenbro et qui a les dimensions d'une boîte a chaussure. C'est un boitier solide et fiable, mais les composant sont trop resserés à l'intérieur et organisés de telle façon que l'air circule mal à travers.

Nouveau boîtier

Le choix d'un nouveau boitier n'est donc pas uniquement justifié par un passage au format rack. On cherche aussi un boîtier plus facilement refroidissable, pour faire baisser la températeur du processeur grâce à un meilleur flux d'air.

Notre choix se porte sur le RM21-304 de chez SilverStone. D'une hauteur de 2U (unitée de rack) et d'une profondeur raisonnable, il a également l'avantage d'être compatible avec les alimentations ATX.
Les ventilateurs d'origine sont remplacés par des Noctua offerts par Etienne Le Louët.

Installation

Bilan

L'opération de transfert est un succès total:

• Meilleur ergonomie de l'installation
• Réduction du bruit grâce à des ventilateurs plus silencieux
• Réduction de la température du processeur
• Aucun soucis rencontré

Statistiques

16h47 début de l'opération
20h37 retour en ligne de Club1
Durée totale: 3h50
Personnel: 2
Réduction en température du processeur: 6°C
Coût total: 200€ (armoire) + 60€ (boitier) + 50€ (alimentation) = 310€

Discussion sur Github

La réunion 002 de CLUB1 à eu lieu le dimanche 26 septembre 2021 à Bastille.

Elle était constituée de membres du club ainsi que de non membres, intéressé⸱e⸱s par prendre part aux discussions.

Membres présents:

• Guilhem
• Audrey
• Nicolas
• Vincent

Non-membres présents:

• Victor
• Melvyn
• Marylove
• Asphodele
• Simi
• MoïMoï

La première partie de la discussion est guidée par Victor qui, curieux des objectifs du Club, va permettre de questionner chacunes des problématiques auxquelles Club1 cherche à se confronter. C'est l'occasion de travailler la formulation du ou des buts du collectif.

Après deux heures de discussions riches en digressions, autant sur des questions éthiques que techniques, nous passons à l'étude de points concrets:

1 - Les C.H.A.T.O.N.S.

Lorsque l'on relit le succin compte-rendu de la première réunion, cela nous rappelle que nous nous étions basé⸱e⸱s sur la pertinente charte du collectif C.H.A.T.O.N.S. pour avancer sur la configuration du serveur. Nicolas, en sa qualitée d'administrateur système, a permis de combler une bonne partie des anciennes lacunes qui permettrait de rejoindre les CHATONS. Reste maintenant à trancher si l'on souhaite candidater ou non au collectif félin.

Vincent présente les CHATONS et nous concluons qu'il y a un avantage évident: celui de clarifier notre démarche. Et surtout, aucun désavantage car nous nous reconnaissons à 100% dans le positionnement des CHATONS.

Il est choisi à l'unanimité que des membres du club peuvent, quand iels en auront l'envie, travailler sur le dossier de candidature.

2 - Enjeux de communication

Si l'intention de rejoindre les chatons va nous aider à mieux inscrire le CLUB1 au sein d'une démarche, il s'agit de préciser cela avec nos partis pris spécifiques.

Les discussions de la première partie de réunion nous ont guidés sur la voie d'une meilleure définition de nos objectifs. A la question posée de comment les mettre en pratique nous nous disons de poursuivre l'édition du site web dans ce sens. En effet, nous sommes d'accord sur le fait que certaines problématiques ne sont pas abordées, ou de façon trop cryptique. On notera tout de même le succès du journal, comme espace d'expression fonctionnel. Actuellement, les éditeurs autorisés du site web sont Nicolas, Guilhem et Vincent. Les deux derniers s'étant déjà investis dans le travail de structure du site web s'engagent à poursuivre cette clarification.

Pour définir notre positionnement spécifique au sein d'un groupement tel que les CHATONS, l'axe de mise en valeur semble être celui de la pédagogie, de la mise en valeur des utilisateurs en tant qu'acteurs d'internet et la réappropriation des moyens de production. Tout cela mis en pratique par des projets comme UNIX CLOUD. Reste à rendre cela compréhensible depuis le site web.

3 - Comment gérer l'inégalitée de la répartition des compétences techniques et donc du pouvoir, entre les membres.

Il était important pour nous d'aborder ce sujet inhérent à toute structure de serveur classique.

Nicolas a le rôle d'administrateur système. Il est le seul, de part ses connaissances et par son accès privilégié (root), à pouvoir effectuer certaines tâches. Comment ne pas faire peser sur lui trop de responsabilités ou une trop grande charge de travail. De la même façon, comment diluer son pouvoir entre les membres pour ne pas qu'iels se sentent dépendant de lui, ce qui est techniquement le cas.

On suggère alors de rendre plus visible le travail de l'administrateur système (ici Nicolas) pour permettre une meilleure compréhension de ce rôle, l'investissement et le niveau de responsabilitée qu'il implique.
Pour se faire: poursuivre la logique de transparence des réflexions (sous formes d'issues Github) et communiquer autour de cet accès publique. Plus ces problèmes seront détaillés, plus il y aura une chance pour que des personnes puissent le soulager en effectuant des petites tâches.

Nicolas ajoute que, dans sa façon de fonctionner, le plaisir est essentiel, car c'est à l'origine un projet d'exploration personnel de l'administration système, hors du cadre pro ou étudiant. La quantité de travail est donc à moduler en fonction de sa motivation, par exemple en stoppant les inscriptions, comme c'est le cas actuellement, tant que certains problèmes techniques ne sont pas résolus.

4 - Avancées de la stratégie d'hébergement de données perso

Nicolas et Vincent expriment leurs dernières réflexions techniques sur l'organisation du dossier personnel, les accès et la synchro.

Actuellement WebDAV est en phase de test sur le serveur. Cependant, peut être que le jeune protocole ETEsync, qui chiffre les données de contacts et agenda sur le serveur serait à l'avenir plus approprié. ETEsync est également en train de développer une interface WEB qui permettrait de gérer contacts, tâches et Agenda. Le tout étant rétro-compatible avec WebDAV.

Vincent évoque également une envie de mettre en place un dossier Private, en parallèle des dossiers public, mail et git, qui serait chiffré, notamment grace à eCryptfs. Ce dossier devrait être déchiffré automatiquement via accès SSH ou WebDAV permettant l'accès via ces différentes méthodes de connexion. On rappelle également que, par défaut, chaque dossier home est accessible en lecture par les autres membres. Ce choix n'est pas remis en question, mais il conviendrait de mieux communiquer sur les façons de changer cela manuellement pour les utilisateurs⸱trices.

5 - Ateliers, entraide, partage de connaissances, mise en relation

Un autre sujet qui nous tiens à coeur: la mise en relation des membres et le partage de connaissances.

Organiser les rencontres

Vincent propose de différencier trois formes de rencontres possibles:

1. Réunion de gestion du CLUB1
2. Atelier (partage de connaissance)
3. Réunion suivi de projets, échanges de points de vue

Des rassemblements sur plusieurs jours sont toujours dans les cartons, eux même sous le coude.

Atelier

La forme atelier (2), à pour l'instant été organisée une seule fois autour de la pratique des languages HTML/CSS sur une journée. En partant du succès de cette première itération, on se demande ce qui pourrait en déclencher d'autres.

Selon nous, c'est aux personnes souhaitant organiser spontanément un tel atelier de choisir leurs conditions. Cependant, le CLUB1 peut aider à trouver un lieu, communiquer sur l'évènement et surtout motiver de tels ateliers en favorisant la mise en relation des membres demandeurs⸱euses et proposant.

Un autre point important concerne les lieux de ces ateliers. Pour l'instant, le fait de varier les espaces autour de l'île de France était déjà une solution pratique. C'est aussi une richesse en terme de croisements de groupes sociaux, tant que les personnes présentes dans les lieux hébergeant sont également invitées. Même les moments "autour" sont des occasions de rencontres.

Réunion de suivi de projets

Ce troisième type de réunion serait moins centré autour d'un thème, mais plus proche d'un groupe de suivi de projet autogéré. On imagine des réunions mensuelles, qui pourraient être principalement en ligne, où l'on tire parti du groupe comme une multitudes d'avis subjectifs.

Encore une fois, le rôle de CLUB1 pourrait être d'aider à la logistique et à la communication autour des rendez vous.

Favoriser la mise en relation des membres

Une des pages les moins entretenue du site web est celle dédiée aux membres. Plusieurs pistes sont suggérées pour la retravailler de façon à mettre plus en évidence ce que les membres ont à partager (connaissances ou projets). On imagine rapidement des outils tels qu'un Linkedin interne, mais on choisit de se contenter pour l'instant de simplement rajouter ces informations aux "profils" des membres, sur la fameuse page membres. À la froideur des CV, Marylove suggère des formulations comme "à l'aise avec telle technique" ou "souhaite partager ceci".

6 - Fin

La dernière partie de la réunion accueille trois amies de Marylove ayant des intérêts et questionnements communs avec ceux de CLUB1. Elle comprend un nouvel exercice de présentation, en anglais cette fois! Des références sont échangés, cela donne envie de continuer ces moments de discussion lors des différentes formes de rencontres imaginés.

Toutes les réunions du Club:

• Réunion 003Compte rendu13/10/2022
• Réunion 002Compte rendu07/10/2021
• La première réunion du clubC'est la première fois que ça se fait05/02/2020

À partir de maintenant, sur le serveur Matrix de CLUB1:

1. Une adresse email valide est nécessaire pour créer un compte. C'est principalement pour ne pas avoir de faux comptes de spambots sur le serveur et ainsi éviter que club1.fr soit mis sur liste noire par d'autres serveurs. C'est la solution recommandée par matrix.org pour limiter les attaques sur le réseau et nous la trouvons raisonnable.
2. Il est possible pour tous les utilisateurs d'ajouter des adresses email à leur compte pour pouvoir récupérer leur mot de passe.
3. Les prévisualisations d'URL vers les sites hébergés sur club1.fr devraient maintenant fonctionner.
4. Le serveur n'est plus dépendant de matrix.org pour valider les clés d'autres serveurs (la dépendance est reportée sur le serveur d'un ami: matrix.jeanpierre.moe).
5. Les messages anciens de plus de 3 ans seront supprimés du serveur.

Une modification a également été apportée à la configuration de l'instance Element de CLUB1: le layout Bubble a été séléctionné par défaut pour rendre plus accessible l'interface de chat aux novices, qui ne sont pas forcément à l'aise avec une interface de style IRC.
Bien-sûr il est toujours possible pour chacun de modifier ce réglage par la suite pour séléctionner le layout qui lui plait.

Tous les articles CLUB1 concernant Matrix:

• Ajout d'un serveur MatrixLe serveur propose maintenant des inscriptions libres à Matrix15/03/2020
• Nouveaux réglages du serveur MatrixLa configuration de Synapse (le serveur Matrix installé chez CLUB1) a été mise à jour12/08/2021

Autres liens:

• MatrixWelcome to the Matrix - Notice d'utilisation de Matrix

• matrix.orgSite officiel du projet Matrix

Depuis le début du projet CLUB1, il y avait l'envie de pouvoir utiliser des adresses email custom finissant par @club1.fr. Mal­heureuse­ment, chaque tentative de mise en place du serveur a été interrompue à cause de la complexité de la configuration.
En effet, ce n'est pas un, ni même deux, mais bien trois serveurs qu'il faut installer et configurer correctement pour que tout fonctionne comme attendu.

Le tutoriel

Une fois encore cet article n'a pas la vocation d'être un tutoriel, mais il a été si long d'en trouver un suffisamment bien pour rendre la tâche agréable qu'il fallait qu'il soit partagé. Le tutoriel en question s'étale sur plusieurs parties bien distinctes qui sont très bien découpées, ce qui permet de faire une pause entre chaque. De plus il explique précisément la fonction de chaque ligne de configuration ajoutée et donne des moyens de tester que tout fonctionne bien au fur et à mesure. Si comme nous vous préférez que les comptes restent reliés aux utilisateurs Unix, vous pouvez sauter la partie 3.

En résumé, il vous apprendra à configurer correctement Postfix, le serveur principal de transmission des emails (via le protocole SMTP). Puis Dovecot, celui pour les consulter (via POP ou IMAP). Et enfin SPF, DKIM et DMARC, des protocoles permettant de garantir l'authenticité des emails et donc d'éviter de tomber dans les SPAMs.

Point important sur les SPAMs

Tant qu'on parle de SPAM, il nous faut aborder un point important. Le réseau email est malheureusement particulièrement sujet au SPAMs, ce qui a conduit à l'omniprésence de filtres permettant de les détecter. Le problème est que ces filtres sont souvent très agressifs, en particulier pour de petits hébergeurs comme CLUB1. Il est donc probable que les premiers emails que vous enverrez tombent dans la boite "indésirables" de vos correspondants tant que la réputation de club1.fr n'aura pas augmenté.

Pour cette raison il est demandé aux membres de ne PAS envoyer de mails de groupe à un grand nombre de destinataires et de prévenir leurs destinataires qu'un email pourrait se trouver dans les indésirables, car l'en enlever améliore notre réputation.

Mode d'emploi pour les membres

Chaque membre de CLUB1 a donc à sa disposition une adresse email reliée à son compte. Elle est composée du nom d'utilisateur, suivi de @club1.fr. Par exemple: michel@club1.fr

Stockage des emails

La technique de stockage qui a été choisie sur CLUB1 est le format Maildir. Cette méthode utilise un dossier par utilisateur contenant l'ensemble des mails envoyés et reçus (ainsi que les brouillons et les indésirables). Le dossier ~/mail/ a été choisi pour cet usage, attention donc de ne pas le supprimer par inadvertance, tous les emails seraient irrémédiablement perdus. Il n'est, par défaut, pas accessible par les autres utilisateurs.

Utilisation des emails sur le serveur

Une fois connecté en SSH au serveur, il est possible de consulter et d'envoyer des emails. Le message "You have new mail." indiquera d'ailleurs, par sa présence lors de la connexion, que de nouveaux emails sont disponibles.

Historiquement sur Unix, c'est avec la commande mail que l'on peut exécuter ces deux actions. Sur notre serveur, cette commande a été remplacée par mutt, car ce dernier est compatible avec la plupart des options de mail, tout en étant plus agréable à utiliser et en supportant mieux le format Maildir. La commande mail lancera donc en réalité mutt.

Connecter un client de messagerie

N'importe quel client de messagerie récent sera capable de se connecter à notre serveur en entrant simplement l'adresse email et le mot de passe correspondant. Il se chargera de la configuration automatiquement. Plus précisément, il doit supporter les protocoles SMTP et IMAP. Les ports utilisés sont les ports standards, mais ça ne coûte rien de les rappeler (les ports SSL/TLS sont préférables) :

Tous les articles CLUB1 concernant les emails:

• Le(s) serveur(s) emailLes membres de CLUB1 ont enfin une adresse email perso27/07/2021
• Transfert d'email & Sender Policy FrameworkSoit la configuration de SRS pour réparer ce que SPF a cassé28/08/2022