AlternC est un projet collaboratif dont l’élément de base constitue un logiciel libre de gestion d’hébergements mutualisés pour Debian.

Ce projet (sous GPLv2+) se veut facile à installer et à utiliser, s’appuyant uniquement sur des logiciels libres.
Il contient un système d’installation et de configuration automatique, ainsi qu’un panneau de contrôle accessible par le web, pour la gestion des utilisateurs et des services orientés web.
Le projet s’adresse à un public faisant de l’administration système et souhaitant déléguer les actions de base d’un hébergement web.

On peut le comparer à des solutions telles que ISPconfig, cPanel, Plesk, Froxlor…

Après de nombreuses années la version 3.5 est arrivée début 2025 et se prépare à la suite, on se propose de rattraper ce temps perdu.

Sommaire

• Qui est derrière AlternC ?
• Enfin une version 3.5
  • Un peu de contexte historique
  • L’objectif de cette version
  • L’histoire récente de la 3.5
• Les changements depuis la 3.3
  • Des nouveautés diverses et variées
  • De nombreux correctifs
• Un écosystème
  •  Des plugins
  •  Un générateur de paquet Debian
  • Tout un ensemble de plugins
• Comment installer ou mettre à jour ?
• Participer
  • Ensuite ?
  • Le code
  • Les traductions
  • Des services à disposition de la communauté

Qui est derrière AlternC ?

Le projet est porté par différentes structures tant associatives que professionnelles. Nous n’établissons aucune statistique, toutefois, portée à notre connaissance, on peut citer dans un désordre alphabétique :

• domainpublic avec environ 500 comptes également ;
• globenet ;
• infini  ;
• koumbit qui représente environ 500 comptes pour 2000 domaines et est contributeur historique ;
• lautre.net compte un peu moins de 1000 adhérents et plus ou moins autant de comptes AlternC ;
• marsnet avec un peu moins de 200 comptes pour 500 domaines et plus de 200 listes de diffusion ;
• neuronexion ;
• octopuce avec environ 80 instances déployées, contributrice historique, héberge une partie de l’infrastructure du projet ;
• ouvaton avec environ 6000 (sous-)domaines actifs ;
• webelys contributeur et animateur de la communauté.

Enfin une version 3.5

Un peu de contexte historique

Entre 2018 et fin 2024, la communauté a eu du mal à s’organiser pour fusionner et proposer une cohérence de développement. Durant cette période, il était alors recommandé d’utiliser une version maintenue avec grande détermination par koumbit.

De nombreux correctifs ont été proposés dans leur bifurcation amicale. C’était de fait la version la plus avancée et active de ces dernières années. On peut noter également que d’autres membres de la communauté disposaient de branches locales. Par exemple, Octopuce maintenait une version 3.3 avec un portage partiel pour fonctionner sur les anciennes versions de Debian.

Sans être exhaustif dans tous les développements épars, on peut dire qu’on s’était tous un peu dispersé. Il était difficile de répondre à des besoins opérationnels immédiats et de prendre le recul nécessaire pour une intégration communautaire saine.

On était arrivé à une situation de déperdition de temps, d’énergie, d’envie conséquente.

L’objectif de cette version

Au fil des années, l’objectif principal de la 3.5 a fortement évolué. De l’apport initial d’innovations diverses nous nous sommes recentrés sur l’essentiel. C’est-à-dire :

• fournir une version unifiée et rationnelle de toutes les variantes connues ;
• gérer les versions stables (du moins plus récentes) de Debian.

L’histoire récente de la 3.5

La communauté AlternC, pour diverses raisons, a fortement tardé pour absorber tout ce retard. Au cours de ces douze derniers mois, on notera les évolutions suivantes :

• Une 3.5~RC2 absorbant le retard avec les apports de koumbit ;
• Une 3.5~RC3 absorbant le retard avec Debian et fournissant la compatibilité avec Bookworm ;
• Une 3.5.0 proposant une version stabilisée compatible de buster à bookworm ;
• Une 3.5.1 proposant un correctif lors de la mise à jour et une compatibilité avec des changements avec roundcube ;
• Une 3.5.2 proposant d’autres correctifs mineurs, plus une gestion de SFTP, réparation de la compatibilité du module awstats, maintenir les configurations DKIM/SPF ;
• Une 3.5.3 proposant des correctifs mineurs, une meilleure gestion des bases de données, la réparation des configurations DNS manuelles, une meilleure prise en charge des versions PHP.

