GLPI - extjs: sous-répertoire manquant

Le
Jean-Marc
--Signature=_Sun__6_Mar_2016_17_58_55_+0100_EJbVz1tV9ZfdYVcv
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

salut la liste,

J'ai récemment posté et reçu de l'aide pour installer et con=
figurer GLPI grâce à nginx.

Mes premiers essais se heurtent à un soucis :
2016/03/06 17:37:37 [error] 19156#0: *10229 open() "/usr/share/glpi/lib/ext=
js/locale/ext-lang-en.js" failed (2: No such file or directory), client: 19=
2.168.x.x, server: _, request: "GET /glpi/lib/extjs/locale/ext-lang-en.js H=
TTP/1.1", host: "x.localdomain", referrer: "http://x.localdomain/glpi/login=
.php"

Normal, dans le répertoire extjs, pas de sous-répertoire locale.

Et c'est repris comme un bug :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766744

Apparemment, l'absence de ce sous-répertoire ne pose pas de soucis Ã=
  GLPI et pas de soucis non plus à certains web serveur comme Apache=
qui ont l'air plus souples (mis à part les nombreux messages d'erreur=
).

Mais nginx semble moins tolérant.

Des idées / suggestions ?


Jean-Marc <jean-marc@6jf.be>

--Signature=_Sun__6_Mar_2016_17_58_55_+0100_EJbVz1tV9ZfdYVcv
Content-Type: application/pgp-signature

--BEGIN PGP SIGNATURE--
Version: GnuPG v2

iQIcBAEBCAAGBQJW3GHPAAoJEEBxy1wt6cT87pAP/j5KgfI/jPZQI8c5tyFjwfrm
TnEhj9JyiXR9Vgcma09nNpSXI0avyodXvpPA/nD4e5RvU7h0hb7Ja3lDIhifA7uN
ABYy0WeVFIV0yXBdDpA+dwyulhdYAxH3ACEUvE7xUXnWQUwHkZ7clgliJwYggPhj
Woj0FzYNj2PlckkaY48FpkrbnSntPFf5Dv5Vt7x6nCKuQajrQo0lsv7VwAPPnO1i
W0kBbSsVJd+TzvAiojhHsqpTouvl6z8aV/8ruvoznr3dsbf0MvdFa5m/kiDUKSL1
v5omtQKrWJvh7OuaXhGEP7hNrtBbiUNp4oSaTefUMOYsIksEx3ugpkzu47nqM+Fq
se61HwVV2q5B72IWOCx9e+b8a+6VrmOJcAztqE5OHZAF1I0oFn3N9smSB33g4c0C
k0PkGkqw1WOUJNq5C8QslDlybTxotI8OyMAEi0eniQcusqoIVJjhSJ+7JXEJhhPA
yY21gbUc2RmiIASx8LEv/RSUvAc46P25tWz/otf6NDkgSXlY/ZiGuTGJRat2eaRv
hcpjM2tQPt2Vvbm7jO77oPzzkClcXRJi6ESMYyE5OEFt0h6sSHgYIPFvpuGJiVSU
vv/AdjKPUWjs8p12aJ9VN3vlptlY051054lwI8wwWEPid1AMtx6OCHNUj1MUibzf
Jx8qD03DPXuhGCT4xymy
=luAw
--END PGP SIGNATURE--

--Signature=_Sun__6_Mar_2016_17_58_55_+0100_EJbVz1tV9ZfdYVcv--
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bernard Schoenacker
Le #26391742
Le Sun, 6 Mar 2016 17:58:55 +0100,
Jean-Marc
salut la liste,

J'ai récemment posté et reçu de l'aide pour installer et configurer
GLPI grâce à nginx.

Mes premiers essais se heurtent à un soucis :
2016/03/06 17:37:37 [error] 19156#0: *10229 open()
"/usr/share/glpi/lib/extjs/locale/ext-lang-en.js" failed (2: No such
file or directory), client: 192.168.x.x, server: _, request:
"GET /glpi/lib/extjs/locale/ext-lang-en.js HTTP/1.1", host:
"x.localdomain", referrer: "http://x.localdomain/glpi/login.php"

Normal, dans le répertoire extjs, pas de sous-répertoire locale.

Et c'est repris comme un bug :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugv6744

Apparemment, l'absence de ce sous-répertoire ne pose pas de soucis à
GLPI et pas de soucis non plus à certains web serveur comme Apache
qui ont l'air plus souples (mis à part les nombreux messages
d'erreur).

Mais nginx semble moins tolérant.

