Journal de CLUB1

Comment j'ai eu un rdv médical grâce à une tâche CRON

2026-01-22T12:00:00+01:00

Un peu de contexte

Cet article est une anecdote personnelle d'un membre de CLUB1. Dans celui-ci, Vincent nous présente un usage du serveur un peu moins connu que l'hébergement de sites Web.

Désert médical

Dans le coin du Lot où j'habite, ya pas foule au niveau des médecins généralistes. On peut même dire que j'habite dans un désert médical. J'ai voulu prendre un rdv, sauf que tout était bouché. L'un des seul cabinet de Cahors qui accueille des nouveau·elles patients s'appelle : Agir pour Mieux Vivre et la seule façon de prendre RDV est sur la plateforme en ligne https://www.maiia.com/ (qui semble assez équivalente à Doctolib).

La plateforme annonce des RDV dispo dans 8 jours, sauf que, je n'ai pas le droit de réserver de première consultation dans des délais supérieurs à 72h (3 jours). Ça semble un paramètre réglable du site, ce qui veut dire que c'est un parti pris du cabinet médical.

J'aurais pu me dire que c'était une situation exceptionnelle, sauf que ma coloc m'avait prévenu qu'elle n’avait jamais réussi à prendre rendez-vous quand elle était allée voir sur le site.

Bon eh bien il ne me reste plus qu'à retourner consulter cette page plusieurs fois pas jour dans l'espoir de tomber sur une annulation récente.

Ou alors....

Faire qu'un programme informatique consulte la page pour moi !

En fait ça m'a rappelé la période du COVID, pendant laquelle des scripts avaient émergés pour "choper les RDV dès qu'ils sont dispo", par exemple avec : DoctoShotGun
Bon là ça va méga loin car le programme s'occupe même de prendre le RDV.

De mon côté je me suis dit que si j'arrivai à faire une sorte d'alerte, ça serait déjà pas mal.

frappe chirurgicale

Je commence donc à essayer de comprendre le fonctionnement du site pour voir si il est possible de "scrapper" les infos qui m'intéressent.
Je suis un peu dérouté car je ne suis pas très familier de ce genre de Web-app où tout est chargé en cours de route via du Javascript. J'ai donc bien pataugé au début.
Par exemple j'ai perdu 5 minutes à bugger sur le script suivant :

tarteaucitron ?? Mais trop chelou d'avoir appelé un de leur scripts comme ça !!! 😵‍💫 je me suis demandé si c'était un nom généré aléatoirement pour camoufler leur fonctionnement. Bon, finalement il s'avère que c'était juste le code de la bannière de cookie 😑

En fait, plutôt que regarder le code, j'ai compris qu'avec ce genre de site, il valait mieux regarder les requêtes que celui-ci effectue. Et là j'ai trouvé en deux secondes !

On voit (en bas à gauche) que la page Web effectue 118 requêtes vers leur serveur et d'autres lorsque je demande d'afficher la page.

🔎 Pour info, on peut voir ça dans Firefox en ouvrant l'inspecteur (touche F12 ou la combinaison Ctrl Maj I), puis en sélectionnant l'onglet "⇅ réseau". En rechargeant la page, on voit alors tout les aller-retours entre notre ordinateur et le(s) serveur(s).

J'avais déjà vu le mot "availability" en auscultant un peu le HTML, j'ai donc filtré les requêtes utilisant ce mot. Et ça n'a pas loupé ! Je découvre une requête effectuée vers l'URL suivante :

https://www.maiia.com/api/pat-public/availability-closests?centerId=64abbc120870ca46e93017b2&from=2025-10-31T16%3A39%3A00.000Z&limit=200&page=0

availability-closests ? Tiens tiens... 🕵️

Et c'est bingo, car derrière cette URL, on obtient des données structurées sous forme d'un JSON :

{
    "availabilityCount": 1,
    "closestPhysicalAvailability": {
        "id": "6904d42d025862180fb450c0",
        "practitionerId": "64abbc120870ca46e93017b7",
        "centerId": "64abbc120870ca46e93017b2",
        "timeSlotId": "68216a1c285d2850f0ca1edd",
        "weekId": "68216a1c285d2850f0ca1eb3",
        "weekTemplateCycleId": "64ad0f8ca12ada5dd802c793",
        "consultationReasonId": "66e00827bd69f40b1a87387c",
        "creationDate": "2025-10-31T15:22:21.860Z",
        "updateDate": "2025-10-31T15:22:21.860Z",
        "startDateTime": "2025-11-05T07:30:00.000Z",
        "endDateTime": "2025-11-05T07:45:00.000Z",
        "percentageNewPatient": 0.0,
        "usedResource": []
    },
    "firstAvailabilityStartDateTime": "2025-11-05T07:30:00.000Z",
    "firstPhysicalStartDateTime": "2025-11-05T07:30:00.000Z"
}

Alors il-y-a toute une section closestPhysicalAvailability qui ne m'intéresse pas trop car c'est en fait des suggestions d'autres endroit où consulter à proximité. Mais en bas, on peut trouver firstAvailabilityStartDateTime et firstPhysicalStartDateTime. J'imagine que le premier intègre les RDV en visio, ce qui ne m'intéresse pas.
En tout cas, ça fait plaisir de voir une belle chaîne de caractères représentant une date ! Et surtout avec une une précision de l'ordre du millième de seconde 🤪.

2025-11-05T07:30:00.000Z

Tout ça s'avère être de bonne augure quant à la faisabilité d'un petit logiciel qui vérifierait cette URL régulièrement en mesurant si la date fournie est dans moins de 72h.

Écriture d'un Scénario

J'avais déjà en tête les outils qui pourrait m'aider sur ce coup là. C'est une combinaison assez classique de programmes qu'on trouve souvent déjà installés avec Linux (l'Operating System installé sur le serveur CLUB1).
Je ne vais donc pas "coder" tout un logiciel, mais plutôt mettre un peu de glue entre des logiciels existants pour former un outil minimaliste. Dans le jargon informatique, on appelle ça "un script" (scénario). J'ai choisi d'appeler le mien apmv.sh.

Équipe de choc

Bon, j'ai vraiment fait une équipe cheaté, j'ai mis que des gros bangers de la ligne de commande. Matez moi cette équipe de fou :

curl va contacter le serveur grâce au bon vieux protocole HTTP 🚀
jq arrive à extraire l'info importante du fichier formaté en JSON 📂
date sait lire les dates et les convertir 📅
crontab permet de déclencher régulièrement une action ⌛️
mailx envoie un email vite fait bien fait ✉️

Chronique des titans

Attardons nous un peu sur le délicieux crontab. C'est ce qu'on appelle communément "les tâches CRON" (sûrement une ref à ce bon vieux Cronos le titan). C'est un outil qui, lorsqu'il est lancé sur un serveur, tourne constamment en arrière plan et va déclencher régulièrement des tâches. Une tâche ? C'est un peu tout ce qu'on voudra, il faut surtout retenir que CRON n'est qu'un déclencheur. Le seul truc qu'il va falloir régler c'est donc la fréquence du déclenchement. Et la façon de la définir est assez déroutante au premier abord :

* * * * * 'truc à faire'

Ceci ne signifie pas un hôtel 5 étoiles, mais "une fois par minute". Vous l'aviez sûrement deviné, mais je le dis quand même ; Chaque partie séparée par un espace signifie dans l'ordre : minute, heure, jour, mois et jour de la semaine.

Par exemple :

15 14 1 * *

Signifie "chaque premier du mois à 14h15" en langage CRON.

Heureusement, on peut se faire aider par ce guru qui traduit en langue de Shakespeare la noble langue de Cron.

Au final, pour mon projet, c'était pas très compliqué :

*/10 * * * * /home/vincent/scripts/apmv.sh

Autrement dit : "lance le script apmv.sh toute les dix minutes !"

Moi aussi je veux trop avoir une tâche CRON !!!

C'est sûrement ce que vous vous dites. Ce rêve n'est peut-être pas si lointain. Par exemple si vous avez un compte sur un serveur, que vous avez la possibilité et la détermination pour vous connecter en SSH et que le logiciel crontab est installé. Eh bien, vous pouvez !

Pour créer sa première tâche cronique, vous devez lancer la commande suivante :

crontab -e

On atterrit dans l'éditeur de fichier par défaut sur ce serveur. En bas du fichier, chaque ligne correspond à une tâche. Vous pouvez par exemple ajouter :

0 10 * * 4 echo '🗑️ ne pas oublier de sortir les poubelles ce soir !'

Normalement echo renvoie un message dans le terminal, mais ici, vu qu'il s'agit d'une cronerie, on va recevoir le message sur notre adresse perso. (Bon il faut que le serveur gère les emails aussi, c'est le cas de club1 par exemple)

Ça marche aussi pour les anniversaires :

0 0 1 12 * echo '🎂 souhaiter son anniversaire à Vincent'