Il est prévu d’autres versions mineures pour prendre en compte les erreurs restantes.

Toutes ces versions ont été diffusées sur le dépôt officiel AlternC ou bien directement sur le dépôt github

Les changements depuis la 3.3

Des nouveautés diverses et variées

Sans faire une liste à la Prévert, notons les points suivants :

• La gestion de Debian Buster à Bookworm ;
• La gestion de PHP de 5.6 à 8.x ;
• L’amélioration de la gestion des mails avec une meilleure prise en charge de DKIM, SPF et DMARC ;
• La gestion de l'autodiscover et autoconfig pour les logiciels de messagerie ;
• La gestion de SFTP en plus de FTP(S) ;
• La capacité de gérer des domaines DNSSEC ;
• Un nouveau thème plus moderne et personnalisable ;
• La définition de politique de validation de mot de passe.

De nombreux correctifs

Les nouveautés ne sont pas le cœur de cette version, on a principalement travaillé sur la stabilisation et la mise en place de correctifs divers et variés commme :

• le report des correctifs pour roundcube pour buster et sa gestion jusqu’à bookworm ;
• l’intégration de phpmyadmin jusqu’à bookorm ;
• des protections CSRF dans les nombreux formulaires ;
• des ajustements dans les scripts de type cron et alternc.install ;
• la prise en charge des fonctionnalités d’apache 2.4 ;
• la prise en charge conditionnel du mode SSL pour apache (permettant des frontaux comme nginx, haproxy…) ;
• des empreintes de mot de passe plus solide — pour entre autres — dovecot ;
• des correctifs pour s’aligner sur les évolutiosn de mariadb (longueur des tables, nommages…) ;
• simplification du javascript pour le panel ;
• support progresif de systemd ;
• la bascule progressive du système de traduction vers weblate.

Un écosystème

AlternC ne se résume pas à un projet avec une structure monolithique. Il s’agit d’un écosystème avec nombre de plugins.

 Des plugins

La version 3.5 apporte de nouveaux plugins, pour faciliter leur évolution. Certaines fonctionnalités ont été extraites ou adaptées en ce sens :

• ACME qui extrait la génération des certificats SSL avec Let's encrypt et le protocole ACME
• nginx-ssl une seconde approche pour gérer les certificats SSL et offrant un frontal nginx pour gérer https
• mailman un gros travail de fond a été réalisé pour permettre le passage de maiman2 à mailman3 tout en assurant une retro compatibilité correcte.

 Un générateur de paquet Debian

AlternC est maintenant fourni avec un générateur automatique de paquets Debian.

Ainsi on facilite l’arrivée de nouvelle proposition sous forme de plugin. Il est n’est pas nécessaire d’intervenir sur l’intégralité du projet AlternC et on peut se concentrer sur une fonctionnalité donnée.

Dès l’intégration du depot dans l’organisation AlternC, le plugin sera automatiquement pris en compte et ses paquets Debian prêts à l’emploi via :

• les releases github
• le dépôt officiel du projet
• la mise à disposition des paquets expérimentaux ou dits nightly

Tout un ensemble de plugins

Au-delà d’AlternC en soi et des plugins listés avant, on peut trouver à différents niveaux de maturité :

• une CLI pour piloter depuis son terminal les espaces utilisateurs
• le transfert de courriel SRS pour assurer des transferts de courriels respectueux de SPF et DKIM
• un proxy agnostique pour rediriger de façon transparente vers un autre service local ou distant, pratique lors d’un changement d’hébergement par exemple
• la liste de diffusion sympa pour supporter le gestionnaire de liste de diffusion Sympa
• des métriques diverses et variées pour avoir des informations normalisées du comportement de la plateforme
• php-fpm pour supporter toutes les versions PHP connues chez Debian

On peut trouver l’ensemble des plugins AlternC depuis son dépôt : https://github.com/AlternC/

D’autres outils sont mis à disposition également sur la forge communautaire du projet

Comment installer ou mettre à jour ?

