Aller au contenu principal

Migrer de 4.x à 11.x

Cette page est destinée à vous aider à migrer une instance de YunoHost 4.4.x (fonctionnant sous Debian Buster/10.x) vers YunoHost 11.x (fonctionnant sous Debian Bullseye/11.x). Remarque : nous avons décidé de sauter les numéros de version 5 à 10 afin de suivre la numérotation des versions Debian.

Notes importantes​

  • L'équipe YunoHost a fait tout son possible pour que la migration se déroule dans les meilleures conditions possibles et l'a testée pendant plusieurs mois dans différents cas de figure.

  • Cela dit, sachez qu'il s'agit d'une opération délicate. L'administration système est un sujet complexe et il est très difficile de couvrir tous les cas particuliers. Par conséquent, si vous hébergez des données et des services critiques, veuillez effectuer des sauvegardes. Et dans tous les cas, soyez patient et attentif pendant la migration.

  • Ne vous précipitez pas en pensant que vous devriez réinstaller votre système à partir de zéro, croyant que ce serait "plus simple" (soupir). (Une attitude courante consiste à vouloir réinstaller un serveur à la moindre complication ...). Au contraire, si vous rencontrez des problèmes, nous vous encourageons à essayer de comprendre ce qui se passe et à demander de l'aide sur le chat et le forum.

  • Vous devriez consulter les problèmes connus au bas de cette page, afin de vous assurer que vos migrations fonctionneront correctement.

Procédure de migration​

Depuis la webadmin​

Après la mise à niveau vers la version 4.4.x, allez dans Outils > Migrations pour accéder à l'interface de migration. Vous devrez lire attentivement et accepter la clause de non-responsabilité, puis lancer la migration.

Depuis la ligne de commande​

Après la mise à niveau vers la version 4.4.x, exécutez :

sudo yunohost tools migrations run

puis lisez attentivement et acceptez la clause de non-responsabilité.

Pendant la migration​

En fonction de votre matériel et des paquets installés, la migration peut prendre jusqu'à plusieurs heures.

Les journaux (logs) seront affichés dans la barre de messages (vous pouvez passer la souris dessus pour voir l'historique complet). Ils seront également disponibles après la migration (comme toutes les autres opérations) dans Outils > Journaux.

Notez que même si vous fermez la page webadmin pour une raison quelconque, la migration se poursuivra en arrière-plan (mais la webadmin sera partiellement indisponible).

Si la migration a planté / échoué à un moment donné​

Si la migration a échoué à un moment donné, il devrait être possible de la relancer. Si cela ne fonctionne toujours pas, vous pouvez essayer de trouver de l'aide (veuillez fournir les messages correspondants ou tout autre élément qui vous fait penser que ça n'a pas marché).

Que faire après la mise à niveau​

Vérifiez que vous êtes bien sous Debian Bullseye et YunoHost 11.x​

Pour cela, rendez-vous dans Diagnostic (catégorie Système de base) ou consultez le pied de page de la webadmin. En ligne de commande, vous pouvez utiliser lsb_release -a et yunohost --version.

Lancez la migration pour réparer votre application Python​

Après la mise à niveau, vos applications Python devraient être indisponibles car leur environnement virtuel (venv) doit être reconstruit.

Pour ce faire, vous pouvez exécuter les migrations en attente dans Webadmin > Mises à jour. Les applications ci-dessous ne seront pas réparées automatiquement, vous devez les mettre à niveau manuellement à l'aide de la commande yunohost app upgrade -F APP.

Ces applications ne seront pas réparées automatiquement et nécessiteront une mise à niveau forcée :

  • calibreweb
  • django-for-runners
  • ffsync (cette application est en python2 et n'est plus maintenue, donc sans aucune garantie)
  • jupiterlab
  • librephotos
  • mautrix
  • mediadrop
  • mopidy
  • pgadmin
  • tracim
  • synapse
  • weblate
astuce

Si nécessaire, vous pouvez désactiver la reconstruction automatique pour une application Python spécifique, en supprimant le fichier dédié se terminant par .requirements_backup_for_bullseye_upgrade.txt avant d'appliquer la migration. Vous trouverez ce fichier près du venv (environnement virtuel Python) de votre application dans /opt ou /var/www.

Vérifiez qu'aucun problème n'est apparu dans le diagnostic​

Dans la section Diagnostic de l'interface d'administration Web, assurez-vous également qu'aucun problème spécifique n'est apparu après l'exécution de la migration (par exemple, un service qui s'est arrêté pour une raison quelconque).

Si le service php7.3-fpm semble être inactif, vous devez mettre à niveau vos applications PHP, telles que les applications web personnalisées. Ensuite, vous pouvez exécuter apt autoremove.

Vérifiez que vos applications fonctionnent correctement​

Vérifiez que vos applications fonctionnent correctement. Si ce n'est pas le cas, essayez de les mettre à jour (il est également recommandé de les mettre à jour même si elles fonctionnent correctement).

Si votre application ne fonctionne plus et que vous disposiez déjà de la dernière version, vous pouvez relancer la mise à niveau grâce à l'option -F|--force :

yunohost app upgrade --force APP_NAME

Problèmes courants connus après la migration​

Impossible d'exécuter la migration en raison de libc6-dev : Breaks : libgcc-8-dev issue​

Remarque : ce problème devrait être résolu dans yunohost_version : 4.4.2.13 Vous disposez d'une application qui dépend du paquet build-essential.

Consultez cette solution pour le corriger manuellement.

DNSmasq ne fonctionne plus​

Nous n'avons pas encore trouvé de solution à ce problème.

Pas de connexion Ethernet après redémarrage suite à une migration sur un Raspberry Pi 4​

attention

Si vous n'avez pas encore redémarré votre serveur, ne le faites pas (nous recherchons une solution). Cela vous évitera d'utiliser un clavier et un écran.

Nous avons trouvé ceci dans la documentation du Raspberry Pi.

Lorsque le paquet dhcpcd5 est mis à jour vers la dernière version (1:8.1.2-1+rpt1 -> 1:8.1.2-1+rpt2), le Raspberry Pi ne parvient pas à obtenir une adresse IP DHCP après le redémarrage suivant ou au démarrage. Ce problème peut être évité en désactivant puis en réactivant l'option "System Options -> Network at Boot" (Options système -> Réseau au démarrage) à l'aide de la dernière version de raspi-config après la mise à jour du paquet dhcpcd5 et avant l'arrêt ou le redémarrage du système.

Si vous utilisez un Raspberry Pi 4 (ou peut-être un RPi 3), consultez cette solution.

Restaurer la sauvegarde ynh4 sur un nouveau ynh11​

Si vous ne parvenez pas à restaurer votre application mais que votre système a été restauré, vous devriez probablement utiliser regen conf pour résoudre les problèmes nginx :

yunohost tools regenconf nginx --force

Après cela, vous devriez pouvoir restaurer vos applications. N'oubliez pas de forcer leur mise à jour si vous obtenez des erreurs 502.