Migration vers Yunohost 4 non effective [RESOLU]

Mon serveur YunoHost

Mini PC sous Win10 (64) 4core 4g de ram sur lequel est hébergé Yunohost en VM (500g dédiés)
**Version de YunoHost: 3.8.5.9 (stable) (Debian 9.13)
J’ai accès à mon serveur : En SSH (en local) et Par la webadmin

Bonjour à tous,

En voulant effectuer la dernière mise à jour de Nextcloud (de 20.0.4~ynh1 à 20.0.7~ynh1), j’ai eu le message d’erreur suivant:
Les pré-requis de nextcloud ne sont pas satisfaits, le paquet yunohost (3.8.5.9) doit être >= 4.1.6

Je fonce dans migration persuadé que j’ai fait la migration vers Yunohost 4 depuis des lustres et j’ai bien ceci:
15. Mise à niveau du système vers Debian Buster et YunoHost 4.x
14. Supprimer les anciens fichiers d’application status.json
13. Migrer vers le nouveau système de catalogue d’applications à l’épreuve du temps
12. Forcer l’authentification PostgreSQL à utiliser MD5 pour les connexions locales
11. Initialiser les groupes d’utilisateurs et autorisations pour les applications et les services
10. Supprimer les catalogues d’applications obsolètes afin d’utiliser la nouvelle liste unifiée ‘apps.json’ à la place (les anciens catalogues seront remplacés durant la migration 13)
9. Dissocier le mécanisme « regen-conf » des services
8. La configuration SSH sera gérée par YunoHost (étape 2, manuelle)
7. La configuration SSH sera gérée par YunoHost (étape 1, automatique)
6. Synchroniser les mots de passe admin et root
5. Migration des bases de données de PostgreSQL 9.4 vers PostgreSQL 9.6
4. Reconfigurer l’ensemble PHP pour utiliser PHP 7 au lieu de PHP 5
3. Mise à niveau du système vers Debian Stretch et YunoHost 3.0
2. Amélioration de la sécurité de DynDNS TSIG en utilisant SHA512 au lieu de MD5
1. Changement des permissions de groupe des certificats de « metronome » à « ssl-cert »

Néanmoins, je constate que la version de yunohost est en réalité la 3.8.5.9.

Je ne relève pas d’alerte particulière dans le diagnostic et les journaux ne signalent pas de problème:
L’architecture du serveur est oracle amd64
Le serveur utilise le noyau Linux 4.9.0-14-amd64
Le serveur utilise Debian 9.13
Le serveur utilise YunoHost 3.8.5.9 (stable)
yunohost version : 3.8.5.9 (stable)
yunohost-admin version : 3.8.3.5 (stable)
moulinette version : 3.8.1.3 (stable)
ssowat version : 3.8.0.3 (stable)

Du coup je sèche…

Merci de votre aide :grinning:

Est-ce que tu peux partager le journal de la migration que tu devrais trouver dans Outils > Journaux > … appliquer la migration 15 (un truc du genre)

1 Like

Bonjour et merci pour votre retour.
Alors je ne peux pas remonter aussi loin dans le log proposé par l’interface web de yunohost.

Je présume que le log intéressant est celui de tools_upgrade, le voici:
[lien effacé]

S’il s’agit d’un autre fichier, ne pas hésiter à me le préciser.

Je précise que j’ai également tenté de relancer la migration (qui n’est pas proposée dans “migration”) avec:
sudo yunohost tools migrations migrate
Et logiquement j’ai obtenu:
Info: Aucune migration à lancer

Edit: je précise un dernier point, après un diagnostic, j’ai ceci :
Le fichier de configuration /etc/ssh/sshd_config semble avoir été modifié manuellement.
(Je n’ai pas le souvenir d’y avoir touché)

Mouarf bon ben je sais pas ce qui s’est passé mais ton log le plus récent montre que tu es toujours en stretch (en fait on pouvait le savoir plus tôt vu que le diagnostique disait : Le serveur utilise Debian 9.13 … bref ce n’est pas juste le paquet yunohost qui n’a pas réussi à passer en 4.x comme je le pensais au début)

Mon hypothèse c’est que tu as cliqué sur le bouton orange “Skip” plutôt que le bouton vert “Run” (ou équivalent en français)

Bref, du coup depuis la ligne de commande en SSH je ferais un

sudo nano /etc/yunohost/migrations.yaml

tu devrais voir la ligne 0015 avec “skipped” à la fin (d’après mon hypothèse). Dans tous les cas, supprime cette ligne, sauvegarde/quitte avec Ctrl+X, Y pour valider, Entrée.

Ensuite tu devrais avoir de nouveau la migration proposée dans l’interface

1 Like

Effectivement j’ai du m’auto-persuader d’avoir fait la migration, j’ai bien la ligne 15 avec skipped.

Ce qui est très curieux c’est que j’ai en réalité les 15 lignes qui se terminent pas skipped alors que je suis un peu un nazi de la mise à jour:
migrations:
0001_change_cert_group_to_sslcert: skipped
0002_migrate_to_tsig_sha256: skipped
0003_migrate_to_stretch: skipped
0004_php5_to_php7_pools: skipped
0005_postgresql_9p4_to_9p6: skipped
0006_sync_admin_and_root_passwords: skipped
0007_ssh_conf_managed_by_yunohost_step1: skipped
0008_ssh_conf_managed_by_yunohost_step2: skipped
0009_decouple_regenconf_from_services: skipped
0010_migrate_to_apps_json: skipped
0011_setup_group_permission: skipped
0012_postgresql_password_to_md5_authentication: skipped
0013_futureproof_apps_catalog_system: skipped
0014_remove_app_status_json: skipped
0015_migrate_to_buster: skipped

J’ai modifié la dernière ligne, la migration m’a été proposée.
Je l’ai lancé et elle est passée comme une fleur !
Merci beaucoup pour ton aide ! :slight_smile:
### 19. Étendre et retravailler le système de gestion des permissions applicatives
### 18. Migrer les anciennes règles de trafic réseau vers le nouveau système basé sur nftables
### 17. Migrer les bases de données de PostgreSQL 9.6 vers 11
### 16. Migrer les configurations php7.0 vers php7.3
### 15. Mise à niveau du système vers Debian Buster et YunoHost 4.x

Penses-tu qu’il faudrait que je retire les 14 autres lignes qui ont encore skipped ? (Je me demande si en rapatriant ma sauvegarde originellement sur un VPS pour la monter sur mon serveur perso, j’ai pas fait une fausse manip pour avoir tout ces skipped )

Arg bon en fait je comprends ce qu’il s’est passé : tu as fait une réinstallation/restauration sur un serveur en Stretch après qu’on ai sorti Buster. Mais lorsque tu fais l’install/postinstall, il commence pas skip toutes les migrations disponibles, dont la 15, quand bien même elle a un statut particulier et ne devrais pas pouvoir être skip. C’est donc plutôt ma faute haha :stuck_out_tongue:

Mais du coup il n’y a pas besoin de “de-skip” les autres migrations, c’est normal et souhaitables qu’elles aient été skip

1 Like

Merci pour ta réponse qui me rassure.

Si besoin de mes logs ou autres pour vous permettre d’intégrer ce type de situation, ne pas hésiter.

Merci encore :slight_smile:

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.