You are not logged in.
Bonjour,
Je viens d'essfectuer une migration de glpi 0.5 (il me semble ) vers la 0.68.2
J'ai mis auparavant à jour mysql en version 4.1.20 par la commande:
yum update mysql*
mysql fonctionne très bien avec mes autres bases.
l'installation de glpi s'est bien effectuée : aucun message d'erreur
dorénavant lorsque je pointe sur http://localhost/glpi/
j'ai maintenant une page blanche aucune erreur , pas d'authentification
quelqu'un aurait-il été confronté à ce pb ?
Distribution: Fedora core 4, mysql 4.1.20,Apache 2.0,php-5.0.4-10, navigateur Firefox
j'ai tout de même un message d'erreur ds /var/log/httpd/error_log:
Wed Nov 01 21:00:49 2006] [notice] Digest: generating secret for digest authentication ...
[Wed Nov 01 21:00:49 2006] [notice] Digest: done
[Wed Nov 01 21:00:49 2006] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Wed Nov 01 21:00:49 2006] [notice] LDAP: SSL support unavailable
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules//usr/lib/php/modules/gd.so' - /usr/lib/php/modules//usr/lib/php/modules/gd.so: cannot open shared object file: No such file or directory in Unknown on line 0
[Wed Nov 01 21:00:49 2006] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
les fichier suivant existent pourtant sous /usr/lib/php/modules:
-rwxr-xr-x 1 apache root 322072 mai 9 2005 gd.so
-rwxr-xr-x 1 apache root 39988 mai 9 2005 ldap.so
-rwxr-xr-x 1 apache root 89368 mai 9 2005 mysqli.so
-rwxr-xr-x 1 apache root 45644 mai 9 2005 mysql.so
-rwxr-xr-x 1 apache root 60948 mai 9 2005 odbc.so
-rwxr-xr-x 1 apache root 86508 mai 9 2005 pgsql.so
-rwxr-xr-x 1 apache root 23140 mai 9 2005 snmp.so
-rwxr-xr-x 1 apache root 7996 déc 17 2005 zip.so
peut être cette erreur n'a rien à voir avec mon pb glpi
De plus, ocs lui fonctionne sans aucun pb
Merci d'avance pour vos réponses et bravo aux développeurs de ce projet
CDT
Offline
juste une précision la version antérieure de glpi était la 0.65
Merci d'avance pour vos suggestions
Offline
Salut, les messages d'erreur précédents non pas forcément d'incidence sur GLPI à moins que tu utilises le module LDAP pour te connecter à GLPI ? Le cas des pages blanches a déjà été vu sur ce forum (malheureusement) mais je ne sais pas si une solution à été trouvé. Fais une rechercher sur le forum et tiens nous au courant.
A+
Offline
Est-ce que vous avez respecté à la lettre la procédure de mise à jour (changement d'archi des fichiers etc...)
Est-ce que le check à la mise à jour était sans erreur ?
Est-ce que la procédure de mise à jour de la db par GLPI s'est déroulée sans pb ?
Est-ce que vous utilisiez l'authentification externe sur ldap ?
Est-ce que vous avez modifié votre memory limit ?
Bref toutes ces questions sont posées à chaque fois. Il serait bon que vous fassiez déjà un check à ce niveau.
Tenez nous au courant.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Voici les réponses à vos questions:
Est-ce que vous avez respecté à la lettre la procédure de mise à jour (changement d'archi des fichiers etc...):
j'ai respecté à la lettre la procédure nottament déplacer les fichiers de :
détarré le fichier sous /var/www/html/glpi-0.68.2.tar.gz
tar zxvf /var/www/html/glpi-0.68.2.tar.gz
recopié:
var/www/html/glpi/backup/dump vers /var/www/html/glpi/files/_dumps
et
var/www/html/glpi/docs vers /var/www/html/glpi/files
mis les droits:
chmod -R 775 /var/www/html/glpi/files
chown -R apache:apache /var/www/html/glpi/files
chmod -R 775 /var/www/html/glpi/config
chown -R apache:apache /var/www/html/glpi/config
que voulez vous dire au juste par changement d'archi des fichiers ?
Est-ce que le check à la mise à jour était sans erreur ?:
aucune erreur lors de la mise à jour, tout OK
Est-ce que la procédure de mise à jour de la db par GLPI s'est déroulée sans pb ?
idem aucune erreur.
Est-ce que vous utilisiez l'authentification externe sur ldap ?
je ne l'utilise pas
Est-ce que vous avez modifié votre memory limit ?
il est à 16 Mo, j'ai essaye aussi de le passer à 32 même pb
Bref toutes ces questions sont posées à chaque fois. Il serait bon que vous fassiez déjà un check à ce niveau.
Je ne vois pas du tout vers ou m'aiguiller, j'ai retenté l'installation après avoir récupéré mon backup de /var/www/html/glpi (version 0.65), le pb est identique.
Juste une remarque que j'ai omi de vous indiquer:
Au tout début :
j'étais auparavant en mysql 4.1.12 et j'avais lancé l'update, lors de l'installatiojn j'ai eu le message de passer au moins en 4.1.13, j'ai continué, , j'avaisq alors la page blanche.
Je me suis dit que cela ne fonctionnait pas à cause de mysql 4.1.12, j'e suis donc passé en mysql 4.1.20 par la commande:
yum update mysql*
J'ai ensuite restoré /var/www/html/glpi (version 0.65), il refonctionnait.
J'ai ensuite relancé la migration et je suis maintenant confronté au même pb
JE veux tester la migration sur un serveur de test avant d'effectuer la migration sur un serveur de prod où glpi contient environ 350 machines, je veux être sûr de la procédure de migration.
Merci pour votre aide et encore bravo à GLPI qui m'aide considérablement ds mon travail d'administrateur.
CDT
Offline
Salut, peux tu essayer avec un MySQL 5 si il est disponible sur ta distrib bien sur.
A+
Offline
Il n'y a pas de raison que ça ne fonctionne pas avec la version de mysql 4.1.20. Maintenant tester avec une versions supérieure peut peut-être nous donner des indices sur le dysfonctionnement...
Pouvez-vous vérifiez par contre que vous avez bien repertoire _session dans files/
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
J'avoue JMD que ça fait déjà un certain nombre de post avec le même problème et pas de solution j'avoue que ça me dépasse un peu car ça m'est aussi arrivé sur une distrib de test et j'ai rien compris...
A+
Offline
J'ai réinstallé un eredhat Fedora core6 (mysql5...) et réinstallé glpi, là cela fonctionne, la mise à jour aurait-elle des pb ds certains cas ?
Maintenant j'aimerais bien comprendre étant donné que je voudrais migrer une machine de prod ayant ocs et glpi 0.65 installés
Offline
y a t-il un moyen de voir via des log ce que fais glpi lors de l'affichage de la bage blanche sans erreur?
Offline
J'ai réinstallé un eredhat Fedora core6 (mysql5...) et réinstallé glpi, là cela fonctionne, la mise à jour aurait-elle des pb ds certains cas ?
Pas à ma connaissance, le souci c'est qu'à chaque fois qu'on nous remonte ce type de pb, il se trouve que l'utilisateur passe à la vitesse supérieure en réinstallant tout et là plus de pb.
Dans ces conditions il est impossible pour nous d'en savoir plus sur l'éventuel bug, de pouvoir l'analyser et d'éventuellement le corriger s'il s'avère dépendre de GLPI.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
moi je lui avait juste conseillé de mettre à jour MySQL (pas taper mais bon le plus simple serait qu'une personne ayant un problème similaire vous laisse accéder à cette machine parce que lorsque j'ai eu ce problème j'ai eu beau chercher pendant plusieurs jours et je n'ai pas trouvé le début d'une réponse mais mes connaissances en mysql et php sont plus que limités.
A+
Offline
Même problème ici avec une Mandriva 2006.0 à jour.
Apache 2.0.54
php 5.0.4
MySQL 4.12 (la dernière de la 2006)
php.ini : mémoire, time out, etc... comme indiqué.
J'avais installé il y a un bon moment une 0.65 qui fonctionnait.
Je ne m'en suis plus servi pendant un moment et j'ai voulu réessayer hier.
Sans rien toucher : page blanche, rien dans aucun log, nulle part.
J'ai voulu mettre à jour glpi en me disant que sans doute j'avais fait des modifs entre temps dans mes autres packages (ils ont été mis à jour entre temps, mise à jour normales de Apache, PHP, MySQL, etc... pour suivre les derniers correctifs.
Ca fonctionne jusqu'après le choix de la base de données et après : page blanche.
Bon, je tente de créer une base vide pour faire une install clean, et maintenant j'obtiens le message
"Version de MySQL trop vieille. Pour fonctionner correctement GLPI nécessite au moins la version 4.1.13 et vous avez la version 4.1.12" (message que je n'avais pas avant)
Ce qui est vrai, mais la 4.1.12 est la plus récente existante sur ma Mandriva2006...
Et lors du début de la procédure, apparemment tout était compatible.
Je n'ai pas particulièrement envie de passer à MySQL5, j'ai une cinquantaine de sites sur cette machine. OK, c'est sûrement compatible mais si jamais il y a un pb, je suis mal. Pareil pour la 2007 qui vient de sortir, j'attendrai que les bugs soient exterminés.
Je détruis le répertoire glpi, je vérifie qu'aucune table n'a été créée dans ma nouvelle base
Je tente de faire une install à partir de zéro: rebelote.
Difficile de savoir ce qui débloque... Où diable puis-je tenter de trouver les messages d'erreur ?
Il n'y a rien dans les logs d'Apache, rien dans les logs de php, rien dans syslog.
Merci
-- Jean Marc
Last edited by jmcoursi (2006-11-06 21:18:45)
Offline
Merci pour vos message,
J'ai tout réinstallé afin de vérifier si l'install fonctionnait sans passer par une maj sur un Fedora Core 6.
Je vais essayer de remonter une Fedora Core 4 (comme au début) remonter glpi version 0.65 (je vois qu'elle est encore dispo sur votre site) et je retenterais un update.
Une question que je me pose, :
Etant donné que le module ldap sous apache était ajouté ds mon httpd.conf, glpi ne tenterait-il pas d'effectuer une authentification ldap et ne passerait-il pas par l'authentification mysql ?
C'est une supposition, ldap j'y connais rien ...
je vous rappelle le message que j'avais dans mon fichier de error_log d'apache:
Wed Nov 01 21:00:49 2006] [notice] Digest: generating secret for digest authentication ...
[Wed Nov 01 21:00:49 2006] [notice] Digest: done
[Wed Nov 01 21:00:49 2006] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Wed Nov 01 21:00:49 2006] [notice] LDAP: SSL support unavailable
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules//usr/lib/php/modules/gd.so' - /usr/lib/php/modules//usr/lib/php/modules/gd.so: cannot open shared object file: No such file or directory in Unknown on line 0
[Wed Nov 01 21:00:49 2006] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
Il faut absolument que je trouve le pourquoi de cette page blanche si je veux migrer mon serveur de prod en 0.68, chose que je ne peux pas faire sans être sûr de la migration.
Merci en tout cas à tous pour votre aide, on y arrivera ...
bye
Offline
Etant donné que le module ldap sous apache était ajouté ds mon httpd.conf, glpi ne tenterait-il pas d'effectuer une authentification ldap et ne passerait-il pas par l'authentification mysql ?
Si vous n'avez pas activé d'authentification externe dans la conf de GLPI, GLPI n'utilise pas d'autre système que l'auth mysql. C'est pour cela que je vous avais posé la question préalablement.
Il y a aussi cette autre question qu'il faudrait vérifier dans votre installation :
"Pouvez-vous vérifiez par contre que vous avez bien le repertoire _session dans files/ "
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
J vais vérifier la présence du répertoire _session dans files/ dès que j'ai remonté la fedora core4 + Glpi 0.65, je pense faire cela ce WE
je vous tiens au courant
Rq: ce répertoire existe bien sur la version 0.68 sur la machine fedora core 6 ou j'ai monté GLPI directement sans passer par un upgrade
Merci
Last edited by man_mickey2001 (2006-11-09 06:26:59)
Offline
juste une remarque: je n'étais pas en version 0.65 initialement mais en 0.6, peut être cela a-t-il une incidence.
Je viens de faire un nouvel essai sur ma machine de test Fedora core6 fraichement installée et fonctionnant en 0.68.2:
J'ai purgé les tables de la base mysqldb sans détruire la base
j'ai supprimé /var/www/html/glpi
me suis positionné sous /var/www/html
tar zxvf glpi-0.6.tar.gz
chown -R apache glpi
http://localhost/glpi
j'ai réinstallé (choix installation) glpi 0.6 , je me retrouve alors dans lemême cas que ma machine de prod sauf que celle ci est en fedora core 4.
sur cette machine de test , j'ai upgradé glpi en 0.68.2 (upgrade):
tar zxvf glpi-0.68.2.tar.gz
chown -R apache glpi
http://localhost/glpi
pris choix upgrade
la mise à jour se déroule sans aucun pb
je relance ensuite http://localhost/glpi
et là l'authentification fonctionne, je n'ai pas la page blanche
je n'arrive pas à reproduire le cas
j'ai vérifié la présence de /var/www/html/glpi/files/_sessions il existe bien et j'ai bien des fichiers dedans
j'y comprend plus rien !
je me demande si j'éssais maintenent de migrer ma machine de prod ayant glpi 0.6 .....
si vous avez d'autres suggestions avant de me lancer ...
CDT
Last edited by man_mickey2001 (2006-11-09 07:23:54)
Offline
encore une info,
vous me demandiez de vérifier la présence de _session dans /files ors c'est _sessions dans /files
sans doute une faute de frappe de votre part !
bye
Offline
j'ajoute:
sous fedora core 6 je suis en mysql 5 alors que sur ma machine de prod suis en mysql 4.1.11 et là il faudrait que j'upgrade aussi mysql en 4.1.20 par la commande:
yum update mysql*
là j'ai un peu peur ...
Offline
Une heure après être tombé sur le pb de "la page blanche" sous GLPI, je tombe sur le même problème pour SPIP ..
Par contre SPIP semble avoir résolu le pb :
http://www.spip-contrib.net/Bug-de-la-p … e-spip-1-7
http://thread.gmane.org/gmane.comp.web. … ocus=17992
Sais pas si ça peut aider...
Offline
Bonjour, je reviens à la charge!
Je viens de remonter une fedora core 4 comme au début sur ma machine de test
je tiens à préciser que je n'ai pas ajouté lors de l'installation les module mod_authz_ldap ni php-ldap ni mod_auth_kerb dans les choix Serveur Web, je ne sais pas si cela a une importance.
J'ai créé ma base glpidb en mysql 4.11 (version de mysql livrée en redhat fedora core 4)
j'ai ensuite installé la version glpi 0.6 sans pb
je me retrouve alors comme au début
j'ai ensuite upgradé mysql par la commande :
yum update mysql
mysql s'est alors updaté en 4.1.20 sans pb
j'ai ensuite upgradé glpi en 0.68 (choix update)
et là oh miracle, pas de page blanche, j'ai l'authentification ................................!
j'avoue ne plus comprendre...
peut être une piste:
lors de ma première migration de 0.6 en 0.68, j'avais eu le message de pb mysql 4.1.11 qu'il fallait updater au moins en 4.1.13, j'étais passé outre et là à la fin: page blanche
j'avais ensuite lancé un update de mysql par la commande : yum update mysql, la base était passée en 4.1.20
j'avais ensuite relancé la migration glpi de 0.6 et 0.68 et là page blanche.
dernière chose, lors de ma première migration j'avais effectué:
chmod -R 775 /var/www/html/glpi/files
chown -R apache:apache /var/www/html/glpi/files
chmod -R 775 /var/www/html/glpi/config
chown -R apache:apache /var/www/html/glpi/config
là j'ai seulement effectué après la commande tar zxvf /var/www/html/glpi-0.68.2.tar.gz:
chmod -R apache glpi (en étant sous /var/www/html)
puis lancé l'update
peut être cela a -t-il une incidence ...
Je vais maintenant me lancer la semaine prochaine à l'upgrade mysql 4.1.11 en 4.1.20 et update glpi 0.6 en glpi 0.68.2 sur ma machine de prod
bien sûr en faisant des backups ...
si quelqu'un a tout de même une suggestion je suis preneur
CDT
Offline
je n'ai pas du tout la maitrise du sujet, et pour tous les gens comme moi, si vous avez, dans tous vos tests effectués, trouvé un peu de logique dans une procedure d'install/upgrade, vous pourriez mettre une info sur le wiki ?
merci d'avance
Serveurs : Debian Wheezy (Apache 2.2.22, Php 5.4.4, mysql 5.5.31).
Logiciels : Firefox 30, 7z 9.20.
Plateforme en exploitation : GLPI 0.84.6/OCS 2.0.5 sur Debian Wheezy.
Plateforme en test : GLPI 0.84.6 sur Windows 7 SP1 x64 / WampServer 2.4 x64
Offline
Salut man_mickey2001, la première chose à faire avant d'installer ou de mettre à jour GLPI ou d'autre logiciel OpenSources bien fait, c'est lire le fichier lisezmoi ou le readme afin de savoir quels sont les packages et leur numéros de version pour procéder à l'installation ou la mise à jour. Bien entendu quand une upgrade de MySQL est à faire je comprend que sur un serveur de prod tu sois réticent mais fais le sur une machine de teste et après fait le sur ta machine de prod parce que le problème peut venir de là bien que ça ne soit pas très évident. Le principal c'est d'avoir toujours une backup sous la main en cas de problème.
A+
Offline
Merci pour tes conseils Aurel,
JE vous tiendrais au courant sur l'upgrade en glpi 0.68 sur mon serveur de Prod, bien sûr là je ferais auparavant un upgrade de mysql .
Merci à tous pour vos conseil
Offline