Si vous avez déjà un AlternC 3.3.x et que vous voulez migrer vers la 3.5.x, faites une sauvegarde complète et suivez la documentation fournie sur notre aide en ligne

Il est important de prendre en compte les informations suivantes :

• La version 3.3 n’est plus officiellement supportée et cesse de fonctionner au-delà de Buster ;
• La version 3.5.x supporte Buster et Bookworm ;
• Le support de Bullseye (Debian 11) n’est pas fourni, cela peut fonctionner uniquement le temps de la mise à jour système.

Participer

Ensuite ?

Le cycle de la 3.6 n’est pas encore planifié. Parmi les idées en reflexion nous avons :

• réduire le support à deux versions stables de Debian (bookworm/trixie)
• l’amélioration de la qualité du code de base (bash et php) à l’aide de diverses CI/CD
• la finalisation du système de traduction pour le core et les plugins via weblate

Le code

L’ensemble du code du projet est actuellement hébergé chez github.
Toute personne est la bienvenue. Vous pouvez proposer un nouveau projet de code, remonter des bogues, suggérer des améliorations, traduire, communiquer…

Nous profitons également de cette nouvelle version pour utiliser le nommage “main” pour la branche principale. C’est plus en adéquation avec notre code de conduite informel et donne également une cohérence sur l’ensemble des projets.

Les traductions

Toutes personne souhaitant traduire dans sa langue est la bienvenue. Vous pouvez participer via le service weblate. Nous gérons actuellement principalement trois langues : le français, l’anglais et l’allemand. Nous avons d’autres langues disponibles pour lesquelles un peu d’amour est nécessaire.

Des services à disposition de la communauté

En complément, le projet AlternC met à disposition divers services à la communauté. Le principal est le service de DNS secondaires disponible sur le site dédié https://www.alternc.net/
Ce service permet de synchroniser ses zones sur deux DNS secondaires depuis ses instances AlternC.

Un autre service est disponible en mettant à disposition des serveurs virtuels jetables pour tester des développements sur différentes distributions Debian (de Jessie à Trixie).

Présentation

Le Frido est un livre de mathématique libre initialement destiné à l'agrégation, mais devenu généraliste. En supposant connue une théorie intuitive des ensembles, ça va jusqu'aux martingales, distributions, extensions de corps, etc. Avec toutes les démonstration intermédiaires (modulo les 981 entrées restantes dans ma liste de choses à faire).

Les résultats sont classés par ordre logique mathématique : chaque démonstration ne s'appuie que sur des résultats énoncés et démontrés plus haut. C'est loin d'être l'ordre pédagogique.

L'extension guilietta donne le reste de ce que je sais en math : groupes de Lie (l'objectif est de donner la liste des représentations de ).

Nouveautés 2025

Le bouquin vient de dépasser les 3000 pages cette année.

