You are not logged in.
et moi sous debian je n'ai aucun problème...
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Bon, ben je reste en 0.68.3.....
Dommage...
Last edited by mindphazer (2008-01-24 21:43:32)
Offline
pour avoir plus d'informations il faudrait faire logguer plus apache et php pour qu'ils donnent le plus d'informations possible.
En forcant glpi en mode debug il est egalement possible d'avoir plus d'informations.
debug=2 dans glpi_config
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Ok, merci pour l'info.
Je me suis mis en mode debug dans glpi, et j'obtiens de magnifiques messages d'erreur :
PHP ERROR: mkdir(): SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /home/httpd/html/glpi1/files/_cache/cache_7 owned by uid 109 in /home/httpd/html/glpi1/lib/cache_lite/Lite.php at line 764
PHP ERROR: fopen(): SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /home/httpd/html/glpi1/files/_cache/cache_7 owned by uid 109 in /home/httpd/html/glpi1/lib/cache_lite/Lite.php at line 768
PHP ERROR: fopen(./files/_cache/cache_7/cache_7a/cache_534075cca0b93be9619acf193fd652f7_520843e631c5516a0238c1c1c0d96a04): failed to open stream: No such file or directory in /home/httpd/html/glpi1/lib/cache_lite/Lite.php at line 768
Fatal error: Call to undefined function: wddx_serialize_value() in /home/httpd/html/glpi1/inc/common.function.php on line 143
Visiblement, glpi essaie d'écrire via l'utilisateur iud 109 dans des répertoires qui sont la propriété du user uid 500.
Effectivement, mon répertoire glpi a été créé par ftp avec le user "webadmin" (uid 500, groupe root), et glpi fait ses créations de fichiers par le biais du user httpd (uid 109, groupe httpd)
Par contre, je ne vois pas bien quoi faire
si j'essaie de passer le user httpd dans le groupe root, ça ne marche pas mieux.
Si j'essaie de changer le possesseur du répertoire glpi pour le "donner" au user httpd, j'obtiens la fenêtre de connexion. Mais lorsque je tape mon mot de passe, je retombe systématiquement sur la mire de connexion.....
Last edited by mindphazer (2008-01-25 10:42:07)
Offline
Voilà on y est
Rien à voir avec GLPI, il s'agit d'administration system.
Donnez les droits d'ecriture à GLPI sur les dossiers dont il a besoin ne consiste pas uniquement pas à faire du chmod, il faut gérer cela avec vos problématiques de droits des propriétaires des fichiers.
Tout cela dépend de votre config et de votre architecture.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Voilà on y est
Rien à voir avec GLPI, il s'agit d'administration system.
Donnez les droits d'ecriture à GLPI sur les dossiers dont il a besoin ne consiste pas uniquement pas à faire du chmod, il faut gérer cela avec vos problématiques de droits des propriétaires des fichiers.
Tout cela dépend de votre config et de votre architecture.
Bonjour, je viens de faire une mise à jour depuis la version 0.70.0 et j'ai le même problème.
Ce qui est étonnant c'est que je n'ai pas changer de configuration coté administration ...
Cordialement.
Offline
Sebmatrix :
1) Avec si peu de renseignements ça va être difficile de vous aider.
2) Comment pouvez savoir s'il s'agit des mêmes causes à partir des symptomes ?
3) Dans le cas présent, on a bel et bien un problème d'administration système :
des fichiers en toto:toto qui ne peuvent écrire dans des répertoires en titi:titi
4) Voir les docs sur le wiki qui presentent des installations simples de GLPI sur différents environnements.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Ok c'est bon.
Suite à tous ces problèmes, je me suis penché sur le user utilisé par Apache.
Je l'ai changé pour mettre celui que j'utilise pour faire mes transferts ftp
Cette fois-ci, c'est tout bon.
Merci à JMD et MoYo et toutes les personnes impliquées
Il me reste cependant une interrogation. Comme je le disais dans un post précédent, j'ai plein d'autres applis php qui tournent sur ce serveur, et la plupart écrivent des fichiers dans le répertoire propre de l'appli sans problèmes. De même, glpi dans sa version précédente écrivait des fichiers dump sans soucis.
Pourquoi le problème se pose-t'il précisément maintenant et sur ce fameux répertoire _cache ? Est-ce dû à la fonction cache_lite qui n'écrit pas ses fichiers de la même manière que les autres ? Je ne suis pas un expert php, loin de là. J'aurais donc du mal à me pencher sur le code pour trouver l'explication. Mais peut-être que ça en vaut la peine, si d'autres personnes ont le même souci que j'ai eu.....
Last edited by mindphazer (2008-01-25 12:37:20)
Offline
A mon avis il n'y a aucun problèmes avec GLPI.
Vous ne pouvez être certain de la comparaison que si vous affectez exactement les mêmes droits et propriétaires à vos autres applications.
Il est fort à parier que vous aviez installé la 0.68 différement du coup vous n'aviez pas le souci.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Absolument pas.
Toutes les applis php que j'utilise (y compris glpi 0.68.3 et ses versions précédentes) ont été installées de la même manière, via un ftp avec le même utilisateur (pour lequel aucune modification de droit n'a été effectuée), et ce depuis plus de 3 ans.
Je ne permettrai pas de dire que glpi est en cause, j'ai bien trop de respect pour le travail que l'équipe de développement a effectué, c'est un simple constat et j'essaie uniquement de comprendre le pourquoi du comment...
Offline
Bien...
Dans ce cas vous devez avoir une directive quelque part qui empèche un fichier en toto:toto d'écrire dans le sous répertoire d'un repertoire en titi:titi, ce qui au passage en terme de répartition de propriétaire me semble anormale mais bon...
Regardez du coté de safe mode et openbasedir : http://de3.php.net/features.safe-mode
Quand au fait que ça marchait avant...
Par ailleurs, il me semblait que le safe mode était à off par défaut désormais.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
GLPI 0.7.02 sous DEBIAN
Bonjour,
Même soucis lors de l'installation du plugin orders (écran blanc plus de fenêtre de login...)
J'ai vidé le le dossier glpi/files/_sessions et tout est rentré dans l'ordre.
Offline
Bonjour,
j'ai le même problème, après l'authentification via un CAS,
je ne suis pas redirigé vers front/central.php, mais vers login.php (même quand je rentre l'URL en dur)
et là, j'ai une page blanche sans message d'erreur en mode debug. Les logs d'apache ne montrent rien.
le pb viens surement de ma config serveur Apache 2.2 (sur debian), car GLPI marche à partir de WAMP.
Pour info, j'ai fait chmod -R 777 sur /_files et /_sessions et chown www-data -R GLPI.
lors de la tentative de connexion, un fichier cache et un fichier session sont créés avec les droits 700,
est-ce normal ?
Sinon, est-ce que ça peut venir de PHP ?
Sur ma plateforme de test WAMP, j'ai PHP5.2, ça marche nikel
et sur mon serveur de prod, j'ai PHP4.4 et j'ai ce problème.
J'ai rajouté les extensions curl et domxml qui n'étaient pas installées, y a t-il d'autres extensions à installer ?
Offline
c'était l'extension php4-ldap à rajouter.
ça marche bien maintenant.
Pour récapituler, il faut activer les extensions PHP suivantes pour que GLPI marche:
curl
domxml
gd
ldap
mysql
Offline
si je passe le mode debug en 2
je suis sur un serveur redhat
j'ai ceci sur fond rouge
PHP ERROR: var: Deprecated. Please use the public/private/protected modifiers in /var/dr75-dospip/glpi/inc/auth.class.php at line 47
(...)
PHP ERROR: Cannot modify header information - headers already sent by (output started at /var/dr75-dospip/glpi/inc/mailing.class.php:49) in /var/dr75-dospip/glpi/index.php at line 56
DRASS ile de france-450 postes, 10 serveurs
GLPI 0.71.2 sur Linux redhat RHEL4 php 5.05 mysql 5 avec OCS-NG sur XAMPP
Offline
> PHP ERROR: var: Deprecated.
Quelle version de PHP ? (je parierais bien pour un 5.1.2...)
A+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
non je suis en 5.0.4
DRASS ile de france-450 postes, 10 serveurs
GLPI 0.71.2 sur Linux redhat RHEL4 php 5.05 mysql 5 avec OCS-NG sur XAMPP
Offline
Voir aussi : http://glpi-project.org/forum/viewtopic.php?id=193
A+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
donc glpi 0.70.1 fonctionne bien sur ce serveur
d'autres appli phpb fonctionnent SPIP, GRR ect
c'est un serveur redhat apache 2 avec php 5.0.4 (faut que je change ma signature)
DRASS ile de france-450 postes, 10 serveurs
GLPI 0.71.2 sur Linux redhat RHEL4 php 5.05 mysql 5 avec OCS-NG sur XAMPP
Offline
Si la 0.70.1 fonctionne et pas la 0.70.2 je pencherais pour un oubli de droits sur le dossier "files" (et les sous-dossiers)
A+
Last edited by remi (2008-02-11 14:17:42)
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
c'est la meme installation que ce soit glpi 070.1 ou 0.70.2. je ne touche vraiment a rien d'autre
DRASS ile de france-450 postes, 10 serveurs
GLPI 0.71.2 sur Linux redhat RHEL4 php 5.05 mysql 5 avec OCS-NG sur XAMPP
Offline
Essayer d'installer une version 0.70.2 de tests sur votre serveur .
Ca permettra déja d'éliminer un problème de DB.
Ensuite modifiez votre php.ini pour qu'il ne balance pas les erreurs de type deprecated (ça pollue inutilement) mais tout le reste.
Vous mettez quoi comme droits et comme propriétaire sur vos fichiers et repertoires ?
Vous avez regardez aussi du coté du cache ? eventuellement désactivez le dans glpi_config
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
je viens de remplacer le fichier /inc/auth.class.php de la version 0.70.2 par celle de la 0.70.1
et maintenant j'accède a glpi 0.70.2
je continue a investiguer
DRASS ile de france-450 postes, 10 serveurs
GLPI 0.71.2 sur Linux redhat RHEL4 php 5.05 mysql 5 avec OCS-NG sur XAMPP
Offline
Hummm, la seule différence entre les deux fichiers concernent la ligne 253 :
$this->destroySession();
Cette action a été ajoutée pour justement corrigé certains problèmes de login.
Apparament ça a eut des effets collatéraux.
Pourriez vous redonner votre configuration serveur exacte SVP
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline