Alianwebserver.com

Problèmes généraux liés aux CGI

1 - Erreur 500
2 - Erreurs les plus fréquentes
3 - Conseils

Cette partie du document est une traduction de Idiot's Guide to Solving Perl/CGI Problems

1 - L'erreur 500 ...

Lorsqu'un script échoue dans son execution, on reçoit parfois sur le browser l'erreur : "500 Internal Server Error - The server encountered an internal error or misconfiguration and was unable to complete your request.-Please contact the server administrator, root@big-bang.alian.fr and inform them of the time the error occurred, and anything you might have done that may have caused the error.)

Ce message n'est généralement pas très parlant, mais en gros il vous dit qu'il n'a pas pu répondre à votre requête, et il vous faut regarder les fichiers logs de la machine (access & error). Ces fichiers contiendront la sortie d'erreur des scripts CGI.

Mieux vaut faire un script qui lit le dernière erreur enregistrée, ou sous Unix tapez tail -f <nom_fichier_erreur>

Leur emplacement varie en fonction du système et de la plate-forme :

• Sous Unix, on peut avoir /var/log/httpd.access, /usr/local/httpd/log/access, ...
• Sous Windows jetez un coup d'oeil dans c:\winNT\system32\log

Pour résoudre vos problèmes :

• Testez le script sous le shell habituel avant de le traiter au browser. Peut-être s'agit-il d'une erreur dans le source ?
• Sous Unix, si le script répond "not found" en faisant ./nom_du_script, deux solutions : le nom de l'interpréteur sur la première ligne est non trouvé, sinon c'est le problème du passage de Windows à Unix (Effectuer un dostounix sur le fichier).
• Si le script se lance sans problêmes, vérifiez que vous générez le bon entête MIME, c'est à dire que la sortie du programme doit être :

print "Content-type: text/html\n\n":

Sinon, il s'agit sûrement d'une erreur sur les droits d'accès.

2 - Les problèmes les plus courants

Q: Quels sont les droits affectés au script ?

A: 0600, mais je réalise qu'il n'est pas executable. Je ferais mieux de me mettre en droit 0755 . En accès telnet il faut faire chmod 755 monfichier.cgi, et si sous vous avez qu'un accès ftp, soit votre outil propose une interface graphique et les droits font partie des propriétés du fichier (clic droit sur le fichier, etc ...), soit vous avez une interface texte, dans ce cas là la commande chmod devrait fonctionner.

Q: Est-ce que le script est dans le bon répertoire ?

A: Non, j'ai oublié de le mettre dans le répertoire /usr/local/etc/httpd/cgi-bin/ c:/inetpub/wwwroot/cgi-bin/...

Q: Est-ce que l'execution des CGI est authorisé sur le serveur pour ce répertoire et cette extension pour les scripts ?

A: Non, mon administrateur système a oublié de configurer le serveur pour les CGI ; Par défault seule la méthode GET était authorisé, en oubliant les possiblités des méthodes POST.

Q: Sous quel uid le serveur execute-t-il les scripts CGI ?

A: wwwuser (Oops, il ne peut écrire dans mes répertoires et mes fichiers.)

Q: Est-ce que l'uid du serveur peut écrire dans n'importe quel fichier dans lequel vous tenter d'écrire ?

A: Non - J'ai conçu les scripts, mais ils ne tournent pas avec mon identité et les permissions sont 0600 au lieu de 0666. Cela explique que les scripts ne pouvaient ouvir mes fichiers !

Q: Que se passe-t-il lorsque vous lancer le script interactivement ?

A: Je ne savais pas que l'on pouvait les lancer interactivement, directement avec perl en local, et en utilisant perl monfichier.cgi

Q: Qu'est-ce qui apparait dans le journal d'erreurs du serveur ?

A: Je n'ai jamais pensé à y jeter un coup d'oeil ... c'est important ?

Q: Où se trouve le journal d'erreur du serveur ?

A: (Aucun chemin particulier - Cela dépend du système - Demander à votre administrateur local ... Regarder à tout hasard ce chemin : /usr/local/etc/httpd/logs/error_log) - c:/winnt/system32/logfiles/

Q: Quelle est la version de Perl et de l'OS ? (si votre version de Perl est <5.005 UPGRADE NOW!)

A: Perl version 5.002, SunOS version 4.1.3 (Essayez perl -v et uname -a pour voir ce résultat)

Q: Quelle est la version de ma librairie ?

A: grep -i version dans la librarie, ou pour CGI.pm , faire :
$ perl -le 'use CGI; print $CGI::VERSION'
2.21

Q: Quel est le chemin de votre executable Perl sur votre serveur ?

A: /contrib/bin/perl

Q: Quel est le chemin de votre executable Perl spécifié dans vos scripts ?

A: /usr/bin/perl (oops, ah oui, il risque pas de le trouver !)

Q: Quelle est la version du démon actif sur votre serveur afin de donner tous les indices sur votre environnement local aux personnes suceptibles de vous aider ?

A: NCSA 1.5

Q: Que se passe-t-il quand vous executez la commande perl -w nom_fichier ?

