migration vers 0.70.2

sperkins · 2008-02-06 16:52:27

Bonjour,

On test l'aventure vers la 0.70 ) Mais nous avons un souci sur notre base de test pour passer notre base test glpi de 0.68.3 vers la 0.70.2. En effet, les logins ne marchent plus (on revient sur l'écran du login).

On a fait quelques tests de migration :

0.68.3 => 0.70 (ou les RC1.2.3) : OK
0.68.3 => 0.70 => 0.70.1 (migration successive) : OK
0.68.3 => 0.70.1 (migration directe) : OK

mais dès qu'on met en place la 0.70.2 dans les 3 cas... boom :-(

Notre serveur :
Linux fedora core 4
Mysql : v4.1.20
Php : 5.0.4

Au niveau des permissions, comme c'est un serveur de test, tout est en root, et tout est chmodé -R 777... De plus rien dans les logs php/httpd/messages...

Merci d'avance,

Sebastian

JMD · 2008-02-06 20:37:51

"Les logins ne marchent plus " vous utilisez une authentification externe ?

Si c'est le cas, il y a peut etre des éléments à ajuster.

Par ailleurs avez vous vider le repertoire /files/_session ?

MoYo · 2008-02-07 01:36:03

activer le mode debug ca pourra vous donner des infos

sperkins · 2008-02-07 11:24:09

Merci pour les pistes.

Alors il n'y a pas d'authenification externe. On n'arrive pas même pas à utiliser le compte admin glpi.

Pour les fichiers, le rép _sessions est vide. Ceci dit lors d'un login en .70.2 j'ai bien un fichier qui y est posé... mais pas de login réussi.

Côté débug j'ai rien au login qui m'aide. J'ai juste ces messages qui se répète 10/20 fois chacun, mais il sont présents en .70.1, mais bon quand c'est du Deprecated ca passe... )

PHP ERROR: var: Deprecated. Please use the public/private/protected modifiers in /home/wwwtest/glpi/inc/auth.class.php at line 47

PHP ERROR: var: Deprecated. Please use the public/private/protected modifiers in /home/wwwtest/glpi/inc/connection.class.php at line 46

PHP ERROR: var: Deprecated. Please use the public/private/protected modifiers in /home/wwwtest/glpi/inc/mailing.class.php at line 48

PHP ERROR: var: Deprecated. Please use the public/private/protected modifiers in /home/wwwtest/glpi/lib/phpmailer/class.phpmailer.php at line 30

PHP ERROR: Cannot modify header information - headers already sent by (output started at /home/wwwtest/glpi/inc/mailing.class.php:88) in /home/wwwtest/glpi/index.php at line 56

Y'a pas qqchose qui aurait - subtilement - changé avec les config php/httpd/mysql entre .70.1 et .70.2 ? Pourtant tous les requis au début de la màj sont tous OK.

Merci !

wawa · 2008-02-07 11:29:38

vous être en mode script php ?

sperkins · 2008-02-07 12:37:20

php OK puique ça marche en 0.70.1

nous avons poussé le vice à installer les versions 0.70.1 et 0.70.2 en mode "installation" et non "mise à jour" sur un nouvelle base évidemment à chaque fois... donc 2 installs 100% clean.

soit :
0.70.1 OK
0.70.2 : login glpi renvoi au login sans message

donc 0.70.2 pose le même pb en update qu'en install...

help !

wawa · 2008-02-07 12:42:12

sperkins wrote:

php OK puique ça marche en 0.70.1

vous avez pas répondu à ma question
vous êtes en mode strict ou pas ?

sperkins · 2008-02-07 12:57:04

wawa wrote:

sperkins wrote:
php OK puique ça marche en 0.70.1
vous avez pas répondu à ma question
vous êtes en mode strict ou pas ?

On utilise mysql4 et il n'y a pas de mode strict (seulement en v5 si je me souviens) mais j'ai vérifié dans les variables et la conf du server.

pour php 5 j'ai pas d'entrées dans le .ini correspondant au strict_mode...

ah oui et par rapport aux 2/3 threads ici, le safe-mode est bien disabled dans le php.ini

phil93 · 2008-02-11 13:10:28

j'ai le meme problème sous linux

0.70.1 impeccable 0.70.2 pas d'accès au delà du login meme sur une base vide.

et pas de pb sous windows avec wamp.

et je ne vois pas ce qui changerait du coté des droits en consultant le changelog

Etienne · 2008-04-30 16:47:15

Bonjour,

Même problème sur une debian stable...
Après un premier débogage, j'ai constaté que cela doit venir de la la variable $_SESSION
dont voilà un dump à l'entrée de la fonction checkCentralAccess dans le fichier auth.function.php

