Transfert GRR sur un nouveau serveur et migration de 1.9.7e en 3.4.0

  • olivierardouin
  • Auteur du sujet
  • Nouveau membre
  • Nouveau membre
Plus d'informations
il y a 5 ans 9 mois #1049 par olivierardouin
Bonjour,

Je tente de transférer une instance de GRR (en 1.9.7e) d'un serveur vers une nouvelle instance (en 3.4.0) sur un nouveau serveur.

Pas de soucis pour faire un export de la base de données de l'ancien serveur, cela me donne un fichier .sql .

Pas de soucis pour configurer un grr "vierge" sur le nouveau serveur en 3.4.0 avec une nouvelle base mysql (mariadb) les mêmes noms de base de données, d'utilisateur sql et de login sql.

Sur la nouvelle instance, je lance une restauration à partir de l'export (.sql) de l'ancienne base. Le process semble se passer correctement.
J'obtiens une demande de mise à jour de la base de données, un message d'information (ci-dessous). Mais à chaque tentative de connexion, je retombe invariablement sur cette demande de mise à jour de la base de données...

le message d'information est le suivant:

"Numéro de version GRR fichier : 3.4.0
Numéro de version GRR BDD : 1.9.7
Préfixe : pgm
---
Système d'exploitation : Linux opxx.xx.x..fr 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64
Version PHP : 7.2.7
Base de données : mysql 5.5.56-MariaDB
---
Time : 1531407580
Date du serveur (Jour-Mois-Annee) : 12-07-2018. Heure : 16:59
Timezone (date_default_timezone_set) : Europe/Paris"


Une idée ? Passez par des versions intermédiaires ? Mais en parcourant le forum, il semble que cela ne soit pas nécessaire...

merci

Connexion ou Créer un compte pour participer à la conversation.

  • Yan
  • Developpeur GRR
  • Developpeur GRR
Plus d'informations
il y a 5 ans 9 mois #1050 par Yan
Bonjour,
en effet, il ne devrait pas être nécessaire de passer par des étapes intermédiaires.
Soit le processus de mise à jour s'est mal passé, soit il est buggé...
Avez-vous un accès phpmyadmin à votre BDD ?
Dans ce cas, quelle est la valeur du champ "version" de la table "setting" ?
Eventuellement, corrigez-le en 3.4.0 et vérifiez si tout va bien.
Merci de nous rendre compte de vos manip'
Cordialement,
YN

Connexion ou Créer un compte pour participer à la conversation.

  • olivierardouin
  • Auteur du sujet
  • Nouveau membre
  • Nouveau membre
Plus d'informations
il y a 5 ans 9 mois - il y a 5 ans 9 mois #1051 par olivierardouin
Bonjour,
Merci pour l'info,
J'ai édité la table setting et changé le champ version de 1.9.7 en 3.4.0
mais hormis le message d'information qui commence maintenant par "Numéro de version GRR fichier : 3.4.0
Numéro de version GRR BDD : 3.4.0"

le problème est maintenant, à la connection :
"La connection au serveur mysql est établie mais certaines tables sont absentes de la base grr."

et en choisissant "Mettre à jour la base Mysql" je tourne en boucle...
Dernière édition: il y a 5 ans 9 mois par olivierardouin.

Connexion ou Créer un compte pour participer à la conversation.

  • Yan
  • Developpeur GRR
  • Developpeur GRR
Plus d'informations
il y a 5 ans 9 mois #1052 par Yan
Cela ressemble fort à un bug.
Puisque vous accédez par phpmyadmin, pouvez-vous nous dire combien de tables contient la base ? Ou comparer la liste des tables après l'installation de la 3.4.0 et après la séquence restauration puis mise à jour ?
Cordialement,
YN

Connexion ou Créer un compte pour participer à la conversation.

  • olivierardouin
  • Auteur du sujet
  • Nouveau membre
  • Nouveau membre