Des idées / suggestions ?


Jean-Marc


bonjour,

serait il possible de comparer avec ce tuto :

https://support.rackspace.com/how-to/installing-nginx-and-php-fpm-setup-for-nginx/
https://www.digitalocean.com/community/tutorials/how-to-install-an-nginx-mysql-and-php-femp-stack-on-freebsd-10-1
https://memo-linux.com/installation-pas-a-pas-de-glpi-sous-un-serveur-linux/


slt
bernard
Ph. Gras
Le #26391749
Le 6 mars 2016 à 17:58, Jean-Marc
salut la liste,

J'ai récemment posté et reçu de l'aide pour installer et configurer GLPI grâce à nginx.

Mes premiers essais se heurtent à un soucis :
2016/03/06 17:37:37 [error] 19156#0: *10229 open() "/usr/share/glpi/lib/extjs/locale/ext-lang-en.js" failed (2: No such file or directory), client: 192.168.x.x, server: _, request: "GET /glpi/lib/extjs/locale/ext-lang-en.js HTTP/1.1", host: "x.localdomain", referrer: "http://x.localdomain/glpi/login.php"

Normal, dans le répertoire extjs, pas de sous-répertoire locale.

Et c'est repris comme un bug :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugv6744

Apparemment, l'absence de ce sous-répertoire ne pose pas de soucis à GLPI et pas de soucis non plus à certains web serveur comme Apache qui ont l'air plus souples (mis à part les nombreux messages d'erreur).

Mais nginx semble moins tolérant.

Des idées / suggestions ?



Je galère aussi en ce moment avec Mailman (Répertoire factice /cgi-bin/mailman) + NginX

La documentation est là :
http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite
http://nginx.org/en/docs/http/ngx_http_core_module.html#location
http://nginx.org/en/docs/http/ngx_http_core_module.html#root

Mais c'est clair comme du jus de chique, j'essaye de comprendre depuis un bail :-(

Des idées / suggestions ?

Ph. Gras


Jean-Marc
S
Le #26391770
Bonjour,

Le dimanche 06 mars 2016 à 17:58, Jean-Marc a écrit :
Mes premiers essais se heurtent à un soucis :
2016/03/06 17:37:37 [error] 19156#0: *10229 open() "/usr/share/glpi/lib/extjs/locale/ext-lang-en.js" failed (2: No such file or directory), client: 192.168.x.x, server: _, request: "GET /glpi/lib/extjs/locale/ext-lang-en.js HTTP/1.1", host: "x.localdomain", referrer: "http://x.localdomain/glpi/login.php"

Normal, dans le répertoire extjs, pas de sous-répertoire locale.

Et c'est repris comme un bug :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugv6744

Apparemment, l'absence de ce sous-répertoire ne pose pas de soucis à GLPI et pas de soucis non plus à certains web serveur comme Apache qui ont l'air plus souples (mis à part les nombreux messages d'erreur).

Mais nginx semble moins tolérant.



Ça ne devrait pas empêcher le fonctionnement général de l’application, Nginx
devrait renvoyer une erreur 404 au chargement de ce fichier et c’est tout
(d’ailleurs le rapport de bug « reproche » la pollution des logs mais pas le
mauvais fonctionnement de l’application).

Quel comportement obtiens-tu (dans ton navigateur) au juste ? Vois-tu des choses
intéressantes si tu charges les outils de dev. de ton navigateur (ou bien
Firebug dans Iceweasel) ?

Sébastien
Jean-Marc
Le #26391776
--Signature=_Mon__7_Mar_2016_12_43_43_+0100_8AH0gOa=.+_b/K8q
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Mon, 7 Mar 2016 11:23:43 +0100
Sébastien NOBILI
Bonjour,



salut Sébastien,

Ça ne devrait pas empêcher le fonctionnement général de l’application, Nginx
devrait renvoyer une erreur 404 au chargement de ce fichier et c’ est tout
(d’ailleurs le rapport de bug « reproche » la pollution des logs mais pas le
mauvais fonctionnement de l’application).



Correct pour le rapport de bug mais c'est sous Apache, pas nginx.


Quel comportement obtiens-tu (dans ton navigateur) au juste ? Vois-t u des choses
intéressantes si tu charges les outils de dev. de ton navigateur (ou bien
Firebug dans Iceweasel) ?



J'ai installé GLPI via le paquet Debian et fait un dpkg-reconfigure da ns la foulée.

Apparemment, tout semble s'être bien passé.

Quand j'essaie de me connecter, j'obtiens l'écran de login de GLPI, j' entre le user/password glpi/glpi comme indiqué dans la doc et j'ai le message suivant :
« The action you have requested is not allowed. Reload previous page b efore doing action again. »

Le seul élément trouvé jusqu'à présent est l'erreu r 404.

Et là, je viens de jeter un œil en détail sur le trafic gr âce à wireshark et je viens de voir que la tentative de connexion reçoit un message "access denied".

Ce n'est qu'ensuite que j'ai les erreurs 404.

Bon, je retourne au charbon.


Sébastien





Jean-Marc
--Signature=_Mon__7_Mar_2016_12_43_43_+0100_8AH0gOa=.+_b/K8q
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW3WlvAAoJEEBxy1wt6cT8p6YP/2Vv15bsaQOC5Ml/YQ3eVB+j
vAvWzOsdVxE5ByjxrP7QKmyOYesMtkKKZoqH9mBL5NMm0r8AKICQBmpYYsvCiaZJ
9s6W0Ry0MHgXzJLGcwzxPlvRGDVTLRFITBocB7OzuSqpmDDcNgbs9RPqqd38e7OA
+EFNsu4bo9hoX0RNxmFo8GRoEkU069/dIvR0zYwKLWEpYE0SAUcos+GPKfgoRUmZ
1Mq2IAMZWunCuP+1lmoZE8Y3zmTluMnRtHzzC4Ulej7czKywnpbA85cKCr4aCTBq
Q4enq03vbGRsbMTB9rWk2rmB5HLnabxxEXuRwgmBRKubRXOfY6QuQ4skSKxLyiHu
olKEvEe7VR5FnTtKTVleP9rJppY4K2ycI8fMnk7XdSvwwE6+ruBqmIkeg3k1+A0b
km31gGFjJk5hrBuOfazG4k/hg78Xs7EW7z4RXcmBJ9nT5Gyk2/4aQIgQEq38/9Kc
JVjU7TGyF88PIMCRg8POPvp5wSwvl3GUaMN/J5E508x6YAzwlERnClLxN4YHOAN4
hfbuECqpe3Ky558Q6tGtyjXhE8cduCf8xwK3al6qHCSVSfvCmwecBABYlp+onUtO
dF394OWvkbI/0l8nScUxGD7YUw4CcMU7EHqvMYc/nKe1qmzfOvrWIm3bf6TCY6MV
IBc6GWxeYGsPzF/08sLR
=0P1v
-----END PGP SIGNATURE-----

--Signature=_Mon__7_Mar_2016_12_43_43_+0100_8AH0gOa=.+_b/K8q--
S
Le #26391784
Le lundi 07 mars 2016 à 12:43, Jean-Marc a écrit :
Quand j'essaie de me connecter, j'obtiens l'écran de login de GLPI, j'entre le user/password glpi/glpi comme indiqué dans la doc et j'ai le message suivant :
« The action you have requested is not allowed. Reload previous page before doing action again. »

Le seul élément trouvé jusqu'à présent est l'erreur 404.

Et là, je viens de jeter un œil en détail sur le trafic grâce à wireshark et je viens de voir que la tentative de connexion reçoit un message "access denied".

Ce n'est qu'ensuite que j'ai les erreurs 404.



Je pense (c’est purement théorique car je n’ai jamais installé / utilisé GLPI)
que tu ne devrais pas te focaliser sur ces erreurs 404 sur des fichiers JS /
CSS.

Tu parles d’un « access denied », sur quelle URL ?

D’où te vient la configuration Nginx ? Du paquet Debian, d’un tuto sur le Web,
de ta production ?

Sébastien
Jean-Marc
Le #26391825
--Signature=_Mon__7_Mar_2016_18_33_01_+0100_q_Q2/UrocId_TKLJ
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Mon, 7 Mar 2016 15:38:43 +0100
Sébastien NOBILI
[...]
Tu parles d’un « access denied », sur quelle URL ?



C'est le tag <title> du html que GLPI me retourne.

Donc, en gros, je poste la forme de login et GLPI me retourne ceci comme HT ML body :


D’où te vient la configuration Nginx ? Du paquet Debian , d’un tuto sur le Web,
de ta production ?



Config' perso basée sur une conversation précédente et d'aut res configs.

La voilà :

location /glpi/ {
root /usr/share;
index index.php;
error_log /var/log/nginx/glpi-errors.log; # debug;

location ~ .php$ {
include snippets/fastcgi-php.conf;
# With php5-fpm:
fastcgi_pass unix:/var/run/php5-fpm.sock;
}

}



Sébastien





Jean-Marc
--Signature=_Mon__7_Mar_2016_18_33_01_+0100_q_Q2/UrocId_TKLJ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW3btNAAoJEEBxy1wt6cT8E1EP/0m/o/pnyCfL4OF98CWB6Fem
V6XUttAKrgm5r3K2Zo2h5cAOOfpakUDHAvwNsVZ4kuWNjGAgv7DTR3D0IQ7n51j4
8ztpx/xOSHY2qAjyCQR4fJ5LCsM2XUd5nHw4wemWMYZZQG/HqvPkfweJpDJaCbAN
s22ya6L58PXq3D3EP6pxk+gtCaXzYpr/itt29eUKeE9/I/sczOvpBh++2WXQjwSY
3W5vCVBOcJKvSpD9EO/ZugsBA1NSn31VyI6+C9L6AJoke6lYBezZaT6LH2/c8tO3
7Y8JuG+AF+6eyPSaCvTpe/JUWAHpGvQoBkDD9E3LR2RW9A/951Iu3ry1KBwSeUCp
Qz6EaiP32u72JM3I83kjjLXMs4eEFfMtZai2SViwjHRJpyaJMwGqnSPJhlB7dIuU
011acmIdKvmfzS8PFAkd38/RoKTYm9f+pZKl+5uLBRtj4vO867J68/VF2iK1ilFb
tGHIyNdBwi+xW3FDfwZeVuGk/03iVq6Bxj3WGCf//P5s8IQuVCNVA6IMR8ycT8dk
sPrwSprRJlKdU0uL4dkGdLMEM9v1Qxh8jLZaOqgGa+GOeAx90ShqWkLssf7/eAwe
mvPXGtLgWj8hDdd/FiVuf4upNwyUivQ86yLrfEIcD0+pC/A8/HhPI/e4ZA8O43Al
Mrvg1Em0LcUTKsAeFP9l
=U/cM
-----END PGP SIGNATURE-----

--Signature=_Mon__7_Mar_2016_18_33_01_+0100_q_Q2/UrocId_TKLJ--
S
Le #26391843
Bonjour Jean-Marc,

Le lundi 07 mars 2016 à 18:33, Jean-Marc a écrit :
Mon, 7 Mar 2016 15:38:43 +0100
Sébastien NOBILI > Tu parles d’un « access denied », sur quelle URL ?

C'est le tag <title> du html que GLPI me retourne.

Donc, en gros, je poste la forme de login et GLPI me retourne ceci comme HTML body :



OK, ce n’est donc pas le serveur Web qui te refoule mais l’application. Quoique…
(voir plus bas)

> D’où te vient la configuration Nginx ? Du paquet Debian, d’un tuto sur le Web,
> de ta production ?

Config' perso basée sur une conversation précédente et d'autres configs.

La voilà :

location /glpi/ {
root /usr/share;


^^^^^^^^^^
Cette ligne m’étonne. Je verrais plutôt « /usr/share/glpi/ ».

En l’état, tu indiques à ton serveur Web de rechercher les fichiers de
l’application dans « /usr/share ». Ça n’est pas recommandé, ça pourrait
permettre à un client de récupérer des données depuis ce dossier (qui ne
contient rien de bien sensible, mais bon…)

Si tu regardes le contenu du fichier « /etc/glpi/apache.conf », la directive
« DocumentRoot » dit la même chose.

Enfin, le paquet fournit un certain nombre de fichiers « .htaccess », il va
falloir que tu reportes (et traduises) leur contenu dans ta configuration Nginx
(je crois). Il doit s’agir principalement de restrictions de sécurité, tu
pourras t’en occuper une fois que l’application fonctionnera.

Sébastien
Jean-Marc
Le #26391864
--Signature=_Tue__8_Mar_2016_12_16_17_+0100_QUfHSaTmE8XP2.A_
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Tue, 8 Mar 2016 10:02:51 +0100
Sébastien NOBILI
Bonjour Jean-Marc,



salut Sébastien,

Et merci pour ton aide.

[...]
>
> Config' perso basée sur une conversation précédente et d 'autres configs.
>
> La voilà :
>
> location /glpi/ {
> root /usr/share;
^^^^^^^^^^
Cette ligne m’étonne. Je verrais plutôt « /us r/share/glpi/ ».



Bon, je pense effectivement que la config de nginx est pas très cool.
Mais si j'indique un root = /usr/share/glpi; quand je tape l'URL http://m onserver/glpi/, nginx me répond «not found» et les logs d'ac cès m'indiquent que j'ai essayé d'obtenir /glpi/glpi/index.php. V oilà pourquoi le root tronqué.

De toutes façon, les bonnes pratiques indiquent de toujours placer la directive root au niveau du bloc server{} et pas location{}.

Je pense donc que je devrais modifier la config nginx pour définir un bloc server{} par application (dokuwiki est aussi installé sur ce serv eur et fonctionne sans soucis; ou presque ;-) ).

Mon soucis, c'est comment définir plusieurs blocs server{} qui cohabit ent ?
Les distinguer via le port et des directives proxy_pass dans le bloc server {} principal ?
Une autre suggestion ?

[...]
Enfin, le paquet fournit un certain nombre de fichiers « .htacc ess », il va
falloir que tu reportes (et traduises) leur contenu dans ta configuration Nginx
(je crois). Il doit s’agir principalement de restrictions de sà ©curité, tu
pourras t’en occuper une fois que l’application fonctionn era.



Effectivement. Ce sera l'étape suivante. Un truc pénible à l a fois.
;-)


Sébastien





Jean-Marc
--Signature=_Tue__8_Mar_2016_12_16_17_+0100_QUfHSaTmE8XP2.A_
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW3rSBAAoJEEBxy1wt6cT8zLgP/0/GpTjBOMJaagVZaMdrKVNO
o815AXI2uZDHppK3juTWjqd1Pv/eZaYlP9SMTc2vHJvvwMKn8cWsfKWO+3hB6jAv
DYGKnik19q0YL/9uVpcNN80A3B0SWbd7nscu3Z6X6KQtTAyqnfCZ/Naf4bWdTw7F
Jh/Md0OKdhMiZx4+5zL9r2e4xJe4fT4gtC+nja8IZ6IaLsZmvJxaPLL7+I9KkSM+
dsk8oWGG7IiqlVojLdhfMkEOKueU7u8D6MNhohCNaBlYz1FFvI1BnJ7o0ZcNdP+m
EndEg2JcZj1ofXCKuTfnFSPQjFOpGhwMeiTIvlXSDCZdUy8wETtBuZDXsSPs7098
omRKz+DGazbxeb7pC0HvsFH+AxQG+OkjO/rmc7k2L7hfFu3+ZVkZhNetPY2MYevX
NgAzFMChF+4+yYtchEkVgMF9+22UXGh0wGnUJP4l2hwARE2SVN3d88VldwxtHWyB
aiS6Fn+w4ukh943910w9fSizEFBmnxqHRpo6R4r4xncnBY0C8vcjqeagL/iEfJVK
6hgUvKvNUp2S7uGhpvPZ/fcr71UdSzcwNz164M1NO4P/FbCDNBSdfbRc6QqWrMsz
9rq4culdArYBIbPfauZAtbcm9BZQzKbCuXsaYL0xhQH2jW9z24sKBf47zW559Rg8
FA50iqHLsElSQWH7voFI
=5+06
-----END PGP SIGNATURE-----

--Signature=_Tue__8_Mar_2016_12_16_17_+0100_QUfHSaTmE8XP2.A_--
Ph. Gras
Le #26391866
Le 8 mars 2016 à 10:02, Sébastien NOBILI
Bonjour Jean-Marc,

location /glpi/ {
root /usr/share;


^^^^^^^^^^
Cette ligne m’étonne. Je verrais plutôt « /usr/share/glpi/ ».



Dans cette configuration, les instructions concernent toutes les requêtes
qui portent sur (location) glpi :

http://example.com/glpi/machintruc.html

Quand tu y définis une racine (root), NginX envoie toutes ce requêtes au
répertoire racine :

open() /usr/share/machintruc.html

Grosso modo, ça marche comme ça d'après ce que j'ai compris.

Ph. Gras=
Ph. Gras
Le #26391869

Je pense donc que je devrais modifier la config nginx pour définir un bloc server{} par application (dokuwiki est aussi installé sur ce serveur et fonctionne sans soucis; ou presque ;-) ).



Ça ne pose pas de problème en théorie, il existe d'ailleurs 2 blocs server dans la conf. d'origine,
l'un étant commenté.

Je m'en sers pour effectuer des redirections vers des sous-domaines. Bon, faut pas qu'ils entrent
en conflit quand même !

Tu peux aussi créer un fichier nginx.conf à la racine de ton site et l'utiliser comme un htaccess ;-)



Ph. Gras=
Publicité
Poster une réponse
Anonyme