Avec la tâche ci-dessus, on recevra un email chaque premier décembre à minuit (l'heure du crime). Mais tant qu'à faire, autant rendre le truc encore plus déshumanisé en l'automatisant au max (parce que c'est bien ça qu'on veut !) :

    3 0 1 12 * echo 'Je te souhaite un très bon anniversaire ! (sincèrement)' | mailx -s '🎉 surprise...' -- vincent@club1.fr

Tadaaa ! Cette fois ci la tâche est directement d'envoyer un email à la personne dont c'est l'anniversaire (en l'occurence moi). Encore une fois on est libéré des vielles traditions sociales qui nous enchaînaient grâce à l'informatique ! Que vas t'on pouvoir faire de tout le temps libre qu'on a acquis ? 🤔
(Vous noterez que j'ai mis la tâche CRON à 00h03 pour que ça fasse plus humain 😎)

curling de date

C'est bon ? tout le monde a sa tâche CRON ? On va pouvoir avancer sur notre shmilblik.

Dans mon cas, je n'avais pas envie de recevoir un email toute les 10 minutes m'indiquant la dispo des RDV. Mon script va d’abord vérifier la disponibilité avant de me prévenir par email. Sa première action est de contacter le serveur Maiia grâce à l'URL que j'ai identifé lors de mon enquête. Cette fois c'est le job de curl :

curl -s 'https://www.maiia.com/api/pat-public/availability-closests?centerId=64abbc120870ca46e93017b2&consultationReasonName=Soins%20non%20programm%C3%A9s%20%28acc%C3%A8s%20libre%29&consultationReasonType=PHYSICAL&from=2025-10-25T18%3A35%3A00.000Z&limit=200&page=0&specialityId=5e185ddfb5346d1863161b4b'

D'ailleurs vous pouvez lancer cette commande sur votre ordinateur si vous avez un terminal et curl d'installé.

Pour filtrer les infos qui nous intéressent, on envoie ça dans jq grâce à un tuyaux | ("pipe" en anglais). Puis rebelote, on envoie la sortie de jq dans date. Ça donne ça :

curl -s 'https://www.maiia.com/api...' | jq -r .firstAvailabilityStartDateTime | date -f -

Lorsque je lance cette commande, le message suivant s'affiche en retour. C'est en français car mon ordinateur est réglé dans cette langue.

mer. 05 nov. 2025 08:30:00 CET

Ce genre de plomberie informatique est une des façon les plus courante pour combiner des logiciels entre eux.

Éviter de spammer

Dans la version simple de mon programme, j'avais donc une vérification toute les 10 minutes de la disponibilité d'un RDV dans moins de 72h. À chaque fois que c'était vrai, je recevrai un email.

Si on chipote un peu, on peut y voir un petit soucis. Lorsque qu'un RDV est dispo longtemps je vais recevoir des emails en boucle jusqu'à ce qu'il soit pris. Par exemple si un·e client·e annule son rdv à une heure du mat', je risque de me réveiller et découvrir une bonne quarantaine d'emails. À vous de voir si c'est si terrible que ça.

Le fait est que j'avais prévu de rajouter les adresses emails de mes colocs au script : une responsabilité supplémentaire. J'ai donc fait en sorte que, lorsque la vérification donne une réponse positive, en plus d'envoyer un petit mail, un fichier vide est également créé à un endroit précis dans mon espace sur le serveur. Je rajoute ensuite une condition disant que : si le fameux fichier existe, on laisse tomber la vérification. Cela signifie qu'un email a déjà été envoyé, on évite ainsi au script de se répéter. Le fichier joue le rôle d'interrupteur ! Si je le supprime ça va ré-activer le programme et il fonctionnera jusqu'au prochain RDV trouvé.

Assemblage

Voici le fameux script combinant tout ce qui a été évoqué ci-dessus. J'ai ajouté des petits commentaires pour décrire les différentes parties. Ce sont les lignes qui commencent par un croisillon #.

#/bin/bash -e
# check la dispo des rdv sur le site Maiia

# si le fichier interrupteur existe, on arrête le script
if test -e /home/vincent/apmv-off
then
    exit 0
fi

# récupération de la date du prochain RDV
avail=$(curl -s 'https://www.maiia.com/api/pat-public/availability-closests?centerId=64abbc120870ca46e93017b2&consultationReasonName=Soins%20non%20programm%C3%A9s%20%28acc%C3%A8s%20libre%29&consultationReasonType=PHYSICAL&from=2025-10-25T18%3A35%3A00.000Z&limit=200&page=0&specialityId=5e185ddfb5346d1863161b4b'| jq -r .firstAvailabilityStartDateTime | date +%s -f - )

in3days=$(date --date='72 hours' +%s)

# si la date de dispo est dans plus de trois jours, on arrête le script
if test $avail -gt $in3days
then
    exit 0
fi

# envoi de l'email
echo 'go prendre un rdv\n' \
| mailx -s '🚀 rdv disponible chez Agir pour mieux vivre' -- vincent@club1.fr

# crée le fichier interupteur
touch /home/vincent/apmv-off

Oasis is good

Vendredi 31 octobre, 9h00, Pantin : le script apmv.sh détecte un créneau de disponible dans moins de 72h et déclenche l'envoi d'un email.

Quelques minutes plus tard, je consulte mon téléphone et check mes emails. En découvrant la nouvelle, je me précipite sur le site pour vérifier qu'il ne s'agit pas d'un faux positif. Heureusement le créneau est bien là ! Je n'ai qu'à cliquer dessus pour le réserver.

Tel un oasis dans le désert médical, grâce à ce script et aux vénérables logiciels à moins de cinq lettres, j'ai pu décrocher un rendez-vous chez le médecin ! 🎉

Est ce que ça résout la problématique du manque de personnel médical ? Pas du tout. Ça illustre par contre le pouvoir qu'apporte la connaissance des technologies qui nous entourent. Et c'est plutôt flippant que ça ne soit qu'entre les mains d'une élite d'informaticiens comme moi. Donc j'espère que ça pourra inspirer des personnes ou des groupes à s'approprier ces outils pour faire des trucs chouettes !

UNIX vibe

Dans ce projet, j'ai fortement tiré parti de ce qu'on appelle la philosophie UNIX :

Écrivez des programmes qui effectuent une seule chose et qui le font bien.
Écrivez des programmes qui collaborent.
Écrivez des programmes pour gérer des flux de texte [en pratique des flux d'octets], car c'est une interface universelle.

C'est une citation de Douglas McIlroy, l'inventeur des tuyaux UNIX. Les programmes qu'il évoque sont ceux que j'ai appelé "les membres de mon équipe". Ils ne font chacun qu'une chose limitée, mais combiné à d'autres, ont peut alors réaliser des actions complexes et puissantes.

C'est une façon de voir les outils informatiques qui diffère totalement de la vision dominante actuelle. On connaît mieux les logiciels monolithique qui sont complexes et riches en fonctionnalités. Par exemple Microsoft Word, Excel, Photoshop ou même Firefox.

Il y a des différences dans la courbe d'apprentissage ainsi qu'au niveau de l'agentivité induite par ces deux approches. Je dirais que les petits outils Unix sont au moins aussi complexes que les gros logiciels à apprendre. Mais une bascule opère lorsque l'on veut faire quelque-chose qui est légèrement en dehors des possibilités permises par un outil monolithique. À ce moment là, on est un peu coincé et il faut chercher un autre programme qui fera exactement ce dont on a besoin. Et si on n'en trouve pas, abandonner, car c'est trop complexe de le coder soi-même. À l'inverse, si l'on maîtrise déjà quelques petits outils, on n'aura souvent qu'à chercher un module manquant pour le combiner à ceux que l'on connaît déjà et arriver à ses fins.

Bon c'est une version un peu idéaliste, mais qui permet de saisir la différence fondamentale. À titre personnel j'étais très content de découvrir une autre façon d'utiliser les ordinateurs. En composant à chaque fois de petits scénarios (les scripts) sur mesure, on passe du statut d'utilisateur à celui de compositeur·ice. Ça a son importance car les outils que nous utilisons nous conditionnent dans une certaine mesure.

Cette approche n'est pas nouvelle car UNIX est un système d'exploitation (OS) déchu datant des années 70 ! Il servira cependant d'inspiration à Linux, d'où la consonance.

Tools shape practices / Les outils influent les pratiques

Pour aller plus loin

Pour apprendre progressivement à utiliser ces petits outils, j'ai entamé mon propre mémo accessible en ligne. Ça me permet de retrouver plus vite mes réglages favoris pour chaque commande.

Et voici quelques pistes à explorer pour creuser le sujet :

The map is the territory

The map is the territory est un fanzine écrit par Zach AKA CoolGuy qui présente la pratique de la ligne de commande d'une façon spirituelle ! C'est en anglais car ce cool guy est australien. Mais on a justement entrepris de le traduire en français avec Nouckey !

Projet de traduction sur le forum Club1

Pas encore de lien sûr car la traduction n'est pas finie.

Le blog d'Arthur Pons

http://arthur.bebou.netlib.re/

J'ai rencontré Arthur à Strasbourg, il est membres du collectif Katzele qui explore l'usage convivial de l'informatique. Son son blog personnel regorge de réflexions sur l'usage de l'ordinateur proche de celui qui est évoqué dans cet article.

Serveur tildes

Les serveur tildes sont une famille de serveurs qui permettent à leurs membres d'y accéder via SSH, leur permettant ainsi de construire des scripts. Le plus connu étant le https://tilde.club/. On peut dire que club1 est une sorte de serveur tilde.

Réunion 005

2025-06-14T14:00:00+01:00

Date et lieu

Le dimanche 27 octobre 2024 dans la salle 378 de Césure à Paris.

Personnes présentes :

Aqua
Audrey
Caman
Hugo
Kappa
Nicolas
Paul
Vincent
Yann

Nouvelle réunion, nouveau lieu. Cette fois-ci nous sommes accueillis par Yann au sein de l'ancien bâtiment de la fac de Paris 3. C'est le Week-end, il n'y a pas grand monde, nous sommes bien tranquilles dans une confortable salle de réunion.

On a repris le méchanisme de la réunion précendente, à savoir : un tag réunion 005 est créé sur le forum pour rassembler des sujets et aboutir à un ordre du jour.
Mais on commence à se connaître. Vu la diversité de profils des membres du club et la spécificité des sujets que l'on aborde, on sait que si l'on veut éviter d'exclure trop de monde, on va devoir prendre un certains temps pour vulgariser et partager des notions. Ça peut être déroutant lorsque l'on participe pour la première fois à une réunion CLUB1 : on avance pas vite du tout ! Pour cette cinquième réunion, on a donc principalement étuidé trois sujets :

1 - Changement de la License de la documentation
2 - Ajout de RAM
3 - Point sur l'utilisations des outils internes

1 - Changement de la License de la documentation

Fil associé sur le forum

Nicolas propose de passer la license de la documentation CLUB1 de GFDL vers CC BY SA.

Contexte : dès qu’on publie un travail sur internet, n’importe qui peut y accéder, mais cela ne signifie pas que n’importe qui peut faire ce qu’il veut avec, par défaut le document appartient à celui qui en a les droits. L'intérêt de spécifier une license est donc de donner des libertés aux personnes qui vont avoir accès à ce travail.

Ici, on parle de la documentation CLUB1, c'est un travail plutôt conséquent, spécifique, mais dont on pense que certaines parties pourraient en être extraites facilement, à d'autres fins.

Parmi les droits que Nicolas voulait accorder à la documentation, il y a le fait de pouvoir la copier, d'en prendre une partie pour l'intégrer dans sa propre création. Mais aussi, dans la veine des licences GPL, la contrainte de devoir appliquer les mêmes règles à son tour. (On dit parfois que ces licenses sont "contaminantes")

Lors de la création de la documentation, il a fallu choisir une license. À l'époque, Nicolas, qui a initié cet ouvrage, connaissait surtout la GPL (une license historique, pensée principalement pour les logiciels). Hors, elle est accompagnée d'une licenses sœur, la GFDL (GNU Free Documentation License), dédiée aux documents et aux manuels. Malgré que cette dernière dispose de clauses spécifiques qui ne nous concernaient pas spécialement, elle a été choisie à l’époque parce qu’on ne connaissait pas bien les autres licences et qu'elle convenait globalement.

Pour le site Web de CLUB1, Nicolas s’était depuis renseigné un peu plus sur les diverses licences, et notamment sur la licence Creative Commons. Son principal avantage : plus de gens sont familiers avec cette licence qu'avec la GPL (bien qu'elle soit plus récente). Cependant, Creative Commons est aussi plus complexe, car elle est modulaire : c’est un licence en kit, à nous de choisir les propriétés que l'on voudrait appliquer.

Dans notre cas, Nicolas a donc sélectionné les options "CC", "BY" et "SA" pour :

CC : Creative Commons, droit de repartager.
BY : c’est l’attribution, on cite les auteurs d’origine, ici les "membres de CLUB1".
SA : Share Alike, partage sous les mêmes conditions (C’est l’attribut « contaminant » équivalent à la GPL)

Puisqu’on n'utilise pas du tout les clauses spécifiques de la Free Document Licence, qu’elle n’est pas très connue, et qu’elle est différente de celle du site web, Nicolas pense que c’est plus malin de changer de licence pour plus de cohérence avec la licence du site Web, (qui est en CC BY SA). La documentation étant un sous-dossier du Site Web, c’est étrange d’avoir en cours d’exploration une zone sous une licence différente.

Pour changer la License :

Légalement, comme le copyright appartient aux membres de CLUB1 (les auteurs sont cités au nom des « membres de CLUB1 »), il faut que tous les membres soient d’accord pour ce changement. On a tout de même une liste d’auteurs cités sur la première page de la documentation, mais bien sûr, autant demander au plus de personnes possibles pour s'approcher du consensus. Techniquement parlant, il n'y a pas de difficulté, car il s’agit juste changer le texte.

On décide d'envoyer un message sur Matrix en complément du forum et de ce compte rendu pour propager l'information.

Et pourquoi pas d'autres licenses ou d'autres options ?

On en profite pour faire un petit tour d'horizon du vaste monde des licenses. Ça tombe bien, on a sous la mains un poster intitulé "Comment partager mes œuvres" (à retrouver sur le site de Clara Bougon) !

Par exemple, voici d'autres propriétés de la Creative Commons :

ND : No Derivatives, pas de modifications.
NC : Non commercial

L'option "ND" est un peu trop stricte à notre goût. À l'inverse, si on avait voulu être le plus souple possible, on aurait pu utiliser la "CC0", qui n'a aucune condition !

Enfin, l'option "NC" est plus délicate. Parmis les communautés utilisant les licenses libres, elle divise. Aussi, il peut être compliqué de tracer une ligne claire, délimitant l'usage commercial ou non d'une oeuvre.

Le choix de license est aussi utilisé pour faire passer des messages politiques en y ajoutant des clauses "éthiques". L'inconvénient de telles méthodes et qu'elles sont rarement reconnues juridiquement. Les licenses personnalisés ont également comme inconvénient de devoir être lues pour être connues. Bon, et puis dans notre cas, l'idée de départ de cette proposition était de rallier la license de la doc à celle du site Web.

Résultat : Durant la réunion, aucun membre ne s’oppose au changement de la License GFDL vers CC BY SA.

2 - Ajout de RAM

Fil associé sur le forum

CLUB1 a récemment reçu un don en nature de 4 barrettes de 16Go de RAM. Il s'agit de matériel informatique que l'on peut connecter sur la carte mère du serveur pour augmenter ses capacités de "mémoire vive". Notre carte mère dispose de 4 emplacements pour ce type de barrette. Au moment de la réunion, un seul de ces emplacements est utilisé (avec une barrette de 16Go), ce qui est le minimum pour que l'ordinateur fonctionne. Il reste donc trois emplacements vides. La question est donc : est ce que l'on souhaite peupler ces espaces vides avec de nouvelles barettes ?

Une barrette de RAM

Est-ce qu'on en a besoin ?

À ce moment, on se doit de présenter un peu plus ce que c'est qu'est la "mémoire vive" (en anglais RAM, pour Radom Access Memory). Déjà, il faut faire gaffe à ne pas la confondre avec les supports de stockage comme les disques durs ou les SSD. La "mémoire" vive ne stocke rien au long terme, car elle est volatile. C'est un peu la zone dans laquelle se trouve tout ce qui est prêt à être utilisé. Dès que le serveur à besoin d'un fichier ou de garder temporairement quelque-chose en tête, c'est mis dans la mémoire vive. Heureusement, c'est un support très rapide (100 fois plus qu'un SSD !)

Si le serveur sature cet espace pour ses besoins de calculs, il ne pourra plus fonctionner. En l'occurence, il n'a jamais atteint sa limite depuis 5 ans de fonctionnement, donc cela ne semble pas être un problème. On peut même très précisément suivre l'usage de la mémoire vive grâce au tableau de bord.

Ce que l'on comprend avec ce graphique, c'est que le système d'exploitation et ses programmes n'utilisent jamais plus de 6Go de RAM (ils correspondent aux deux courbes les plus basses). Ce qui explique pourquoi on n'a jamais eu de problème avec une seule barrette.

👆️ Mais alors, c'est inutile d'augmenter la capcité !

C'est ce qu'on pourrait se dire au premier abord, mais le graphique n'a pas qu'une seule courbe. En fait le système sait mettre à profit l'espace restant pour y garder les fichiers les plus populaires 😎, on appelle cela "mettre les fichiers en cache". Si on a besoin d'ouvrir un tel fichier, ça évite de devoir retourner lire le support de stockage, ce qui est bien fastidieux en comparaison.

En conclusion : avec notre usage actuel, le serveur peut se passer de plus de mémoire vive. Augmenter sa capacité, c'est plus du confort et de la marge potentielle pour plus tard (si l'usage du serveur continue à augmenter).

Qu'est ce que ça coûte ?

Normalement, ce type de barrette neuve coûte une centaine d'euros ! En l'occurence, ce sont des barrettes d'occasions que nous n'avons pas payé. Par contre, ça consomme de l'électricité. Lors de la réunion, Nicolas propose une estimation de 2W supplémentaire par barrette inspirée par cet article. Mais en fait on n'en sait trop rien. Et puis, c'est difficile de se représenter une telle valeur. On aimerait pouvoir mettre ça en relation avec le reste du serveur, ou même, de nos autres appareils électriques domestiques.

Mais au fait, combien est ce que le serveur consome ?

Au moment de la réunion la seule info que l'on a est l'indication de la puissance consomée en temps réel par l'onduleur. Selon lui, les appareils qui lui sont branchés (serveur, box internet, routeur) consomment aux alentours de 50W. Aucun moyen de connaître leurs consomations respectives, et encore moins celles des composants du serveur.

Paul en profite pour nous partager un projet qu'il a déjà utilisé appellé Scaphandre. Ce dernier permet de mesurer la consomation électrique de certains composants. C'est plutôt destiné à des grosses infrastructures, mais peut-être qu'on pourrait s'en servir avec CLUB1 ?

Qu'est ce qu'on fait ?

Trois possibilitées s'offrent à nous :

Ne rien faire !
Ajouter une deuxième barrette et doubler la quantité de mémoire vive. 🚀 (32Go)
Ajouter trois barrettes et quadrupler la quantité de mémoire vive. 🚀🚀🚀 (64Go)

En l'absence d'informations de consomation fiables, on a du mal à prendre une décision. Après discussion, il est convenu de faire une expérimentation en conditions réelles de la solution à deux barrettes (2) pour vérifier l'augmentation pressentie de la consommation à 2W.

Mesures

Depuis la réunion, des mesures ont été effectuées. On a branché un Watt-mètre à différents endroits, avant et après avoir ajouté une deuxième barrette de RAM. Pour essayer d'avoir des mesure représentatives, on a laissé l'appareil branché pendant environ deux semaines et calculé une moyenne.

mesure	barrettes	conso moyenne
toute l'infrastructure*	1 x 16Go	69,5W
toute l'infrastructure*	2 x 16Go	71 W
serveur seul	1 x 16Go	31,06W
serveur seul	2 x 16Go	33,66W

*toute l'infra : onduleur, serveur, Bbox Bouygues, Boîtier fibre ONT, Switch PoE 🏠️, Point d'accès Wi-FI (chambre) 🏠️

🏠️ : appareils non nécessaire au fonctionnement de club1

Le serveur consomme donc approximativement 2W supplémentaire lorsque l’on ajoute une seconde barrette de RAM.

Quelques images de l'opération

Repérage des emplacements adéquats sur le schéma de la carte mère.

Deux barrettes de RAM branchées sur la carte mère du serveur

Le Watt-mètre d'Aymeric

3 - Point sur l'utilisations des outils internes

Comme lors de la dernière réunion, on en profite pour re-faire un tour d'horizon des outils internes de club1 et sur comment les membres peuvent se les approprier lorsqu'ils ont envie de s'investir.

Participation au site Web

Un des point évoqué est la participation au site Web officiel de CLUB1. Celui-ci est en fait un wiki, sur lequel il faut avoir un compte indépendant du compte CLUB1, pour créer ou éditer des pages. On est pas satisfait de cette solution car elle nécessite la gestion d'un compte supplémentaire.

🎉 Bonne nouvelle : depuis la réunion, il est maintenant possible de s'y connecter avec son compte club1 pour créer de nouvelles pages ! La documentation a été mise à jour pour reflèter cette amélioration.

Toutes les réunions du Club :

Réunion 00514/06/2025
Réunion 00402/06/2024
Réunion 00313/10/2022
Réunion 00207/10/2021
La première réunion du club05/02/2020

Rapport d'incident #005

2024-10-20T19:58:00+02:00

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 découvrir 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

Réunion 004

2024-06-02T10:48:00+02:00

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.

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.
P.S. : On cherche un lieu ! 🔍🏕️
Une soirée de lancement pour le service de WebRadio

Toutes les réunions du Club :

Réunion 00514/06/2025
Réunion 00402/06/2024
Réunion 00313/10/2022
Réunion 00207/10/2021
La première réunion du club05/02/2020

Soirée d'inauguration du service radio

2024-01-07T00:27:00+01:00

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.

Le logo d'Icecast

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 !

Le diplôme d'Alix

2023-12-01T12:00:00+02:00

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 diplôme, 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 Morgane. 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 !

Ci-dessous, deux photos de la datafoire en action, lors d'une fete organisé par Sainte Claude, dans la foret.

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

Migration de Ubuntu à Debian (Phase 3)

2023-11-30T10:45:00+01:00

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.

La clé contenant l'ISO de Debian est branchée en facade et l'ancien SSD est complètement déconnecté pour être certain de ne pas modifier son contenu.

Le nouveau SSD NVMe est en place dans son port M.2.

L'iKVM en Javascript un peu foireux de Supermicro nous permet tant bien que mal de lancer l'installateur Debian.

Le protocole de restauration/migration décrit sur le forum est scrupuleusement respecté, mais les ennuis pointent le bout de leur nez.

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 commence à se faire tard.

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

Migration de Ubuntu à Debian (Phase 2)

2023-11-14T19:48:00+01:00

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 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).

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

