Bonjour, et bravo à toute la communauté yunohost. Super chouette de voir arriver le support de la migration vers buster (le tout dans l’interface web!)
Mon serveur YunoHost
Matériel: VM Version de YunoHost: 4.0.3 J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : possible Si oui, expliquer: par exemple certaines sources supplémentaires apt (pas liées à postgres) ont été déployée à un moment donnée sur la VM.
Description du problème
J’ai lancé la migration vers buster depuis l’interface web. Une bonne partie de la migration a l’air de fonctionner … il bloque un peu sur postgresql. Je vais
error: 'Migration 0017_postgresql_9p6_to_11 did not complete, aborting. Error: Command
est probablement le problème. Dans loadable_libraries.txt qu’on trouve dans /var/log/postgresql/pg_upgradecluster-9.6-11-main.*/ :
could not load library "$libdir/postgis-2.3": ERROR: could not access file "$libdir/postgis-2.3": No such file or directory
could not load library "$libdir/rtpostgis-2.3": ERROR: could not access file "$libdir/rtpostgis-2.3": No such file or directory
Je vais aller chercher comment corriger ceci coté debian, et essayer de retrouver quelle application yunohost a ajouté du postgis dans l’equation.
Et puis j’ai un peu abandonné en me disant qu’un dropdb puis un restore serait bien suffisant (il s’agit d’une install de test “preprod” donc pas de données à conserver).
Du coup après un systemctl stop mobilizon puis su postgres; dropdb mobilizon, la migration passe bien.
Je vais aller mettre une issue sur le projet mobilizon. Une rapide recherche me fais penser que https://github.com/YunoHost-Apps/umap_ynh sera peut-être aussi concerné par le problème.
Pour les fichiers concernés par la commande tools regen-conf, j’ai 2 warning sur /etc/ldap/schema/mailserver.schema et /etc/ldap/schema/sudo.schema est ce normal ?
Yep, quand ya postgis, la migration du cluster peut a priori pas passer par pg_upgradecluster comme ça. Il faut que tu le fasses à version égale de postgis, ce qui n’est pas ultra facile sur une upgrade de debian, parce qu’en général t’as pas les paquets qu’il faut (en gros, faudrait pouvoir avoir soit postgresql-9.6-postgis-2.5 soit postgresql-11-postgis-2.3, sur l’une des deux distros). Une possibilités : regarder du côté de du dépôt pgdg ce qu’il y a.
Sinon, oui, je valide complètement le bon gros pg_dump/restore des familles, à condition que mobilizon n’utilise pas de fonction postgis dépréciée (un bon gros paquet ont été enlevés en 2.4). Mais bon on va dire que si Mobilizon marche correctement pour toi, c’est que c’est bon !
D’ailleurs, au passage, pour cette raison je me demande si des apps comme mobilizon qui utilisent des extensions postgresql natives qui empêchent potentiellement le pg_upgradecluster ne devraient pas créer leur propre cluster postgresql plutôt que d’utiliser celui par défaut. Elles seraient alors responsables de le mettre à jour correctement selon leur besoin.
Ou alors, il faudrait que yunohost passe par du pg_dumpall --globals, puis pg_dump/pg_restore de chaque base pour migrer le cluster postgresql la prochaine fois. (mais encore une fois, dans le cas de postgis, ça suppose que l’appli n’utilise rien de déprécié), mais bon c’est presque un peu dommage parce que ce sera beaucoup plus long et fastidieux…
(Pour info j’ai release une version 4.0.4 qui devrait résoudre les problèmes identifiés au début du thread - du genre le dropcluster qui marche pas si le cluster existe pas - ou a minima aider le debugging)
… il bloque un peu sur postgresql. Je vais
…