10 ovanliga orsaker till Apache CGI Internt serverfel, och hur man fixar dem

Apaches CGI-läge gör det möjligt för webbansvariga att minska minnesanvändningen. Det är det bästa sättet att köra många webbplatser med låg trafik.

men CGI-läget är ganska känsligt för saker som behörigheter och filkodning, vilket leder till 500 Internt serverfel.

i vår roll som supportingenjörer för webbhotell har vi sett ett brett spektrum av orsaker till detta fel.

några vanliga orsaker och deras korrigeringar är:

• fel fil – eller mappbehörigheter-skriptfiler och kataloger måste ha exakt 755 behörigheter. I vissa servrar kan kataloger behöva 750 behörigheter.
• felaktigt ägande (användare & gruppproblem) – ägandet av filen ska ställas in på ”användare : APACHEUSER” eller ”Användare : Användare” beroende på Apache-konfigurationen.
• felaktig kodning-filer som laddas upp i binärt läge misslyckas och bör laddas upp igen som ASCII.

nästan 80% av fel 500-problem skulle lösas av dessa korrigeringar.

den här artikeln handlar om resten 20% av orsakerna som är svåra att hitta och fixa.

ovanliga orsaker till Apache CGI Internal Server Error

500 Internal Server Error är en webbservers sätt att säga, ”något har gått fel när jag försökte visa sidan. Inte säker på vad.”

om det inte är tillstånd eller äganderättsproblem kan det vara allt från applikationsfel & Apache-felkonfigurationer till brandväggsblock & filsystemfel.

här är de 10 ovanliga problem som vi har sett i vårt arbete.

saknade moduler

webbapplikationer är beroende av många PHP-eller Perl – ”moduler” för specifika funktioner.

vissa sådana moduler är en del av en standardserverinställning, men många är det inte.

vi har sett att efter en migrering eller en under en ny webbplatsinställning misslyckas skript ofta eftersom alla nödvändiga moduler inte finns.

felloggen säger att det finns ”odefinierade” funktioner eller att” metoder ” inte existerar.

för att åtgärda detta går vi igenom appkravsspecifikationerna och installerar alla saknade moduler.

nätverks timeouts (av API-samtal, fjärrskript, etc.)

vissa webbappar hämtar data från fjärrservrar (t.ex. väderdata).

om denna anslutning till fjärrservern av någon anledning avbryts väntar webbappen ett tag och visar sedan ett time-out-fel.

Apache rapporterar sedan denna status som ett fel 500.

det här problemet kan vara svårt att felsöka eftersom det kanske inte lämnar en loggpost.

vi upptäcker timeout-problem genom att inspektera långa väntande utgående anslutningar och fixa det genom att inaktivera appfunktionen som kräver utgående anslutningar.

gamla programvägar (kompilator)

den första raden i varje CGI-app (kallad Shebang) innehåller sökvägen till programmet som ska utföra det.

för t.ex. Perl-skript har den här sökvägen:

#!/usr/bin/perl

men den här vägen kan skilja sig beroende på operativsystemleverantörer och anpassade kompileringsinställningar.

så kommer skriptet att leta efter programfilen på en viss plats, och om den inte hittas där kommer skriptet att visa ett fel 500.

två effektiva metoder är:

• använd de sökvägar som definieras i servermiljön – sökvägarna för alla program lagras i serverns ”miljö” – variabel. Så vi ändrar den första raden genom att ringa miljön, som så:
  • #!/usr/bin/env perl
  • detta kommer att se till att oavsett var Perl är inställd kommer Sökvägen att vara tillgänglig för skriptet.
• definiera programvägarna i apache config-använd Apache-direktiven” AddHandler ”och” Action ” för att utföra alla filer med rätt program. För t.ex. så här ställer du in PHP som en CGI:
  • AddHandler application/x-httpd-php5 php
  • Action application/x-httpd-php5 /local-bin/php-cgi

fel i programkod

webbplatsägare kan göra små fel som att ta bort en”; ” eller infoga en herrelös tecken när du redigerar program eller konfigurationsfiler.

detta kommer att resultera i att programmet inte körs, men Apache kommer bara att spotta ut det kryptiska ”Internal Server Error” – meddelandet.

