19 Avril 2026
Vous pouvez partager cet article, en extraire des morceaux en indiquant la source et l’héberger ailleurs en le modifiant (CC-BY-SA)
Bonjour à vous et merci de prendre le temps de lire cet article débutant une série sur mon expérience avec l’autohébergement et de la fédération.
L’original à jour de cet article lui-même, peut-être celui que vous consultez en ce moment, est auto hébergé.
Cet article fait suite au précédant billet sur pleroma détaillant la raison de mon choix de pleroma et de yunohost.
Ce qui a motivé tout cela est la résolution du problème de paquet pleroma_ynh cassé impossible d’installer pleroma sur yunohost ni de le mettre à jour.…
Mon service pleroma est à l’heure actuelle en 2.10.0 avec la version en testing et cela fonctionne, donc c’est résolu ! Vous pouvez fermer cette page ;-)
Cela n’a pas été sans effort, ni sans aide de la part de la communauté Yunohost.
Oyez ici l’aventure extraordinaire … ou pas.
Je suis parti de loin car je ne connaissais pas le projet dans lequel je me suis embarqué ni son écosystème et son langage ( Elixir ). J’ai donc découvert un monde …
Dans la catégorie des sigles OTP me fait toujours penser à One Time Password, c’est à dire à la catégorie d’authentification reposant sur un mot de passe à utilisation unique. Ce n’est absolument pas le cas ici OTP n’a rien à vous avec l’authentification, ni TOTP même si nous reparlerons de TOTP plus tard, juste parce j’aime bien rendre les choses confuses.
Puisque je digresse, OTP n’est pas un acronyme, pour qu’il soit un acronyme il faudrait le prononcer autrement que lettre par lettre, donc c’est un sigle.
Mais c’est quoi OTP ?
C’est en relation avec erlang qui est le système qui fait tourner le code compilé de pleroma.
OTP c’est Open Telecom Platform , un héritage provenant d’ericsson puisque c’est la société qui a créé erlang à la base. Le choix du mot telecom provient d’ericsson et n’a pas tellement plus de sens que celui-ci.
Mais ce serait trop simple si pleroma était codé en erlang, pleroma est codé en Elixir qui est compilé en code machine erlang. Et donc ici erlang est une machine virtuelle qui exécute le code.
Pour savoir si votre version d’elixir est OTP il suffit de lui demander : elixir –version
Erlang/OTP 25 [erts-13.2.2.5] [source] [64-bit] [smp:8:4] [ds:8:4:10] [async-threads:1] [jit:ns]
Elixir 1.14.0 (compiled with Erlang/OTP 24)
Dans le cadre du projet pleroma la version OTP est celle qui vient avec les binaires erlang et elixir et leur dépendances pour un architecture matérielle et une version du système donnée.
S’il ne s’agit pas de la version OTP alors on utilise les sources pour la compiler. Si on ne souhaite pas utiliser OTP il faut comiler les sources en fournissant les paquets de développement pour toutes les dépendances. C’est ce que j’appelle la version MIX, mix étant l’outil utilisé pour la génération du code erlang.
Entre OTP et MIX, les script sont différents et l’organisation du code et des fichiers de configuration est différente.
Si une version ‘OTP’ est disponible depuis le projet pleroma, il est fourni avec les binaires elixir et erland et des outils spécifiques OTP.
| OTP | Package officiel | Avec Yunohost |
|---|---|---|
| Répertoire d’installation | /opt/pleroma |
/var/www/pleroma/live/ |
| Répertoire statique | /var/lib/pleroma/static |
/home/yunohost.app/pleroma/ |
| Fichier de configuration | /etc/pleroma/config.exs |
/etc/pleroma/config.exs |
| Ligne de commandes | /bin/pleroma_ctl |
/var/www/pleroma/live/bin/pleroma_ctl |
En OTP les binaires tels qu’erlang sont fourni par l’archive.
MIX depuis les sources requiert une compilation mais utilise les dépendances du système, c’est à dire les paquets elixir et erlang et les dépendances de developpement.
Le projet relatif à ce build MIX lors de l’installation buildatinstall
| MIX | Official Package | With Yunohost buildatinstall |
|---|---|---|
| Install directory | /opt/pleroma |
/var/www/pleroma/mix/ |
| Static directory | instance/static |
/home/yunohost.app/pleroma/ |
| Configuration file | config/${MIX_ENV}.secret.exs |
/etc/pleroma/config.exs |
| Command line path | mix |
mix with pleroma HOME (see examples) |
En MIX Les paquets debian de erlang et de elixir sont utilisés. L’archive ne fourni aucun binaire.
Un intérêt ici est le support des architectures non fournies par OTP, par exemple arm 32 bits (armh), ou d’autres plus exotiques dont je ne connais pas la nature (riscv ? ).
Avant 2020 le paquet yunohost de pleroma reposait sur MIX uniquement, et dépendait des paquets erlang de sources variées, à partir de 2020 la version OTP obtenue depuis le projet parent (upstream) pleroma a été utilisée.
En Juin 2020 une version importante de yunohost est la 2.0.5 qui a vu l’inclusion du LDAP de yunohost dans pleroma. Ce qu’il faut en retenir c’est que depuis pleroma et yunohost sont liés par les liens LDAP et cela a des conséquences.
Fin 2025, depuis 2026 le projet pleroma a changé sa forge logicielle pour passer de GitLab à ForgeJo et c’est lors de ce changement que les versions OTP gnéérées ont disparues.
L’impact sur yunohost a été visible puisqu’il était alors devenu impossible d’installer pleroma sur yunohost ni de le mettre à jour..
Mais avant même que ce problème n’apparaisse, l’obtention de l’archive chez pleroma était déjà problématique.
l’url pour obtenir les ressources OTP sur pleroma est constante et indique ‘latest’ c’est à dire que lorsqu’une nouvelle version sort, l’archive obtenue est celle de la nouvelle version. Or le paquet yunohost indiqué une somme de contrôle qui forcément sera à changer. Cela veut dire aussi que l’installation d’un paquet qui fonctionnait par le passé peut ne plus fonctionner. Les paquets d’applications yunohost ont besoin d’une version fixe, une version variable ne sera pas viable sur le long terme.
Pour pouvoir pointer sur une version fixe, il est possible de trouver version quoi pointe l’url latest, c’est une redirection vers la vraie url. Mais là encore l’url redirigée, même si elle est fixe n’a pas une garantie de validité dans le temps car elle fait référence au ‘job’ d’intégration continue qui l’a construit et même pire elle est détruite au bout d’un temps qui a d’ailleurs été réduite pour des raisons de limitations de ressources. donc même avec une version fixe, les paquets d’application pleroma s’invalidaient au cours du temps.
Deux choix ici :
Revenir à la solution MIX et faire le build lors de l’installation. Dans cette option la version source n’a pas disparue, elle est liée au dépôt git et est ivable à) long terme. Cependant cela consomme des ressources sur chacune des machine qui fait l’installation et allonge notablement le temps d’installation surotu sur des petits équipements. Il faut plus de vingt minutes sur un raspberry pi3 B+ par exemple.
Avoir une archive des builds OTP à fournir, et cela ne peut pas être dans le projet pleroma car il n’a pas finlaisé la migration et les archives des build OTP précédants n’existent plus.
Thomas a donc créé un projet pour faire le build manquant depuis le github de Yunohost-Apps et c’est ce build otp qui est désormais utilisé plutôt que le build du projet pleroma.
Et je l’en remercie du fond du coeur car c’est l’option qui a permis de remettre l’application pleroma en selle.
Jusqu’ici il n’était plus possible d’installer pleroma, l’application était indiqué avec un niveau 0, c’est à dire que la validation des build ne passait pas dessus et que l’application n’était plus proposée à l’installation ni à l’upgrade.
Ce qui a été cassé a été réparé, mais les nombreux bugs existants n’ont pas disparus, il se cumulent au cours du temps et finissent pas s’agréger en une connaisssance diffuse que l’on peut trouver dans les tickets ouverts, dans la documentation du paquet et dans les forums de yunohost et de pleroma.
A ce jour il y a 777 tickets sur pleroma dont 369 marqués comme des bugs dans le gestionnaire de code de pleroma, donc il y a matière …
Il faut prendre en compte le fait que pleroma est intégrée de façon très légère dans yunohost, la seule chose vraiment partagée avec yunohost est la base d’utilisateurs de l’annuaire LDAP de yunohost.
Le SSO n’est pas supporté, c’est à dire que le fait de s’être authentifié sur le portail n’est pas pris en compte par l’application. En fait pour pleroma c’est même encore plus marqué… Il n’est pas possible de se logguer sur l’interface Web de pleroma, qui est par défault Pleroma-FE ( pleroma Front End ) si on est connecté au portail, il faut absolument avoir aucune connection sur le portail lié au domaine de pleroma, c’est un bug à corriger. On peut cependant être connecté à l’administration de yunohost ou bien sur un autre domaine qui ne soit pas le parent de celui du portail.
Et là aussi il faut suivre l’évolution des paquets yunohost et du projet pleroma au cours du temps.
La gestion des mots de passes entre yunohost et pleroma est encore un sujet à documenter …
Autours de ces questions il y a la possiblité à des utilisateurs de s’enregistrer sur la plateforme. En pratique ça n’est plus possible. Pour que cela fonctionne il faut désactiver LDAP. C’est possible depuis l’interface d’administration de Pleroma-FE mais vous perdrez votre authentication admin et retournerez au mot de passe initial saisit lors de l’installation.
Et je ne parle des bugs propres au script pleroma_ctl en mode OTP qui est sensbile à l’utilisation de caractères tels que les espaces , les single quotes et autres choses ayant un sens en bash. Donc pour le mot de passe administrateur … Ce n’est pas vraiment grave étant donné qu’il ne sert plus vraiment à rien.
Il faut comprendre ici que pleroma n’a pas de dissociation des utilisateurs en fonction de leur authentification, et s’il y a du LDAP c’est celui ci qui est utilisé. Un utilisateur a cependant un mot de passe conservé sous forme hashée, mais uniquement s’il a été créé directement dans pleroma.
S’il y a un LDAP, il fut un temps ou le mot de passe LDAP était capturé au login et renseigné, mais cela a été supprimé dans pleroma en Aout 2020 et amha c’est plutôt une bonne chose au niveau sécurité. Pourtant la demande a été nouveau formulée en 2022, pouvoir utiliser le mot de passe local si l’authentification LDAP n’est pas fonctionnelle Ticket de fonctionalité de repli LDAP. Cela laisse penser que la connaissance du fonctionnement de pleroma et les choix autours de l’authentification sont diffus au sein du projet, puisqu’une foncitonalité explicitement supprimée est demandée comme si elle était totalement nouvelle.
Depuis cette inclusion le mot de passe administrateur demandé à l’installation n’est plus celui qui est nécessaire pour se connecter mais il reste celui qui est vérifié pour l’ajout facteurs multiples d’authentification (MFA), tels que TOTP. Je vous l’avais dit que je caserais du TOTP à un moment ;-)
TOTP est une suite de chiffre à utilisation unique ( un one time password ) basé sur le temps, c’est à dire en pratique pour pleroma un code à 6 chiffres qui change toutes les 30 secondes et qui peut être généré par des applications sur smartphone comme FreeOTP+. Bref, on ne peut pas ajouter la double authentification pour des utilisateurs LDAP car il n’ont pas de mot de passe interne, un bug a été ouverts auprès de pleroma à ce sujet.
Dans cette aventure où je me suis trouvé embarqué bon gré mal gré, je suis devenu le mainteneur de pleroma pour yunohost. J’en tire une grande satisfaction et une fierté que j’essaie médiocrement de dissimuler.
Avec l’espérance que cela profite à la communauté .