J'héberge une instance Mastodon depuis quelques temps maintenant. Comme la plupart des personnes qui font tourner ce type d'instance, je le fais sur mon temps libre, de façon totalement bénévole et gratuite, mais je garde un souci de qualité : performance et disponibilité d'abord, mais aussi sécurité et confiance de la part de mes utilisateurs. Mais samedi soir (le 19 février 2022), j'ai rencontré quelques difficultés et je voulais vous partager mon expérience.

Un peu d'historique

L'instance a été créée le 18 Décembre 2020, soit en v3.2.1 de Mastodon.

J'ai quelques spécificités dues à mon infrastructure, qui peuvent être intéressantes à connaître pour la suite :

  • Mastodon est exécuté dans un conteneur LXC sous Debian 10 (Buster)
  • La base de données PostgreSQL tourne dans un autre conteneur LXC
  • Le tout est exécuté sur le même hôte, derrière un conteneur (encore) qui sert de Reverse Proxy
  • Quelques modifications ont été apportées aux fichiers des services Mastodon, notamment pour modifier l'adresse d'écoute (BIND)
  • Les sauvegardes sont faites avec BorgBakcup et borgmatic.

Les tâches de maintenance quotidiennes

Au quotidien, afin de m'assurer que tout ça tourne correctement ainsi qu'un temps de réaction relativement court, j'ai mis en place quelques outils et pratiques :

  • Supervision : comme pour le reste de mes services, je surveille la disponibilité de mon instance avec Uptime-Kuma.
  • Métrologie avec telegraf et influxdb pour m'assurer des performances.
  • Vérifications quotidienne des sauvegardes via un rapport journalier.
  • Des tests plus ou moins réguliers des sauvegardes.
  • Snapshot régulier du conteneur pour en avoir un état stable en permanence.

Ici l'état stable des derniers snapshots étant discutable, j'ai préféré les laisser de côté.

Ce qu'il s'est passé

Attention : Les faits rapportés plus bas dépendent grandement de mon niveau technique, de mon (manque d') expérience, et des différents loupés possibles.

Début 2022

J'ai procédé à la mise à jour du conteneur LXC qui accueille Mastodon, pour passer à Debian 11 (Bullseye), ce qui ne s'est pas fait sans conséquences.

Je me suis retrouvé avec le service mastodon-web.service qui refusait de démarrer, l'instance était donc hors-service. La plupart des erreurs semblaient liées à Ruby qui m'indiquaient que les librairies proposées par le système n'étaient pas dans leur bonne version. À première vue, les gems utilisés par Mastodon demandaient des versions de bibliothèques qui n'étaient plus proposées par Debian Bullseye.

J'ai alors fait exactement ce qu'il ne fallait pas faire, ou presque. J'ai utilisé gem pristine sans trop savoir ce que je faisais afin de régénérer les gem specs pour la nouvelle version de Debian et de ses bibliothèques. Sans succès bien évidemment. Je bricole alors pour réinstaller les bibliothèques dans les versions demandées par les gems jusqu'à ne plus avoir d'erreurs liées à cela. Sans succès, encore une fois. Je finis alors par modifier dans mon unité de service systemd pour :

ExecStart=/home/mastodon/.rbenv/shims/bundle exec rails s

Au lieu de :

ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb -b tcp://0.0.0.0:3000

Petit contournement, mais ça repart, l'instance est de nouveau accessible en v3.4.4.

Samedi 19 Février 2022

Dans la soirée, innocemment, je lance ce pouet :

J'aurais peut-être dû prendre la réponse d'Augier en compte...

Mais on ne se refait pas, et je me lance gaiement, à 23 heures, dans les mises à jour successives en v3.4.5 puis v3.4.6. Les mises à jour se passent bien, l'instance est accessible mais... Plus aucun processus sidekiq ne s'exécute ce qui signifie qu'aucune des files n'est traitée :

  • Récupération des pouets depuis les autres instances (fédération)
  • Envoi des pouets au reste de la fédération
  • Envoi des courriels aux utilisateurs ou pour les inscriptions
  • ...

En gros : on est entre nous, et il ne se passe rien d'autre. Du fédéré non fédéré en somme.

Je me retrouve alors avec des erreurs qui ne me semblent pas claires et mis à part sidekiq tout me paraît ok.

Je passe mon dimanche (enfin des moments dans la journée) entre recherches Google et tentatives de debug en partant sur un clone de mon conteneur. Sans succès.

Dimanche soir, perdu pour perdu, je tente une réinstallation complète à partir d'un conteneur vierge, et directement en Debian Bullseye.

Les prérequis de Mastodon étant plutôt clairs dans le readme, j'installe directement nodejs 17 pour prendre de l'avance et être tranquille un certain temps. Après tout, c'est bien une version supérieure à la 12.

À la fin de la procédure d'installation de Mastodon, des erreurs dues à la version de Nodejs... stop... j'abandonne et supprime mon conteneur.

La solution

Incapable de repartir directement sur une base Debian 11 le dimanche soir, et ce peu importe la version de NodeJS finalement, je décide le lundi matin de créer un conteneur basé sur Debian 10 avec NodeJS 12.x (recommandée dans la documentation), et de récupérer le fichier de configuration du conteneur initial (réseau notamment).

Je procède ensuite à la réinstallation complète de Mastodon, à l'exception de la partie base de données qui est toujours disponible sur un autre conteneur et de la configuration de Mastodon qui sera restaurée plus tard. Je récupère les fichiers .service des trois unités de service systemd de Mastodon, et les personnalise rapidement (tu te souviens, l'interface d'écoute).

Je restaure ensuite les données (dossier public/system et fichier .env.production) à partir de ma sauvegarde. J'aurais pu le faire depuis les fichiers de l'ancien conteneur, mais c'était là aussi une occasion de tester mes sauvegardes en conditions réelles. Je suis la procédure pour recompiler Mastodon et reconstruire les différents feeds.

Je finis par restaurer ma configuration nginx propre au conteneur, vu que je suis derrière un reverse proxy, et le service redémarre. Le rattrapage du retard de la fédération se fait en quelques heures et tout est bon. On repart comme avant, et on remet en place la sauvegarde.

Conclusion

Dans mes différentes actions, il y a sûrement eu de ma part de nombreuses erreurs dues à des lacunes techniques concernant certaines briques de Mastodon, notamment Ruby et Sidekiq. On peut aussi inclure Redis. J'ai certainement loupé par manque d'attention des indications spécifiques à chaque mise à jour. Par exemple, mes fichiers de services ne correspondaient pas du tout à ceux fournis par la nouvelle installation de Mastodon. Enfin, après différentes recherches, il semblerait que Mastodon ne soit pas tout à fait compatible avec Debian 11, ou pas si facilement. Mais je n'ai là aucune certitude, je ne me base que sur les différents contenus trouvés au fil de mes recherches.

Et maintenant ?

Maintenant, il me faudra être plus vigilant sur les mises à jour et les instructions qui les accompagnent. Il me faut apprendre davantage sur les briques que je ne maîtrise pas, et creuser leur documentation pour mieux en saisir le fonctionnement. Je vais également faire un snapshot avant chaque mise à jour, que ce soit du conteneur, de Mastodon, ou des différents paquets, et surtout continuer à vérifier mes sauvegardes (ce qui fera plaisir à notre roi) puisqu'elles m'ont bien sauvé ici.

Et surtout, ne pas oublier qu'on apprend de nos erreurs ;)


Article de Xakan et photo de Jason Briscoe - Unsplash

Previous Post