Apache CGI mód lehetővé teszi a webmester, hogy csökkentse a memória használat. Ez az előnyben részesített módja sok alacsony forgalmú webhely futtatásának.
de a CGI mód nagyon érzékeny az olyan dolgokra, mint az engedélyek és a fájlkódolás, ami 500 belső Szerverhibához vezet.
webtárhelyeket támogató mérnökként a hiba okainak széles skáláját láttuk.
néhány gyakori ok és javításuk a következő:
- hibás fájl – vagy mappaengedélyek-a Szkriptfájloknak és könyvtáraknak pontosan 755 jogosultsággal kell rendelkezniük. Egyes szervereken a könyvtáraknak 750 engedélyre lehet szükségük.
- hibás tulajdonjog (felhasználó & Csoportos problémák) – a fájl tulajdonjogát az Apache konfigurációjától függően “USER : ApacheUser” vagy “USER : USER” értékre kell állítani.
- helytelen kódolás – a bináris módban feltöltött fájlok végrehajtása sikertelen lesz, ezért ASCII-ként kell őket újra feltölteni.
az 500-as hibák majdnem 80% – át megoldják ezek a javítások.
ez a cikk a többi 20% – ról szól okok, amelyeket nehéz megtalálni és kijavítani.
az Apache CGI belső szerverhiba Nem gyakori okai
500 a belső szerverhiba egy webszerver módja annak, hogy azt mondja: “valami rosszul ment, amikor megpróbáltam megjeleníteni az oldalt. Nem tudom, mit.”
ha ez nem engedély vagy tulajdonosi kérdés, akkor bármi lehet az alkalmazás hibáitól & az Apache hibás konfigurációi a tűzfalblokkokig & fájlrendszer hibák.
itt vannak a top 10 Nem gyakori kérdések láttuk a mi munkánk során.
hiányzó modulok
a webes alkalmazások sok PHP vagy Perl “modulra” támaszkodnak bizonyos funkciókhoz.
néhány ilyen modul egy szabványos szerverbeállítás része, de sok nem.
láttuk, hogy egy áttelepítés vagy egy új webhely beállítása során a szkriptek gyakran meghibásodnak, mert az összes szükséges modul nincs jelen.
a hibanapló azt fogja mondani, hogy vannak “meghatározatlan” függvények vagy” módszerek ” nem léteznek.
ennek kijavításához áttekintjük az alkalmazás követelményeit, és telepítjük az összes hiányzó modult.
hálózati időtúllépések (API hívások, távoli szkriptek stb.)
egyes webes alkalmazások távoli szerverekről kapnak adatokat(pl. időjárási adatok).
ha valamilyen okból megszakad ez a kapcsolat a távoli kiszolgálóval, a webalkalmazás vár egy ideig, majd időtúllépési hibát jelenít meg.
az Apache ezt az állapotot 500-as hibaként jelenti.
ezt a problémát nehéz elhárítani, mivel előfordulhat, hogy nem hagy naplóbejegyzést.
az időtúllépési problémákat a hosszú függőben lévő kimenő kapcsolatok ellenőrzésével észleljük, és a kimenő kapcsolatokat igénylő alkalmazás funkció letiltásával javítjuk.
régi program (fordító) elérési útjai
minden CGI alkalmazás első sora (Shebang néven) tartalmazza annak a programnak az elérési útját, amely állítólag végrehajtja.
pl. Perl szkriptek ezt az utat:
#!/usr/bin/perl
de ez az út eltérhet az operációs rendszer gyártóitól és az egyéni fordítási beállításoktól függően.
tehát a szkript megkeresi a programfájlt egy adott helyen, és ha nem találja ott, akkor a szkript 500-as hibát jelenít meg.
két hatékony módszer:
- használja a kiszolgálói környezetben meghatározott útvonalakat-az összes program elérési útját a kiszolgáló “környezet” változója tárolja. Tehát megváltoztatjuk az első sort a környezet meghívásával, így:
#!/usr/bin/env perl- ez biztosítja, hogy a Perl telepítésétől függetlenül az elérési út elérhető legyen a szkript számára.
- határozza meg a Program útvonalait az Apache config-ben – használja az Apache” AddHandler “és” Action ” irányelveit az összes fájl végrehajtásához a megfelelő programmal. Pl. így állíthatja be a PHP-t CGI-ként:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
hibák az alkalmazáskódban
a webhelytulajdonosok kisebb hibákat követhetnek el, például törölhetnek egy”; ” – t vagy beszúrhatnak egy kóbor karaktert az alkalmazás-vagy konfigurációs fájlok szerkesztése közben.
ennek eredményeként az alkalmazás nem fog végrehajtani, de az Apache csak a rejtélyes “belső szerverhiba” üzenetet fogja kiköpni.
az ilyen problémákat a naplófájlok elemzésével észleljük, és megoldjuk a kódhiba kijavításával vagy a hibát okozó plugin / addon / téma letiltásával.
régi konfigurációs fájlok hibás modulútvonalakkal
a webhelyeket gyakran a szerver környezetéhez és a programútvonalakhoz igazítják.
a webhelyek áttelepítésekor a konfigurációs fájlok tartalmazzák ezeket a régi útvonalakat, amelyek esetleg nem kompatibilisek az új kiszolgálóval.
láttunk olyan eseteket, amikor a webes alkalmazások egyedi konfigurációs fájlokat használnak (mondjuk php.ini) könyvtári funkciók betöltéséhez. Ez sikertelen lesz, ha az útvonal megváltozik egy új kiszolgálón.
ilyen esetekben eltávolítjuk a kódolt programútvonalakat, és ehelyett környezeti változókat használunk a programhelyek automatikus megszerzésére.
biztonsági korlátozások (webalkalmazások tűzfala, SELinux stb.)
manapság a legtöbb szerver rendelkezik webes alkalmazás tűzfalakkal, például mod_security vagy ComodoWAF.
ezek a tűzfalak 500-as hibát okozhatnak, ha egy oldalkérést támadásként értelmeznek.
pl. láttuk, hogy a webes alkalmazások kudarcot vallanak, mert egy külső fájlhívást a mod_security távoli Fájlbeviteli támadásként értelmezett.
ilyen esetekben egyedi tűzfal-kizárási szabályokat hozunk létre, hogy az alkalmazás már ne legyen blokkolva, miközben a szerver biztonságát ez nem befolyásolja.
a SELinux beállításának megváltoztatása “érvényesítésről” “Megengedőre” szintén segített kijavítani ezt a hibát.
nincs Exec (nincs végrehajtás) korlátozás a partíción
a CGI alkalmazások programként kerülnek végrehajtásra.
az, hogy szüksége van valami úgynevezett” Execute ” jogosultság.
ez az “Execute” jogosultság ki van kapcsolva a nyilvánosan elérhető partíciók, például a “/tmp” és az adattároló partíciók, például a “/backup” esetén a rosszindulatú programok végrehajtásának megakadályozása érdekében.
láttunk olyan eseteket, amikor ez a” végrehajtás ” bit ki van kapcsolva a webhelyházaknál, ezáltal a szkript végrehajtása sikertelen.
visszaállítjuk a végrehajtást:
# mount -o remount,exec /home
Apache &.htaccess hibás konfigurálása (nincs ExecCGI, nincs AllowOverride stb.)
az Apache-nak tudnia kell, hogy mely könyvtárak tartalmaznak CGI szkripteket.
ezt az “ExecCGI”irányelvvel jelöljük.
pl. a /cgi-bin/ CGI könyvtárként való jelöléséhez az Apache-t a következőkkel kell konfigurálni:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
néhány szerveren láttuk, hogy az “ExecCGI” le van tiltva a cgi-bin-ben az Apache conf fájl vagy az an hibás konfigurálása miatt .htaccess a szülő könyvtárban.
hasonlóképpen láttuk a CGI-vel kapcsolatos irányelveket .a htaccess hatástalanná válik, mert .a htaccess nem volt engedélyezve az Apache config” AllowOverride ” irányelvén keresztül.
mindez sikertelen parancsfájl-végrehajtást, következésképpen 500-as hibát eredményezhet.
hibás engedélyek a saját könyvtárban
a CGI könyvtárak általában a saját könyvtárban vannak elhelyezve. Pl. a cgi-bin elérési útja a cPanel szerverekben:
/home/username/public_html/cgi-bin/
sok webmester gondoskodik arról, hogy a cgi-bin könyvtár és a webalkalmazások könyvtárainak engedélyét 755-re változtassa, de elfelejti ellenőrizni a saját könyvtár engedélyeit.
néhány Apache konfigurációban (pl. SuExec használata esetén), a saját könyvtárnak 755 jogosultsággal kell rendelkeznie. Bármi más, mint ez (pl. 777), a parancsfájl végrehajtása sikertelen lesz.
tehát az egyik első dolog, amit a szkriptfájl-engedélyekkel együtt ellenőrizünk, az, hogy ellenőrizzük a fájl elérési útjában lévő összes könyvtár engedélyét.
mindent pontosan beállítottunk, hogy megbizonyosodjunk arról, hogy a szkript hiba nélkül fut.
Chroot kapcsolatos hibák, amelyek megszakítják a fájl elérési útját
egyes megosztott kiszolgálókon a biztonságot úgy hajtják végre, hogy minden Felhasználót bebörtönzött környezetre korlátoznak.
ez megakadályozza, hogy egy felhasználó hozzáférjen bármely más felhasználó fájljaihoz.
de az ilyen környezetek megszakíthatják a programfájlokra mutató softlinkeket.
pl. ha a programok az “/opt/php/bin/” könyvtárban vannak tárolva, és a “/usr/bin/php/” könyvtárhoz kapcsolódnak, akkor ezek a hivatkozások megszakadhatnak.
ezek nagyon ritka esetek, és úgy javítjuk ki, hogy a szervert (vagy webhelyet) újra konfiguráljuk, hogy a softlinkek helyett a helyes utat használja.