Migration grr 1.9.7e vers 3.5.1 : accès compte administrateur

Bonjour,
Nous avons un site grr 1.9.7e (centos 6) et nous voulons le mettre à jour vers grr 3.5.1.
Pour cela, depuis une nouvelle VM en Rocky Linux 8 (PHP 7.4 et MariaDB 10.3.39), j'ai déposé les scripts et le site a été initialisé à partir de l'interface web.
Nous avons un site opérationnel qu'on atteint par grr.mondomaine .
J'ai repris les mêmes identifiants de connexion à la base de données.

J'ai importé les données de la base de données du grr 1.9.7e et l'import se passe bien.
Le problème arrive lorsque je veux me connecter avec un compte administrateur sur grr.mondomaine/login.php .
Il est impossible d'aller sur la page pour faire les montées de version.
J'obtiens une URL : grr.mondomaine/admin/logout.php?auto=1&u...dmin%2Fadmin_maj.php
et une page blanche avec : File not found.

Les logs :
"GET /login.php HTTP/1.1" 302 -
"GET /admin/admin_maj.php HTTP/1.1" 302 -
"GET /admin/logout.php?auto=1&url=%2Fadmin%2Fadmin_maj.php HTTP/1.1" 404 16
Sous l'ancien site, nous avons un SSO HTTP. Sur le nouveau site, celle-ci passe bien, mais il y a un échec de connexion à GRR.Ce qui serait normal à ce stade étant donné que la base de données n'a pu encore être upgradé.

Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, bool given in /var/www/html/grr/include/mysql.inc.php on line 131
Echec de connexion à GRR.
Identification correcte mais l'importation du profil est impossible. Veuillez signaler ce problème à l'administrateur GRR

J'ai essayé de passer dans include/config.inc.php, la valeur de "$sso_super_admin" à "true" -> sans effet
J'ai alors effacé dans la table grr_setting la valeur du paramètre "sso_statut" : http_utilisateur", pour ne plus faire appel au SSO HTTP.
J'ai aussi changé la valeur de grr_url avec le nouveau site, mais sans résultat probant.

Je ne vois pas trace de ce problème dans l'historique du forum.
Auriez-vous une idée sur le problème ?
J'ai pensé aussi à appliquer à la main la mise à jour de la base en reprenant les requêtes présentes dans admin/admin_maj.php, mais est-ce une bonne idée ? :
ALTER TABLE ".TABLE_PREFIX."_entry CHANGE create_by create_by VARCHAR( 100 ) NOT NULL  default '';
...
Merci pour votre aide.




 

Bonjour,
je vous conseille de créer un utilisateur "local" avec les droits d'administrateur dans l'ancienne version de GRR, afin de pouvoir reprendre la main lorsque vous restaurerez les bases de l'ancienne vers la nouvelle.
Il y a des paramètres complémentaires qui ont été introduits dans les réglages du SSO, peut-être est-ce une autre source de problèmes.
Il y a aussi visiblement une erreur de calcul dans l'URL de redirection vers la page de logout, mais c'est accessoire.
De toutes façons, garder un administrateur local est un bonne précaution pour gérer GRR.
N'hésitez pas à revenir pour d'autres pistes.
Cordialement,
YN

Bonjour,
Je vous remercie pour votre assistance.
Nous avons bien un compte administrateur local avec les droits administrations dans notre grr 1.9.7e et nous l'utilisons sans problème.
Je confirme notre soucis de ne pas avoir la page d'authentification pour accéder au compte local, même après avoir retiré l'authentification SSO HTTP dans la table grr_setting.

Je signale aussi ce bug :
Sur le nouveau site grr 3.5.1, neuf, sans import de base, j'ai testé l'authentification SSO HTTP. Je l'ai donc activé depuis un compte administrateur. Après après avoir entré mes identifiants dans la session http (authentification ldap apache), une erreur est intervenue :

Un problème est survenu lors de la création d'un nouvel utilisateur ! Veuillez contacter le support technique.Data too long for column 'nom' at row 1

J'ai réglé facilement ce problème en modifiant dans grr_utilisateurs la colonne nom de type varchar(30) en type varchar(100).
C'est alors passé.
Mais il me faut absolument pouvoir mettre à jour la base après l'avoir importé de grr 1.9.7 et donc je vais tenter d'appliquer à la main les différentes commandes de montée en version de la base.
Je vous ferai un retour du résultat.

Cordialement


 

Bonjour,
merci pour votre retour.
C'est la première fois que l'on nous remonte un problème sur le champ "nom".
Passer à varchar(100) est peut-être beaucoup, non ? Dans votre base, l'utilisateur qui fait bloquer l'import a un nom de quelle longueur ?
Avez-vous bien suivi les instructions de mise à jour indiquées dans le fichier INSTALL.txt ?
Cordialement,
YN

Bonjour,
Il s'est passé la chose suivante sur le SSO HTTP de grr 3.5.1: c'est par l'adresse mail qu'on s'identifie dans apache et grr cherche à la copier dans la colonne "nom". Effectivement mon adresse mail dépassait les 30 caractères, d'où l'erreur. Mais le problème sur le champ nom est secondaire.

Le plus important :
J'ai réussi à importer dans grr 3.5.1 les données du grr 1.9.7 en modifiant "à la sauvage" le script admin/admin_maj.php
J'ai compris que c'est l'appel à ce code qui bloquait tout :
// si pas en mode script, vérifier que la session est ouverte
if(!$majscript){
    // Session related functions
    require_once("../include/session.inc.php");
    require_once("../include/resume_session.php");
    // Paramètres langage
    include "../include/language.inc.php";
}

J'ai commenté une grande partie du code pour me passer de la vérification de la session et de l'authentification, pour ne conserver que les fonctions de mises à jour.
La base de données a été upgradée et tout fonctionne bien.
J'ai même remis le SSO HTTP et l'authentification passe et je retrouve tous les sites, domaines, réservations effectuées dans grr 1.9.7.

Je voudrais vous remercier pour ce bel outil et vous demander si vous pouviez me donner un conseil pour faire la migration de façon plus propre le jour de la mise en production.
Une variable à positionner dans le script ?

 

Merci pour votre retour.
Je ne comprends pas ce qui pose problème avec l'authentification locale pour faire la mise à jour.
Il y a peut-être un réglage à faire dans l'authentification http pour que l'adresse mail arrive dans le login plutôt que le nom.
Si ce contournement du problème vous donne un fonctionnement satisfaisant, je ne vois pas pourquoi hésiter à passer en production. Il faudra juste faire attention lors des futures mises à jour.
À suivre...
Cordialement,
YN

Merci Yan
Effectivement je reste toujours avec le script d'origine admin_maj.php qui ne fonctionne pas, sans que je sache pourquoi.
Je pense que toute façon, je vais rester en version 3.5.1, sans aller vers la version 4.2.3. Trop compliqué pour l'instant lorsqu'on part de grr 1.9.7 !

Je voudrais encore vous demander quelle version de PHP est compatible avec la 3.5.1 ?
PHP 8.0 ? 8.1 ? 8.2 ? 8.3 ?

Cordialement

 

Je fais les développements en php 8.2 et vérifie épisodiquement la compatibilité avec php 7.4 et php 5.6.
Je n'ai pas encore testé php 8.3.
Cordialement
YN

Merci pour toutes ces infos.
Bien cordialement