• Théorème de Banach-Alaoglu.
• Démonstration du fait que le système trigonométrique est une base hilbertienne.
• Fonctions analytiques entre espaces de Banach. L'objectif sera d'énoncer et démontrer le théorème d'inversion locale. Le seul doc que j'aie trouvé est celui-ci. Sinon ChatGPT se débrouille assez bien.
• Structure de groupe de Lie sur un sous-groupe fermé (ça c'est dans une extension)
• Dans le même ordre d'idée : modification de la définition d'une variété pour accepter des cartes à partir d'ouverts de n'importe quel espace vectoriel normé (et non seulement de ). Formellement, ça rend correcte pour un groupe de Lie l'idée de prendre des cartes depuis l'algèbre de Lie. En pratique, ça permet aussi de prendre des cartes depuis le produit tensoriel des fibres pour prendre le produit tensoriel de fibrés vectoriels. Si on n'accepte que des cartes depuis des ouverts de , il faut prendre un isomorphisme (pas canonique) entre et le produit tensoriel, et montrer qu'en réalité rien ne dépend de ce choix. L'inconvénient est qu'on ne peut plus parler de l'ensemble des cartes.

Sommaire

• • Mon flot de rédaction
    • ChatGPT
    • Mon activité sur Stack
      • Zorn et existence d'un max pour tout ensemble fini
      • Connexité
    • Remarque pas très gentille
  • Citations
  • Plagiat massif
  • Pourquoi citer ses sources ?
    • Le cas particulier chatGPT (1)
    • Le cas particulier chatGPT (2)
    • Le cas particulier chatGPT (3)
  • Images de couverture
  • yanntricks
    • L'inconvénient
  • Vente
  • Problème d'accès aux ressources documentaires
  • Que faire ? Tout accepter ?

Mon flot de rédaction

Quand j'écris une démonstration, soit je cherche un peu par moi-même, soit je cherche sur internet. Quand je trouve un texte qui me semble correct, je commence par rédiger sur du papier de brouillon; la plupart du temps j'ajoute beaucoup de détails par rapport à ce que je lis. En particulier, j'écris sur mon papier de brouillon les labels (dans le Frido) des résultats à citer.

Quand ma démonstration est terminée, je copie des feuilles vers LaTeX. Chaque démonstration passe donc par (au moins) deux rédactions personnelles : une de l'écran vers le papier de brouillon et une du papier vers LaTeX.

ChatGPT

Ce flot est valable également quand je demande à ChatGPT. Ce dernier est maintenant crédité comme source dans neuf démonstrations. Parfois seul parfois en collaboration avec moi ou d'autres sources. Je ne copie-colle jamais un résultat.

Avant de demander à ChatGPT, je regarde d'abord pas mal sur internet ; et je me demande parfois pourquoi d'ailleurs.

Mon activité sur Stack

Lorsque je ne trouve pas une démonstration en ligne, je demande souvent sur Stack. Et parfois je n'ai pas de réponses satisfaisantes.

Zorn et existence d'un max pour tout ensemble fini

Je demande si il est vrai que tout ensemble Dedekin-fini totalement ordonné a un maximum.

À mon avis la preuve donnée par Asaf Karagila (et qui a 5 votes positifs) a au moins un trou ; j'explique dans les commentaires ce qui ne me va pas. Si vous avez une idée de comment compléter, n'hésitez pas.

Connexité

Voici une question qui lie connexité et espaces totalement normaux. Je ne suis pas certain que l'énoncé soit même vrai.

Si vous êtes douées en topologie, lâchez-vous.

Remarque pas très gentille

À chaque fois que je dois poser une question sur Stack ou à ChatGPT, je ne peux pas m'empêcher de penser que soit je suis nul en recherche sur Internet (c'est le cas), soit l'ensemble de la communauté mathématique a échoué à mettre en ligne des résultats importants.

Citations

Le Frido cite toutes ses sources, théorème par théorème. À côté de chaque énoncé, il y a une liste des endroits où j'ai trouvé des informations utiles soit pour l'énoncé soit pour la démonstration.

La référence [1] signifie qu'il y a de l'invention personnelle non triviale. C'est moi qui ai inventé (une partie de) soit de l'énoncé, soit de la preuve.

Plagiat massif

Dans le monde de l'enseignement académique, le plagiat massif est la norme. Par exemple, le dernier en date que j'ai utilisé cite cinq livres en avouant ouvertement que ce n'est pas complet. Et bien entendu, il ne dit pas quelle partie de son texte vient d'où.

En ne remontant ma bibliographie pas plus loin que juillet 2025, je trouve celui-ci qui ne cite aucune source. Si un étudiant avait fait ça dans un mémoire de licence, il aurait été engueulé comme du poisson pourri.

Les mathématiciens professionnels ne citent pratiquement jamais Wikipédia ou math.stackexchange.com. Le Frido oui.

Pourquoi citer ses sources ?

La bibliographie sert à remercier la personne qui a fait l'effort de me rendre l'information disponible.

En ce qui me concerne, la bibliographie ne sert pas à :

1. permettre de remonter à l'inventeur original d'un énoncé ou d'une technique
2. permettre au lecteur d'aller plus loin
3. donner de la crédibilité à un résultat.

Développons

1. Les résultats présentés dans le Frido ne sont pas de la recherche toute fraîche. Il est illusoire de remonter la chaîne de la source de la source de la source pour trouver l'idée originale.
2. Si le lecteur veut aller plus loin, il possède le même internet que moi. Il est de très rare que j'utilise une source qui ne soit pas en ligne.
3. Ce qui fait la crédibilité d'un résultat, c'est la démonstration. Si la lectrice veut se convaincre qu'un résultat est vrai, elle peut soit faire la même recherche que moi sur le même internet, soit lire la preuve donnée. Le Frido n'est pas un ouvrage de vulgarisation. La lectrice est supposée être là pour lire et comprendre les démonstrations.