Rapport d'incident #004 (01/11/2023)

2023-11-02T22:25:00+01:00

Hier à 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 Cyberrance :

Heure	Sujet
12:22	UPS eaton-5p@localhost on battery
12:48	UPS eaton-5p@localhost on line power
12:52	UPS eaton-5p@localhost on battery
12:59	UPS eaton-5p@localhost battery is low
12:59	Auto logout and shutdown proceeding

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 Cyberrance 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 ce jour étant 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.

Migration de Ubuntu à Debian (Phase 1)

2023-08-01T10:53:00+01:00

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 en 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 :

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.
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é.
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.

apt-mark showmanual > packages.txt

Et pour les installer sur le nouveau système :

sudo apt update
cat packages.txt \
| xargs sudo DEBIAN_FRONTEND=noninteractive apt install --no-install-recommends -y

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 :

E: Unable to locate package apport-symptoms
E: Package 'busybox-initramfs' has no installation candidate
Note, selecting 'libcom-err2' instead of 'libcomerr2'
Note, selecting 'libgcc-s1' instead of 'libgcc1'
...

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 :

...
openssh-server is already the newest version (1:8.4p1-5+deb11u1).
openssh-server set to manually installed.
openssh-sftp-server is already the newest version (1:8.4p1-5+deb11u1).
openssh-sftp-server set to manually installed.
...

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.

