Ce sujet indique l’état du service Mastodon sur LIRE.IM
Nous avons eu une période hors-ligne. Je ferai une investigation ce week-end pour connaître les raisons du problème et évaluer comment y remédier définitivement.
Le fil correspondant à cette discussion se trouve à
Comme indiqué sur LIRE.IM une erreur de manipulation a pulvérisé les fichiers sur le serveur y compris les versions de sauvegarde.
En revanche la base de données est intacte : seules les images manquent. Les messages et les relations ne sont pas affectés.
Nous publierons ici les informations au fur et à mesure…
Nous vous présentons encore toutes nos excuses pour cet incident malencontreux et les inconvénients qu’il peut vous causer.
Nous sommes en train de remonter les fichiers des comptes distants (avatars, etc.) malheureusement les fichiers des comptes locaux sont perdus.
Nous évaluons la manière la plus simple de remettre ce qui peut être récupéré en place. Voici quelques pistes :
-
Dans vos préférences, au profil :
- remettre « Image de profil » (l’avatar)
- remettre « Image d’en-tête » (bannière)
-
Votre page de profil est peut-être sauvegardée en cache quelque part, soit sur Web Archive, soit sur une instance que vous suivez et qui vous suit.
À suivre…
Comme je le craignais, les statuts épinglés comportant des images les ont perdues définitivement. Le mieux, dans ce cas, est de les refaire, tout simplement.
Voici les étapes suivies pour rétablir @ps@lire.im :
1. Restauration de l’avatar et de la bannière
Changer l’image de profil (avatar) et l’image d’en-tête (bannière) sur https://re.lire.im/settings/profile
2. Suppression et réécriture d’un statut épinglé
Cliquer sur l’icone « points de suspension » (…) en bas et à droite du message à modifier pour faire apparaître les options. Dans le dernier bloc vous trouverez « Modifier » et « Supprimer et réécrire ».
Dans un premier temps, sélectionner « Modifier » afin de faire une copie du message et des balises « Alt » de chaque image. Ainsi vous pourrez simplement copier-coller les descriptions.
Ensuite, cliquer « Supprimer et réécrire » et coller le message, ajouter les images et modifier leur « Alt » avec les données sauvées plus tôt.
Enfin, épingler de nouveau ce message sur votre profil.
Premier rapport
Nous avons identifié une invocation du oomkiller par postgres : la base de données s’est trouvée à court de mémoire.
Lors de nos tentatives de sauvegarde et notamment de « nettoyage » des données distantes stockées par Mastodon, la commande tootctl qui régit ce nettoyage a elle-même rencontré une limite de mémoire.
Dans un premier temps, nous avons mis en place un fichier d’échange (swapfile) afin de pallier au plus pressé et observer l’usage de la mémoire :
installation de 4Go de swap
# Create a file owned by root:root and
# only readable and writable by root
install -o root -g root -m 0600 /dev/null /swapfile
# Fill it with 4GiB of zeroes
dd if=/dev/zero of=/swapfile bs=1k count=4096k
# Make it a SWAP filesystem
mkswap /swapfile
# Activate it
swapon /swapfile
# Let's see what we've got now
free -m
total used free shared buff/cache available
Mem: 3818 3124 149 836 1641 694
Swap: 4095 6 4089
Prochaines étapes
- relancer les processus
tootctlpour observer l’usage de la RAM et SWAP - effectuer un backup complet
- mettre en place un module d’observation du système
- utiliser ces nouvelles données pour évaluer les optimisations nécessaires pour la base de données et éventuellement ajouter de la RAM ou distribuer les processus (par exemple, répliquer la base de données sur une autre machine dédiée)
- Refreshed 80698 accounts
- Visited 57 accounts and removed profile media totaling 2,14 Mo
- Removed 9942 preview cards (approx. 1,79 Go)
Sauvegarde complète !
Ensuite…
Ces deux étapes vont demander d’arrêter les services durant la migration. Cette nuit est une bonne candidate pour effectuer ce changement.
- Mise à jour PostgreSQL 16 → 17
- Migrer sur ARM64 / 8GB RAM (fois deux) / 4 CPU (plus un) pour 1 € de moins par mois (15% d’économie).
2 Likes
POST-MORTEM
Fatigue, stress et solitude – ou comment j’ai détruit notre service
Là j’ai un beau backup, tout est prêt pour le transfert et… Pourquoi le fichier .env.production est-il vide ? Oh, ce n’est pas grave, j’en ai plein de copies dans les sauvegardes. … … Euh… Les sauvegardes n’ont pas de copie ?
RHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Bon ben là c’est mort de chez mort. J’ai tout bien fait sauf que mon backup ne comprend pas .env.production qui contient tous les secrets de la base de données. J’ai mal vérifié mon backup, du coup quand j’ai fait git reset --hard pour tenter de récupérer public/system j’ai effacé la seule copie. Putain je me hais. J’avais tout récup’ et là je ne peux même pas relancer le service. Toutes les données sont inutiles. Mauvaise utilisation de tar. Bien fait pour ta gueule.
J’ai honte, j’ai la rage, et je suis profondément désolæ pour toutes les personnes qui m’ont fait confiance.
Je suis vraiment désolée d’apprendre cela.
LIRE.IM : Accident (presque) Fatal
Le 24 janvier 2025, notre service Mastodon a connu un incident qui l’a rendu temporairement indisponible. Une première intervention a remis le service en place. Mais lors de l’investigation sur ses causes, le lendemain une erreur de manipulation a effacé les fichiers (avatars, bannières, photos…), puis une seconde erreur dans la nuit a rendu la base de données inutilisable… ou pas ?
Ce billet dissèque l’incident pour rendre compte de manière transparente de l’enchaînement des événements entraînant la destruction du service et poser les bases d’une éventuelle suite.
tl;dr : nous avons eu chaud, très chaud. Ç’aurait pu être bien pire.
Autopsie
1. OOM Killer : l’exhaustion de mémoire appliquée au cerveau
Dans la soirée du 24 janvier an usagær de LIRE.IM rapporte que le site est indisponible. Je me connecte au serveur et constate que la base de données est stoppée : je la redémarre et vérifie que le service fonctionne bien, en proposant de mener l’enquête le lendemain.
Le 25 janvier, j’ai identifié dans les logs l’invocation d’une fonction du kernel Linux (oomkiller) qu’un processus réclame lorsqu’il n’a pas suffisamment de mémoire. Dans ce cas c’était la base de données.
J’avais installé ce service un peu rapidement en me disant que j’y reviendrais, mais évidemment, ce ne fut pas le cas. Je me mis donc en tête de préparer une mise à jour, d’autant plus que la base de données avait changé de version.
2. Ne jamais bouger des données sans savoir où elles vont
Malheureusement je n’étais pas en grande forme et la fatigue m’a rapidement causé des ennuis. J’ai commencé par faire le ménage : cela prend pas mal de temps lorsque les processus de Mastodon doivent passer à travers de dizaines de milliers de comptes (distants) pour vérifier lesquels utilisent potentiellement de l’espace de stockage pour rien. Pendant ce temps je regardai d’autres choses, comme l’espace disque disponible et me dis que l’un des volumes quasiment vides pourrait être utilisé pour les sauvegardes. J’entrepris donc de transférer des données d’un endroit à un autre. Mais je n’avais pas remarqué – parce que je ne me souvenais pas vraiment de comment cette machine était configuré, et que je luttais contre la fatigue – que le volume que je pensais libérer était en fait déjà monté à l’endroit où je voulais le mettre. En clair, j’ai copié 85Go de fichiers de l’endroit où ils se trouvaient vers… l’endroit où ils se trouvaient. 
Mais voilà, comme je ne m’en suis pas rendux compte, une fois la « copie » effectuée, j’ai effacé la source… donc la seule copie. 
Là : panique. Oh la la, c’est terrible, tout est parti. Et les sauvegardes ? Ben, en fait, comme c’était beaucoup de fichiers et que je n’avais pas mis en place de sauvegarde distante, j’étais en train de faire la première sauvegarde. 
OK, des génocides sont en cours dans plusieurs régions du monde, ce n’est pas si grave : les données sont intactes, c’est juste une question de remettre son avatar et sa bannière. Gênant et un peu honteux, mais pas trop grave. J’annonce la problématique et envoie des messages en ce sens, plutôt rassurants.
3. Ne jamais faire en prod ce qu’on peut faire ailleurs
Mais quand même, j’aimerais bien tenter quelque chose… J’ai déjà mis en place un fichier de mémoire tampon pour m’assurer que l’oomkiller ne va plus nous embêter, mais c’est un peu porcasse. En parcourant quelque documentation, je me rends compte que tout de même ce problème de mémoire est relativement courant à partir d’une certaine activité sur Mastodon. Alors je me décide à monter un machine plus puissante, avec plus de mémoire, en mettant en place des scripts qui surveillent l’état des lieux et lancent des alertes : rien de bien inhabituel.
Je lance donc un gros nettoyage et des sauvegardes pour préparer la migration. Cela prend pas mal de temps, du coup je reviens sur cette histoire de fichiers effacés… Peut-être que je peux au-moins récupérer les fichiers par défaut, c’est déjà ça. Pour cela, rien de plus simple : un bon vieux git checkout et c’est marre… 
Euh… Cela ne restaure pas les fichiers ? Hum. Bon ben, git reset --hard. Ah, là ça marche… Service relancé, nouvelle mise à jour de l’info. On est bien.
Je commence à transférer les fichiers importants… Enfin : le fichier critique .env.production, de la machine en cours de ramonage et la nouvelle clinquante : ssh old:/home/mastodon/live/.env.production new:/home/mastodon/live/.env.production. Bon, je crois que je finirai demain, personne n’utilise Mastodon le samedi soir ni le dimanche matin.
Après une bonne nuit de sommeil, retour au clavier. Tiens, .env.production est vide ? Ha ! Je n’aurais pas dû faire ce git reset, c’était vraiment débile : j’aurai pu cloner le dépôt de nouveau et copier les fichiers. Mais bon, pas grave, je le prends depuis le backup. 
Euh… 
Pourquoi n’est-il pas dans le backup ? Je vérifie le script : ben oui, c’est la première chose qu’il fait, copier ce fichier… 
Je relis le script… Oh…
tar zcvf $BACKUP_DIR.tgz $BACKUP_DIR/* && rm -rf $BACKUP_DIR
En clair : t’as codé ça à quat’du mat’ avec tes oreilles. Bon déjà, la destruction du répertoire cible de la sauvegarde pour gagner de la place c’est bien, mais cela ne permet pas de vérifier ce qu’il y a dedans. Donc, le bouger à la fin, quand tout est fait. Mais surtout, surtout… Le tar là, pour créer une archive de ce répertoire, il ne prend pas les « fichiers cachés » (qui commencent par un ., comme… .env.production.
Sans ce fichier, la base de données a beau être intacte, il est impossible de lire ce qu’elle contient. Enfin peut-être pas tout. En passant par le gestionnaire de la base de données et non par Rails, nous pouvons lire certaines choses, mais sera-ce suffisant ?
Rééducation
À présent que nous avons pu identifier les causes des pannes, nous avons mis en œuvre des méthodes pour éviter que ce genre d’erreurs ne se reproduise, qui seront documentées ici-même.
Reste l’espoir de pouvoir migrer les comptes et restaurer les messages à partir de la base de données mais sans les secrets, comment cela va-t-al se passer ? Nous ne savons pas vraiment (et sommes curieuz de connaître les conséquences réelles.)
If you lose application secrets, some functions of Mastodon will stop working for your users, they will be logged out, two-factor authentication will become unavailable, Web Push API subscriptions will stop working.
La doc dit : « Si vous perdez les secrets de l’application, certaines fonctions de Mastodon ne fonctionneront plus pour vos usagærs, als seront déconnectæs, l’authentification multi-facteurs ne sera plus disponible et les souscriptions par le biais de l’interface « Web Push » cesseront de fonctionner.
Mais cela ne dit pas si toutes ces fonctionnalités sont récupérables par la suite. Nous verrons bien.
Qu’avons-nous appris ce weekend ?
- Sysadmin et fatigue : non. Le surmenage mène à la faute. Les geeks ont tendance à penser que le sommeil est optionnel. Et bien non, pas du tout. Et si vous n’arrivez pas à dormir c’est peut-être que vous passez trop de temps sédentaire devant un ordinateur.
- Ne jamais déplacer des données dans le vide. À moins d’être en apesanteur, c’est comme poser une tasse de café en suspension dans l’air : la gravité s’en charge, et après vous devez nettoyer. Même si vous pensez savoir, vérifier quand même comment les montages sont faits.
- Vérifier les sauvegardes : c’est con, mais c’est indispensable. Un fichier manquant et cela peut être fatal.
- Ne jamais faire en production ce qu’øn peut faire ailleurs. Là encore, c’est évident mais dans le feu de l’action, avec l’exaltation du travail sans filet du super-utilisateur, c’est facile de faire une boulette… sans retour. Alors que c’est tellement simple de tester une hypothèse. Deux précautions valent mieux qu’une.
Relance
Si vous aviez un compte sur https://lire.im/, je suis vraiment désolæ des erreurs commises et des conséquences négatives qu’elles peuvent avoir pour vous. Je vous demande humblement pardon et je fais tout ce qui est possible pour que ce genre d’incident ne se reproduise pas.
Je vous engage à répondre à ce sujet pour engager une discussion sur l’avenir de ce service.
Si vous avez perdu confiance et que vous désirez ouvrir un compte ailleurs, je comprendrai et je vous soutiendrai, mais je regretterai votre absence. 
Cependant si vous désirez réactiver votre compte, vous devez :
- Vous connecter (apparemment les mots de passe sont inchangés)
- Vous rendre sur votre profil pour remettre votre avatar et votre bannière
- Engueuler le sysadmin ou le réconforter, selon votre humeur : je le prendrai bien.
Merci de votre attention. 
Plan d’action
Ces mesures visent à assurer la pérennité du service. Les coches marquent les actions en place.
- Installation d’un serveur plus puissant
- Correction du script de sauvegarde
- Respect des conditions du Mastodon Server Covenant
- Surveillance automatisée des conditions de service
Maintenance du soir…
- Ajouter un volume dédié aux fichiers dans
public/system- Copier les données depuis
~mastodon/live/public/systemvers le nouveau volume - Stopper les services
- Finaliser la copie des données depuis
~mastodon/live/public/systemvers le nouveau volume - Démonter
~mastodon/public - Déplacer les données de l’ancien volume vers
~mastodon/public - Monter le nouveau volume sur
~mastodon/live/public/system - Relancer les services
- Copier les données depuis
Si nous avons le temps :
- Dédier l’ancien volume aux backups
- Virer l’ancien répertoire public
- Effectuer un backup complet
- Mettre en place les backups distants
Active moderation against racism, sexism, homophobia and transphobia
Users must have the confidence that they are joining a safe space, free from white supremacy, anti-semitism and transphobia of other platforms.
- Daily backups
It is important for users to have the confidence that a trip over the power cable or a rogue bit flip will not erase all of their data. Having a backup strategy is a basic necessity of providing a public service.
Voici nos programmations de sauvegardes :
.env.productionest sauvegardé en multiples exemplaires dont au-moins 3 copies (chiffrées) hors du serveur (dont une dans un dépôtgit) et tout changement est surveillé et alerté chaque minute.- La base de données est sauvegardée toutes les heures localement, puis chaque jour à distance (pour l’instant une seule copie, mais nous en préparons deux autres)
- Les fichiers dans
public/systemsont copiés localement chaque demi-heure et sauvegardés à distance chaque jour. - D’autres fichiers importants pour le système sont sauvegardés chaque heure localement et chaque jour à distance
- L’ensemble des sauvegardes est sécurisé (accès au serveur uniquement par clés, tous les fichiers uniquement accessibles par les compte de service, et toutes les sauvegardes distantes sont chiffrées et protégées par mot de passe comptant (beaucoup) plus de 128 bits)
- nous envisageons des copies distantes toutes les quatre heures.
- At least one other person with emergency access to the server infrastructure
Various circumstances can prevent the original owner of the Mastodon server from answering technical emergencies. For this reason, more than one person must have that capability.
Pour l’instant seule une personne a accès à l’infrastructure, mais nous allons ajouter deux autres accès au serveur rapidement (le temps de former les personnes.)
- Commitment to give users at least 3 months of advance warning in case of shutting down
Sometimes services shut down, it is the cycle of life. But users must have the confidence that their account will not disappear overnight, so that they have time to export their data and find another server.
Nous sommes une association sans but lucratif opérationnelle depuis 8 ans. Nous pouvons annoncer la fermeture d’un service en avance.
Je compte.
La solitude est aussi le pire ennemi du sysadmin.
Je peux apporter mon aide si vous le souhaitez
2 Likes