Plus d'informations
il y a 5 ans 9 mois - il y a 5 ans 9 mois #1053 par olivierardouin
Bonjour,

Je ne dispose pas de PHPmyadmin, mais sur le serveur "originel" uniquement de la possibilité de sauvegarder la base (un dump mysql). Par contre j'ai accès à la console mysql sur le nouveau serveur.

Sur le nouveau serveur (après import) j'ai 26 tables :
MariaDB [grr]> show tables;
+
+
| Tables_in_grr |
+
+
| pgm_area |
| pgm_area_periodes |
| pgm_calendar |
| pgm_calendrier_feries |
| pgm_calendrier_jours_cycle |
| pgm_calendrier_vacances |
| pgm_correspondance_statut |
| pgm_entry |
| pgm_entry_moderate |
| pgm_j_mailuser_room |
| pgm_j_site_area |
| pgm_j_type_area |
| pgm_j_user_area |
| pgm_j_user_room |
| pgm_j_useradmin_area |
| pgm_j_useradmin_site |
| pgm_log |
| pgm_modulesext |
| pgm_overload |
| pgm_page |
| pgm_repeat |
| pgm_room |
| pgm_setting |
| pgm_site |
| pgm_type_area |
| pgm_utilisateurs |
+
+
26 rows in set (0.00 sec)

en regardant dans le dump de la base de départ j'ai uniquement les information pour créer 22 tables :

>grep "DROP" ngs_le_2018_07_12_a_17h05.sql
DROP TABLE IF EXISTS `pgm_area`;
DROP TABLE IF EXISTS `pgm_area_periodes`;
DROP TABLE IF EXISTS `pgm_calendar`;
DROP TABLE IF EXISTS `pgm_calendrier_jours_cycle`;
DROP TABLE IF EXISTS `pgm_entry`;
DROP TABLE IF EXISTS `pgm_entry_moderate`;
DROP TABLE IF EXISTS `pgm_type_area`;
DROP TABLE IF EXISTS `pgm_j_type_area`;
DROP TABLE IF EXISTS `pgm_j_mailuser_room`;
DROP TABLE IF EXISTS `pgm_j_user_area`;
DROP TABLE IF EXISTS `pgm_j_user_room`;
DROP TABLE IF EXISTS `pgm_log`;
DROP TABLE IF EXISTS `pgm_repeat`;
DROP TABLE IF EXISTS `pgm_room`;
DROP TABLE IF EXISTS `pgm_setting`;
DROP TABLE IF EXISTS `pgm_utilisateurs`;
DROP TABLE IF EXISTS `pgm_j_useradmin_area`;
DROP TABLE IF EXISTS `pgm_overload`;
DROP TABLE IF EXISTS `pgm_site`;
DROP TABLE IF EXISTS `pgm_j_useradmin_site`;
DROP TABLE IF EXISTS `pgm_j_site_area`;
DROP TABLE IF EXISTS `pgm_correspondance_statut`;


la différence en termes de nombre de tables sont les suivantes :

pgm_calendrier_feries |
| pgm_calendrier_vacances |
| pgm_modulesext |
| pgm_page

présente uniquement sur le nouveau serveur.

Y a-t-il des logs spécifiques consultables ?
Dernière édition: il y a 5 ans 9 mois par olivierardouin. Raison: precisions

Connexion ou Créer un compte pour participer à la conversation.

  • Yan
  • Developpeur GRR
  • Developpeur GRR
Plus d'informations
il y a 5 ans 9 mois #1054 par Yan
Bonjour,
merci pour votre retour.
22 tables en 1.9.7e et 26 tables en 3.4.0, c'est normal.
Ce qui cloche, c'est que le script de mise à jour ne crée pas les tables manquantes... Je fouille pour trouver le bug.
Cordialement,
YN

Connexion ou Créer un compte pour participer à la conversation.

  • Yan
  • Developpeur GRR
  • Developpeur GRR
