10 usædvanlige årsager til Apache CGI Internal Server Error, og hvordan du løser dem

Apaches CGI-tilstand gør det muligt for os at reducere hukommelsesforbruget. Det er den foretrukne måde at køre mange lav trafik hjemmesider.

men CGI-tilstanden er ret følsom over for ting som tilladelser og filkodning, der fører til 500 Intern serverfejl.

i vores rolle som Supportingeniører til internetværter har vi set en lang række årsager til denne fejl.

nogle almindelige årsager og deres rettelser er:

• forkerte fil – eller mappetilladelser-scriptfiler og mapper skal have nøjagtigt 755 tilladelser. I nogle servere kan mapper have brug for 750 tilladelser.
• forkert ejerskab (bruger & gruppeproblemer) – ejerskabet af filen skal indstilles til “bruger : ApacheUser” eller “bruger : bruger” afhængigt af Apaches konfiguration.
• forkert kodning – filer uploadet i binær tilstand vil mislykkes udførelse, og bør re-uploadet som ASCII.

næsten 80% af fejl 500 problemer ville blive løst ved disse rettelser.

denne artikel handler om resten 20% af årsager, som er svære at finde og rette.

Ikke almindelige årsager til Apache CGI Intern serverfejl

500 Intern serverfejl er en internetservers måde at sige, “noget er gået galt, da jeg forsøgte at vise siden. Ikke sikker på hvad.”

hvis det ikke er problemer med tilladelse eller ejerskab, kan det være alt fra applikationsfejl & Apache-fejlkonfigurationer til filsystemfejl &.

her er de top 10 usædvanlige problemer, vi har set i vores arbejde.

manglende moduler

internetapplikationer er afhængige af en masse PHP eller Perl “moduler” til specifikke funktioner.

nogle sådanne moduler er en del af en standardserveropsætning, men mange er det ikke.

vi har set, at efter en overførsel eller en under en ny hjemmeside opsætning, scripts ofte mislykkes, fordi alle nødvendige moduler ikke er til stede.

fejlloggen siger, at der er “udefinerede” funktioner, eller “metoder” findes ikke.

for at løse dette, vi går gennem app krav specifikationer, og installere alle manglende moduler.

netværkstidsudgange (af API-opkald, eksterne scripts osv.)

nogle internetapps henter data fra eksterne servere (f.eks. vejrdata).

hvis denne forbindelse til fjernserveren af en eller anden grund afbrydes, venter internetappen et stykke tid og viser derefter en time-out-fejl.

Apache rapporterer derefter denne status som en fejl 500.

dette problem kan være svært at fejlfinde, da det muligvis ikke efterlader en logpost.

vi registrerer timeout-problemer ved at inspicere langvarige udgående forbindelser og rette det ved at deaktivere appfunktionen, der kræver de udgående forbindelser.

gamle program (compiler) stier

den første linje i hver CGI-app (kaldet Shebang) indeholder stien til det program, der skal udføre det.

til f.eks. Perl scripts har denne sti:

#!/usr/bin/perl

men denne sti kan variere baseret på operativsystemleverandører og brugerdefinerede kompileringsindstillinger.

så scriptet vil søge efter programfilen på et bestemt sted, og hvis det ikke findes der, viser scriptet en fejl 500.

to effektive metoder er:

• Brug de stier, der er defineret i servermiljøet – stierne for alle programmer gemmes i serverens “miljø” – variabel. Så vi ændrer den første linje ved at kalde miljøet som sådan:
  • #!/usr/bin/env perl
  • dette vil sikre, at uanset hvor Perl er setup, stien vil være tilgængelig for scriptet.
• Definer programstierne i Apache config-brug Apaches direktiver” AddHandler” og “Action” til at udføre alle filer med det rigtige program. For f.eks. Sådan konfigureres PHP som en CGI:
  • AddHandler application/x-httpd-php5 php
  • Action application/x-httpd-php5 /local-bin/php-cgi

fejl i programkode

hjemmesideejere kan lave små fejl som at slette et “;” eller indsætte et omstrejfende tegn under redigering af program-eller konfigurationsfiler.

dette vil resultere i, at applikationen ikke udføres, men Apache spytter kun den kryptiske meddelelse “Internal Server Error”.

