You are not logged in.
Bonjour,
Je voudrais partager un problème rencontré lors de l'upgrade en 0.83.1 de GLPI. Voici le contexte :
$uname -a
Linux glpi 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux
- GLPI 0.80.7 connecté à un AD depuis lequel j'ai importé environ 100 users en post-only + 4 users en admin.
- 1 collecteur email POP3
- OCSNG installé sur le même serveur et connecté à GLPI
Concernant la procédure d'upgrade, j'ai:
- sauvegardé ma base et le DocumentRoot de GLPI
- dé-tar-gzipé le glpi-0.83.1.tar.gz directement sur le DocumentRoot pour écraser les fichiers existant
Au moment d'accéder à http://<mon_serveur/glpi, le browser "tourne dans le vide" indéfiniment. Aucune page ne s'affiche. Pas de timeout même après 1h sans réponse.
Je me suis finalement aperçu qu'en désactivant la connexion automatique du navigateur via l'AD dans la conf apache et en rafraîchissant mon navigateur la première page du process d'upgrade s'affiche instantanément. Pour info, voici la conf apache du virtualhost concerné :
PerlModule Apache2::AuthenNTLM
<Directory "/var/www/glpi">
PerlAuthenHandler Apache2::AuthenNTLM
AuthType ntlm,basic
AuthName paipartners
require valid-user
PerlAddVar ntdomain "mondomaine.com nomduserveur1 nomduserveur2"
#PerlAddVar ntdomain "@@DOMAIN2_AU_BESOIN@@ @@PDC2@@ @@BDC2@@"
PerlSetVar defaultdomain mondomaine.com
PerlSetVar splitdomainprefix 1
PerlSetVar ntlmdebug 0
PerlSetVar ntlmauthoritative off
</Directory>
L'upgrade s'est ensuite déroulé sans encombre et j'ai finalement ré-activé la connexion automatique qui a tout de suite re-fonctionnée.
Voilà...
En espérant que ça aidera quelqu'un :)
Marc
Offline
- dé-tar-gzipé le glpi-0.83.1.tar.gz directement sur le DocumentRoot pour écraser les fichiers existant
Très mauvaise idée... et ce n'est d'ailleurs pas la procédure à respecter
En effet, vous sauvegardez votre dossier GLPI si vous voulez avant la migration mais les nouvelles pages doivent être déposées dans un dossier glpi vierge.
En effet, en 0.83, nous avons changé la gestion des onglets et de ce fait, beaucoup de fichiers ont été supprimés.
Avec votre méthode, les fichiers sont toujours présents et peuvent justement entrer en conflit avec la nouvelle méthode de gestion.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
oops effectivement j'ai lu trop vite la doc (http://www.glpi-project.org/spip.php?article171), qui n'est pas tout à fait clair à ce sujet... bien qu'en relisant je comprends mon erreur :
b) Cas où vous réalisez une mise à jour de GLPI version >=0.68 vers une version supérieure (exemple 0.7 ...)
Décompressez simplement la nouvelle archive de GLPI, à la place de l’ancienne.
Du coup, que dois-je faire ? est-ce que la procédure d'upgrade doit être refaire ? ou je remplace simplement l'ancien répertoire glpi par la nouvelle version ?
Merci!
Marc
Offline
remplacer l'ancien dossier par le nouveau en récupérant dans le dossier config, le fichier config_db
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Je complète mon précédent post
- récupérer le fichier confi_db issus de la migration (configuration liaison base MySql)
- récupérer également de dossier files qui contient entre autre vos documents injectés dans GLPI
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline