[technique] Disques corrompus sur matrix.tetaneutral.net

[Guilhem Saurel]

Bonsoir,

C’est bon, le serveur matrix est à nouveau tout neuf tout fonctionnel.
Vous pouvez vous re-créer un compte ici:
https://im.tetaneutral.net/#/register en mettant vos identifiants djadhere, puis
retrouver la liste des salons sur
https://im.tetaneutral.net/#/group/+ttnn:tetaneutral.net

Bonne soirée,
Guilhem.


Mail de Guilhem Saurel du lundi 2019-11-11 10:48:
> 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/20191113/71726372/attachment.sig>