Der CGI-Modus von Apache ermöglicht es Webmastern, die Speichernutzung zu reduzieren. Es ist der bevorzugte Weg, um viele Websites mit geringem Datenverkehr zu betreiben.
Der CGI-Modus reagiert jedoch ziemlich empfindlich auf Dinge wie Berechtigungen und Dateicodierung, was zu einem internen Serverfehler von 500 führt.
In unserer Rolle als Support Engineers für Webhosts haben wir eine Vielzahl von Ursachen für diesen Fehler gesehen.
Einige häufige Ursachen und deren Behebung sind:
- Falsche Datei- oder Ordnerberechtigungen – Skriptdateien und Verzeichnisse müssen GENAU 755 Berechtigungen haben. Auf einigen Servern benötigen Verzeichnisse möglicherweise 750 Berechtigungen.
- Falscher Besitz (Benutzer & Gruppenprobleme) – Der Besitz der Datei sollte je nach Apache-Konfiguration auf „BENUTZER: ApacheUser“ oder „BENUTZER: BENUTZER“ festgelegt werden.
- Falsche Kodierung – Im Binärmodus hochgeladene Dateien schlagen fehl und sollten als ASCII erneut hochgeladen werden.
Fast 80% der Fehler 500-Probleme würden durch diese Korrekturen behoben.
In diesem Artikel geht es um die restlichen 20% der Ursachen, die schwer zu finden und zu beheben sind.
Ungewöhnliche Ursachen für Apache CGI Internal Server Error
500 Internal Server Error ist die Art eines Webservers zu sagen: „Etwas ist schief gelaufen, als ich versucht habe, die Seite anzuzeigen. Nicht sicher, was.“
Wenn es sich nicht um Berechtigungs- oder Besitzprobleme handelt, kann es sich um Anwendungsfehler handeln & Apache-Fehlkonfigurationen zu Firewall-Blöcken & Dateisystemfehler.
Hier sind die 10 häufigsten ungewöhnlichen Probleme, die wir im Laufe unserer Arbeit gesehen haben.
Fehlende Module
Webanwendungen sind für bestimmte Funktionen auf viele PHP- oder Perl- „Module“ angewiesen.
Einige dieser Module sind Teil eines Standard-Server-Setups, viele jedoch nicht.
Wir haben gesehen, dass Skripte nach einer Migration oder während einer neuen Website-Einrichtung häufig fehlschlagen, weil nicht alle erforderlichen Module vorhanden sind.
Das Fehlerprotokoll besagt, dass „undefinierte“ Funktionen oder „Methoden“ nicht vorhanden sind.
Um dies zu beheben, gehen wir die App-Anforderungsspezifikationen durch und installieren alle fehlenden Module.
Netzwerk-Timeouts (von API-Aufrufen, Remote-Skripten usw.)
Einige Web-Apps erhalten Daten von Remote-Servern (z. Wetterdaten).
Wenn diese Verbindung zum Remote-Server aus irgendeinem Grund unterbrochen wird, wartet die Web-App eine Weile und zeigt dann einen Timeout-Fehler an.
Apache meldet diesen Status dann als Fehler 500.
Dieses Problem kann schwer zu beheben sein, da es möglicherweise keinen Protokolleintrag hinterlässt.
Wir erkennen Timeout-Probleme, indem wir lange ausstehende ausgehende Verbindungen überprüfen und beheben, indem wir die App-Funktion deaktivieren, für die ausgehende Verbindungen erforderlich sind.
Alte Programmpfade (Compiler)
Die erste Zeile in jeder CGI-App (Shebang genannt) enthält den Pfad zu dem Programm, das sie ausführen soll.
Für zB. Perl-Skripte haben diesen Pfad:
#!/usr/bin/perl
Dieser Pfad kann jedoch je nach Betriebssystemanbieter und benutzerdefinierten Kompilierungseinstellungen unterschiedlich sein.
Das Skript sucht also an einem bestimmten Speicherort nach der Programmdatei, und wenn sie dort nicht gefunden wird, zeigt das Skript einen Fehler 500 an.
Zwei wirksame Methoden sind:
- Verwenden Sie die in der Serverumgebung definierten Pfade – Die Pfade aller Programme werden in der Variablen „Umgebung“ des Servers gespeichert. Also ändern wir die erste Zeile, indem wir die Umgebung so aufrufen:
#!/usr/bin/env perl- Dadurch wird sichergestellt, dass unabhängig davon, wo Perl eingerichtet ist, der Pfad für das Skript verfügbar ist.
- Definieren Sie die Programmpfade in Apache config – Verwenden Sie die Direktiven „AddHandler“ und „Action“ von Apache, um alle Dateien mit dem richtigen Programm auszuführen. Für zB. so richten Sie PHP als CGI ein:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
Fehler im Anwendungscode
Websitebesitzer können beim Bearbeiten von Anwendungs- oder Konfigurationsdateien kleine Fehler wie das Löschen eines „;“ oder das Einfügen eines verirrten Zeichens machen.
Dies führt dazu, dass die Anwendung nicht ausgeführt werden kann, aber Apache spuckt nur die kryptische Meldung „Interner Serverfehler“ aus.
Wir erkennen solche Probleme, indem wir die Protokolldateien analysieren und beheben, indem wir entweder den Codefehler beheben oder das Plugin / Addon / Theme deaktivieren, das den Fehler verursacht.
Alte Konfigurationsdateien mit falschen Modulpfaden
Websites werden häufig an die Umgebung und die Programmpfade des Servers angepasst.
Wenn Sites migriert werden, enthalten ihre Konfigurationsdateien diese alten Pfade, die möglicherweise nicht mit dem neuen Server kompatibel sind.
Wir haben Fälle gesehen, in denen Webanwendungen benutzerdefinierte Konfigurationsdateien verwenden (z. B. php.ini), um Bibliotheksfunktionen zu laden. Dies schlägt fehl, wenn sich der Pfad auf einem neuen Server ändert.
In solchen Fällen entfernen wir die fest codierten Programmpfade und verwenden stattdessen Umgebungsvariablen, um automatisch Programmspeicherorte zu erfassen.
Sicherheitseinschränkungen (Web Application Firewall, SELinux, etc.)
Die meisten Server verfügen heutzutage über Webanwendungs-Firewalls wie mod_security oder ComodoWAF.
Diese Firewalls können einen Fehler 500 verursachen, wenn sie eine Seitenanforderung als Angriff interpretieren.
Für zB. wir haben gesehen, dass Web-Apps fehlgeschlagen sind, weil ein externer Dateiaufruf von mod_security als Remote File Inclusion-Angriff interpretiert wurde.
In solchen Fällen erstellen wir benutzerdefinierte Firewall-Ausschlussregeln, damit die App nicht mehr blockiert wird, während die Serversicherheit nicht beeinträchtigt wird.
Das Ändern der SELinux-Einstellung von „Erzwingen“ in „Zulassen“ hat uns ebenfalls geholfen, diesen Fehler zu beheben.
Keine Exec-Einschränkung (no execution) auf der Partition
CGI-Apps werden als Programme ausgeführt.
Dafür benötigt es ein sogenanntes „Execute“ -Privileg.
Dieses „Execute“-Privileg ist für öffentlich zugängliche Partitionen wie „/tmp“ und Datenspeicherpartitionen wie „/backup“ deaktiviert, um die Ausführung von Malware zu verhindern.
Wir haben Fälle gesehen, in denen dieses „Execute“ -Bit für Website-Homes deaktiviert ist, wodurch die Skriptausführung fehlschlägt.
Wir restaurieren exec durch:
# mount -o remount,exec /home
Apache & .htaccess-Fehlkonfiguration (kein ExecCGI, kein AllowOverride usw.)
Apache muss wissen, welche Verzeichnisse CGI-Skripte enthalten.
Das wird mit der Direktive „ExecCGI“ bezeichnet.
Für zB. um /cgi-bin/ als CGI-Verzeichnis zu bezeichnen, sollte Apache mit:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
Auf einigen Servern wurde „ExecCGI“ in cgi-bin aufgrund einer Fehlkonfiguration in der Apache conf-Datei oder in einer .htaccess im übergeordneten Verzeichnis.
In ähnlicher Weise haben wir CGI-bezogene Direktiven in gesehen .htaccess wird unwirksam, weil .htaccess wurde nicht durch eine „AllowOverride“ -Direktive in Apache config aktiviert.
All dies kann zu einer fehlgeschlagenen Skriptausführung und folglich zu einem Fehler 500 führen.
Falsche Berechtigungen für das Home-Verzeichnis
CGI-Verzeichnisse werden normalerweise im Home-Verzeichnis abgelegt. Für zB. der Pfad zu einem CGI-Bin in cPanel-Servern lautet:
/home/username/public_html/cgi-bin/
Viele Webmaster achten darauf, die Berechtigung des cgi-bin-Verzeichnisses und der Webanwendungsverzeichnisse auf 755 zu ändern, vergessen jedoch, die Berechtigungen des Home-Verzeichnisses zu überprüfen.
In einigen Apache-Konfigurationen (z. bei Verwendung von SuExec) sollte das Home-Verzeichnis auch 755 Berechtigungen haben. Alles andere als das (zB. 777), führt dazu, dass die Skriptausführung fehlschlägt.
Eines der ersten Dinge, die wir zusammen mit den Skriptdateiberechtigungen überprüfen, ist die Überprüfung der Berechtigungen aller Verzeichnisse im Pfad der Datei.
Wir haben alles genau richtig eingestellt, um sicherzustellen, dass das Skript fehlerfrei ausgeführt wird.
Chroot-bezogene Fehler, die den Dateipfad unterbrechen
In einigen gemeinsam genutzten Servern wird die Sicherheit erzwungen, indem jeder Benutzer auf eine Jail-Umgebung beschränkt wird.
Dies verhindert, dass ein Benutzer auf die Dateien eines anderen Benutzers zugreift.
Aber solche Umgebungen können Softlinks zu Programmdateien unterbrechen.
Für zB. wenn Programme in „/ opt / php / bin /“ gespeichert sind und von „/ usr / bin / php /“ verlinkt werden, können diese Referenzen beschädigt werden.
Dies sind ziemlich seltene Fälle, und wir beheben dies, indem wir den Server (oder die Site) neu konfigurieren, um den richtigen Pfad anstelle von Softlinks zu verwenden.