Le cas particulier chatGPT (1)

chatGPT n'est pas un cas particulier.

Si c'est l'entreprise OpenAI qui a fait l'effort de mettre une information disponible pour moi, c'est elle que je cite. C'est bien l'entreprise OpenAI qui a la citation, pas chatGPT lui-même en tant que "personne". Cela est à mettre en relief par rapport au cas de cette réponse où je cite bien la personne qui a écrit et non l'entreprise derrière stack.

Que OpenAI elle-même soit incapable de citer les sources sur lesquelles elle base sa réponse est — dans mon contexte — un non-problème. En effet, je serais moi-même incapable de vous dire d'où je connais le paradoxe de Zénon, la définition de la continuité ou la démonstration de la formule . Ce sont des informations qui sont codées dans mon cerveau. Je suis capable de vous les dire, mais pas de faire de citations de mes sources.

Le cas particulier chatGPT (2)

Ce n'est pas un cas particulier.

En remontant ma biblio jusqu'à janvier 2025, je trouve cet intéressant exemple : ma question sur math.stackexchange à propos de variétés analytiques.

Voici l'ordre dans lequel se sont passées les choses.

1. Je me pose une question de math qui me semble assez naturelle.
2. Je ne trouve rien sur internet.
3. Je pose la question sur math.stackexchange
4. Je n'ai pas de réponses.
5. Je pose à chatGPT un copié-collé de ma question qui est sur Stack.
6. chatGPT me donne une réponse correcte.
7. Je rédige la réponse de chatGPT et la publie dans Giulietta.

Question : à qui suis-je supposé donner le crédit de la démonstration ?

Ma réponse : à OpenAI.

Au final, la communauté mathématique a échoué à mettre en ligne un énoncé et une démonstration correcte de «tout groupe de Lie est analytique».
Ensuite la communauté mathématique a échoué à répondre à une question sur stackexchange.
Au final c'est un échec retentissant pour l'ensemble de la communauté mathématique.

En réalité la question de savoir si OpenAI mérite une entrée dans ma biblio est une question très accessoire. Il y a un problème de publication scientifique largement en amont.

Le cas particulier chatGPT (3)

Bon. ok. ChatGPT est un cas particulier. Le plus souvent quand je demande à chatGPT c'est que j'ai déjà fait des recherches sur Internet et souvent également demandé sur stack sans avoir de réponses utiles.

Donc quand je cite chatGPT, c'est un signe que l'ensemble de la communauté mathématique a échoué dans sa mission de mettre la connaissance correctement en ligne.

Mettons une mathématicienne (nommons-la Alice) ayant écrit un résultat dans un livre privateur. Supposons qu'elle retrouve ce résultat dans le Frido avec chatGPT comme source. Est-elle en droit de râler ?

Étudions la question.

1. Au niveau du Frido, tous les résultats sont établis depuis plus d'un siècle. Aucune de mes sources n'a probablement inventé aucun des résultats présentés.
2. Si elle avait publié le PDF de son bouquin en ligne plutôt que de le vendre à un éditeur, elle aurait sans doute eu la citation. Elle a échangé de l'argent contre de la visibilité (j'assume : je dis bien qu'elle a reçu de l'agent pour être moins visible).
3. OpenAI l'a-t-elle volé ? Peut-être. Son éditeur pourra pleurnicher devant un tribunal.
4. Son salaire est payé par mes impôts. Donc la moralité de publier un livre privateur est en soi déjà une question pas du tout triviale.

Bref.

Qu'il y ait un problème dans la chaîne "livre privateur -> openAI -> moi" est possible.

Mais le vrai problème de mon point de vue est largement en amont. Pourquoi il y avait un livre privateur à la base ?

Images de couverture

Les images de couverture proviennent de Pepper et Carrot.

yanntricks

On parlait de tikz dans un fil sur typst.

Le Frido fait ses figures avec yanntricks, un module python basé sur sage. Le principe est qu'on décrit sa figure en python, puis le code Tikz est généré automatiquement. Pratiquement tout ce qui est calculable en python/sage est traçable.

Il y a deux idées de base :

• Tout est ramené à des points et segments de droites. Écrivez en python une fonction ma_fonction qui prend un réel et retourne un point, passez cette fonction au constructeur ma_courbe=CustomGraph(ma_fonction), et hop ma_courbe.code_tikz() est le code tikz d'une série de segments de droites qui donnera votre courbe.

• Le code Tikz créé contient du code LaTeX écrivant dans un fichier la taille des boîtes (bounding box) des éléments LaTeX que vous insérez, de telle sorte qu'en deux passes, yanntricks soit au courant des tailles (ça marche avec tous les compteurs internes de LaTeX; vous pouvez donc tenir compte du numéro de la page courante dans votre image). Cela permet de faire :

C = Cirle(Point(2,1),4)  #cercle de centre (2,1) et de rayon 4
C.put_mark($\omega-x$, 30) # placer $\omega-x$ sur le cercle à un angle 30 degrés
C.tikz_code()

Le code tikz produit mettra automatiquement à la bonne place pour que le centre de la boîte soit sur le rayon qui fait un angle de 30 degrés avec l'horizontale, et assez loin pour que la boîte ne coupe pas le cercle.

Très peu de changements sont nécessaires pour générer le code pstricks ou tikz ou quoi que ce soit d'autre : seulement les droites, points et quelque trucs de base. Pas besoin des cercles, courbes, etc.

L'inconvénient

L'inconvénient de yanntricks est que le code est une usine à gaz que j'ai développé par à coups pendant une dizaine d'années — sans linter, sans annotations de types et sans rigueur. En réalité, le prix du billet d'entrée est absurdement élevé. Tellement que moi-même je ne m'y aventure plus.

Vente

Extrait du règlement (dans le rapport), page 42) de l'agrégation :

Durant tout ce temps, elles ou ils ont libre accès […] à leurs
propres ouvrages. Seuls sont autorisés les ouvrages avec un numéro ISBN et jouissant d'une véritable
diffusion commerciale. […] une « diffusion commerciale avérée » est tout autant importante.
[…] Cette restriction est motivée par le principe d'égalité des candidats : les ressources documentaires autorisées doivent être facilement accessibles à tout candidat au concours.

En résumé :

