Aller au contenu

Messages recommandés

Posté(e)

Bonjour

Depuis une mise à jour de mon NAS, je ne peut plus faire tourner mes script CGI sur mon navigateur cela me note "Désolé, la page que vous recherchez est introuvable."
Je suis sure que mes scripts fonctionnais il y a quelques semaines de cela. Je n'ai plus eu le temps d'y travailler dessus depuis un moment.

si je regarde les droits, cela à l'air d’être juste :

> ls -l
-rwxrwxrwx 1 admin users 101 Nov 21 23:07 test.cgi

Sous SSH quand je vais dans le répertoire et que je l’exécute (>perl test.cgi) il fonctionne parfaitement.

> perl test.cgi
Bonjour

Dans le fichier user-error_log il se note ceci:

[sat Nov 22 10:25:39 2014] [error] (13)Permission denied: exec of '/var/services/web/cgi-bin/test.cgi' failed
[sat Nov 22 10:25:39 2014] [error] [client 195.202.253.212] Premature end of script headers: test.cgi
Je ne comprend pas, cela fait plusieurs jours que je me casse la tête, sans rien trouver sur le net!
Merci à mon futur sauveur!
Posté(e) (modifié)

Plusieurs petites choses à vérifier lorsque tu veux faire du cgi en perl :

Ton fichier cgi et ton répertoire cgi-bin doivent avoir les droits d’exécution par le serveur Web

Ton script cgi doit contenir en toute première ligne le shebang correct

Ton script cgi doit retourner du content html dans ses headers.

Voici le petit test que j'ai effectué sur mon syno en DSM 5.0:

Création du répertoire "/var/services/web/cgi-bin" avec les bon droits:

mkdir /var/services/web/cgi-bin

chmod 755 /var/services/web/cgi-bin

Création du fichier "/var/services/web/cgi-bin/test.cgi" avec les bons droits :

vi /var/services/web/cgi-bin/test.cgi

#!/usr/bin/perl
print "Content-type: text/htmlnn";
print "Hello, world!n";

chmod 755 /var/services/web/cgi-bin/test.cgi

Et j'ai bien le résultat attendu dans mon browser sur l'URL http://monsyno/cgi-bin/test.cgi (étant entendu que le Web Station sur mon syno est activé).

Ensuite si tu veux sécuriser un minimum les droits de tes fichiers web, je te conseille comme l'a dit Raoul d'utiliser http:htttp pour les droits, ce qui donnerait :

chown -R http:http /var/services/web/cgi-bin

chmod -R 750 /var/services/web/cgi-bin

Modifié par loli71
Posté(e) (modifié)

Merci pour tous ces renseignements j'ai fait pas par pas exactement ce que tu as dis, mais sur mon navigateur, cela note "Désolé, la page que vous recherchez est introuvable."

Et je n'ai pas compris ou on configure pour que l'accès au script CGI soit effectif pour le compte "http", groupe "http". Pourrais-tu développer Raoul, stp? ce serait vraiment sympas...

Est ce que quelqu'un pourrait m'afficher le contenu de son fichier httpd.conf-user, pour vérifier que tous est bien configuré là-dedans?

Modifié par maho
Posté(e)

Et je n'ai pas compris ou on configure pour que l'accès au script CGI soit effectif pour le compte "http", groupe "http". Pourrais-tu développer Raoul, stp? ce serait vraiment sympas...

Ce que Raoul a dit correspond à ce que je t'ai expliqué avec les chmod et chown.

Pour être certain, quelques questions :

- As tu bien activé Web Station dans le DSM ?

- Arrives tu à accéder à un fichier .html normal créé au même endroit que ton script perl ?

- Avec quoi as tu créé ton fichier cgi (bloc note sur windows et posé sur le syno par un partage windows ou autre) ?

En ce qui concerne mon fichier httpd.conf-user que je n'ai pas modifié, il contient entre autre la définition ci dessous qui permet l'utilisation de scripts cgi dans le répertoire "/var/services/web" et donc les répertoire à l'intérieur :

