Apache CGI-modus lar webmaster redusere minnebruk. Det er den foretrukne måten å kjøre mange lav trafikk nettsteder.
MEN CGI-modusen er ganske følsom for ting som tillatelser og filkoding, som fører til 500 Intern Serverfeil.
i vår rolle Som Supportingeniører for webverter har vi sett en rekke årsaker til denne feilen.
noen vanlige årsaker og deres rettelser er:
- Feil fil-eller mappetillatelser-Skriptfiler og kataloger må HA NØYAKTIG 755 tillatelser. I noen servere kan kataloger trenge 750 tillatelser.
- Feil eierskap (bruker & gruppeproblemer) – eierskapet til filen skal settes til «USER: ApacheUser «eller» USER : USER » avhengig Av Apaches konfigurasjon.
- Feil koding-Filer lastet Opp I Binær modus vil mislykkes kjøring, og bør re-lastet opp SOM ASCII.
Nesten 80% av feil 500 problemer vil bli løst av disse reparasjonene.
denne artikkelen handler om resten 20% av årsakene som er vanskelig å finne og fikse.
Uvanlige årsaker Til Apache Cgi Intern Serverfeil
500 Intern Serverfeil er en webservers måte å si: «Noe har gått galt da jeg prøvde å vise siden. Ikke sikker på hva.»
hvis det ikke er problemer med tillatelse eller eierskap, kan det være alt fra programfeil & Apache-feilkonfigurasjoner til brannmurblokker & filsystemfeil.
her er topp 10 uvanlige problemer vi har sett i løpet av arbeidet vårt.
manglende moduler
Webapplikasjoner stole på MANGE PHP eller Perl «moduler» for spesifikke funksjoner.
Noen slike moduler er en del av et standard serveroppsett, men mange er ikke.
vi har sett at etter en migrering eller a under et nytt nettstedoppsett, mislykkes skript ofte fordi alle nødvendige moduler ikke er til stede.
feilloggen vil si at det er «udefinerte» funksjoner eller «metoder» eksisterer ikke.
for å fikse dette, går vi gjennom appkravspesifikasjonene, og installerer alle manglende moduler.
Tidsavbrudd For Nettverk (AV API-kall, eksterne skript, etc.)
noen nettapper får data fra eksterne servere (f.eks . værdata).
hvis denne tilkoblingen til den eksterne serveren av en eller annen grunn avbrytes, vil webappen vente en stund og deretter vise en tidsavbruddsfeil.
Apache rapporterer deretter denne statusen som En Feil 500.
dette problemet kan være vanskelig å feilsøke, da det kanskje ikke etterlater en loggoppføring.
vi oppdager tidsavbruddsproblemer ved å inspisere lange ventende utgående tilkoblinger, og fikse det ved å deaktivere appfunksjonen som krever utgående tilkoblinger.
gamle programbaner
den første linjen i HVER CGI-app (kalt Shebang) inneholder banen til programmet som skal utføre det.
For eksempel. Perl-skript har denne banen:
#!/usr/bin/perl
men denne banen kan variere basert på operativsystemleverandører og tilpassede kompileringsinnstillinger.
så vil skriptet se etter programfilen på et bestemt sted, og hvis det ikke er funnet der, vil skriptet vise En Feil 500.
To effektive metoder er:
- Bruk stiene som er definert i servermiljøet-stiene til alle programmer lagres i serverens» miljø » – variabel. Så, vi endrer den første linjen ved å ringe miljøet, slik som:
#!/usr/bin/env perl- Dette vil sørge for at uansett Hvor Perl er oppsett, vil banen være tilgjengelig for skriptet.
- Definer programbanene I Apache config-Bruk» AddHandler «og» Action » – direktivene Til Apache for å utføre alle filer med riktig program. For eksempel. SLIK konfigurerer DU PHP som EN CGI:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
Feil i programkode
webområdeeiere kan gjøre små feil som å slette en»; » eller sette inn en bortkommen karakter mens du redigerer program-eller konfigurasjonsfiler.
dette vil resultere i at programmet ikke kjører, Men Apache vil bare spytte ut den kryptiske «Intern Serverfeil» – meldingen.
vi oppdager slike problemer ved å analysere loggfilene, og løse det ved enten å fikse kodefeilen, eller ved å deaktivere plugin / addon / tema som forårsaker feilen.
Gamle config-filer med feil modulbaner
Nettsteder er ofte tilpasset serverens miljø-og programbaner.
når områder overføres, inneholder konfigurasjonsfilene disse gamle banene som kanskje ikke er kompatible med den nye serveren.
vi har sett tilfeller der webapplikasjoner bruker tilpassede konfigurasjonsfiler (si php.ini) for å laste bibliotekfunksjoner. Dette vil mislykkes når banen endres i en ny server.
i slike tilfeller fjerner vi de hardkodede programbanene og bruker i stedet miljøvariabler for å automatisk skaffe programplasseringer.
sikkerhetsrestriksjoner (Webapplikasjonsbrannmur, SELinux, etc.)
De fleste servere i disse dager har Webapplikasjonsbrannmurer som mod_security eller ComodoWAF.
disse brannmurene kan forårsake En Feil 500 hvis den tolker en sideforespørsel som et angrep.
For eksempel. vi har sett web apps sviktende fordi en ekstern fil samtaler ble tolket Som En Ekstern Fil Inkludering angrep av mod_security.
i slike tilfeller oppretter vi egendefinerte regler for brannmurekskludering slik at appen ikke lenger blir blokkert, mens serversikkerheten ikke påvirkes.
Endring Av SELinux-innstilling fra «Håndheving » til» Permissiv » har også hjulpet oss med å fikse denne feilen.
ingen exec (ingen kjøring) begrensning på partisjonen
CGI apps kjøres som programmer.
For at den trenger noe som kalles en» Utføre » privilegium.
denne «Execute»-rettigheten er slått av for offentlig tilgjengelige partisjoner som «/tmp» og datalagringspartisjoner som «/backup» for å forhindre kjøring av skadelig programvare.
vi har sett tilfeller der denne» Utfør » biten er slått av for hjemmesider, og dermed forårsaker at skriptutførelsen mislykkes.
vi gjenoppretter exec av:
# mount -o remount,exec /home
Apache & .htaccess feilkonfigurasjon (Ingen ExecCGI, Ingen AllowOverride, etc.)
Apache trenger å vite hvilke kataloger som inneholder cgi-skript.
som er merket med direktivet «ExecCGI».
For eksempel. For å betegne /cgi-bin/ som EN cgi-katalog, Bør Apache konfigureres med:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
i noen servere har vi sett» ExecCGI » deaktivert i cgi-bin på grunn av feilkonfigurasjon i Enten Apache conf-fil eller en .htaccess i den overordnede katalogen.
På Samme måte har VI sett CGI – relaterte direktiver i .htaccess blir ineffektiv fordi .htaccess ble ikke aktivert gjennom et» AllowOverride » – direktiv I Apache config.
Alt dette kan resultere i en mislykket skriptkjøring, og dermed En Feil 500.
Feil tillatelser på hjemmekatalogen
CGI-kataloger er vanligvis plassert i hjemmekatalogen. For eksempel. banen til en cgi-bin i cPanel-servere er:
/home/username/public_html/cgi-bin/
Mange webmastere ta vare å endre tillatelse fra cgi-bin katalogen og webapplikasjonskataloger til 755, men glemmer å sjekke hjemmekatalogen tillatelser.
i Noen Apache-konfigurasjoner (f.eks. Når Du bruker SuExec), bør hjemmekatalogen også ha 755 tillatelser. Noe annet enn det (f.eks. 777), vil føre til at skriptutførelsen mislykkes.
så, en av de første tingene vi sjekker sammen med skriptfiltillatelser, er å sjekke tillatelsene til alle kataloger i filens bane.
vi setter alt sammen akkurat for å sikre at skriptet utføres uten feil.
Chroot-relaterte feil som bryter filbanen
i enkelte delte servere håndheves sikkerheten ved å begrense hver bruker til et fengslet miljø.
dette forhindrer at en bruker får tilgang til filene til en annen bruker.
men slike miljøer kan bryte softlinks til programfiler.
For eksempel. hvis programmer er lagret i «/ opt / php / bin/ «og det er knyttet til fra» / usr / bin / php/», kan disse referansene bli ødelagt.
dette er ganske sjeldne tilfeller, og vi løser det ved å konfigurere serveren (eller nettstedet) for å bruke riktig vei i stedet for softlinks.