Apachen CGI-tila mahdollistaa webmasterin vähentää muistin käyttöä. Se on edullinen tapa ajaa monia vähäliikenteisiä sivustoja.
mutta CGI-tila on melko herkkä asioille, kuten käyttöoikeuksille ja tiedostojen koodaukselle, mikä johtaa 500 sisäiseen Palvelinvirheeseen.
toimiessamme web-isäntien tukena olemme nähneet monenlaisia syitä tähän virheeseen.
joitakin yleisiä syitä ja niiden korjauksia ovat:
- väärien tiedostojen tai kansioiden käyttöoikeudet – Komentosarjatiedostoilla ja-kansioilla on oltava täsmälleen 755 käyttöoikeutta. Joillakin palvelimilla hakemistot saattavat tarvita 750 käyttöoikeutta.
- väärä omistus (käyttäjä & ryhmäongelmat) – tiedoston omistus tulee asettaa muotoon ”USER : ApacheUser” tai ”USER : USER” Apachen kokoonpanosta riippuen.
- virheellinen koodaus-tiedostot, jotka on ladattu Binääritilassa, epäonnistuvat suorituksessa, ja ne tulee ladata uudelleen ASCII-muodossa.
lähes 80% virhe 500 asioista ratkeaisi näillä korjauksilla.
tämä artikkeli käsittelee loput 20% syistä, joita on vaikea löytää ja korjata.
Uncommon causes for Apache CGI Internal Server Error
500 Internal Server Error on WWW-palvelimen tapa sanoa: ”Something has gone wrong when I tried to display the page. En tiedä mitä.”
jos se ei ole lupa-tai omistusongelmia, se voi olla mitä tahansa sovellusvirheistä & Apache-virhelaskelmista palomuurilohkoihin & tiedostojärjestelmävirheisiin.
tässä ovat top 10 uncommon issues we ’ ve seen in our course of work.
puuttuvat moduulit
Web-sovellukset tukeutuvat paljon PHP-tai Perl – ”moduuleihin” tiettyjä toimintoja varten.
jotkut tällaiset moduulit ovat osa tavanomaista palvelinasetusta, mutta monet eivät.
olemme nähneet, että migraation tai uuden verkkosivuston asennuksen aikana skriptit usein epäonnistuvat, koska kaikki tarvittavat moduulit eivät ole läsnä.
virheloki kertoo, että on olemassa ”määrittelemättömiä” funktioita tai ”menetelmiä” ei ole olemassa.
korjataksemme tämän käymme läpi sovelluksen vaatimusmääritykset ja asennamme kaikki puuttuvat moduulit.
verkon aikakatkaisut (API-puheluista, etäkosketuksista jne.)
jotkut verkkosovellukset saavat dataa etäpalvelimilta (esim. säätiedot).
jos yhteys etäpalvelimeen jostain syystä katkeaa, verkkosovellus odottaa hetken ja näyttää sitten aikakatkaisuvirheen.
Apache ilmoittaa tämän jälkeen tämän tilan virheenä 500.
tämän ongelman vianmääritys voi olla vaikeaa, koska se ei välttämättä jätä lokimerkintää.
havaitsemme aikakatkaisuongelmat tarkastamalla pitkään vireillä olevia lähteviä yhteyksiä, ja korjaamme sen poistamalla käytöstä sovelluksen ominaisuuden, joka vaatii lähteviä yhteyksiä.
vanhan ohjelman (kääntäjän) polut
jokaisen CGI-sovelluksen ensimmäinen rivi (nimeltään Shebang) sisältää polun ohjelmaan, jonka on tarkoitus suorittaa se.
esim. Perl-skripteillä on tämä polku:
#!/usr/bin/perl
mutta tämä polku voi vaihdella perustuu käyttöjärjestelmän toimittajat, ja custom kokoelma-asetukset.
joten skripti etsii ohjelmatiedoston tietystä paikasta, ja jos sitä ei löydy sieltä, skripti näyttää virheen 500.
kaksi tehokasta menetelmää ovat:
- käytä palvelinympäristössä määriteltyjä polkuja-kaikkien ohjelmien polut tallennetaan palvelimen ”ympäristö” – muuttujaan. Vaihdamme ensimmäisen rivin soittamalla ympäristöön.:
#!/usr/bin/env perl- tämä varmistaa, että riippumatta siitä, missä Perl on setup, polku on käytettävissä skripti.
- Määritä Apache config-ohjelman polut – käytä Apachen” AddHandler ”- ja” Action ” – direktiivejä kaikkien tiedostojen suorittamiseen oikealla ohjelmalla. Esim. näin määrität PHP: n CGI: ksi:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
virheet sovelluskoodissa
verkkosivujen omistajat voivat tehdä pieniä virheitä, kuten poistaa”;”: n tai lisätä harhaisen merkin muokatessaan sovellusta tai asetustiedostoja.
tämä johtaa siihen, että sovellus ei suorita, mutta Apache sylkee ulos vain kryptisen ”sisäisen Palvelinvirheen” viestin.
havaitsemme tällaiset ongelmat analysoimalla lokitiedostoja, ja ratkaisemme sen joko korjaamalla koodivirheen tai poistamalla virheen aiheuttavan liitännäisen / addonin / teeman käytöstä.
Vanhat asetustiedostot, joissa on väärät moduulipolut
verkkosivut on usein räätälöity palvelimen ympäristö-ja ohjelmapoluille.
kun sivustoja siirretään, niiden asetustiedostot sisältävät nämä vanhat polut, jotka eivät välttämättä ole yhteensopivia uuden palvelimen kanssa.
olemme nähneet tapauksia, joissa verkkosovellukset käyttävät mukautettuja asetustiedostoja (sano PHP.ini) kirjaston toimintojen lataamiseen. Tämä epäonnistuu, kun polku muuttuu uudessa palvelimessa.
tällaisissa tapauksissa poistamme kovakoodatut ohjelmapolut ja käytämme sen sijaan ympäristömuuttujia hankkiaksemme automaattisesti ohjelmapaikat.
Tietoturvarajoitukset (verkkosovelluksen palomuuri, SELinux jne.)
useimmilla palvelimilla on nykyään Web-sovellusten palomuurit, kuten mod_security tai ComodoWAF.
nämä palomuurit voivat aiheuttaa virheen 500, Jos se tulkitsee sivupyynnön hyökkäykseksi.
esim. olemme nähneet web-sovellusten epäonnistuvan, koska ulkoiset tiedostopuhelut tulkittiin Mod_securityn etätiedostojen Sisällyttämishyökkäykseksi.
tällaisissa tapauksissa luomme mukautettuja palomuurin sulkusääntöjä niin, että sovellusta ei enää estetä, kun taas palvelimen tietoturva ei muutu.
SELinux-asetuksen muuttaminen ”Enforcingista” ”sallivaan” on myös auttanut meitä korjaamaan tämän virheen.
ei Exec (ei suoritusta) – rajoitusta osiolle
CGI-sovellukset suoritetaan ohjelmina.
siihen se tarvitsee jotain niin sanottua” Execute ” – etuoikeutta.
tämä” Suorita ”-etuoikeus on pois päältä yleisesti käytettävissä olevissa osioissa, kuten” /tmp”, ja data-store-osioissa, kuten” /backup”, haittaohjelmien suorittamisen estämiseksi.
olemme nähneet tapauksia, joissa tämä” Suorita ” – bitti on kytketty pois päältä verkkosivustojen koteihin, jolloin skriptin suoritus epäonnistuu.
palautamme suorituksen:
# mount -o remount,exec /home
Apache & .htaccess misfiguration (no ExecCGI, No AllowOverride, jne.)
Apachen on tiedettävä, mitkä hakemistot sisältävät CGI-skriptejä.
, joka merkitään direktiivillä ”ExecCGI”.
esim. merkitäkseen /cgi-bin/ CGI-hakemistona Apache tulee määrittää:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
joissakin palvelimissa olemme nähneet ”ExecCGI” käytöstä cgi-bin johtuen virheellisestä joko Apache conf tiedosto tai an .htaccess ylähakemistossa.
vastaavasti olemme nähneet CGI: hen liittyviä direktiivejä .htaccess tulossa tehoton, koska .htaccess ei ollut käytössä ”AllowOverride” – direktiivin avulla Apache configissa.
kaikki tämä voi johtaa epäonnistuneeseen komentosarjan suoritukseen ja siten virheeseen 500.
kotihakemiston väärät käyttöoikeudet
CGI-hakemistot sijoitetaan yleensä kotihakemistoon. Esim. polku cgi-bin cPanel-palvelimissa on:
/home/username/public_html/cgi-bin/
monet Webmasterit pitävät huolen siitä, että cgi-bin-hakemiston ja web-sovellusten hakemistojen oikeudet muutetaan 755: ksi, mutta unohtavat tarkistaa kotihakemiston käyttöoikeudet.
joissakin Apassikonfiguraatioissa (esim. kun käytät Suexecia), kotihakemistossa pitäisi olla myös 755 käyttöoikeutta. Mitään muuta kuin että (esim. 777), aiheuttaa skriptin suorituksen epäonnistumisen.
niin, yksi ensimmäisistä asioista tarkistamme yhdessä komentosarjatiedoston käyttöoikeudet on tarkistaa kaikkien hakemistojen oikeudet tiedoston polku.
asetimme kaiken juuri oikein varmistaaksemme, että skripti suoritetaan virheettömästi.
chrootiin liittyvät virheet, jotka katkaisevat tiedostopolun
joissakin jaetuissa palvelimissa tietoturva varmistetaan sulkemalla jokainen käyttäjä vangittuun ympäristöön.
tämä estää yhtä käyttäjää pääsemästä toisen käyttäjän tiedostoihin.
mutta tällaiset ympäristöt voivat murtaa ohjelmatiedostojen softlinkejä.
esim. jos ohjelmat tallennetaan ”/opt/php/bin/” ja se on linkitetty ”/usr/bin/php/”, nämä viittaukset voivat murtua.
nämä ovat melko harvinaisia tapauksia, ja korjaamme sen määrittämällä palvelimen (tai sivuston) uudelleen käyttämään oikeaa polkua softlinkkien sijaan.