Plus d'informations
il y a 5 ans 9 mois - il y a 5 ans 9 mois #1055 par Yan
Je n'ai pas trouvé la cause de ce bug, mais un palliatif : connecté en administrateur, pouvez-vous exécuter le script de mise à jour forcée :
Code:
https://localhost/GRR340/admin/admin_maj.php?force_maj=
en remplaçant le début de l'URL par ce qui convient à votre configuration ?
Cela devrait ajouter les tables manquantes.
Cordialement,
YN
Dernière édition: il y a 5 ans 9 mois par Yan.

Connexion ou Créer un compte pour participer à la conversation.

  • olivierardouin
  • Auteur du sujet
  • Nouveau membre
  • Nouveau membre
Plus d'informations
il y a 5 ans 9 mois #1057 par olivierardouin
Bonjour,

J'ai testé cet URL pour forcer la MAJ, mais cela ne change rien à mon soucis.

Je me suis peut-être mal exprimé dans mon message précédent, mais les 4 tables supplémentaires sont biens crées dans la base mysql.
Mon problème est qu'en voulant me connecter au GRR je tombe invariablement sur la page ..../admin/admin_maj.php :
"Mise à jour de la base de données (accès administrateur)"

puis après saisie des login et mot de passe cette page :

"
Numéro de version et mise à jour
Informations
Copier dans le presse-papiers

Numéro de version GRR fichier : 3.4.0
Numéro de version GRR BDD : 1.9.7
Préfixe : pgm
---
Système d'exploitation : Linux grr.xxx.fr 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64
Version PHP : 7.2.7
Base de donnée : mysql 5.5.56-MariaDB
---
Time : 1531736248
Date du serveur (Jour-Mois-Annee) : 16-07-2018. Heure : 12:17
Timezone (date_default_timezone_set) : Europe/Paris

Recherche de mises à jour avec le serveur officiel de GRR"

et plus rien sous cette dernière ligne...

une idée ?

Connexion ou Créer un compte pour participer à la conversation.

  • olivierardouin
  • Auteur du sujet
  • Nouveau membre
  • Nouveau membre
Plus d'informations
il y a 5 ans 9 mois #1058 par olivierardouin
Je viens d'essayer avec la version 3.3.1a du GRR et j'ai le même problème.

après la mise à jour j'obtient :

:Numéro de version et mise à jour
Numéro de version de GRR
Numéro de version : GRR 3.3.1a

Préfixe : pgm

Base de donnée : 5.5.56-MariaDB
Système d'exploitation : Linux openv.iurc.montp.inserm.fr 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64
Version PHP : 7.2.7
Rendez-vous sur le site de GRR pour connaître la dernière version : GRR (Gestion et Réservation de Ressources) V3


Recherche de mises à jour avec le serveur officiel de GRR:"

et pas d'accès au GRR...

Connexion ou Créer un compte pour participer à la conversation.

  • olivierardouin
  • Auteur du sujet
  • Nouveau membre
  • Nouveau membre
Plus d'informations
il y a 5 ans 9 mois #1059 par olivierardouin
Je pense avoir trouvé un palliatif:

en cherchant une ancien version j'ai à tout hasard téléchargé celle-ci:

github.com/mtalmont/grr.git
qui est une 3.7 ? je n'ai pas regardé dans les détails mais c'est peut-être un fork.

quoiqu'il en soit :

installation de cette version sur une base mysql vide. Création de la base du GRR (vide). connexion, mise à jour, --> OK

Conservation de la base mysql

Installation des fichiers de la v 3.4.0, mise à jour "forcée" de la base de donnée ---> j'ai accès même si certain champs de présentation (Mairie de Thalmont St Hilaire) ne sont pas à jour.

Ce n'est pas super satisfaisant comme migration car vu que certains champs ne sont pas passés, j'ai un doute sur ceux non vérifiés.

Y à t'il des anciennes version 2 stable qui seraient téléchargeables pour faire une étape ?

Connexion ou Créer un compte pour participer à la conversation.

Modérateurs: Yan