A: Il me parle d'erreurs listées en détail dans la manpage de perldiag où j'ai eu l'intelligence de jeter un coup d'oeil, mais que je peux directement avoir u moment de la compilation avec use diagnostics;

Q: Que se passe-t-il quand vous executez la commande perl -T nom_fichier ?

A: Il me parle de problèmes de sécurité décrit dans la manpage de perlsec, que j'ai eu la précaution de lire et de comprendre . J'ai aussi lu la CGI Security FAQ.

Q: Que se passe-t-il quand vous usez de la commande use strict ?

A: Il me dit toutes les erreurs relatives à la déclaration de mes variables . J'ai corrigé attentivement en utilisant my() , use vars.

Rappelé-vous de toujours cracher l'entete MIME type avant tout autre sortie (Les autres entetes peuvent être Location: ou Set-Cookie:)

A: Oh, OK ! Il faut une entete valide et un corps valide . Je suppose que je dois lire l'entete plus tot et je vérifie d'avoir mis deux retours chariots et non une seule .
Non : print "Set-cookie: GroversDelight\n";
Oui : print "Content-Type: text/html\n\n"; #

Q: Que se passe-t-il lorsque vous vérifiez tous les retours des appels systèmes ?

A: Cela me semblait trop de travail, mais pour être sur j'ai ajouté quelque chose de ce gout la : open(FILE, ">some_file") || die("can't write some_file: $!"); Le fichier d'erreur du serveur me montre $! c'est à dire la dernière erreur du programme et je peux voir :``Permission denied'' ou ``No such file or directory'', et tout devient clair .

Q: Avez-vous installer votre interpréteur Perl dans votre répertoire cgi-bin malgré les avertissements annoncés dans http://www.perl.com/perl/news/latro-announce.html et au CERT?

A: Oui, qu'y a-t-il de mal à cela ?

A: Destruction du disque après avoir volé les informations sensible de votre réseau, sympa non ?

Q: Que se passe-t-il ? Regardez, j'ai (mal) installé moi-même un script dans le répertoire cgi-bin et lui ai affecté les droits 0700. Je suppose que cela ne marche pas, pourquoi ?

A: Rappelez-vous de poster vos appels à l'aide dans comp.infosystems.www.authoring.misc, à la place de comp.lang.perl.* si ceux-ci ne concernent finalement pas Perl !

A: Ah oui ! Cela explique que je n'ai recu aucune réponses mais justes un retour de flammes ?

Q: Auriez-vous un script qui fait ...

Avant de commencer un travail jeter un coup d'oeil sur Internet pour savoir si un module ne pourrait pas vous servir .
Jeter un coup d'oeil ici http://www.perl.com/cgi-bin/cgi_mod?modules=CGI.

Les problemes lies aux plates-formes

Si vous êtes un peu dérangé, adepte du pseudo-discipliné système des forces du Mal, il vaut peut-être mieux lire Perl for Win32 FAQ.

3 - Quelques conseils

1 - PERL
2 - SCRIPTS CGI
3 - SECURITE

1 - Perl

• Les variables qui ne sont pas déclarées en local sont par défaut globales. Pensez donc à utiliser local() et my() qui fixent la portabilité des variables. C'est un gain de mémoire et de temps de débuggage ! Pour vous contraindre à l'utiliser systématiquement, utiliser use strict;
• Si l'utilisation des variables globales est faite, utilisez une convention d'écriture pour les reconnaitre tout de suite !
  ex:

  $main ::GLOBAL{'NOM_VAR'}="bbbb";

  ou beaucoup plus propre :

  use strict;
  use vars qw($myvar1 $myvar2);

2 - Scripts CGI

Un script CGI est par définition dynamique .... Eviter tout de suite de coder des nom de fichiers ou d'images dans le source et proposez une interface ou au moins un fichier pour configurer votre application . Sinon, sa portabilité sur une autre machine va être impossible !

3 -SECURITE

La mise en place de CGI peut compromettre la sécurité du serveur Web (et par de là, le reste du réseau) sur lequel il est installé si certaines ne sont pas observée:

- Droits :

• Evitez un 777 sur les CGI ... ce serait comme laissez un shell ouvert.
• Limiter les répertoires ouverts en écriture qu'à certains fichiers ou certains répertoires bien déterminés et surveillés.
• Attention à l'espace disque disponible (le mieux mettre des quotas sur les répertoires concernés).
• Les CGI réservés aux administrateurs doivent être protégés par mot de passe, ainsi que ceux impliquant une grosse charge machine

- Variables utilisateurs ou externes :

Ne jamais faire confiance à un utilisateur :-)

Surveiller tout particulièrement tout ce qui touche aux appels systèmes (2 commandes au lieu d'une seule, buffer-overflow, ...). En Perl, un excellent moyen de contrôler ces variables est d'utiliser l'option -P. Toutes les variables externes au programmes sont rejetées si elles n'ont pas été contrôler. Cela est expliqué en détail dans perldiag

- Lire au moins une fois ce document:

The WWW Security FAQ