array(5) {
["glpi_currenttime"]=>
string(19) "2008-04-30 16:17:14"
["glpilist_limit"]=>
string(2) "25"
["glpilanguage"]=>
string(5) "fr_FR"
["glpi_plugins"]=>
array(0) {
}
["MESSAGE_AFTER_REDIRECT"]=>
string(0) ""
}

Pour l'instant je m'arrête là ....

MoYo · 2008-04-30 19:40:16

vous avez bien les droits sur le repertoire files/_session ?

Etienne · 2008-05-05 08:45:12

Bonjour et merci de votre réponse.

voici le résultat de la commande ls -lia files/_sessions/
total 8
123066656 drwxr-xr-x 2 www-data www-data 67 2008-05-01 18:09 .
110235363 drwxr-xr-x 10 www-data www-data 129 2008-01-28 12:50 ..
123066657 -rw-r--r-- 1 www-data www-data 80 2008-01-28 12:50 remove.txt
123078187 -rw------- 1 www-data www-data 169 2008-05-01 18:09 sess_dff3f479acb074464d48e17954f6896d

( sur une debian stable...)

JMD · 2008-05-05 12:41:03

Humm je saisi pas bien là. Aucun souci de fonctionnement de GLPI sur une deb stable de mon coté.

Vous avez bien désactivé tous vos plugins lors de la mise à jours ?
Vous utilisez l'authentification externe ?
Vous avez déplacé le répertoire de GLPI ?

yllen · 2008-05-05 13:09:55

Essayes de vider les répertoires
glpi/files/_cache et _sessions.

Nelly

Etienne · 2008-05-05 16:09:28

Re-Bonjour,

>>Vous avez bien désactivé tous vos plugins lors de la mise à jours ?

Non. Cela viendrait-il de là ? Dans ce cas, comment tenter de rattraper le truc ?
( je ne suis plus complètement sur d'utiliser un plugin, d'ailleurs...)
Après vérification, le répertoire glpi/plugins est vide : cela ne viens donc en fait certainement pas de là.

En ce qui concerne l'authentification, je passe par ldap...

Je n'ai pas déplacé le répertoire glpi

En ce qui concerne les répertoires glpi/files/_cache et _sessions, je les avais vidés
auparavant. J'ai retenté la chose et rien de mieux.

J'ai tenté d'activer le debugage en inscrivant directement une valeur dans la base. ( je ne sais pas exactement quelle est la valeur la plus appropriées, j'ai mis 2)
Il me semble que j'ai des messages d'erreurs qui apparaissent dans la fenêtre avant la redirection vers la page index.
C'est trop furtif pour voir quelque chose. Y-a-t il moyen de récupérer ces messages ?

Merci de votre aide

Etienne · 2008-05-06 09:54:32

Bonjour,

Toujours dans mon problème.
Je voudrais éliminer l'hypothèse d'un problème ldap.
Je veux donc changer de mode d'authentification.
Pour cela :
- je change dans la table user la valeur du champ auth_method : je la mets à 1.
- je renseigne le champ password et le champ password_md5 par, respectivement, une valeur et sa transformation md5

et cela ne marche toujours pas. Mais il me manque peut-être quelque chose lors de la manip....

Merci de m'éclairer.

JMD · 2008-05-06 19:04:50

pour tracer vous pouvez activer les logs dans la conf, vous aurez les erreurs dans un fichier /files/_log

Sinon vous avez essayer dans repertoire de test une fresh install de GLPI ?

Etienne · 2008-05-07 09:42:00

JMD wrote:

Sinon vous avez essayer dans repertoire de test une fresh install de GLPI ?

C'est ce que je me suis résolu à faire et je constate ce que je commençais à pressentir : la structure de ma base de donnée n'est pas à jour... cf plus bas et par exemple la table user :

Comment récupérer le coup ? A quel version de glpi cela correspond-il ? Suffit-il que je mette cette version dans la table de configuration et de relancer l'update ?

Et aussi ...comment en suis je arrivé là ?

CREATE TABLE `glpi_users` (
`ID` int(11) NOT NULL auto_increment,
`name` varchar(80) default NULL,
`password` varchar(80) default NULL,
`password_md5` varchar(80) default NULL,
`email` varchar(200) default NULL,
`phone` varchar(100) default NULL,
`phone2` varchar(255) default '',
`mobile` varchar(255) default '',
`realname` varchar(255) default NULL,
`firstname` varchar(255) default '',
`location` int(11) default NULL,
`tracking_order` enum('yes','no') NOT NULL default 'no',
`language` varchar(255) default NULL,
`comments` text,
`id_auth` int(11) NOT NULL default '-1',
`auth_method` int(11) NOT NULL default '-1',
`last_login` datetime NOT NULL default '0000-00-00 00:00:00',
`date_mod` datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (`ID`),
UNIQUE KEY `name` (`name`),
KEY `name_2` (`name`),
KEY `location` (`location`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=48 ;

JMD · 2008-05-07 12:51:11

1) Pour comparer les structures de db

Faites un diff entre l'export de votre structure de db actuelle et l'export de la structure de la dB GLPI 0.70.X fresh install.

Vous aurez une vue des éléments manquants.

2) En théorie pour forcer la mise à jour, il est possible de modifier le numéro de version dans la DB.

La question est de savoir quelle version mettre et le point 1 permettrait d'y répondre.

3) Comment en êtes vous arrivé là ? Bonne question