vi registrerer sådanne problemer ved at analysere logfilerne og løse det ved enten at rette kodefejlen eller ved at deaktivere plugin / addon / Tema, der forårsager fejlen.

gamle konfigurationsfiler med forkerte modulstier

hjemmesider tilpasses ofte til serverens miljø og programstier.

når sider migreres, vil deres konfigurationsfiler indeholde disse gamle stier, som muligvis ikke er kompatible med den nye server.

vi har set tilfælde, hvor internetapplikationer bruger brugerdefinerede konfigurationsfiler (siger php.ini) for at indlæse biblioteksfunktioner. Dette mislykkes, når stien ændres i en ny server.

i sådanne tilfælde fjerner vi de hardkodede programstier og bruger i stedet miljøvariabler til automatisk at erhverve programplaceringer.

sikkerhedsbegrænsninger.)

de fleste servere i disse dage har Internetapplikations brandvægge som mod_security eller Comodoaf.

disse brandvægge kan forårsage en fejl 500, hvis den fortolker en sideanmodning som et angreb.

til f.eks. vi har set apps mislykkes, fordi en ekstern fil opkald blev fortolket som en ekstern fil inklusion angreb af mod_security.

i sådanne tilfælde opretter vi brugerdefinerede udelukkelsesregler, så appen ikke længere blokeres, mens serversikkerheden ikke påvirkes.

det har også hjulpet os med at rette denne fejl, hvis vi ændrer indstillingen “Enforcing” til “Permissive”.

ingen Eksekveringsbegrænsning på partitionen

CGI-apps udføres som programmer.

for at det har brug for noget, der kaldes en “udføre” privilegium.

dette “udfør”-privilegium er slået fra for offentlige tilgængelige partitioner som “/tmp” og datalagringspartitioner som “/backup” for at forhindre ondsindet programudførelse.

vi har set tilfælde, hvor denne “Udfør” bit er slået fra for hjemmesidens hjem, hvilket får scriptudførelsen til at mislykkes.

vi gendanner udførelse af:

• # mount -o remount,exec /home

Apache & .htaccess fejlkonfiguration (ingen eksekverbar, ingen Tilladelseoverride osv.)

Apache skal vide, hvilke mapper der indeholder CGI-scripts.

det er betegnet ved hjælp af direktivet”eksekvering”.

til f.eks. for at betegne /cgi-bin/ som en CGI-mappe skal Apache konfigureres med:

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

på nogle servere har vi set “eksekverbar” deaktiveret i cgi-bin på grund af fejlkonfiguration i enten Apache conf-fil eller en .htaccess i den overordnede mappe.

Tilsvarende har vi set CGI-relaterede direktiver i .htaccess bliver ineffektiv, fordi .htaccess blev ikke aktiveret via et” Tillad Override ” – direktiv i Apache config.

alt dette kan resultere i en mislykket scriptudførelse og dermed en fejl 500.

forkerte tilladelser på hjemmekataloget

CGI-mapper placeres normalt i hjemmekataloget. For f.eks. stien til en cgi-bin i cPanel-servere er:

/home/username/public_html/cgi-bin/

mange netadministratorer sørger for at ændre tilladelsen fra cgi-bin-mappen og internetapplikationsmapperne til 755, men glemmer at kontrollere hjemmekatalogets tilladelser.

i nogle Apache-konfigurationer (f.eks. hjemmekataloget skal også have 755 tilladelser. Alt andet end det (f. eks. 777), vil få scriptudførelsen til at mislykkes.

så en af de første ting, vi kontrollerer sammen med scriptfiltilladelser, er at kontrollere tilladelserne for alle mapper i filens sti.

vi sætter det hele lige rigtigt for at sikre, at scriptet udføres uden fejl.

Chroot relaterede fejl, der bryder filsti

i nogle delte servere håndhæves sikkerhed ved at begrænse hver bruger til et fængslet miljø.

dette forhindrer en bruger i at få adgang til filer fra enhver anden bruger.

men sådanne miljøer kan bryde softlinks til programfiler.

til f.eks. hvis programmer er gemt i “/opt/php/bin/”, og det er knyttet til fra “/usr/bin/php/”, kan disse referencer blive brudt.

dette er temmelig sjældne tilfælde, og vi løser det ved at omkonfigurere serveren (eller stedet) til at bruge den rigtige sti i stedet for softlinks.