git remote add ubuntu nicolas@club1.fr:etc.git
git remote update
git merge --allow-unrelated-histories ubuntu/master
git mergtool                                  # résolution des confilts
git clean -i                                  # suppression des fichiers *.orig créés par nvimdiff
git reset                                     # unstage tout
git rev-parse ubuntu/master > .git/MERGE_HEAD # restauration de l’info de merge après le reset
git add -u .                                  # ajout des fichiers modifiés uniquement
git add -N .                                  # indique à git qu’on compte ajouter le reste des
                                              # fichiers à l’index, pour pouvoir add en interactive
git add -p .                                  # add interactif
git merge --continue                          # finalisation du merge
git reset --hard                              # suppression des modifications non voulues
etckeeper init                                # mise à jour des fichiers de etckeeper

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.

L'étape de merge avec Neovim en tant que mergetool. La plupart du temps les conflits sont assez simples à résoudre, puisqu'on veut généralement la configuration de Debian. Ils sont donc souvent expédiés à grand coups de :diffget LO pour utiliser le contenu du fichier local.

Avec git mergetool, lorsqu'il y a un conflit avec un lien symbolique, il faut simplement choisir la destination que l'on préfère, ici celle de Debian, on utilise alors l pour "local".

Une fois les conflit résolus, vient alors le tour de git add en mode interactif. De cette manière, Git affiche les patchs avant de nous demander ce que l'on veut en faire. Ici il s'agit du fichier d'entête de CLUB1 pour le MOTD. On veut évidemment le garder donc y pour "yes".

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.

Le gratifiant résumé de la fusion, obtenu grâce à git log --graph, qui nous montre les deux historiques séparés (lignes verte et rouge) se rejoignant en un commit de merge.

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 ! 😎

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

Déménagement à la Cyberrance

2023-07-20T00:37:00+02:00

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

19h20 : Extraction du serveur hors de son placard pantinois.

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).

Ici on peut voir l'onduleur au premier étage.

Insertion du serveur dans sa nouvelle coquille, tel un bernard l'ermite. 🐚

20h45 : le serveur est devant la Cyberrance, à Romainville.

Ce modèle de flycase est très confortable à porter à plusieurs car les poignées ne sont pas renfoncées.

Positionnement préçis sur le meuble à chaussures.

Subtile intégration dans le décor. On remarque que le napperon cache tout juste l'unité de rack non-utilisée. Ceci est un PRO TRICK 😉

Tout le monde se demande sûrement ce qui est inscrit sur le tee-shirt de Nicolas.

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).

Ça faisait longtemps que l'on avait pas pu voir le logo CLUB1 lors de la connexion SSH.

🎉 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.

Dans le studio d'Armand, le premier bénéficiaire de la remise en ligne est un chat, captivé par l'animation du logo CHATONS sur la page d'accueil du site web de CLUB1.

