500 Internal Server Error

[bsd-root]

voila j un probleme

quand j'essais d'installer un cms quickstart(joomla+theme ja_teline +modules) distribuer par joomlart.com

j'ai le message suivant :

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

:!:

d'ou vien cette erreur et comment je peut remedier a ce probleme

[TrocWeb]

Bonjour

j'ai trouvé cela si ca peut t'aider

cordialement

TrocWeb

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_AT_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":

CGI 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.

[bsd-root]

oui j deja vu ce document mais ca ne m'as pas bcp aide

merci quand même

[Jeanluc]

L'erreur 500 survient souvent quand les droits d'accès aux fichiers ne sont pas compatibles entre l'application et la configuration du serveur. Tous les hébergements ne sont pas compatibles avec Joomla. Pose peut-être directement la question à ton hébergeur.

Jean-Luc

[Dan]

J'opterais aussi pour un problème de droits d'accès et permissions.

Si ton hébergement utilise SuPhp (php en CGI avec l'identification de l'utilisateur au lieu de celle d'Apache) in ne faut pas avoir des permissions supérieures à 755. Donc partout où ton programme d'installation te demande de mettre 777, il faut plutôt mettre 755.

Mais ce n'est valable qu'avec Php en CGI, et comme tu ne donnes pas le nom de ton hébergeur, c'est difficile à confirmer.