tryb CGI Apache pozwala webmasterom zmniejszyć zużycie pamięci. Jest to preferowany sposób uruchamiania wielu witryn o małym natężeniu ruchu.
ale tryb CGI jest dość wrażliwy na takie rzeczy, jak uprawnienia i kodowanie plików, co prowadzi do wewnętrznego błędu serwera 500.
w naszej roli jako inżynierów wsparcia dla hostów internetowych widzieliśmy szeroki zakres przyczyn tego błędu.
niektóre typowe przyczyny i ich poprawki to:
- nieprawidłowe uprawnienia do plików lub folderów – pliki skryptów i katalogi muszą mieć dokładnie 755 uprawnień. Na niektórych serwerach katalogi mogą wymagać uprawnień 750.
- Niewłaściwa własność (user & problemy z grupą) – własność pliku powinna być ustawiona na „USER: ApacheUser” lub „USER: USER” w zależności od konfiguracji Apache ’ a.
- nieprawidłowe kodowanie – pliki przesłane w trybie binarnym nie wykonają się i powinny zostać ponownie przesłane jako ASCII.
prawie 80% problemów z błędami 500 zostanie rozwiązanych przez te poprawki.
ten artykuł dotyczy reszty 20% przyczyn, które są trudne do znalezienia i naprawienia.
niezbyt częste przyczyny wewnętrznego błędu serwera Apache CGI
Wewnętrzny błąd serwera 500 to sposób serwera www na powiedzenie: „coś poszło nie tak, gdy próbowałem wyświetlić stronę. Nie wiem co.”
jeśli nie są to problemy z uprawnieniami lub własnością, może to być wszystko, od błędów aplikacji & błędy konfiguracji Apache do bloków zapory & błędy systemu plików.
oto 10 najczęstszych problemów, które widzieliśmy w naszej pracy.
brakujące Moduły
aplikacje internetowe opierają się na wielu „modułach” PHP lub Perla dla określonych funkcji.
niektóre takie moduły są częścią standardowej konfiguracji serwera, ale wiele z nich nie.
zauważyliśmy, że po migracji lub podczas nowej konfiguracji witryny Skrypty często zawodzą, ponieważ nie ma wszystkich wymaganych modułów.
dziennik błędów powie, że istnieją” niezdefiniowane „funkcje lub” metody ” nie istnieją.
aby to naprawić, przechodzimy przez specyfikacje wymagań aplikacji i instalujemy wszystkie brakujące Moduły.
przekroczenia czasu pracy sieci (wywołań API, skryptów zdalnych itp.)
niektóre aplikacje internetowe pobierają dane ze zdalnych serwerów(np. danych pogodowych).
jeśli z jakiegoś powodu połączenie ze zdalnym serwerem zostanie przerwane, aplikacja webowa odczekuje chwilę, a następnie wyświetli błąd przerwania.
Apache zgłasza ten status jako Błąd 500.
ten problem może być trudny do rozwiązania, ponieważ może nie pozostawiać wpisu dziennika.
wykrywamy problemy z limitem czasu, sprawdzając długo oczekujące połączenia wychodzące i naprawiamy je, wyłączając funkcję aplikacji, która wymaga połączeń wychodzących.
stare ścieżki programu (kompilatora)
pierwsza linia w każdej aplikacji CGI (zwanej Shebang) zawiera ścieżkę do programu, który ma ją wykonać.
dla np. Skrypty Perla mają taką ścieżkę:
#!/usr/bin/perl
ale ta ścieżka może się różnić w zależności od dostawców systemów operacyjnych i niestandardowych ustawień kompilacji.
tak więc skrypt będzie szukał pliku programu w określonej lokalizacji, a jeśli nie zostanie tam znaleziony, skrypt pokaże błąd 500.
dwie skuteczne metody to:
- użyj ścieżek zdefiniowanych w środowisku serwera-ścieżki wszystkich programów są przechowywane w zmiennej „środowisko” serwera. Zmieniamy pierwszą linię wywołując środowisko, tak:
#!/usr/bin/env perl- zapewni to, że bez względu na to, gdzie jest ustawiony Perl, ścieżka będzie dostępna dla skryptu.
- Zdefiniuj ścieżki programu w konfiguracji Apache-użyj dyrektyw” AddHandler „i” Action ” Apache, aby wykonać wszystkie pliki za pomocą odpowiedniego programu. Dla np. oto jak skonfigurować PHP jako CGI:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
błędy w kodzie aplikacji
właściciele stron internetowych mogą popełniać małe błędy, takie jak usuwanie „;” lub wstawianie błądzącego znaku podczas edycji aplikacji lub plików konfiguracyjnych.
spowoduje to, że aplikacja nie zostanie uruchomiona, ale Apache wypluje tylko tajemniczy komunikat „Internal Server Error”.
wykrywamy takie problemy, analizując pliki dziennika i rozwiązując je, naprawiając błąd kodu lub wyłączając wtyczkę / dodatek / motyw, który powoduje błąd.
stare pliki konfiguracyjne z niewłaściwymi ścieżkami modułów
strony internetowe są często dostosowywane do środowiska serwera i ścieżek programu.
gdy Witryny są migrowane, ich pliki konfiguracyjne będą zawierały te stare ścieżki, które mogą nie być kompatybilne z nowym serwerem.
widzieliśmy przypadki, w których aplikacje internetowe używają niestandardowych plików konfiguracyjnych (powiedzmy php.ini) do ładowania funkcji bibliotecznych. Nie powiedzie się to, gdy ścieżka zmieni się na nowym serwerze.
w takich przypadkach usuwamy zakodowane na stałe ścieżki programu i zamiast tego używamy zmiennych środowiskowych do automatycznego pozyskiwania lokalizacji programu.
ograniczenia bezpieczeństwa (Firewall aplikacji webowych, SELinux itp.)
większość serwerów ma obecnie zapory aplikacji internetowych, takie jak mod_security lub ComodoWAF.
te zapory mogą spowodować błąd 500, jeśli zinterpretuje żądanie strony jako atak.
dla np. widzieliśmy awarie aplikacji internetowych, ponieważ zewnętrzne wywołania plików zostały zinterpretowane jako atak zdalnego włączania plików przez mod_security.
w takich przypadkach tworzymy niestandardowe reguły wykluczania zapory, dzięki czemu aplikacja nie będzie już blokowana, a bezpieczeństwo serwera nie zostanie naruszone.
Zmiana ustawienia SELinux z „Enforcing” na „Permissive” również pomogła nam naprawić ten błąd.
Brak ograniczeń Exec (brak wykonania) na partycji
aplikacje CGI są uruchamiane jako programy.
do tego potrzebuje czegoś, co nazywa się przywilejem „Execute”.
ten przywilej „wykonaj” jest wyłączony dla publicznie dostępnych partycji, takich jak „/tmp” i partycji przechowywania danych, takich jak „/backup”, aby zapobiec wykonywaniu złośliwego oprogramowania.
widzieliśmy przypadki, w których bit „Execute” jest wyłączony dla domów stron internetowych, powodując tym samym niepowodzenie wykonywania skryptu.
przywracamy exec przez:
# mount -o remount,exec /home
Apache &.błąd w konfiguracji htaccess (brak ExecCGI, brak Alloweroverride, itp.)
Apache musi wiedzieć, które katalogi zawierają skrypty CGI.
, który jest oznaczony za pomocą dyrektywy „ExecCGI”.
dla np. aby określić/ cgi-bin / jako katalog CGI, Apache powinien być skonfigurowany z:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
na niektórych serwerach widzieliśmy” ExecCGI ” wyłączone w cgi-bin z powodu błędnej konfiguracji w pliku Apache conf lub an .htaccess w katalogu nadrzędnym.
podobnie, widzieliśmy dyrektywy związane z CGI w .htaccess staje się nieskuteczny, ponieważ .htaccess nie został włączony przez dyrektywę „AllowOverride” w konfiguracji Apache.
wszystko to może spowodować nieudane wykonanie skryptu, a w konsekwencji Błąd 500.
niewłaściwe uprawnienia do katalogu domowego
katalogi CGI są zwykle umieszczane w katalogu domowym. Dla np. ścieżka do cgi-bin w serwerach cPanel jest:
/home/username/public_html/cgi-bin/
wielu webmasterów stara się zmienić uprawnienia katalogu cgi-bin i katalogów aplikacji internetowych na 755, ale zapomina sprawdzić uprawnienia katalogu domowego.
w niektórych konfiguracjach Apache(np. podczas używania SuExec), katalog domowy również powinien mieć uprawnienia 755. Cokolwiek innego (np. 777), spowoduje, że wykonanie skryptu nie powiedzie się.
tak więc jedną z pierwszych rzeczy, które sprawdzamy wraz z uprawnieniami do pliku skryptu, jest sprawdzenie uprawnień wszystkich katalogów w ścieżce pliku.
ustawiamy wszystko tak, aby upewnić się, że skrypt wykonuje się bez błędów.
błędy związane z Chroot, które łamią ścieżkę pliku
w niektórych współdzielonych serwerach bezpieczeństwo jest wymuszane przez ograniczenie każdego użytkownika do uwięzionego środowiska.
uniemożliwia to jednemu użytkownikowi dostęp do plików innego użytkownika.
ale takie środowiska mogą łamać softlinki do plików programowych.
dla np. jeśli programy są przechowywane w „/opt/php/bin/” i jest on połączony z „/usr/bin/php/”, te odwołania mogą zostać złamane.
są to dość rzadkie przypadki i naprawiamy to, ponownie konfigurując serwer (lub witrynę), aby używał właściwej ścieżki zamiast linków Softlink.