<Directory "/var/services/web">
    Options MultiViews FollowSymLinks ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>
Posté(e)

Donc,

- Oui Web station est activé

- J'arrives à accéder au pages web avec mon navigateur

- J'utilise notepad+++ pour éditer depuis le répertoire web qui est partagé depuis windows,

mais j'ai aussi essayé ton code "hello word" avec vi depuis SSH.

- J'ai la même configuration sur httpd.conf-user

Et j'ai toujours la même erreur sur le fichier user-error_log:

[sun Nov 23 21:20:04 2014] [error] (13)Permission denied: exec of '/var/services/web/cgi-bin/test.cgi' failed
[sun Nov 23 21:20:04 2014] [error] [client 195.202.253.212] Premature end of script headers: test.cgi
comment savoir si c'est bien #!/usr/bin/perl que je dois mettre, et pas un autre chemin?
Posté(e) (modifié)

Alors d'abord, faut faire attention aux fichiers fait sur windows et posés sur le syno par le répertoire partagé depuis windows à cause des saut de ligne windows et linux qui sont différents. Il faut donc bien penser à convertir les sauts de ligne en format UNIX dans notepad++.

Ensuite pour répondre à la question sur la première ligne shebang, il suffit de passer la commande suivante en ssh:

nas> which perl
/usr/bin/perl

Ensuite, peux tu mettre ici le résultat des commandes suivantes stp pour être certain :

ls -lsa /var/services/web/

ls -lsa /var/services/web/cgi-bin/

J'ai exactement le même message d'erreur que toi si le script n'a pas les bon droits:

[Sun Nov 23 21:43:16 2014] [error] (13)Permission denied: exec of '/var/services/web/cgi-bin/test.cgi' failed
[Sun Nov 23 21:43:16 2014] [error] [client 192.168.1.8] Premature end of script headers: test.cgi
Modifié par loli71
Posté(e)
Alors which perl me donne bien /usr/bin/perl
Mahox> ls -isa /var/services/web/
14540 8 .
2 4 ..
27659588 4 Nouveau document texte.txt
45094475 4 cgi-bin
14574 4 index.html
25168443 4 install
29884608 4 phpMyAdmin
14581 4 web_imageschmod ls -l/
29099687 4 webalizer
Mahox> ls -isa /var/services/web/cgi-bin/
45094475 4 . 14540 8 .. 45221150 4 test.cgi

Si avec SSH je tape "perl test.cgi" celà fonctionne!

les droits ont l'air juste :

drwxr-xr-x 2 http http 4096 Nov 23 18:56 cgi-bin

-rwxr-xr-x 1 http http 73 Nov 23 22:03 test.cgi
Posté(e)

euh, c'etait "ls -lsa", pas isa mais bon, tu as remis les droits du répertoire et du fichier ensuite ...

Essaye deux chose au cas où :

ps -w | grep http

pour savoir sous quel utilisateur tourne le serveur web sur ton syno

