modul CGI Apache permite webmaster pentru a reduce utilizarea memoriei. Este modul preferat de a rula multe site-uri cu trafic redus.
dar modul CGI este destul de sensibil la lucruri cum ar fi permisiunile și codarea fișierelor, ceea ce duce la eroarea internă a serverului 500.
în rolul nostru de ingineri de asistență pentru gazdele web, am văzut o gamă largă de cauze pentru această eroare.
unele cauze comune și remedierile lor sunt:
- permisiuni greșite pentru fișiere sau foldere – fișierele și directoarele Script trebuie să aibă exact 755 de permisiuni. În unele servere, directoarele pot avea nevoie de permisiuni 750.
- proprietate greșită (utilizator & probleme de grup) – proprietatea fișierului trebuie setată la „utilizator : ApacheUser” sau „utilizator : utilizator” în funcție de configurația Apache.
- codare incorectă – fișierele încărcate în modul binar vor eșua executarea și ar trebui să fie reîncărcate ca ASCII.
aproape 80% din problemele de eroare 500 ar fi rezolvate prin aceste remedieri.
acest articol este despre restul de 20% din cauzele care sunt greu de găsit și repara.
cauze mai puțin frecvente pentru eroarea serverului intern Apache CGI
500 eroarea serverului intern este modul unui server web de a spune: „ceva nu a mers bine când am încercat să afișez pagina. Nu sunt sigur ce.”
dacă nu este vorba de probleme de permisiune sau de proprietate, ar putea fi orice, de la erori de aplicație & Apache Configurări greșite la blocuri de firewall & erori de sistem de fișiere.
iată primele 10 probleme neobișnuite pe care le-am văzut în cursul nostru de lucru.
module lipsă
aplicațiile Web se bazează pe o mulțime de „module” PHP sau Perl pentru funcții specifice.
unele astfel de module fac parte dintr-o configurare standard a serverului, dar multe nu sunt.
am văzut că, după o migrare sau o în timpul unui nou site de configurare, script-uri de multe ori nu reușesc, deoarece toate modulele necesare nu sunt prezente.
Jurnalul de erori va spune că există funcții „nedefinite” sau „metode” nu există.
pentru a remedia această problemă, parcurgem specificațiile cerințelor aplicației și instalăm toate modulele lipsă.
timeout-uri de rețea (de apeluri API, Scripturi la distanță etc.)
unele aplicații web obțin date de pe servere la distanță (de ex. date meteo).
dacă din anumite motive această conexiune la serverul de la distanță este întreruptă, aplicația web va aștepta un timp și apoi va afișa o eroare de expirare.
Apache raportează apoi această stare ca o eroare 500.
această problemă poate fi greu de depanat, deoarece este posibil să nu lase o intrare în jurnal.
detectăm probleme de expirare prin inspectarea conexiunilor de ieșire în așteptare lungă și remediem prin dezactivarea funcției aplicației care necesită conexiunile de ieșire.
căi vechi de program (compilator)
prima linie din fiecare aplicație CGI (numită Shebang) conține calea către programul care ar trebui să o execute.
pentru ex. Scripturile Perl au această cale:
#!/usr/bin/perl
dar această cale poate diferi în funcție de furnizorii de sisteme de operare și de setările de compilare personalizate.
deci, scriptul va căuta fișierul programului într-o anumită locație și, dacă nu este găsit acolo, scriptul va afișa o eroare 500.
două metode eficiente sunt:
- utilizați căile definite în mediul serverului – căile tuturor programelor sunt stocate în variabila „mediu” a serverului. Deci, schimbăm prima linie apelând mediul, așa:
#!/usr/bin/env perl- acest lucru vă va asigura că, indiferent unde este setat Perl, calea va fi disponibilă pentru script.
- definiți căile programului în Apache config – utilizați directivele” AddHandler” și „Action” ale Apache pentru a executa toate fișierele cu programul potrivit. Pentru ex. iată cum să configurați PHP ca CGI:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
erori în codul aplicației
proprietarii de site-uri web pot face mici erori, cum ar fi ștergerea unui „;” sau inserarea unui caracter rătăcit în timp ce editați fișiere de aplicație sau de configurare.
acest lucru va duce la faptul că aplicația nu reușește să execute, dar Apache va scuipa doar mesajul criptic „Eroare internă a serverului”.
detectăm astfel de probleme analizând fișierele jurnal și le rezolvăm fie prin remedierea erorii de cod, fie prin dezactivarea pluginului / addonului / temei care cauzează eroarea.
fișiere de configurare vechi cu căi de module greșite
Site-urile web sunt adesea personalizate pentru mediul serverului și căile programului.
când Site-urile sunt migrate, fișierele lor de configurare vor conține aceste căi vechi care ar putea să nu fie compatibile cu noul server.
am văzut cazuri în care aplicațiile web folosesc fișiere de configurare personalizate (să zicem php.ini) pentru a încărca funcțiile bibliotecii. Acest lucru va eșua atunci când calea se schimbă într-un server nou.
în astfel de cazuri, eliminăm căile de program codificate și folosim în schimb variabile de mediu pentru a achiziționa automat locațiile programului.
restricții de securitate (firewall pentru aplicații Web, SELinux etc.)
majoritatea serverelor din zilele noastre au firewall-uri pentru aplicații Web, cum ar fi mod_security sau ComodoWAF.
aceste firewall-uri pot provoca o eroare 500 dacă interpretează o solicitare de pagină ca un atac.
pentru ex. am văzut aplicații web care nu reușesc, deoarece un apel de fișiere externe a fost interpretat ca un atac de includere a fișierelor la distanță de către mod_security.
în astfel de cazuri, creăm reguli de excludere firewall personalizate, astfel încât aplicația să nu mai fie blocată, în timp ce securitatea serverului nu este afectată.
schimbarea setării SELinux de la „aplicarea” la „permisiv” ne-a ajutat, de asemenea, să remediem această eroare.
nicio restricție Exec (fără execuție) pe partiția
aplicațiile CGI sunt executate ca programe.
pentru asta are nevoie de ceva numit privilegiu de „executare”.
acest privilegiu „Execute” este dezactivat pentru partițiile accesibile publicului, cum ar fi „/tmp” și partițiile de stocare a datelor, cum ar fi „/backup”, pentru a preveni executarea programelor malware.
am văzut cazuri în care acest bit „Execute” este oprit pentru casele de site-uri web, provocând astfel executarea scriptului să eșueze.
restaurăm exec prin:
# mount -o remount,exec /home
Apache &.htaccess misfiguration (fără ExecCGI, fără AllowOverride etc.)
Apache trebuie să știe ce directoare conțin scripturi CGI.
care este notat folosind Directiva „ExecCGI”.
pentru ex. pentru a desemna /cgi-bin/ ca director CGI, Apache ar trebui să fie configurat cu:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
în unele servere am văzut” ExecCGI ” dezactivat în cgi-bin din cauza configurației greșite fie în fișierul Apache conf, fie într-un fișier .htaccess în directorul părinte.
în mod similar, am văzut directivele legate de CGI în .htaccess devine ineficient, deoarece .htaccess nu a fost activat printr-o directivă” AllowOverride ” în Apache config.
toate acestea pot duce la o execuție eșuată a scriptului și, în consecință, la o eroare 500.
permisiuni greșite în directorul principal
directoarele CGI sunt de obicei plasate în directorul principal. Pentru ex. calea către un cgi-bin în serverele cPanel este:
/home/username/public_html/cgi-bin/
mulți webmasteri au grijă să schimbe permisiunea directorului CGI-bin și a directoarelor de aplicații web la 755, dar uită să verifice permisiunile directorului de acasă.
în unele configurații Apache (de ex. când utilizați SuExec), directorul de acasă ar trebui să aibă și permisiuni 755. Orice altceva decât asta (ex. 777), va determina executarea scriptului să eșueze.
deci, unul dintre primele lucruri pe care le verificăm împreună cu permisiunile fișierului script este să verificăm permisiunile tuturor directoarelor din calea fișierului.
am stabilit totul doar dreptul de a vă asigura că scriptul execută fără erori.
erori legate de Chroot care rupe calea fișierului
în unele servere partajate, securitatea este impusă prin limitarea fiecărui utilizator la un mediu închis.
acest lucru împiedică un utilizator să acceseze fișierele oricărui alt utilizator.
dar astfel de medii pot rupe Softlink-urile la fișierele de program.
pentru ex. dacă programele sunt stocate în „/opt/php/bin/” și este legat de „/usr/bin/php/”, aceste referințe pot fi rupte.
acestea sunt cazuri destul de rare și le remediem reconfigurând serverul (sau site-ul) pentru a utiliza calea corectă în loc de softlinks.