[technique] Disques corrompus sur matrix.tetaneutral.net

Guilhem Saurel guilhem at saurel.me
Lun 11 Nov 10:48:55 CET 2019


Hello,

TL;DR: Après une maintenance un peu ardue, je pense que le serveur matrix
fonctionne, mais est dans un état inconsistant vis à vis de la fédération, et
que la méthode la plus simple pour régler ça et de supprimer notre DB pour
repartir à 0.


Hier soir, j’ai voulu mettre la VM matrix à jour. J’ai commencé par voir que les
disques (boot & data) avaient des soucis:
- un arbre git disait "FATAL: corrupt loose object" lors d’opérations
- "apt upgrade" refusait de s’exécuter parce qu’il manquait une ligne dans un
  paquet (supprimer le paquet dans le cache apt a permis de le réinstaller)
- postgres se plaignait qu’il manquait un fichier dans des transactions
- faire un rsync du répertoire data de postgres depuis un autre serveur refusait
  de prendre quelques fichiers parce qu’ils étaient corrompus.

Les deux options pour le offline fsck¹ ont donné l’erreur suivante:
> /dev/sdb1 has unsupported feature(s): metadata_csum
> e2fsck: Get a newer version of e2fsck!

J’ai donc détruit la VM, renommé ses disques (matrix.tetaneutral.net-disk-1-old
& matrix.tetaneutral.net-bootdisk-old), recréé la VM, et tout réinstallé dedans.

J’ai vérifié que le serveur matrix se lançait bien avec une DB vide, puis j’ai
essayé de remettre les données de l’ancienne DB.

Pour ça, j’ai remonté les anciens disques dans /mnt, et lancé le e2fsck depuis
la nouvelle VM. J’ai ensuite copié le dossier postgresql/data, mais postgres
sortait encore des erreurs d’inconsistance, donc j’ai fait un pg_resetwal, et
postgres a arrêté de se plaindre, mais synapse (le serveur matrix) n’arrivait
pas à se lancer. Après un pg_dumpdata, que j’ai ensuite ré-importé dans un
nouveau dossier data, tout arrive maintenant à se lancer.

Je pense que l’app et la DB sont dans un état cohérent, mais que mes différents
tests pour en arriver là ont posé des problèmes de consistence au niveau de la
fédération.

Les messages envoyés depuis mon compte LAAS arrivent bien sur mon compte ttnn,
mais pas dans l’autre sens. La vérification de devices entre différents serveurs
pose aussi des problèmes (je pense que le problème est au niveau du système de
notifications)
Et hier soir les logs de postgres & synapse semblaient correct, mais maintenant
que tout le monde s’est réveillé et a rallumé ses ordinateurs / téléphones, y’a
des erreurs qui apparaissent régulièrement.


Donc là, j’envisage de supprimer la DB et de repartir à 0, sauf si quelqu’un a
une meilleure idée :)

En pratique, ça voudra dire qu’il vous faudra re-créer vos comptes (toujours en
utilisant vos identifiants djadhere), et re-rejoindre les salons. Les salons
dans lesquels il y a des utilisateurs provenant d’autres serveurs matrix (ce qui
est le cas pour tous les salons de +ttnn:tetaneutral.net) ont un contenu
sauvegardé dans tous les cas.

Je pense faire ça demain soir, pour vous laisser le temps de vérifier que vous
avez sauvegardé ce à quoi vous teniez, de discuter avec les auteurs de synapse,
ou de voir si quelqu’un a une autre solution.


Bonne journée,
Guilhem.


¹: https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Openstack_Management_TTNN#Offline-fsck
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 833 octets
Desc: non disponible
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20191111/59b0f51b/attachment.sig>


Plus d'informations sur la liste de diffusion technique