Le mode CGI d’Apache permet aux webmasters de réduire l’utilisation de la mémoire. C’est le moyen préféré d’exécuter de nombreux sites Web à faible trafic.
Mais le mode CGI est assez sensible à des choses telles que les autorisations et l’encodage de fichiers, ce qui entraîne une erreur de serveur interne 500.
Dans notre rôle d’ingénieurs de support pour les hébergeurs Web, nous avons constaté un large éventail de causes à cette erreur.
Certaines causes courantes et leurs correctifs sont:
- Autorisations de fichier ou de dossier incorrectes – Les fichiers et répertoires de script doivent avoir EXACTEMENT 755 autorisations. Sur certains serveurs, les répertoires peuvent nécessiter 750 autorisations.
- Mauvaise propriété (problèmes de groupe utilisateur &) – La propriété du fichier doit être définie sur « USER:ApacheUser » ou « USER:USER » selon la configuration d’Apache.
- Encodage incorrect – Les fichiers téléchargés en mode binaire échoueront à l’exécution et devront être ré-téléchargés en ASCII.
Presque 80% des problèmes d’erreur 500 seraient résolus par ces correctifs.
Cet article concerne les 20% restants des causes difficiles à trouver et à corriger.
Causes peu communes d’erreur de serveur interne Apache CGI
500 L’erreur de serveur interne est une façon pour un serveur Web de dire : » Quelque chose s’est mal passé lorsque j’ai essayé d’afficher la page. Je ne sais pas quoi. »
S’il ne s’agit pas de problèmes d’autorisation ou de propriété, il peut s’agir de bogues d’application & erreurs de configuration Apache aux blocs de pare-feu & erreurs du système de fichiers.
Voici les 10 principaux problèmes inhabituels que nous avons rencontrés au cours de notre travail.
Modules manquants
Les applications Web reposent sur de nombreux « modules » PHP ou Perl pour des fonctions spécifiques.
Certains de ces modules font partie d’une configuration de serveur standard, mais beaucoup ne le sont pas.
Nous avons vu qu’après une migration ou lors d’une nouvelle configuration de site Web, les scripts échouent souvent car tous les modules requis ne sont pas présents.
Le journal des erreurs indiquera qu’il existe des fonctions « non définies » ou que les « méthodes » n’existent pas.
Pour résoudre ce problème, nous passons en revue les spécifications requises pour l’application et installons tous les modules manquants.
Délais d’attente réseau (des appels d’API, des scripts distants, etc.)
Certaines applications Web obtiennent des données de serveurs distants (par exemple. données météorologiques).
Si, pour une raison quelconque, cette connexion au serveur distant est interrompue, l’application Web attendra un certain temps, puis affichera une erreur de délai d’expiration.
Apache signale alors ce statut comme une erreur 500.
Ce problème peut être difficile à résoudre car il pourrait ne pas laisser d’entrée de journal.
Nous détectons les problèmes de délai d’attente en inspectant les connexions sortantes en attente prolongée et nous les corrigeons en désactivant la fonctionnalité d’application qui nécessite les connexions sortantes.
Anciens chemins de programme (compilateur)
La première ligne de chaque application CGI (appelée Shebang) contient le chemin d’accès au programme censé l’exécuter.
Par exemple. Les scripts Perl ont ce chemin:
#!/usr/bin/perl
Mais ce chemin peut différer en fonction des fournisseurs de systèmes d’exploitation et des paramètres de compilation personnalisés.
Ainsi, le script recherchera le fichier du programme dans un emplacement particulier, et s’il n’y est pas trouvé, le script affichera une erreur 500.
Deux méthodes efficaces sont:
- Utilisez les chemins définis dans l’environnement du serveur – Les chemins de tous les programmes sont stockés dans la variable « environnement » du serveur. Donc, nous changeons la première ligne en appelant l’environnement, comme ceci:
#!/usr/bin/env perl- Cela garantira que peu importe où Perl est configuré, le chemin sera disponible pour le script.
- Définissez les chemins du programme dans la configuration d’Apache – Utilisez les directives « AddHandler » et « Action » d’Apache pour exécuter tous les fichiers avec le bon programme. Par exemple. voici comment configurer PHP en tant que CGI:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
Erreurs dans le code d’application
Les propriétaires de sites Web peuvent faire de petites erreurs comme la suppression d’un « ; » ou l’insertion d’un caractère parasite lors de l’édition des fichiers d’application ou de configuration.
Cela entraînera l’échec de l’exécution de l’application, mais Apache ne fera que cracher le message crypté « Erreur interne du serveur « .
Nous détectons de tels problèmes en analysant les fichiers journaux et les résolvons en corrigeant l’erreur de code ou en désactivant le plugin / addon / thème à l’origine de l’erreur.
Les anciens fichiers de configuration avec des chemins de module incorrects
Les sites Web sont souvent personnalisés pour l’environnement du serveur et les chemins de programme.
Lorsque des sites sont migrés, leurs fichiers de configuration contiennent ces anciens chemins qui peuvent ne pas être compatibles avec le nouveau serveur.
Nous avons vu des cas où des applications Web utilisent des fichiers de configuration personnalisés (disons php.ini) pour charger les fonctions de la bibliothèque. Cela échouera lorsque le chemin d’accès change sur un nouveau serveur.
Dans de tels cas, nous supprimons les chemins de programme codés en dur et utilisons à la place des variables d’environnement pour acquérir automatiquement les emplacements du programme.
Restrictions de sécurité (Pare-feu d’application Web, SELinux, etc.)
La plupart des serveurs de nos jours ont des pare-feu d’applications Web tels que mod_security ou ComodoWAF.
Ces pare-feu peuvent provoquer une erreur 500 s’ils interprètent une requête de page comme une attaque.
Par exemple. nous avons vu des applications Web échouer car un appel de fichier externe a été interprété comme une attaque d’inclusion de fichier à distance par mod_security.
Dans de tels cas, nous créons des règles d’exclusion de pare-feu personnalisées afin que l’application ne soit plus bloquée, tandis que la sécurité du serveur n’est pas affectée.
Changer le paramètre SELinux de « Enforcing » à « Permissif » nous a également aidés à corriger cette erreur.
Aucune restriction d’exécution (pas d’exécution) sur la partition
Les applications CGI sont exécutées en tant que programmes.
Pour cela, il a besoin de quelque chose appelé un privilège « Execute ».
Ce privilège « Exécuter » est désactivé pour les partitions accessibles au public telles que « /tmp » et les partitions de stockage de données telles que « /backup » pour empêcher l’exécution de logiciels malveillants.
Nous avons vu des cas où ce bit « Exécuter » est désactivé pour les maisons de site Web, entraînant ainsi l’échec de l’exécution du script.
Nous restaurons exec par:
# mount -o remount,exec /home
Apache &.erreur de configuration htaccess (pas d’ExecCGI, pas d’AllowOverride, etc.)
Apache doit savoir quels répertoires contiennent des scripts CGI.
Qui est noté à l’aide de la directive « ExecCGI ».
Par exemple. pour désigner /cgi-bin/ comme répertoire CGI, Apache doit être configuré avec:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
Sur certains serveurs, nous avons vu « ExecCGI » désactivé dans cgi-bin en raison d’une mauvaise configuration dans le fichier de configuration Apache ou un.htaccess dans le répertoire parent.
De même, nous avons vu des directives liées à CGI dans.htaccess devient inefficace car.htaccess n’a pas été activé via une directive « AllowOverride » dans la configuration d’Apache.
Tout cela peut entraîner un échec de l’exécution du script, et par conséquent une erreur 500.
Les autorisations erronées sur le répertoire personnel
Les répertoires CGI sont généralement placés dans le répertoire personnel. Par exemple. le chemin d’accès à un cgi-bin dans les serveurs cPanel est:
/home/username/public_html/cgi-bin/
De nombreux webmasters prennent soin de changer l’autorisation du répertoire cgi-bin et des répertoires d’applications Web en 755, mais oublient de vérifier les autorisations du répertoire personnel.
Dans certaines configurations Apache (par exemple. lors de l’utilisation de suEXEC), le répertoire personnel doit également avoir 755 autorisations. Autre chose que cela (par exemple. 777), provoquera l’échec de l’exécution du script.
Ainsi, l’une des premières choses que nous vérifions avec les autorisations des fichiers de script est de vérifier les autorisations de tous les répertoires du chemin d’accès du fichier.
Nous avons tout réglé correctement pour nous assurer que le script s’exécute sans erreurs.
Erreurs liées au Chroot qui rompent le chemin du fichier
Dans certains serveurs partagés, la sécurité est renforcée en limitant chaque utilisateur à un environnement emprisonné.
Cela empêche un utilisateur d’accéder aux fichiers d’un autre utilisateur.
Mais de tels environnements peuvent casser des liens logiciels vers des fichiers de programme.
Par exemple. si les programmes sont stockés dans « /opt/php/bin/ » et qu’ils sont liés à partir de « /usr/bin/php/ », ces références peuvent être brisées.
Ce sont des cas assez rares, et nous le corrigeons en reconfigurant le serveur (ou le site) pour utiliser le bon chemin au lieu des liens logiciels.