Puis essaye aussi de passer lla commande suivante au cas où (ce qui donne le droit en lecture, écriture et exécution pour tout le monde sur ton répertoire et script :

chmod -R 777 /var/services/web/cgi-bin
Posté(e)
Pour "ps -w | grep http" cela me donne ça:
4061 root 11640 S < /usr/bin/httpd -DAPPARMOR -f /etc/httpd/conf/httpd.con f-sys
6270 root 25840 S /var/packages/MediaServer/target/sbin/lighttpd -f /var /packages/MediaServer/target/etc/lighttpd.conf -m /
10049 http 5784 S nginx: worker process
10152 http 36672 S php-fpm: pool www
10153 http 36672 S php-fpm: pool www
10172 root 12644 S /usr/bin/httpd -DHAVE_PHP
10175 http 12392 S /usr/bin/httpd -DHAVE_PHP
10176 http 12392 S /usr/bin/fcgi- -DHAVE_PHP
10180 http 286m S /usr/bin/httpd -DHAVE_PHP
10311 root 11640 S /usr/bin/httpd -DAPPARMOR -f /etc/httpd/conf/httpd.con f-sys
10312 root 48860 S < /usr/bin/httpd -DAPPARMOR -f /etc/httpd/conf/httpd.con f-sys
21491 root 4000 S grep http
pi avec le chmod -R 777. ... ça change rien....
Posté(e) (modifié)

Ben je dois avouer que j'ai du mal a y comprendre quelque chose du coup ...

Pour moi c'est clairement un problème de droit d'exécution du script par le user utilisé par le serveur web (donc http).

si les droits sont bon sur le répertoire cgi-bin et sur le script test.cgi; il faudrait voir les droits sur les répertoires en dessous:

ls -lsa /

ls -lsa /volume1/

(si le répertoire "web" est bien sur ton /volume1, sinon tu peux voir sur quel volume il est avec la command suivante :

nas2> ls -lsa /var/services/
   0 lrwxrwxrwx    1 root     root            12 Nov 15 18:55 web -> /volume1/web

Moi j'ai cela :

nas2> ls -lsa /
..
   4 drwxr-xr-x   24 root     root          4096 Nov 22 11:50 volume1


nas2> ls -lsa /volume1/
..
   4 drwxr-xr-x    4 root     root          4096 Nov 23 14:09 web
Modifié par loli71
Posté(e)

C'est déprimant.. j'ai exactement la même chose que toi!

La nuit porte conseille.. on verra demain!

Encore un grand merci pour avoir essayé de m'aider, bonne soirée!

Posté(e)

Juste une dernière idée comme çà, après je sèche .... tu n'aurais pas un fichier ".htaccess" qui trainerait quelque part dans l'un de tes répertoires et qui redéfinirait les valeurs du "Options" en enlevant le ExecCGI ?

Posté(e) (modifié)

Si avec SSH je tape "perl test.cgi" celà fonctionne!

Faut plutôt faire ce test avec les droits du compte http, en s'y prenant comme cela:

su - http -s /bin/sh -c "perl /var/services/web/cgi-bin/test.cgi"
Modifié par CoolRaoul
Posté(e)

Faut plutôt faire ce test avec les droits du compte http, en s'y prenant comme cela:

su - http -s /bin/sh -c "perl /var/services/web/cgi-bin/test.cgi"

Donc dans SSH celà fonctionne avec cette ligne de commande!

Pi pour mes .htacces, j'ai recherché et j'en ai trouvé quelques-un ici:

/usr/syno/synoman/webman/modules/Indexer/.htaccess

/usr/syno/synoman/webapi/lib/.htaccess
/usr/syno/synoman/webapi/.htaccess
/volume1/@appstore/PhotoStation/photo/.htaccess
/volume1/web/phpMyAdmin/setup/.htaccess
Donc je ne pense pas que c'est ça.
Par contre il ne devrait pas avoir une ligne dans hhtpd.conf_user qui ressemble à ça: LoadModule cgi_module modules/mod_cgi.so

J'ai cru voir ça dans un tuto pour installer perl sur apache

Posté(e) (modifié)

Pour être un peu plus précis sur le test de Raoul, il faudrait même lancer la commande suivante (sans le "perl" devant le script, car le module CGI ne sait pas qu'il s'agit d'un cgi en perl et il utilise la ligne shebang pour savoir quoi utiliser):

su - http -s /bin/sh -c "/var/services/web/cgi-bin/test.cgi"

Pour le module CGI, out dépend de ta version de DSM, moi pour la version 50.1 j'ai cela dans ma config d'origine httpd.conf-user:

LoadModule cgid_module modules/mod_cgid.so
...
...
ScriptSock /run/httpd/user-cgisock
...
...
Modifié par loli71
Posté(e)

Ha! peut-être une piste?

Mahox> su - http -s /bin/sh -c "/var/services/web/test.cgi"
/var/services/web/test.cgi: line 1: #!/usr/bin/perl: not found
/var/services/web/test.cgi: line 3: print: not found
/var/services/web/test.cgi: line 4: print: not found
Posté(e) (modifié)

Ha! peut-être une piste?

Mahox> su - http -s /bin/sh -c "/var/services/web/test.cgi"
/var/services/web/test.cgi: line 1: #!/usr/bin/perl: not found
/var/services/web/test.cgi: line 3: print: not found
/var/services/web/test.cgi: line 4: print: not found

Ah non, au temps pour moi, la bonne commande est

su - http -s /bin/sh -c "perl /var/services/web/test.cgi"

(mais pourquoi avoir répondu auparavant "Donc dans SSH celà fonctionne avec cette ligne de commande" ?)

Modifié par CoolRaoul
Posté(e) (modifié)

Si je mets "perl" avant le chemin cela fonctionne, et si je ne mets que le chemin entre guillemets cela fonctionne pas.

su - http -s /bin/sh -c "perl /var/services/web/test.cgi" -> Ok

su - http -s /bin/sh -c "/var/services/web/test.cgi" -> Erreur

Modifié par maho
Posté(e) (modifié)

Euh, je persiste et signe ... il n'est pas nécessaire d'indiquer le programme a exécuter pour lancer un cgi à partir du moment où le shebang est bien mis dans la toute première ligne du cgi (donc attention, pas d'espace ou de ligne vide avant cette ligne shebang !!!) et que l'utilisateur http a les droits pour exécuter le cgi.

Etant donné qu'un cgi peut être fait avec n'importe quel langage de programmation (perl, sh, bash, ksh ou c compilé) c'est grace au shebang que apache sait quel langage doit être utilisé pour interpréter le code qui suit.

nas2> cat /var/services/web/cgi-bin/test.cgi
#!/usr/bin/perl
print "Content-type: text/htmlnn";
print "Hello, world!";
Lancement de la commande en ssh depuis le compte root :

nas2> su - http -s /bin/sh -c "/var/services/web/cgi-bin/test.cgi"
Content-type: text/html

Hello, world!
Connection au compte http depuis le compte root avec le shell /bin/sh et lancement de la commande directe :

nas2> su - http -s /bin/sh

BusyBox v1.16.1 (2014-10-10 08:38:16 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

nas2> whoami
http

nas2> /var/services/web/cgi-bin/test.cgi
Content-type: text/html

Hello, world!
Modifié par loli71
Posté(e)

Normalement, ça devrait aussi marcher sans le "perl", sous réserve que le script soit exécutable (et c'est le cas d’après les résultats de tes "ls") et que la ligne shebang soit correcte

Cependant l'erreur:

/var/services/web/test.cgi: line 1: #!/usr/bin/perl: not found

semble indiquer le contraire

Es-tu sur que le .cgi à bien été créé avec Notepad++ configuré (préférences->nouveau document->format des sauts de lignes) pour utiliser les fins de lignes unix?

Pour corriger: "édition" -> "convertir les sauts de lignes"

Posté(e)

Connection au compte http depuis le compte root et lancement de la commande directe :

nas2> su - http
nas2> /var/services/web/cgi-bin/test.cgi
Content-type: text/html

Hello, world!

Gaffe: ici le cgi s'exécute sous le compte "root" et pas "http" car le "su - http" retourne immédiatement à la session initiale (sous réserve que le shell du compte ait été laissé à sa valeur par défaut, "/bin/false"):

fserv> su - http
fserv> id 
uid=0(root) gid=0(root) groups=0(root)

Faut ajouter "-s /bin/sh" à la commande "su" pour éviter ça.

Posté(e) (modifié)

Ah vi, bien vu , je corrige mon post précédent, mais le résultat est le même, cela fonctionne chez moi ;-)

A mon avis la piste est a creuser du coté de l'erreur "#!/usr/bin/perl: not found".

Modifié par CoolRaoul
Posté(e)

Oui Raoul, entièrement d'accord avec toi.
soit les sauts de lignes ne sont pas au format UNIX, soit il y a une ligne vide ou un espace avant la ligne shebang dans le script ...

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.