sudo -u postgres psql lufi -c 'UPDATE mojo_migrations SET version = 6;'
could not change directory to "/var/www/lufi/utilities": Permission denied
UPDATE 1
sudo -u postgres psql lufi -c 'SELECT * FROM mojo_migrations;'
could not change directory to "/var/www/lufi/utilities": Permission denied
name | version
------------+---------
migrations | 6
(1 row)
YEAH ! \o/ Tu saurais m’expliquer ?
(y’a encore un petit bug mais bon…)
BRAVO ! et merci !
Success! lufi upgraded
sh: 0: getcwd() failed: No such file or directory
Ce n’est rien : tu es juste dans un répertoire qui, à un moment, a été supprimé -j’imagine que c’est /var/www/lufi ?-
exactement ^_^’
/var/www/lufi/utilities/migrations
Et bien, bien joué !
(et tout ça pour une version “wrong commit”, c’est dommage, ça fera pas avancer le schmilblick de manière très intéressante…)
Mais merci pour votre acharnement à vous deux @otm33 et @marc !
La version buguée 0.07.2 appliquait une migration => 7 alors que la version 0.07.3 arrête les migrations à la version 6. Oui, tu peux aussi remercier @marc qui avait vu le lien avec la base de données. Le dév donnait la solution au problème mais je ne comprenais pas pourquoi tu revenais en version 7 et je n’ai trouvé nulle part le fichier pg.sql avec la mention de cette migration.
Content pour toi que cela ait finalement réussi et j’espère qu’il n’y aura pas d’effet néfaste ou indésirable.
1 Like
@marc Comme tu le suggérais, un script lisait les migrations et ces dernières menaient à la version à 7.
Un beau travail d’équipe 
C’est cool, ça fait plaisir en tout cas ! 
Je ne comprends toujours pas. Tu lui a fais modifier le pg.sql de son installation actuelle, et je n y vois pas de lien avec la valeur 7 de la version ni avec les scripts d upgrade ynh…
J ai fait ce que j ai pu, a ma modeste mesure
@marc pg.sql répertorie les migrations et les commandes à exécuter pour les effectuer; dans l’installation de @Jeey , les intructions allaient jusqu’à la version 7.
Chaque fois qu’il effectuait des changements directement dans la base de données, les scripts (et notamment la ligne citée plus haut) passaient derrière lui à chaque extinction, démarrage ou redémarrage du service. Je crois que cela devait se passer comme ça :
- Modification manuelle dans la base postgres → version active dans la db: 6
- Lancement de l’upgrade :
- backup → sauvegarde de la db avec comme version active 6
- stop lufi → lancement du script → lecture de
pg.sql→ migrations → version active dans la db: 7 - installation des nouvelles sources (qui contiennent un nouveau
pg.sqlne mentionnant plus de migration 7) → démarrage → lancement du script → lecture du nouveaupg.sql→ erreur : la dernière migration dans le nouveaupg.sqlest la numéro 6 alors que la version active dans la db est la 7 = échec de l’upgrade. - restauration du backup donc de la db avec comme version active 6, démarrage de lufi → lancement du script → lecture de
pg.sql→ migrations → version active dans la db: 7, etc.
1 Like
Bonne analyse sur les migrations de la base de données, c’était un vrai casse-tête avec la version 7. Heureusement, le backup a bien sauvé la situation. Merci à vous pour l’échange et la solution trouvée !
1 Like
Bonjour @otm33 ,
désolé je reviens sur ce sujet car je ne comprenais pas grand-chose au fonctionnement que tu expliquais, car je n’ai vu nulle part dans le code la saisie de version dans mojo_migrations
Après avoir passé un peu de temps à étudier le code, j’ai compris:
- le service défini par lufi fait appel au script
/var/www/lufi/utilities/lufi.service - Dans ce script, le démarrage et l’arrêt du service font tous les deux appel au
script /var/www/lufi/script/lufi - ce script contient tout simplement la commande
Mojolicious::Commands->start_app(‘Mounter’);Il s’agit de démarrer le script/var/www/lufi/lib/mounter.pm - Ce script démarre le plugin
var/www/lufi/lib/Lufi/Plugin/Helpers/pm... - …qui fait les migrations de base de données grâce aux fonctions de Mojo::Pg::Migrations et au script
/var/www/lufi/utilities/migrations/pg.sql - et ces fonctions de migration, décrites ici Mojo::Pg::Migrations - Migrations utilisent les commentaires
-- VERSION UP/DOWNpour augmenter le contenu (version) de la base de donnéesmojo_migrations
J’ai enfin compris comment ce foutu numéro “version” augmentait jusqu’à atteindre la versio 6 ou 7, sans qu’on retrouve le code correspondant au format SQL dans le code de lufi.
Ouf!
Concernant le bug qui nos concerne, j’ai téléchargé la version de lufi-0.07.2 disponible dans les dépôts officiels. Et cette version s’arrête bien à la version 6.
Or la version de @Jeey va jusqu’à la version 7. J’en conclus que la version Yunohost de lufi pour lufi-0.07.2 était celle de dév, pas celle officielle!! Aie
En conclusion, pour revenir à la correction de bug, je pense qu’il n’y a pas besoin de modifier le pg.sql. Un simple arrêt de service doit suffire. Donc :
sudo service lufi stop-
sudo -u postgres psql lufi -c 'UPDATE mojo_migrations SET version = 6;' -
sudo -u postgres psql lufi -c 'ALTER TABLE invitations RENAME COLUMN auth_user_mail TO ldap_user_mail;' -
sudo -u postgres psql lufi -c 'ALTER TABLE invitations RENAME COLUMN auth_user TO ldap_user; - puis relancer l’upgrade
Et puisque d’autres utilisateur vont avoir le même problème, alors je suppose que si on voulait bien faire les choses, on ajouterait, dans l’upgrade de ynh, un ensemble de commandes pour faire ça en automatique après arrêt du service. Mais c’est une autre histoire…
Cela semble en effet tout à fait logique @marc .
1 Like
YNH pointe bien vers le dépôt officiel mais la version a été corrigée upstream entretemps (on voit que le checksum a changé) et @Jeey est tombé au mauvais moment.