1. Si une ressource est gratuite, ce n'est pas assez cher pour être facilement accessible à tous les candidats.
2. Les livres qui ne sont plus vendus (et qui ne sont donc disponibles qu'en seconde main) ne sont pas autorisés.

Truc marrant : le point 1 est bizarre, mais est appliqué, tandis que le point 2 est très raisonnable mais n'est pas appliqué. C'est ce qui arrive quand on écrit un règlement en ayant un cas très précis en tête et qu'on ne se rend pas compte que ce qu'on écrit a une portée beaucoup plus large que le seul cas auquel on pense.

Et le pire est que ce règlement n'interdit même pas ce livre qui, si j'ai bien compris, est exactement ce qu'on avait envie de refuser au départ : une pure liste de définitions et d'énoncés de théorèmes classés par leçon.

Avis si vous travaillez dans une prépa agreg : tapez un plan par leçon (avec la démonstration des deux développements), publiez-là sur thebookedition et ensuite bachotez seulement ces leçons avec vos étudiants.

Bref, pour faire plaisir au règlement de l'agreg, le Frido est en vente :

• volume 1 du Frido 2025 (29,73 €)
• volume 2 du Frido 2025 (29,73 €)
• volume 3 du Frido 2025 (31,63 €)
• volume 4 du Frido 2025 (24,77 €)

Total : 115,86 euros.

Problème d'accès aux ressources documentaires

Ironie mise à part, je trouve que l'objectif est évidemment très louable :
« principe d'égalité des candidats : les ressources documentaires autorisées doivent être facilement accessibles à tout candidat au concours.»

Par contre force est de constater que l'accès aux ressources est encore très inégalitaire.

• certaines candidates arrivent avec des valises entièrement remplies de livres. Probablement un millier d'euros de livres. Toutes les candidates ne peuvent pas facilement se procurer ça.
• l'acceptation des livres qui ne sont plus disponibles qu'en seconde main (voire plus du tout) crée une forte inégalité entre les candidates qui ont accès à une bibliothèque universitaire et les autres.

Que faire ? Tout accepter ?

Finalement, si tout était accepté sans aucune restriction, certes certaines auraient accès à quelque documents de plus que les autres. Mais il y a tellement de ressources disponibles que le petit plus qu'un candidat pourrait se procurer n'a aucune chance d'être décisif.

Cette dépêche présente Bandcamp, une plateforme de distribution de musique qui fait figure d'alternative artist-friendly parmi les mastodontes du secteur, ainsi que deux plateformes alternatives, Subvert et Nina, qui se sont montées récemment en réaction aux craintes liées à la situation de monopole et au rachat de Bandcamp.

Bandcamp

Parmi les plateformes de distribution de musique en ligne, Bandcamp fait figure d'exception. Contrairement à Deezer, Spotify ou Tidal, il ne s'agit pas d'une plateforme classique où on streame de la musique en continu et où on partage des listes de lecture. C'est un magasin en ligne où les artistes peuvent exposer leur contenu et le proposer à la vente (numérique ou physique, merchandising, etc.).

Les utilisateurs peuvent acheter avec ou sans compte et offrir des albums à des amis. Un compte permet de garder une trace de ses achats, les exposer pour les faire découvrir, et les streamer via une appli mobile, ainsi que de suivre des artistes pour être notifié des sorties et recevoir leurs messages, ou d'autres utilisateurs pour être notifié de leurs achats.

Les artistes peuvent choisir de laisser leurs albums en écoute libre, et c'est souvent le cas, même si certains ne permettent l'écoute que d'un ou deux morceaux dans un album. L'achat d'un album est principalement un acte de soutien de la part des fans.

Bandcamp bénéficie d'une excellente image auprès du public. Elle est reconnue pour pratiquer des tarifs raisonnables pour les artistes. Lors du COVID, la plateforme a instauré le Bandcamp Friday, pendant lequel elle ne prélève aucun frais (hors frais bancaires). Elle continue de proposer un Bandcamp Friday de temps en temps.

En mars 2022, Bandcamp a été revendue à Epic Games (créateurs de Fortnite), qui l'a revendue un an et demi plus tard à Songtradr qui a licencié la moitié des 118 employés, notamment ceux impliqués dans la création d'un syndicat. Cela suscite des craintes chez les artistes et les utilisateurs quant à la pérennité du modèle. Bandcamp deviendrait-t-elle evil ?

Des alternatives se montent.

Subvert : le modèle coopératif

Crée en août 2024 sur un modèle coopératif, Subvert prévoit d'être opérationnelle à l'automne 2025. Le principe devrait être le même, mais la plateforme appartient à ses membres (artistes, labels, auditeurs).

L'adhésion à la coopérative coûte 100$. Elle est gratuite pour les créateurs.

Subvert annonce 0% de frais de plateforme lors des achats (Bandcamp Friday tous les jours). Le modèle économique repose sur les adhésions à la coopérative et les contributions volontaires proposées lors des achats.

Subvert annonce 7139 artistes, 1305 labels, et 987 soutiens.

Nina : le modèle décentralisé

Nina est une plateforme décentralisée démarrée en février 2021. Elle s'appuie sur des technologies opensource (blockchain). Solana est utilisée pour les transactions et les données de réseau (quel utilisateur suit quel artiste ou autre utilisateur, etc.). Arweave est utilisée pour les sons, images et métadonnées des albums.

Code source et outils sont disponibles ici: https://dev.ninaprotocol.com/.

Artistes et même utilisateurs peuvent créer des hubs pour exposer de la musique, des listes de lecture, etc.

La musique sur Nina est en écoute libre. L'achat est donc un acte de soutien mais il peut aussi donner droit à des bonus (sons en meilleure qualité, morceaux supplémentaires, vidéos,…).

Il n'y a pas de frais de plateforme. Les artistes doivent payer un montant initial minime pour publier un album et les acheteurs ont des frais de transaction minimes aussi (0,04 $) via Solana.

Nina auto-évalue favorablement son impact environnemental.

Nina annonce plus de 20 000 artistes, labels et auditeurs.

Un rapport récent a introduit l’Indice Européen de Résilience Numérique (EDRIX) dont l'objectif est de mesurer de manière chiffrée et objective la capacité des 27 États membres de l'Union européenne à « construire, maintenir et contrôler leur propre destinée numérique » et vise à fournir un outil d'analyse pour guider les politiques industrielles vers un « EuroStack » souverain.

L'indice agrège les scores de cinq piliers, dont quatre reposent sur des données mesurables concrètes, plutôt que de se contenter de simples déclarations d'intention.

• Politiques Publiques : maturité des stratégies Open Source nationales (basé sur les rapports OSOR de la Commission européenne).
• Écosystème de Développeurs : densité de développeurs par habitant (données GitHub, à défaut de disposer des données des autres plateformes) et nombre de solutions souveraines référencées dans les principaux annuaires (données agrégées issues de l'annuaire EuroStack).
• Adoption par la Société Civile : part de marché des navigateurs "souverains" (Firefox, Brave, Opera) et part de marché des ordinateurs sous Linux (moyenne de 3,7 % dans l'UE27).
• Résilience du Secteur Privé : souveraineté de l'infrastructure (web, mail, DNS) des domaines nationaux à fort trafic.
• Résilience du Secteur Public : souveraineté de l'infrastructure des institutions publiques clés (Présidence, Gouvernement, capitale).

Le rapport introduit également un indice complémentaire plus spécifique au logiciel libre, l'EOTRIX (European Open Technology Readiness Index).

Concernant la France, qui se classe seulement 6ème, le rapport révèle un tableau contrasté qui illustre le fossé entre politique et pratique, avec un écosystème de développeurs et une adoption par la société civile qui n'obtiennent que des scores moyens (respectivement 4,08/10 et 5,09/10).

Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.

Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.

Sommaire

• • Premier diagnostic
  • Eh bien des requêtes habituelles…
  • La boucle sans fin
  • Une dernière page d’epub ?
  • Retour en graphiques sur la journée
  • Mesures préventives et correctives
  • Bonus inattendu pour l’incident précédent du 26 juin 2025

Premier diagnostic

Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.

La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.

Le premier contact réétabli avec le serveur est assez clair (une forte charge) :

$ uptime
15:06:59 up 2 days,  2:54,  1 user,  load average: 50,00, 205,21, 260,83

(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)

Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.

Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.

Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.

La console est remplie d’élimination de processus de ce type :

Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?

Eh bien des requêtes habituelles…

Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.

Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.

Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.

Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.

OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.

La boucle sans fin

Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :

(...)
close(623199355)                        = -1 EBADF (Bad file descriptor)
close(623199356)                        = -1 EBADF (Bad file descriptor)
close(623199357)                        = -1 EBADF (Bad file descriptor)
(...)

Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.

En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :

# close fd's inherited from the ruby parent
        import resource
        maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
        if maxfd == resource.RLIM_INFINITY:
            maxfd = 65536

        for fd in range(3, maxfd):
            try:
                os.close(fd)
            except:
                pass

Donc on itère sur tous les descripteurs entre 3 et le maximum déterminé…

>>> import resource
>>> print(resource.getrlimit(resource.RLIMIT_NOFILE)[1])
524288
>>> print(resource.RLIM_INFINITY)
-1

Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.

On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.

Une dernière page d’epub ?

Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).

Voir ce commentaire sur la dépêche de l’incident précédent expliquant la séparation du service epub et du conteneur principal de production (en bref : dette technique et migration en cours).

Retour en graphiques sur la journée

Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.

Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52   ô_Ô)

Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.

Mesures préventives et correctives

Dans les actions en cours ou à prévoir :

• mettre à jour la documentation pour disposer facilement et rapidement des informations pour les connexions aux cartes d’administration ou les procédures de blocages d’IP
• procéder à la montée de version des composants (yapuka, épineux sujet de la dette technique à éponger)
• vérifier l’efficacité des limitations CPU/mémoire mises sur certains conteneurs LXC et les étendre aux autres
• mettre des limites sur des processus particuliers (comme ceux de pygments)
• ajouter le déploiement des limites par utilisateur dans le code Ansible
• corriger la collecte rrd des métriques concernant les interfaces réseau
• remonter les alertes OOM qui ne sont pas normales
• comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)

Bonus inattendu pour l’incident précédent du 26 juin 2025

De façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.