Apache ‘ s CGI-modus staat webmaster toe om het geheugengebruik te verminderen. Het is de voorkeur manier om veel low traffic websites draaien.
maar de CGI-modus is vrij gevoelig voor zaken zoals machtigingen en bestandcodering, wat leidt tot 500 Interne serverfout.
in onze rol als Support Engineers voor webhosts, hebben we een breed scala aan oorzaken voor deze fout gezien.
enkele veelvoorkomende oorzaken en hun oplossingen zijn:
- verkeerde bestand-of mapmachtigingen-scriptbestanden en mappen moeten exact 755 machtigingen hebben. In sommige servers hebben mappen mogelijk 750 machtigingen nodig.
- verkeerde eigendom (gebruiker & problemen met de groep) – de eigendom van het bestand moet worden ingesteld op “USER : ApacheUser” of “USER : USER”, afhankelijk van de configuratie van Apache.
- onjuiste codering-bestanden die in binaire modus zijn geüpload, zullen niet worden uitgevoerd en moeten opnieuw worden geüpload als ASCII.
bijna 80% van de fout 500 problemen zou worden opgelost door deze oplossingen.
dit artikel gaat over de rest van 20% van de oorzaken die moeilijk te vinden en op te lossen zijn.
soms oorzaken voor Apache CGI Interne serverfout
500 Interne serverfout is een webserver manier om te zeggen: “Er is iets mis gegaan toen ik probeerde de pagina weer te geven. Ik weet niet zeker wat.”
als het geen permission of ownership problemen zijn, kan het van alles zijn van applicatie bugs & Apache misconfiguraties tot firewall blokken & bestandssysteem fouten.
hier zijn de top 10 ongewone problemen die we hebben gezien in onze loop van het werk.
ontbrekende modules
webtoepassingen vertrouwen op veel PHP of Perl “modules” voor specifieke functies.
sommige van deze modules maken deel uit van een standaard server setup, maar vele niet.
we hebben gezien dat na een migratie of een Tijdens een nieuwe website-instelling, scripts vaak mislukken omdat niet alle vereiste modules aanwezig zijn.
het foutenlog zal zeggen dat er” ongedefinieerde “functies zijn of dat “methoden” niet bestaan.
om dit op te lossen, gaan we door de app vereiste specificaties, en installeren alle ontbrekende modules.
netwerk time-outs (van API-aanroepen, scripts op afstand, enz.)
sommige webapps krijgen gegevens van externe servers (bijv. weerdata).
als Om een of andere reden deze verbinding met de externe server wordt onderbroken, zal de web-app een tijdje wachten en dan een time-outfout tonen.
Apache rapporteert deze status als een fout 500.
dit probleem kan moeilijk worden opgelost omdat het mogelijk geen logboekvermelding achterlaat.
we detecteren time-outproblemen door langdurige uitgaande verbindingen te inspecteren en deze op te lossen door de app-functie die de uitgaande verbindingen vereist, uit te schakelen.
oude programmapaden (compiler)
de eerste regel in elke CGI-app (genaamd Shebang) bevat het pad naar het programma dat het moet uitvoeren.
voor eg. Perl scripts hebben dit pad:
#!/usr/bin/perl
maar dit pad kan verschillen op basis van Leveranciers van besturingssystemen en aangepaste compilatie-instellingen.
dus, het script zal zoeken naar het programma bestand op een bepaalde locatie, en als het daar niet gevonden wordt, zal het script een fout 500 tonen.
twee effectieve methoden zijn::
- gebruik de paden die zijn gedefinieerd in de serveromgeving – de paden van alle programma ‘ s worden opgeslagen in de variabele “omgeving” van de server. We veranderen de eerste regel door de omgeving te noemen, :
#!/usr/bin/env perl
- dit zorgt ervoor dat ongeacht waar Perl is ingesteld, het pad beschikbaar zal zijn voor het script.
- Definieer de programma paden in Apache config-gebruik de” AddHandler “en” Action ” richtlijnen van Apache om alle bestanden uit te voeren met het juiste programma. Voor eg. hier is hoe je PHP als een CGI:
AddHandler application/x-httpd-php5 php
Action application/x-httpd-php5 /local-bin/php-cgi
fouten in toepassingscode
Website-eigenaren kunnen kleine fouten maken, zoals het verwijderen van een”; ” of het invoegen van een verdwaalde teken tijdens het bewerken van applicatie-of configuratiebestanden.
dit zal resulteren in het niet uitvoeren van de toepassing, maar Apache zal alleen het cryptische “Interne serverfout” bericht uitspuwen.
we detecteren dergelijke problemen door de logbestanden te analyseren en deze op te lossen door de codefout te herstellen of door de plugin / addon / theme die de Fout Veroorzaakt uit te schakelen.
oude configuratiebestanden met verkeerde modulepaden
Websites worden vaak aangepast aan de omgeving en programmapaden van de server.
wanneer sites worden gemigreerd, zullen hun configuratiebestanden deze oude paden bevatten die mogelijk niet compatibel zijn met de nieuwe server.
we hebben gevallen gezien waarin webtoepassingen aangepaste configuratiebestanden gebruiken (bijvoorbeeld php.ini) om bibliotheekfuncties te laden. Dit zal mislukken wanneer het pad verandert in een nieuwe server.
in dergelijke gevallen verwijderen we de hard-gecodeerde programmapaden en gebruiken we in plaats daarvan omgevingsvariabelen om automatisch programmalocaties te verkrijgen.
Beveiligingsrestricties (Web application firewall, SELinux, etc.)
de meeste servers hebben tegenwoordig Firewalls voor webapplicaties zoals mod_security of ComodoWAF.
deze firewalls kunnen een fout veroorzaken 500 als het interpreteert een pagina verzoek als een aanval.
voor eg. we hebben gezien web apps falen omdat een extern bestand oproepen werden geïnterpreteerd als een externe File Inclusion aanval door mod_security.
in dergelijke gevallen maken we aangepaste firewall-uitsluitingsregels, zodat de app niet langer wordt geblokkeerd, terwijl de serverbeveiliging niet wordt aangetast.
het veranderen van SELinux instelling van” Enforcing “naar” Permissive ” heeft ons ook geholpen deze fout op te lossen.
geen Exec (geen uitvoering) beperking op de partitie
CGI apps worden uitgevoerd als programma ‘ s.
daarvoor heeft het een zogenaamde” Execute ” privilege nodig.
dit” uitvoeren “privilege is uitgeschakeld voor publiek toegankelijke partities zoals” /tmp “en data-store partities zoals” /backup ” om het uitvoeren van malware te voorkomen.
we hebben gevallen gezien waarin deze” Execute ” bit is uitgeschakeld voor websitewoningen, waardoor de uitvoering van het script mislukt.
we herstellen exec door:
# mount -o remount,exec /home
Apache & .htaccess misconfiguratie (geen ExecCGI, geen AllowOverride, enz.)
Apache moet weten welke mappen CGI-scripts bevatten.
die wordt aangeduid met de richtlijn “ExecCGI”.
voor eg. om /cgi-bin/ aan te duiden als een CGI directory, moet Apache geconfigureerd worden met:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
in sommige servers hebben we gezien “ExecCGI” uitgeschakeld in cgi-bin als gevolg van verkeerde configuratie in Apache conf bestand of een .htaccess in de bovenliggende map.
evenzo hebben we CGI gerelateerde richtlijnen gezien in .htaccess steeds ineffectief omdat .htaccess werd niet ingeschakeld door een” AllowOverride ” richtlijn in Apache config.
dit alles kan resulteren in een mislukte script uitvoering, en dus een fout 500.
verkeerde rechten op de persoonlijke map
CGI-mappen worden gewoonlijk binnen de persoonlijke map geplaatst. Voor eg. het pad naar een cgi-bin in cPanel servers is:
/home/username/public_html/cgi-bin/
veel webmasters zorgen ervoor dat de rechten van de cgi-bin directory en de web applicatie directory ‘ s worden gewijzigd naar 755, maar vergeten de rechten van de home directory te controleren.
in sommige Apache-configuraties (bijv. bij gebruik van SuExec) moet de home directory ook 755 rechten hebben. Iets anders dan dat (bijv. 777), zal de uitvoering van het script mislukken.
dus, een van de eerste dingen die we controleren samen met script bestand permissies is om de permissies van alle mappen in het bestandspad te controleren.
we hebben alles precies goed ingesteld om ervoor te zorgen dat het script zonder fouten wordt uitgevoerd.
chroot-gerelateerde fouten die het bestandspad
verbreken In sommige gedeelde servers wordt beveiliging afgedwongen door elke gebruiker te beperken tot een jailed-omgeving.
dit voorkomt dat een gebruiker toegang heeft tot de bestanden van een andere gebruiker.
maar dergelijke omgevingen kunnen softlinks naar programmabestanden verbreken.
voor eg. als programma ‘ s worden opgeslagen in “/opt/php/bin/” en het is gekoppeld aan “/usr/bin/php/”, kunnen deze verwijzingen verbroken worden.
dit zijn vrij zeldzame gevallen, en we repareren het door de server (of site) opnieuw te configureren om het juiste pad te gebruiken in plaats van softlinks.