Je ne connais pas l'historique complet des manipulations réalisées, ni des mises à jours successives.

A priori j'aurai tendance à penser que la mise à jour s'est arrété en cours de route faute de ressources suffisantes très certainement.

gui80 · 2008-05-07 14:34:04

Bonjour,

j'ai le même souci que toi.
Je pense que c'est à propos des droits sur le répertoire files/_session.
Lorsqu'une authentification se fait, un fichier est créée. Pour le groupe autres, j'ai ---, donc aucun droit. Le programme ne peut pas lire les infos stockés dans le fichier temporaire de session, du coup les variables de session sont inaccessible, et donc, dans la fonction checkControlAccess dans inc/auth.fonctions.php je crois, un truc dans le genre, on se fait redirigé vers index.php après avoir fait le chemin index.php->login.php->central.php puis dégagé vers index.php. Faudrai voir le umask sur ce répertoire ou serveur. J'espère que c'est celà, j'ai soumis le problème au webmaster du serveur sur lequel est hébergé GLPI.

Etienne · 2008-05-07 16:04:51

JMD wrote:

1) Pour comparer les structures de db
Faites un diff entre l'export de votre structure de db actuelle et l'export de la structure de la dB GLPI 0.70.X fresh install.
Vous aurez une vue des éléments manquants.

Beaucoup ..

JMD wrote:

2) En théorie pour forcer la mise à jour, il est possible de modifier le numéro de version dans la DB.
La question est de savoir quelle version mettre et le point 1 permettrait d'y répondre.

Cela a fonctionné ! C'était la 681 Je me suis repéré à la conversion en utf8

JMD wrote:

3) Comment en êtes vous arrivé là ? Bonne question
Je ne connais pas l'historique complet des manipulations réalisées, ni des mises à jours successives.
A priori j'aurai tendance à penser que la mise à jour s'est arrété en cours de route faute de ressources suffisantes très certainement.

Je ne m'attendait pas à une réponse précise ;-) mais je crois effectivement que la piste proposée est la bonne. J'ai modifié le htaccess pour augmenter la ressource utilisable à php. Surement trop tard...
L'alerte mise à ce propos devrait-être bloquante... car ensuite il n'y a pas de message.

JMD · 2008-05-14 20:33:22

Je clos

Forum GLPI-Project

Announcement

#1 2008-02-06 16:52:27

migration vers 0.70.2

#2 2008-02-06 20:37:51

Re: migration vers 0.70.2

#3 2008-02-07 01:36:03

Re: migration vers 0.70.2

#4 2008-02-07 11:24:09

Re: migration vers 0.70.2

#5 2008-02-07 11:29:38

Re: migration vers 0.70.2

#6 2008-02-07 12:37:20

Re: migration vers 0.70.2

#7 2008-02-07 12:42:12

Re: migration vers 0.70.2

#8 2008-02-07 12:57:04

Re: migration vers 0.70.2

#9 2008-02-11 13:10:28

Re: migration vers 0.70.2

#10 2008-04-30 16:47:15

Re: migration vers 0.70.2

#11 2008-04-30 19:40:16

Re: migration vers 0.70.2

#12 2008-05-05 08:45:12

Re: migration vers 0.70.2

#13 2008-05-05 12:41:03

Re: migration vers 0.70.2

#14 2008-05-05 13:09:55

Re: migration vers 0.70.2

#15 2008-05-05 16:09:28

Re: migration vers 0.70.2

#16 2008-05-06 09:54:32

Re: migration vers 0.70.2

#17 2008-05-06 19:04:50

Re: migration vers 0.70.2

#18 2008-05-07 09:42:00

Re: migration vers 0.70.2

#19 2008-05-07 12:51:11

Re: migration vers 0.70.2

#20 2008-05-07 14:34:04

Re: migration vers 0.70.2

#21 2008-05-07 16:04:51

Re: migration vers 0.70.2

#22 2008-05-14 20:33:22

Re: migration vers 0.70.2

Board footer