You are not logged in.
Bonjour,
J'ai un souci lors de la migration de mon glpi.
Ma configuration actuelle:
machine virtuelle Hyper-v
OS : eyesofnetwork release 4.2 charline
glpi: version 0.85.4 avec OCS inventory NG
Opérations effectuées:
sur glpi 0.85.4, sauvegarde de la base SQL -> OK
Création d'une machine virtuelle sur VMWARE, avec os Debian Buster ->OK
Sur cette machine installation de apache2, php, mysql (mariaDB), perl -> OK
Paramétrage mysql ->OK
Téléchargement et installation de glpi version 0.85.4, et attribution des permissions-> OK
Import de la base sql de mon ancien glpi dans le nouveau ->OK
Connexion via le web avec l'adresse ip du nouveau glpi, et installation -> OK
Je peux me log avec les mêmes identifiants de sur mon ancien glpi -> OK
Mon problème se situe ici:
je ne peux me connecter que sur des comptes utilisateurs "self-service", je vois bien les données, elles sont présentes, de même lorsque je consulte la base avec phpmyadmin, tout est bon.
Mon compte utilisateur a 3 habilitations, self-service, technicien et super-admin.
Le souci c'est que lorsque je passe en technicien ou en super-admin, ma page glpi est blanche...
Même résultat quand je me connecte avec le compte glpi, pas de message d'erreur, il se connecte bien, mais affiche juste une page blanche.
Je bloque à cet endroit, en sachant que l'étape que je souhaitais effectuer après, était de lancer la mise à jour de glpi afin de monter jusqu'à la version 9.4.3.
Je pense avoir été le plus clair possible sur ma situation, si vous avez des pistes pour m’aiguiller je suis preneur.
Merci
Offline
Bonjour,
Quelques pistes :
- Est-ce que les droits sur les fichiers sont corrects ?
- Vidage du cache du navigateur ?
- la version de PHP est-elle correcte avec les prérequis glpi ?
- y a-t-il des messages d'erreur dans les logs apache, glpi ?
- y at-t-il eu altération du fichier export SQL en passant par windows (problème de page de code par exemple)
- comment a été fait l'export : un mysqldump est obligatoire.
- y a-t-il eu des erreurs lors de l'import (taille maxi upload php...) ?
Contexte : GLPI 9.4.3/FusionInventory 9.4+1.1 / Agent FI 2.5.1
Offline
Bonjour mab3,
Pour répondre à tes questions:
-J'ai bien attribué les droits sur le dossier /usr/share/glpi
-Vider le cache n'a rien donné
-J'utilise php7, je ne pense pas qu'il y ai de problèmes de compatibilité avec mon glpi 0.85.4
-Les logs d'erreurs de apache en voici un:
[Wed Sep 18 15:35:19.480568 2019] [php7:error] [pid 16114] [client 192.168.9.18:49428] PHP Fatal error:
'continue' not in the 'loop' or 'switch' context in /usr/share/glpi/inc/transfer.class.php on line 2079, referer: http://192.168.9.18/glpi/front/login.php
Log d'erreur glpi:
*** PHP Notice(8): A non well formed numeric value encountered
Backtrace :
inc/toolbox.class.php:1948
inc/document.class.php:437 Toolbox::return_bytes_from_ini_vars()
inc/ticket.class.php:3000 Document::getMaxUploadSize()
front/helpdesk.public.php:94 Ticket->showFormHelpdesk()
2019-09-18 15:18:22 [3@SRV-GLPI-01]
*** PHP Notice(8): A non well formed numeric value encountered
Backtrace :
inc/toolbox.class.php:1948
inc/document.class.php:437 Toolbox::return_bytes_from_ini_vars()
inc/ticket.class.php:3000 Document::getMaxUploadSize()
front/helpdesk.public.php:94 Ticket->showFormHelpdesk()
2019-09-18 15:18:24 [3@SRV-GLPI-01]
*** PHP Notice(8): A non well formed numeric value encountered
Backtrace :
inc/toolbox.class.php:1948
inc/document.class.php:437 Toolbox::return_bytes_from_ini_vars()
inc/ticket.class.php:3000 Document::getMaxUploadSize()
front/tracking.injector.php:100 Ticket->showFormHelpdesk()
-pas d'altération du fichier sql
-l'export a été fait depuis glpi ->administration >maintenance>sauvegarde sql
-pas d'erreur d'import
Je rajoute aussi que j'ai effectuer des test avec une nouvelle base toute de neuve de glpi et le problème est le même, page blanche avec le compte glpi, tech, normal, mais ça marche avec le compte post-only.
Donc cela ne vient pas de la base de mon ancien glpi.
Offline
Il est préférable de faire un export avec mysqldump et l'import avec mysql que de passer par la maintenance interne de GLPI
Manger un castor, c'est sauver un arbre.
Quand on est mort, on ne sait pas qu'on est mort ; c'est pour les autres que c'est difficile. Quand on est con, c'est pareil !
Offline
Petite question : es-tu certain d'avoir bien mis la nouvelle version de GLPI dans ton serveur ?
Je suis en 9.4.3, et j'ai
return_byte_from_ini_vars en ligne 460 dans inc/document.class.php
getMaxUploadSize en ligne 5212 dans inc/ticket.class.php
et
showFormHelpdesk en ligne 90 dans front/tracking.injector.php
Donc nos version ne correspondent pas.
Afin d'être certain, peux-tu donner le retour de :
head /var/www/html/glpi/CHANGELOG.md (ou ailleurs, selon ta config)
moi, j'ai :
(...)
## [9.4.3] unreleased
(...)
Contexte : GLPI 9.4.3/FusionInventory 9.4+1.1 / Agent FI 2.5.1
Offline
@sico31
c'est noté. Par contre le problème ne viens pas de ma base car même avec une nouvelle base j'ai toujours le souci.
@mab3
Non en effet, comme je l'ai dit dans mon post plus haut, j'ai installer la 0.85.4 sur le nouveau serveur car je voulais faire la mise à jour vers 9.4.3 dans un deuxième temps.
J'avais lu aussi quelque part qu'il ne valait mieux pas faire directement un import export de la base glpi de 0.85.4 vers 9.4.3.
Offline