22h30 : Le serveur est prêt à passer sa première nuit hors de Pantin. Il a tout de même une petite veilleuse le temps qu'il s'habitue à son nouvel environnement bien plus vaste que son précédent placard.

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.

Rapport d'incident #003 (05/06/2023)

2023-07-19T20:31:00+02:00

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.

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 Telecom et en rose par CLUB1. Les PBO sont sous la responsabilité de l'immeuble et les PTO sous celles des FAI (aussi appelés opérateurs commerciaux).
Schéma d'origine provenant du blog uniformatic.

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 Telecom) 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 ensuite présentées. 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.

Prochaine Action

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'a donc pas la capacité d'agir directement. Notre interlocuteur nous a également confirmé que la date donnée pour dans deux semaines é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.

La carte des déploiements fibre de l'ARCEP en vue par communes.

On peut voir qu'il y a deux opérateurs d'infrastructure à Pantin : Orange et SFR.

La vue rapprochée permet d'avoir les informations par immeuble (chaque petit point) !

Le mercredi 14 juin nous recontactons Bouygues Telecom 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 juin. 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.

Ces 6 semaines de coupure de CLUB1 seront plus tard surnommées les "six semaines noires d'Internet".

Suivi de l'incident

Bouygues Telecom ne fournissant aucune mise-à-jour de la situation, Nicolas a tenté de suivre la panne via une succession d'appels téléphonique. Malheureusement, ils participent surtout à augmenter la frustration car il n'y a aucun dialogue possible et le FAI nous fait sentir le peu de considération qu'il a pour nous et ses 57 autres clients.

19/06 18:51

Pas de retour d'internet ni de message de Bouygues.
Redémarrage de l'ONT : 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.
Déplacement de la date butoir au 23 Juin.

20/06 15:44

Appel infructueux : "il y a eu des complications".

21/06 16:29

Déplacement de la date butoir au 26 Juin.
Bouygues renvoie la responsabilité à Orange : "d'après Orange, le signal obtenu après réparation était de trop mauvaise qualité et il fallait donc rerouter les fibres"
Entre temps, on apprend que les clients Orange ont retrouvé un accès internet dans la résidence.

27/06 16:53

Déplacement de la date butoir au 3 Juillet.

04/07 19:02

Aucune intervention n'a finalement eu le lieu le 3 Juillet.
Information d'une nouvelle intervention le 10 Juillet.

17/07 16:56

Pas de nouvelle date d'intervention prévue.
Visiblement pas d'intervention le 10 Juillet.
Un voisin aurait eu l'information officieuse que le service ne risquait pas d'être rétabli de sitôt.

19/07 20:30

Déménagement du serveur CLUB1 à la Cyberrance (voir l'article correspondant)

Bilan et retours d'expériences

Voici un petit bilan à chaud de cette expérience :

Culpabilité et frustration

À la base de CLUB1, il y a la volonté d'expérimenter l'auto-hébergement en recyclant une connection à internet d'habitation particulière. En profitant notamment de la qualité et de la symmétrie du débit qu'apportent les connections via fibre optique. De part ce positionnement, les problèmes venant de cette connection sont hors de la portée de CLUB1.
Le vrai risque de ce genre de panne, est de faire naître un sentiment de culpabilité chez les personnes qui se sont impliquées dans le bon fonctionnement du serveur. Hors il est primordial dans un projet bénévole tel que le notre, que les membres se sentent bien.

Dans un premier temps, l'idée était donc de ne rien faire, d'attendre que la connection soit rétablie.
Seulement, plus la panne perdure, plus le sentiment de frustration grandit. Il faut dire que nous n'avions pas imaginé de telles durées pour des pannes qui englobent autant de personnes (toute une résidence). Le fait de n'avoir aucune date de rétablissement annoncée et, pire, qu'elle se déplace sans cesse, n'aide pas non plus à prendre des décisions.
C'est pourquoi nous avons mis autant de temps avant de changer de stratégie, de passer à l'action en déménageant le serveur à la Cyberrance.

Communication

C'est la double peine ! Non seulement nous perdons nos espaces de diffusion, mais également une partie de nos outils de communication et de prise de décision (notre Forum, Matrix et les Emails). Heureusement, nous avons une liste d'emails indépedants du serveur prévue à cet effet. Mais ce système de secours est archaïque : seul une poignée de membres peut écrire au reste du groupe.

💡 Piste de solution : Ticket concernant l'utilisation d'un service de mailing list externe sur notre forum.

Faire du matériel avec du vide

Pour nous qui tentons de rendre internet plus matériel aux yeux de ses usagers, le fait que des sites web ne soint pas toujours accessibles peut avoir un intérêt. Cela permet de casser la virtualité induite par le 100% disponible. Comme dans notre monde concret, où les choses se cassent, ferment, vieillissent. C'est exactement l'idée du site web du Low Tech Magazine, qui est alimenté par énergie solaire uniquement.

Actuellement, lorsqu'un site web est hors ligne suite à une telle panne, l'URL (par exemple https://club1.fr) nous amène vers le néant. Une page qu'il faut attendre indéfiniment. C'est frustrant, mais ça ne raconte pas grand chose. Si l'on pouvait envoyer un message d'erreur de notre cru, situant la panne et son contexte, cela participerait à rendre plus visible l'infrastructure d'internet. Et peut être que la frustration laisserai sa place à d'autre sentiments.
Cette idée pose cependant un problème technique, car pour pouvoir renvoyer un tel message, il faut... un serveur. 😅

👀 Voir le ticket correspondant sur notre forum.

Off line first

Perdre l'accès à ses données en ligne renvoie forcément à se questionner sur sa dépendance aux services en ligne. La coupure que nous avons vécue va pouvoir alimenter les réflexions à ce sujet. La philosophie Off line first prend tout son sens dans ces moments là. Elle nous rappelle qu'il est bon d'avoir ses fichiers en local pour se sentir équipé quoi qu'il arrive !

"Si on ne peut pas amener les fichiers aux membres CLUB1, il suffit d'amener les membres au serveur."

— Einstein 🐶

Une autre technique consiste à venir en personne voir le serveur pour y réccupérer ses données en mains propres. Et en plus, on gagne un petit café ! L'étape suivante c'est bien-sûr les clefs USB sur pigeons voyageurs. 🐦

🐸 Votre ressenti nous intéresse !!

Que vous soyez membre de CLUB1 ou non, on est curieux·se de savoir ce que cette panne de 6 semaines vous a fait ressentir, quelles émotions vous ont traversées pendant tout ce temps.

Pour cela, envoyez nous un email à 6semainessans@club1.fr !

⚠️ On souhaiterait repartager ces ressentis sur notre site web, mais si ça vous gêne, merci de l'indiquer dans l'email.

📫 Envoyer une carte postale au serveur

Et si vous voulez juste partager le bonheur de retrouver CLUB1 en ligne, c'est aussi possible. On vous propose d'envoyer une carte postale au serveur CLUB1 ! On la diffusera ensuite sur une page dédiée du site 🏤.

Voici sa nouvelle adresse :

CLUB1
93 Rue de la Liberté
93230 Romainville

Souvenirs de la journée Contre le Cloud

2023-04-01T13:00:00+01:00

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 ?

Emotions dans les espaces virtuels

2023-02-11T23:27:00+01:00

Un peu de contexte

Cet article est le fruit des réflexions d'une membre de CLUB1, Fae, 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 Fae 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 mes premières interactions avec des ordinateurs avaient été conditionnées 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".

Création d'un forum

2022-12-01T16:45:00+01:00

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.

Rapport d'incident #002 (18/11/2022)

2022-11-21T00:31:00+01:00

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.

Réunion 003

2022-10-13T13:00:00+01:00

Date de la réunion : le premier octobre 2022 à 16h15

Personnes présentes :
- Audrey
- Etienne
- Fae
- 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 Picasoft.

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

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 :

Étendre le certificat : le defaut est que ces sous.sous.domaines seront listés et retrouvables depuis le certificat de CLUB1.
Créer un nouveau certificat par sous.sous.domaines. C'est la solution choisie actuellement.
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 00514/06/2025
Réunion 00402/06/2024
Réunion 00313/10/2022
Réunion 00207/10/2021
La première réunion du club05/02/2020

Camp CHATONS 2022

2022-09-07T14:09:00+02:00

Du 18 au 22 Août 2022 s'est déroulé la deuxiè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.

"Logo CHATONS" par le collectif CHATONS sous licence CC-BY-SA 4.0.

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 !

Le Moulin avec le barnum où étaient organisés les repas.

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.

Préparation d'un déjeuner (l'erreur de cuisiner dans l'herbe sèche n'a pas été reproduite).

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 !).

Transfert d'email & Sender Policy Framework

2022-08-28T21:12:00+02:00

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 Le(s) serveur(s) 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 explication 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) :

apt-get install -y postsrsd
postconf -e "sender_canonical_maps = tcp:localhost:10001"
postconf -e "sender_canonical_classes = envelope_sender"
postconf -e "recipient_canonical_maps = tcp:localhost:10002"
postconf -e "recipient_canonical_classes= envelope_recipient,header_recipient"
systemctl reload postfix

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
Rapport d'incident #005La journée aux 30000 mails20/10/2024