vi upptäcker sådana problem genom att analysera loggfilerna och lösa det genom att antingen fixa kodfelet eller genom att inaktivera plugin / addon / tema som orsakar felet.

gamla konfigurationsfiler med fel modulvägar

webbplatser anpassas ofta för serverns miljö och programvägar.

när webbplatser migreras kommer deras konfigurationsfiler att innehålla dessa gamla sökvägar som kanske inte är kompatibla med den nya servern.

vi har sett fall där webbapplikationer använder anpassade konfigurationsfiler (säg php.ini) för att ladda biblioteksfunktioner. Detta kommer att misslyckas när sökvägen ändras i en ny server.

i sådana fall tar vi bort de hårdkodade programvägarna och använder istället miljövariabler för att automatiskt skaffa programplatser.

säkerhetsbegränsningar (brandvägg för webbapplikationer, SELinux, etc.)

de flesta servrar har idag brandväggar för webbapplikationer som mod_security eller ComodoWAF.

dessa brandväggar kan orsaka ett fel 500 om det tolkar en sidbegäran som en attack.

för t.ex. vi har sett webbappar misslyckas eftersom en extern fil samtal tolkades som en fjärrfil integration attack av mod_security.

i sådana fall skapar vi anpassade brandväggsuteslutningsregler så att appen inte längre blockeras, medan serverns säkerhet inte påverkas.

att ändra SELinux-inställningen från” Enforcing ”till” Permissive ” har också hjälpt oss att åtgärda detta fel.

ingen Exec (ingen exekvering) begränsning på partitionen

CGI-appar körs som program.

för att det behöver något som kallas en” exekvera ” privilegium.

denna ”Execute”-behörighet är avstängd för offentligt tillgängliga partitioner som ”/tmp” och datalagringspartitioner som ”/backup” för att förhindra körning av skadlig kod.

vi har sett fall där denna” Execute ” – bit är avstängd för hemsidor på webbplatsen, vilket gör att skriptexekveringen misslyckas.

vi återställer exec genom:

• # mount -o remount,exec /home

Apache & .htaccess felkonfiguration (ingen ExecCGI, ingen AllowOverride, etc.)

Apache behöver veta vilka kataloger innehåller CGI-skript.

som betecknas med direktivet”ExecCGI”.

för t.ex. för att beteckna /cgi-bin / som en CGI-katalog bör Apache konfigureras med:

<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>

i vissa servrar har vi sett” ExecCGI ” inaktiverad i cgi-bin på grund av felkonfiguration i antingen Apache conf-fil eller en .htaccess i den överordnade katalogen.

på samma sätt har vi sett CGI-relaterade direktiv i .htaccess blir ineffektivt eftersom .htaccess aktiverades inte genom ett” AllowOverride ” – direktiv i apache config.

allt detta kan resultera i ett misslyckat skriptkörning, och följaktligen ett fel 500.

felaktiga behörigheter på hemkatalogen

CGI-kataloger placeras vanligtvis i hemkatalogen. För t.ex. sökvägen till en cgi-bin i cPanel-servrar är:

/home/username/public_html/cgi-bin/

många webbansvariga tar hand om att ändra behörigheten för cgi-bin-katalogen och webbapplikationskatalogerna till 755, men glömmer att kontrollera hemkatalogens behörigheter.

i vissa Apache-konfigurationer (t.ex. när du använder SuExec) bör hemkatalogen också ha 755 behörigheter. Något annat än det (t.ex. 777), kommer att orsaka att skriptkörningen misslyckas.

så, en av de första sakerna vi kontrollerar tillsammans med skriptfilbehörigheter är att kontrollera behörigheterna för alla kataloger i filens sökväg.

vi ställer in allt rätt för att se till att skriptet körs utan fel.

chroot-relaterade fel som bryter filvägen

i vissa delade servrar upprätthålls säkerheten genom att begränsa varje användare till en fängslad miljö.

detta förhindrar en användare från att komma åt filer från någon annan användare.

men sådana miljöer kan bryta mjuklänkar till programfiler.

för t.ex. om program lagras i” /opt/php/bin/ ”och det är länkat till från” /usr/bin/php/”, kan dessa referenser brytas.

det här är ganska sällsynta fall, och vi fixar det genom att omkonfigurera servern (eller webbplatsen) för att använda rätt väg istället för mjuklänkar.