Le problème le plus handicapant pour moi suite à la mise à niveau c’était l’impossibilité d’accéder à ma messagerie. J’ai essayé avec mes Thunderbird, mon client android (FairEmail), mon appli web, à chaque fois le même constat: impossible de se connecter au serveur.

Je sais que c’est de l’IMAP et que c’est géré par dovecot, je vais donc voir le journal du service:

Je continue en vérifiant l’état du service: systemctl status dovecot et là bonne surprise! J’ai droit à un beau message m’indiquant comment générer une clef DH et ajouter l’option pour la prendre en compte dans la conf dovecot, ce que je me suis empressé de faire et bingo, tout s’est remis à fonctionner (après un redémarrage des services dovecot et sogo tout de même).

Je ne détaille pas ici la manipulation, on verra plus bas que ce n’est pas ce que j’aurais du faire.

À noter qu’au moment de me reconnecter j’ai retrouvé des messages qui m’étaient parvenus entretemps, confirmant qu’aux yeux de l’Internet, ma messagerie n’a jamais cessé de fonctionner.

Rien de spécial ici, même erreur que sur l’instance de test, même solution, toujours pas la meilleure mais toujours la flemme de chercher: réinstallation.

Voilà le gros morceau. En me connectant à l’URL habituelle je tombe sur une page Grafana.

Là pas question de faire comme avec lufi et lutim, je ne sais pas du tout comment va se comporter l’appli si je me contente de la réinstaller, on parle là d’un réseau social fédéré donc de multiples connexions avec d’autres instances.

J’avais déjà eu ce problème dans le passé et la solution avait été assez simple, faire une mise à jour, ce que j’ai essayé de faire…​

Ce fut un misérable échec: j’avais lancé la mise à jour un matin vers 8H et lorsque j’ai vérifié le soir vers 18H j’ai pu voir que la mise à jour avait échoué et qu’une restauration était en cours. Le processeur carburait et ça swappait comme pas possible, j’ai décidé d’arrêter le processus (Ctrl+C).

Mon instance n’a jamais été très rapide mais je n’ai jamais rencontré de lenteurs trop perturbantes, cependant je me suis quand même décidé à passer la VM de deux à quatre CPUs.

Nouvelle tentative, fail encore plus rapide, logique, j’avais laissé l’appli dans un état batard avec mon arrêt forcé.

Bref, comme la restauration n’a pas pu aller au bout, le fichier de sauvegarde est toujours présent dans /home/yunohost.backup/tmp/, je décide de l’utiliser:

Ça met quelques heures mais la restauration va jusqu’au bout. Malheureusement, l’appli ne fonctionne toujours pas à ce stade.

Un yunohost service status me dit que mastodon-sidekiq et mastodon-web sont arrêtés.

Un systemctl status mastodon-sidekiq me retourne entre autre gem nokogiri is missing.

Ok, donc:

Maintenant que la gemme manquante et bien d’autres ont été installées, je redémarre les services qui étaient dans les choux:

Si sidekiq a bien voulu redémarrer, ce n’est pas le cas de web.

systemctl status mastodon-web m’apprend que le port 3000 qu’il souhaite utiliser est déjà pris.

netstat -tupanl | grep 3000 me dit que c’est grafana qui le squatte. Je tente de tuer le processus sans succès. Dans le doute, je reboot, bingo, ça refonctionne.

Fort de ce succès je me dis que ça y-est, je touche au but, maintenant que l’application fonctionne à nouveau je la mets à niveau et ça va marcher comme sur des roulettes. Eh ben tu m’crois, tu m’crois pas, ça fonctionne toujours pas! Je jette un oeil aux messages d’erreur, un problème d’index lors de la migration, je me retrouve comme la première fois avec une restauration qui pédale dans la semoule.

D’après ce que je lis sur le dépôt officiel de l’application ce n’est pas un souci propre à Yunohost (le problème d’index). Bref, je décide de restaurer à nouveau le backup pre-migration et de m’occuper de ce souci d’index plus tard.

Je me retrouve donc avec une instance mastodon fonctionnelle mais pas à jour. Affaire à suivre…​

Comme indiqué dans la doc j’aurais dû lancer ce diagnostic avant tout autre chose après la migration ça m’aurait sûrement épargné des modifs manuelles, mais bon, j’y penserai la prochaine fois :)

Après le redémarrage pour mastodon, le diagnostic retourne lufi en erreur, dans les logs ça dit que la base de données était encours de démarrage. Bon, un simple systemctl start lufi règle le problème, il faudra que j’aille notifier le mainteneur du paquet de ce souci.

J’ai d’autres warnings sur des fichiers de conf modifiés à la main et qu’il faut regénérer:

Pour chacun d’eux, je fais une vérification du diff avec la commande proposée par le diagnostic YNH, puis une sauvegarde du fichier et regénération de la config, encore une fois avec la commande proposée par le diagnostic.

Pour nslcd et nsswitch.conf c’est un bug connu et remonté dans la page concernant la migration

Pour dovecot.conf il s’agit des modifications que j’avais faites manuellement décrites plus haut ainsi qu’une autre dont j’ai parlé dans un autre article.

Pour sshd_config il s’agissait du port d’écoute que j’avais remplacé ainsi que d’autres évolutions.

J’ai redémarré les services nslcd et dovecot pour prendre en compte les changements mais j’ai à nouveau changé le port d’écoute ssh avant de relancer le service correspondant.

Après quelques tests, le souci de perte de connexion remonté précédemment était réapparu, j’ai donc appliqué la même solution.

J’ai mis à niveau les applications qui étaient dépendantes de Yunohost 4 en faisant attention de ne pas lister mastodon.

Il me reste à retenter la mise à niveau de mastodon après avoir jeté un oeil aux solutions proposées dans l’issue ouverte sur le dépôt upstream. Malheureusement ça date du mois de juillet et ce n’est toujours pas résolu.