Rapport d'incident #001 (07/08/2022)

2022-08-13T15:54:00+02:00

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 à UptimeRobot, 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 Bouygues 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.

La coupure bien visible dans le dashboard, indiquant que Prometheus n'a pas été en mesure de relever les métriques du serveur.

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.

Le syslog s'arrête brusquement avec une longue ligne de "caractères nuls" (raccourcie pour la capture).

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 :

439  2022/08/07 12:33:59  #0xca  Watchdog 2  Timer Interrupt - Assertion
440  2022/08/07 12:34:00  #0xca  Watchdog 2  Hard Reset - Assertion

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 Supermicro 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 Supermicro, 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.

$ sudo bmc-watchdog --get
Timer Use:                   SMS/OS
Timer:                       Running
Logging:                     Enabled
Timeout Action:              Hard Reset
Pre-Timeout Interrupt:       None
Pre-Timeout Interval:        0 seconds
Timer Use BIOS FRB2 Flag:    Clear
Timer Use BIOS POST Flag:    Clear
Timer Use BIOS OS Load Flag: Clear
Timer Use BIOS SMS/OS Flag:  Clear
Timer Use BIOS OEM Flag:     Clear
Initial Countdown:           900 seconds
Current Countdown:           877 seconds

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 :

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

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
```
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à.

La nouvelle documentation

2022-07-08T22:09:00+02:00

Page d'accueil de la version Web de la documentation.

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. Deuxièmement, 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. Finalement, il fallait que le language de rédaction de la documentation soit le Markdown, 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 ReadTheDocs, 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 Weblate ou encore de Certbot.

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 PDFLaTeX 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).

La toute première version imprimée de la documentation CLUB1. Elle n'est déjà plus très à jour, aussi bien au niveau du fond que de la forme.

Customisation à l'extrème

Bien que Sphinx ne soit prévu à l'origine que pour fonctionner avec reStructuredText, l'extension MyST recommandée par la documentation officielle, permet de lui ajouter le support de Markdown. 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 Markdown, MyST se voit forcé d'étendre la syntaxe de Markdown 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-informaticiens, 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-documentation !

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-documentation 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.

A new home

2022-05-31T12:18:00+02:00

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 système 256Go
├── bin
├── boot
├── dev
├── etc
├── home -> /ssd home
├── mnt
└── var

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.

/ssd home 1To
├── vincent
├── leila
├── fae
└── ...

🧱 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".

Workshop #003

2022-02-07T10:00:00+01:00

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

vidéo proj + tables + chaises + multiprises, telles sont les éléments de base d'un bon workshop de code

Un moment intense de résolution de bug PHP

Repas dans la cafet lors d'un moment ensoleillé

Un élément essentiel du Workshop

Merci à tout le monde d'avoir participé !

Un nouveau boitier

2021-12-19T15:58:00+01:00

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 MONDE DU 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. L'unité de hauteur s'appelle le "U".

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

Nicolas en train d'installer les composant dans le premier boitier de serveur.

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

À gauche, l'ancien boîtier, à droite, le nouveau.

On commence par percer un trou dans le fond de l'armoire pour faire passer les câbles.

Le placard.

L'opération chirurgicale est en cours.

En théorie, passer tout les composant dans un nouveau boitier n'est pas risqué. Mais tout changement apporte toujours son lot de suprise.

Vue du dessus : à gauche, les quatres disques durs; au milieu, une rangée de ventilateurs 80mm; tout en bas à droite, l'alimentation et juste au dessus, la carte mère Supermicro.

Transfert des disques durs.

Lancement du serveur dans sa nouvelle boîte. Vérification que tout fonctionne avant de l'installer dans son rack.

Le switch et son adaptateur rackable.

L'onduleur est placé à la base, car c'est l'élement le plus lourd (il est rempli de batteries).

L'arrivée du serveur dans son nouveau cadre de vie.

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€

Le rack dans son ensemble une fois le montage terminé.

La réduction de température observée après l'installation du nouveau boitier.

Discussion sur Github

Réunion 002

2021-10-07T15:18:00+02:00

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:

Fae
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, Fae 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:

Réunion de gestion du CLUB1
Atelier (partage de connaissance)
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 00514/06/2025
Réunion 00402/06/2024
Réunion 00313/10/2022
Réunion 00207/10/2021
La première réunion du club05/02/2020

Nouveaux réglages du serveur Matrix

2021-08-12T11:18:00+01:00

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

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.
Il est possible pour tous les utilisateurs d'ajouter des adresses email à leur compte pour pouvoir récupérer leur mot de passe.
Les prévisualisations d'URL vers les sites hébergés sur club1.fr devraient maintenant fonctionner.
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).
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

Le(s) serveur(s) email

2021-07-27T20:00:00+02:00

Depuis le début du projet CLUB1, il y avait l'envie de pouvoir utiliser des adresses email custom finissant par @club1.fr. Malheureusement, 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.

Envoyer un email...

echo "Le contenu" | mutt -s "Le sujet" destinataire@example.org

...ou bien à partir d'un fichier

cat contenu.txt | mutt -s "Le sujet" destinataire@example.org

Consulter ses emails

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) :

Ports IMAP

STARTTLS	SSL/TLS
143	993

Ports SMTP

STARTTLS	SSL/TLS
587	465

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

DAV

2021-05-11T00:00:00+02:00

Les différents protocoles WebDAV, CardDAV et CalDAV sont maintenant en place sur le serveur et n'attendent plus que de se synchroniser avec vos appareils ! Cette fonction réservée aux membres du club est le premier pas vers le kit d'outils numériques que l'on souhaite proposer aux utilisateurs sans avoir forcément de projet web spécifique.

Mais qu'est ce que c'est ?

Ce sont des protocoles standardisés qui permettent de synchroniser des données entre un serveur et un ou plusieurs appareils. Par exemple: des fichiers, des contacts ou des calendriers...

La définission d'une suite numérique Unix-compatible

La redéfinission des outils numériques est une des problématique que l'on souhaite soulever avec le projet Club1. Elle s'exprime lorsque l'on choisit quel standards rejoindre ou quelles applications installer. Pour cela nous avons dû faire une hiérarchie entre les fonctionnalités, la simplicité d'utilisation et surtout l'intérêt pédagogique des différentes options. Nous avons défini dans un texte théroique le kit d'outils idéal que nous souaiterions offrir aux membres du serveur. Dans cette définition transparait les aspects que nous avons souhaité prioriser:

la pédagogie (transparence des outils, demande d'investissement de la part des utilisateurs)
rejoindre des standards (libres) existants au maximums
la légèrté technologique (une interprétation du low tech)

Le nom Unix Cloud laisse entendre une interpolarité avec le compte utilisateur linux (UNIX) qui est mis à disposition des membres. La sensation que l'on souhaite engendrer est celle d'un ordinateur partagé (physiquement logé quelquepart) et non celle d'un nuage indéfini accentuant l'aspect magique et inconsistant d'internet.

Qu'est ce que ça donne au final

Le standard retenu est donc celui de WebDAV pour Web-based Distributed Authoring and Versioning, décliné en CardDAV pour les contacts et CalDAV pour les calendriers. Plutôt qu'une solution tout en un type NextCloud, cela laisse la possibilité aux utilisateurs de choisir quels clients utiliser au lieu de les enfermer dans une seul interface possible. C'est aussi et surtout la seule solution trouvée qui permet de garder une transparence avec les interfaces de connections plus ancectrales tels que les protocoles FTP ou SSH.

Mais la nécessité d'une interface de type logiciel ou application, bien que cela accroisse la sécurité, risque de réduire certains usages pour les utilisateurs les moins pantouflards. Il manque la possibilitée de se connecter à ses fichiers directement depuis un naviguateur web. Cette fameuse idée de pouvoir accèder à ses fichiers même sans avoir aucun de ses appareils est apparue pour beaucoup avec des outils comme Google Drive. C'est un tournant qui a participé à sortir l'informatique de son corp physique, du hardware et à participé à réduire internet à la simple naviguation sur le web et non à un agrégat multi-protocolaire.

CLUB1 over IPv6

2021-04-09T15:31:00+02:00

Bouygues Telecom nous ayant gentillement délégué un préfixe/60 IPv6, il nous est enfin possible de rendre accessible CLUB1 sur ce nouveau système de routage.
Pas grand chose à ajouter là-dessus, mis à part que tous les sous-domaines n'ont pas encore été mis à jour.

Mise à jour vers PHP 7.4

2021-03-04T13:30:00+02:00

J'ai enfin pris le temps de mettre-à-jour l'ensemble des virtualhosts apache vers PHP7.4. Ce n'était pas une tâche herculéenne mais comme PHP-FPM est utilisé à la place du simple apache-modphp, un petit script de mise a jour a été nécessaire.

En plus de passer à une nouvelle version de PHP, ce script modifie aussi la manière dont sont gérées les pools FPM. Précedemment Il y avait un pool par virtualhost, maintenant il y a un pool par utilisateur. Ce changement à été motivé par les raisons suivantes :

Simplifier la configuration

La principale raison qui nous a poussé à utiliser PHP-FPM en premier lieu était de pouvoir choisir avec quel utilisateur PHP s'éxecute pour chaque site. Le fait d'avoir un fichier par utilisateur permet de ne pas avoir à dupliquer le même fichier pour chaque virtualhost. Maintenant il y a simplement plusieurs virtualhost qui utilisent le même pool. Ce choix réduit légèrement la granularité des réglages de PHP, mais il permet au moins de conserver des réglages différents pour chaque utilisateur.

Simplifier la mise-à-jour vers les version de PHP suivantes

En plus de modifier la manière dont sont répartis les pools, la nouvelle configuration a aussi pris en compte la facilité de mise-à-jour. En effet le numéro de version n'est plus utilisé dans le nom de la socket que chaque pool écoute. De cette manière, il suffit de déplacer les fichiers de pools du dossier de l'ancienne à la nouvelle version de PHP. Alors que là pour tout mettre à jour il a fallu déplacer les fichiers de pool, modifier leur contenu ainsi que le contenu des fichiers de virtualhost.

Préparer le terrain pour Unix-cloud

Bon ce n'est pas encore du tout sur le point d'arriver, mais un jour, il y aura un serveur WebDAV sur CLUB1. Ce serveur sera accessible à tous les membres de CLUB1 et permettra de synchroniser des calendriers, des contacts, des notes et des fichiers. Dans un premier temps il n'y aura pas de WebUI, mais seulement une API. Concrêtement, ce service ne sera accessible que via des applications qui synchroniseront leurs contenu avec le serveur.

La raison pour laquelle on ne s'oriente pas vers un simple NextCloud n'est pas juste la recherche de la complexité. Le but est d'apporter une meilleure intégration avec le reste de nos services, à savoir, l'accès FTP et SSH. On veut pouvoir accéder aux même fichiers à la fois via le FTP et via la synchro WebDAV, de cette manière tout est à un seul endroit ce qui multiplie les possibilités.

Sauvegardes

2020-09-12T13:30:00+02:00

Jusqu'ici, il n'y avait aucune sauvegarde automatisée mise en place sur le serveur. Mais cela vient de changer. Avant, si l'appartemment de Pantin (lieu où est installé le serveur) subissait des dommages, il y avait un risque pour que le serveur soit détruit, et les préçieux fichiers des utilisateurs avec. Ou simplement lors d'une panne de SSD... Heureusement, Notre cher ADMINSYS à eu la bonne idée de mettre en place un protocole de sauvegarde.

Redondance

La base de la sauvegarde est la redondance des données, c.a.d. le fait que les données soient dupliqués sur deux supports. De cette façon, lorsque l'un ne fonctionne plus, il reste toujours l'autre. Ouf...

Mais encore faut il que les deux supports ne soient pas détruits en même temps. S'ils sont stockés au même endroit et que, par exemple, un incendie se déclenche, alors ce n'était pas la peine d'avoir dupliqué les supports...

C'est pourquoi il est astucieux d'utiliser une sauvegarde externalisée, c.a.d. qui duplique les données loin du lieu où se trouve le premier support.
La question qui se pose alors est la suivante : où mettre ce deuxième support ?

Plutôt que de construire un deuxième serveur uniquement dans ce but, qui ne se réveillerait qu'une fois par semaine, la nuit venue, pour acceuillir la sauvegarde hebdomadaire, on a voulu ré-utiliser un serveur déjà existant, qui voudrait bien accueillir nos sauvegardes. Encore un cas où les amitiés dans la vrai vie peuvent améliorer la sécurité informatique : En demandant gentillement, c'est un certain Sylvain qui a accepté de stocker nos sauvegardes sur son home-serveur parisien. Merci à lui !

Petite explication plus technique

Le logiciel a été choisi selon un cahier des charges assez précis. Il fallait en effet que tout soit automatisé et facile à configurer en CLI, que les sauvegardes soient incrémentales et dédupliquées et qu'il soit possible de répartir les sauvegardes sur plusieurs serveurs. En plus de ça il fallait que les bases de données (MySql et PostgreSql) soient sauvegardées de manière intelligente (c'est-à-dire via un dump et non une copie des fichiers binaire). Evidemment toutes ces exigeances n'étaient pas aisement satisfaites par un seul logiciel.

C'est le conseil d'un ami, Julien, qui nous a orienté vers la bonne piste. Il nous a suggéré l'utilisation du logiciel Borg. Celui-ci remplissait à lui seul une grande partie de notre cahier des charges, à savoir fournir des sauvegardes incrémentales, dédupliquées et réparties sur plusieurs serveurs en plus d'être doté d'une CLI très complète. De plus les sauvegardes sont chiffrées. Ce détail n'avait pas été pris en compte dans un premier temps mais il s'est avéré nécessaire pour les sauvegardes distantes en raison de la sensibilité des données qu'elles contiennent. Son seul point faible étant de ne pas gérer l'automatisation des sauvegardes, il fallait donc réaliser le script de sauvegarde soi-même. Cette manière de faire a l'avantage d'offrir plus de flexibilité mais elle est aussi plus délicate à mettre en place et, bien que le script ne soit pas si compliqué à écrire et que Borg fournisse toutes les commandes necessaire, un bug dans ce dernier entrênerait une perte de données conséquente en cas de panne.

Nous ne sommes evidemment pas les premiers à être confrontés à ce problème, c'est pourquoi certains ont eu la bonne idée de créer une surcouche d'automatisation pour Borg, intelligeament nommée Borgmatic. Celle-ci permet de gérer avec aisance plusieurs repos borg à l'aide de fichiers de configuration. Il suffit de créer un fichier par repo dans lequel l'ensemble des paramètres de la sauvegarde sont configurables, comme par exemple le nombre de sauvegardes quotidiennes, hebdomadaires et mensuelles conserver, les adresses des repos distants et, cerise sur le gâteau, les bases de données SQL à inclure dans la sauvegarde.

Ces deux logiciels étant bien-sûr tous deux inclus dans les dépots Debian, on préférera leur installation via apt plutôt que via pip comme suggéré dans leurs docs. La suite se résume à configurer Borgmatic selon les préférences de chacun.

Enfin, Borgmatic fournit une fonctionnalité supplémentaire qui n'était pas prévue dans le cahier des charges initial mais qui s'est également révélée être primordiale pour la fiabilité du système : sa capacité de branchement avec des systèmes d'alertes tiers. Nous avons donc mis en places des alertes à l'aide d'https://healthchecks.io, un excellent service open-source pour vérifier la santé de taches CRON avec lequel Bormatic s'intègre parfaitement. Le statut de nos sauvegardes peut ainsi facilement être vérifié à tout moment grâce au badge d'état des sauvegardes. De plus, healthchecks est capable d'envoyer des notifications via Matrix — le système de messagerie instantanné qu'on utilise chez CLUB1 — ce qui nous permet de recevoir les alertes immédiatement.

Gestion maison des DNS

2020-07-02T17:30:00+02:00

Cela fait environ 6 mois maintenant que le serveur CLUB1 gère ses propres DNS. Ce n'est pas du tout extraordinaire mais il y a toutefois quelques details intéressants à noter.

Pourquoi diable gérer ses DNS soi-même ?

Je vous le demande ! L'un des intérêts premiers était de réduire la force du lien qui nous retenait à notre registraire, qui, bien que fort sympatique, nous enlevait une certaine part d'indépendance. Nous somme évidemment toujours tributaire de cette tierce partie mais dans une bien moindre mesure. En effet c'est toujours lui qui reserve nos noms de domaine et informe les domaines de premier niveau du nom de nos authoritative name servers mais toute la gestion et la configuration des zones se fait maintenant sur notre serveur. Cela nous amène à la deuxième raison qui nous a poussée à réaliser ce changement : les possibilités illimitées de configuration et surtout de scripting de cette dernière.

Pour bien comprendre l'intérêt majeur que représente cette histoire de scripting il faut revenir aux fondations du projet qu'est CLUB1. Apprendre et s'amuser, tels étaient les maîtres-mots dès la première ébauche de cette aventure dans les vastes étendues de l'auto-hébergement. C'est donc par envie et avec entrain que nous nous engageons sur les chemins sinueux de l'installation manuelle en CLI plutôt que sur les grandes voies toutes tracées des solutions telles que https://yunohost.org. Ces dernières, fortement fréquentées et à juste titre, n'étaient effectivement pas compatibles avec notre but qui se focalisait bien moins sur la destination que sur le voyage en lui même. Mais le chemin aura beau être splendide, devoir y repasser sans cesse le rendra monotone. C'est là qu'interviennent les scripts. Ces petits bouts de code sont en fait des raccourcis qui permettent d'accélérer considérablement les portions longues et ennuyeuses du trajet pour pouvoir se concentrer sur l'exploration de terrains inconnus.

Un petit paquet de scripts a donc été réalisé, principalement pour la gestion des utilisateurs et de l'hébergement web, mais une parcelle, particulièrement rébarbative restait malheureusement impossible à scripter. Il s'agit comme vous pouvez vous en douter de la gestion des DNS. Pire encore, cette gestion, non contente de ne pas être automatisable, se devait d'être accédée par le biais d'une GUI qui, bien qu'à minima disponible de n'importe où car s'agissant d'une interface web, n'en requérait pas moins une souris pour son utilisation. Cet affront insupportable pour les intrépides aventuriers que nous étions fut sans nul doute l'élément déclencheur de l'éxpédition qui suivra.

Une première tentative

L'objectif était simple : supprimer cette inacceptable opération manuelle et de surcoît à la souris. La première approche envisagée consistait à s'appuyer sur l'API que mettait à disposition notre registraire. La présence d'une route update permettant de mettre à jour les champs de la configuration DNS nous confortant dans cette décision, nous entreprenons donc l'intégration de quelques requêtes HTTP au cœur de nos scripts. La réponse 200 ne se fait pas trop attendre et nous pouvons ainsi définitivement tirer un trait sur ce probème. Ou du moins c'est ce que nous pensions.

Quelques jours plus tard, nous remarquons qu'un de nos sous-domaines n'est plus accessible. En fait c'est une bonne partie de nos sous-domaines qui ne le sont plus. Une rapide inspection de nos zones DNS à partir de la GUI web nous indique effectivement que les entrées correspondantes n'étaient plus présentes. Nous les y ajoutons donc à nouveau mais le même schéma se reproduit à l'identique peu de temps après. Les appels API récemment ajoutés et utilisés sont rapidement supectés et une nouvelle lecture de la documentation de ces appels nous fait immédiatement comprendre notre erreur: la route que nous pensions pouvoir utiliser pour ajouter un sous-domaine permettait en fait de remplacer l'ensemble de la configuration de la zone par le contenu de la requête. Il n'éxistait donc pas de route pour ajouter un sous-domaine et plus gênant encore celle que nous utilisions avait un comportement imprédictible, car certains sous-dommaines était encore fonctionnels à l'issue de l'opération. Nous décidons donc de laisser tomber cette solution qui de toute façon n'aurait jamais apporté entière satifaction en raison de l'impossibilité de consulter facilement la configuration des zones.

La mise en place du serveur

La solution ultime d'une gestion in-house complète des DNS apparait alors encore plus attrayante maintenant qu'elle est la seule. Nous n'allons probablement pas revenir sur l'installation et la configuration du serveur bind9 puisque cela se résume finalement à un petit coup d'apt install et de quelques lignes de configuration de zones, ma foi pas bien méchantes. Un export plain text de l'ensemble de nos sous-domaines n'était pas étranger à la rapidité de la migration. Nous rendons enfin une dernière visite à l'interface web de notre registraire pour y remplacer les noms des authoritative name servers par le notre avant de la fermer en nous délectant de l'idée de ne plus jamais avoir à la rouvrir.

Une fois le script d'ajout de sous-domaine adapté à cette nouvelle architecture, la satifaction induite par cette solution est immédiate, tout fonctionne parfaitement, sans aucun accroc. Mais un défaut persiste : en réduisant notre délégation DNS de trois authoritative name servers à un seul, nous exposons nos services à une panne, puisqu'il suffit que cet unique serveur ne réponde pas pour pour que l'ensemble de nos sous-domaines soient inaccessibles. Dans notre cas ce n'est pas tellement dramatique car les services et les DNS sont gérés par le même serveur et si celui-ci est en panne alors plus rien n'est accessible de toute façon, mais nous décidons tout de même de ne pas prendre ce défaut à la légère et nous nous mettons donc en quête d'un service de réplication de DNS. Notre choix s'arrête sur https://buddyns.com, un service gratuit qui nous apporte exactement ce dont on avait besoin. Quelques modifications de fichiers de configuration plus tard, la réplication est fonctionnelle et nous pouvons enfin dormir sur nos deux oreilles.

Ajout d'un serveur Matrix

2020-03-15T10:19:00+01:00

Bien que le serveur Matrix soit en place depuis plus d'un mois, la veritable nouvelle est l'arrivée du client element à l'adresse https://riot.club1.fr

Qu'est ce que c'est que ça ?

C'est un outil de communication permettant de faire de créer ou rejoindre des espaces de discussions (rooms) pour y échanger des messages, fichiers, appels audio ou vidéo.

Notice d'utilisation de Matrix

Serveur / Clients

Il faut bien distinguer le protocole, Matrix, qui s'installe sur des serveurs, des divers clients, parmis lesquel element, qui sont les interface permettant de se connecter à un ou plusieurs serveurs.

Il n'existe donc qu'un seul protocol Matrix, mais plusieurs clients, disponibles sur différentes plateformes.

Le plus connu, Element est disponible en tant qu'interface web (c'est celle que nous utilisons sur le serveur), mais aussi en tant qu'application mobile : Element. On peut également installer différents logiciels, on notera le client Spectral, bien plus léger que Element, à installer sur différentes plateformes.

Pourquoi avoir installé une instance Matrix ?

La grosse différence entre le projet open source Matrix, par rapport aux entreprises que sont Slack et Discord, réside dans son potentiel décentralisé. Un peu comme pour les emails, il est possible d'avoir une adresse reliée à un serveur de son choix (gmail.com, yahoo.com, riseup.net), qui pourtant peut communiquer avec les autres.

Lorsque l'on se crée un compte Matrix, il faut donc choisir, en plus d'un identifiant, un serveur.

A la différence d'une adresse email, le choix du serveur peut tout de même avoir une influence sur l'accès à certaines discussions. En effet, certaines rooms peuvent limiter leur accès ou leur découverte aux utilisateurs inscris sur le même serveur.

Un serveur Matrix peut donc être utilisé en circuit fermé, pour une entreprise par exemple, ou comme un noeud d'un réseau plus large. Cela peut aussi être les deux à la fois.

Sur le serveur Club1, le choix à été de laisser en libre accès le serveur Matrix. Cependant, il existe des conversations privées réservées aux membres ou à l'administration. C'est une façon de soutenir le projet Matrix et de favoriser les rencontres possibles entres les utilisateurs du serveur et les visiteurs.

Controller le stockage des données sur le serveur pour les rooms locales
De soulager le serveur "officiel" Matrix.org et de garantir son indépendance face à quoi qu'il puisse advenir.

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

La première réunion du club

2020-02-05T14:23:00+01:00

Date et lieu

Le 4 février 2020 à Pantin.

Personnes présentes :

Fae
Nicolas
Vincent

Le 4 février, à été organisé à Pantin, la première réunion des membres fondateurs du Club.
Le but étant de définir les objectifs possibles pour le serveurs et de sonder les intérêts de chacuns dans les divers orientations possibles.

Les points clefs abordés étaient à peu près ceux là :

Mesurer la distance qui nous sépare du label des Chatons https://chatons.org
Evoquer les améliorations de sécurité possibles et en estimer le coût en temps/argent/motivation
Définir la structure administrative du serveur, les différents status de membres, etc...
Planifier la création du site web
Discuter de l'implantation d'un serveur Matrix

Toutes les réunions du Club :

Réunion 00514/06/2025
Réunion 00402/06/2024
Réunion 00313/10/2022
Réunion 00207/10/2021
La première réunion du club05/02/2020

Journal de CLUB1

Comment j'ai eu un rdv médical grâce à une tâche CRON

Un peu de contexte

Désert médical

frappe chirurgicale

Écriture d'un Scénario

Équipe de choc

Chronique des titans

Moi aussi je veux trop avoir une tâche CRON !!!

curling de date

Éviter de spammer

Assemblage

Oasis is good

UNIX vibe

Pour aller plus loin

The map is the territory

Le blog d'Arthur Pons

Serveur tildes

Réunion 005

Date et lieu

Personnes présentes :

1 - Changement de la License de la documentation

Pour changer la License :

Et pourquoi pas d'autres licenses ou d'autres options ?

2 - Ajout de RAM

Est-ce qu'on en a besoin ?

Qu'est ce que ça coûte ?

Mais au fait, combien est ce que le serveur consome ?

Qu'est ce qu'on fait ?

Mesures

Quelques images de l'opération

3 - Point sur l'utilisations des outils internes

Participation au site Web

Toutes les réunions du Club :

Rapport d'incident #005

La cause

La Découverte

Effet secondaires

Conclusion

Tous les articles CLUB1 concernant les emails :

Réunion 004

Date et lieu

Personnes présentes :

1 - Inclusivité et légitimité

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

Permissions : qui peut faire quoi ?

A quoi peut servir la newsletter

Le forum et la catégorie ticket

Edition du site web

Journal de bord

La doc

La bibliothèque

Conclusion :

3 - Point sur le serveur Matrix

Résumé de la problématique

Conclusion

4 - On parle des prochains événements

Toutes les réunions du Club :

Soirée d'inauguration du service radio

Un nouveau service

Radio CLUB1

Et si tout le monde avait sa propre radio ?

Plus de photos !!

Émission à ré-écouter

Le diplôme d'Alix

Le Catalogue du Meatspace

Outdoor computer Club

Data foire

Notre bilan

Les +

Les -

Bonus : la captation 📺

Migration de Ubuntu à Debian (Phase 3)

Étapes de la migration

Dernières préparations

Installation de Debian

Les problèmes commencent

Enfin fini !

Tous les articles de cette migration

Migration de Ubuntu à Debian (Phase 2)