Tipinės svetainės neveikimo priežastys

IV_VygandasS

Šiame informaciniame straipsnyje glaustai aptarsime tipines problemas dėl kurių Jūsų svetainė gali būti neatvaizduojama.

Tipinių problemų skirstymas

Dažniausiai nesėkmingai bandant priversti naują svetainę veikti reikia atsakyti į šiuos klausimu:

• Ar web serverio tarnybą įdiegta?
• Ar web serverio tarnyba yra paleista?
• Ar web serverio konfigūracijos sintaksė yra teisinga?
• Ar sukonfigūruoti prievadai yra atidaryti/pasiekiami?
• Ar DNS nukreipimai yra atlikti korektiškai?
• Ar yra tinkamai nurodytas svetainės šakninis katalogas?
• Ar web serveris pateikia tinkamus indekso failus?
• Ar svetainės failų ir katalogų teisės bei savininkai yra nurodyti teisingai?
• Ar per konfigūracinius failus nėra ribojama prieiga?
• Jeigu svetainė naudoja duomenų bazes, ar duomenų bazių tarnyba yra paleista?
• Ar svetainė sėkmingai prisijungia prie reikalingos duomenų bazės?
• Ar web serveris yra tinkamai sukonfigūruotas atvaizduoti dinaminį turinį?

Pirma vieta kur reikėtų ieškoti problemos priežasties yra atitinkamos tarnybos žurnalų išrašai. Įprastai žurnalų išrašai serveryje yra laikomi /var/log/ kataloge, bei jo subkataloguose.

Pavyzdžiui, jeigu mūsų web serveris yra Apache, tuomet priklausomai nuo operacinės sistemos Apache žurnalų išrašus rasime /var/log/Apache2/ arba /var/log/httpd/ kataloguose. Taip pat jeigu turime duomenų bazių serverį, tuomet duomenų bazių tarnybos žurnalų išrašus taip pat rasime /var/log/ kataloge.

Taip pat svarbu atkreipti dėmesį, kokį klaidos pranešimas pateikia (jeigu pateikia) tarnyba kai ši yra paleidžiama, bei koks klaidos pranešimas yra pateikiamas bandant apsilankyti pačioje pageidaujamoje svetainėje.

Tiek pagal gaunamus klaidų pranešimus apsilankant pačioje svetainėje, tiek žurnalų išrašuose yra pakankamai patogu susirasti problemos priežastį naudojantis pageidaujama paieškos sistema.

Ar web serverio tarnyba įdiegta?

Pirmas ir pagrindinis dalykas kuris yra reikalingas atvaizduojant internetinę svetainę tai žinoma yra web serverio tarnyba.

Žinoma visuose serveriuose aptarnaujančiuose internetines svetaines vienu ar kitu momentu buvo/yra įrašyta web serverio tarnyba. Tačiau pasitaiko atvejų kai atliekant operacijas su kitų tarnybų paketais, web serverio tarnyba yra paprasčiausiai pašalinama kartu su kitais paketais.

Todėl pastebėjus jog visgi web serverio tarnyba buvo tyčia ar netyčia pašalinta, iš naujo įdiegti web serverio tarnybą galime naudojant šias komandas:

Naudojant Ubuntu ar Debian operacines sistemas, šiomis komandomis bus įdiegiamas Apache web serveris:

sudo apt-get update
sudo apt-get install apache2

Šiose sistemose Apache procesas yra vadinamas Apache2.

Naudojant Ubuntu ar Debian operacines sistemas, šiomis komandomis bus įdiegiamas Nginx web serveris:

sudo apt-get update
sudo apt-get install nginx

Šiose sistemose Nginx procesas yra vadinamas Nginx.

Naudojant CentOS ar Fedora operacines sistemas, šiomis komandomis bus įdiegiamas Apache web serveris:

sudo yum install httpd

Šiose sistemose Apache procesas yra vadinamas httpd.

Naudojant CentOS ar Fedora operacines sistemas, šiomis komandomis bus įdiegiamas Nginx web serveris:

sudo rpm -Uvh http://download.Fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
sudo yum install nginx

Šiose sistemose Nginx procesas yra vadinamas Nginx.

Ar web serverio tarnyba yra paleista?

Įsitikinus jog web serverio tarnyba yra įdiegta, reikia įsitikinti jog ji yra paleista.

Vienas iš būdų kaip tai galime atlikti yra patikrinimas ar Apache tarnyba yra atidariusi prievadą. Tai galime pamatyti įvykdžius šią komandą:

sudo netstat -plunt | grep apache2

Numatomas rezultatas:

tcp6       0      0 :::80           :::*            LISTEN      2000/apache2

Pastaba: komandoje naudojamą Apache2 reikėtų pakeisti į mūsų serveryje naudojamą web serverio proceso pavadinimą.

Jeigu prieš tai pateikta komanda negrąžina jokio rezultato, tuomet tikėtina jog web serverio tarnyba nėra paleista.

Taip pat patikrinti ar Apache procesas yra paleistas galime pažiūrėti pačio proceso statusą sistemoje, šiomis komandomis:

Ubuntu ar Debian:

sudo service apache2 status

CentOS ar Fedora:

sudo service httpd status

Tokiu atveju priklausomai nuo naudojamos operacinės sistemos web serverio tarnybą paleisti galime žemiau pateiktų komandų principu:

Ubuntu ar Debian:

sudo service apache2 start

CentOS ar Fedora:

sudo /etc/init.d/httpd start

arba

sudo service httpd start

Jeigu web serverio tarnyba yra startavo, tuomet pakartotinai patikriname netstat komandos rezultatą.

Ar web serverio konfigūracijos sintaksė yra teisinga?

Jeigu paleisti web serverio tarnybos visgi nepavyksta, dažniausiai tai indikuota problemą tarnybos konfigūraciniame faile. Tiek Apache tiek Nginx turi pakankamai griežtus reikalavimus direktyvų sintaksei.

Konfigūraciniai failai įprastai yra laikomi /etc/ direktorijos subkataloge, kuris yra vadinamas pagal pačio proceso pavadinimą.

Ubuntu ar Debian į pagrindinę Apache direktoriją mes galime patekti įvykdę šią komandą:

cd /etc/apache2

CentOS ar Fedora į pagrindinę Apache direktoriją mes galime patekti įvykdę šią komandą:

cd /etc/httpd

Šiuose kataloguose konfigūracija gali būti išmėtyta per kelis skirtingus konfigūracinius failus. Todėl pradžiai reikia patikrinti būtent tą konfigūracinį failą, kuriame startuojant tarnyba aptiko klaidą.

Siekiant tikrinimą supaprastinti galime naudoti konfigūracijos sintaksės tikrinimui skirtas komandas:

Naudojant Apache naudojama ši komanda:

apache2ctl configtest

Numatomas rezultatas:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Naudojant Nginx naudojama ši komanda:

sudo nginx -t

Numatomas teigiamas rezultatas:

Nginx: the configuration file /etc/Nginx/Nginx.conf syntax is ok
Nginx: configuration file /etc/nginx/nginx.conf test is successful
As you can see, this process checks your syntax as well. If we remove an ending semi-colon from a line in the file (a common error for Nginx configurations), you would get a message like this:

Numatomas neigiamas rezultatas:

Nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed
There is an invalid number of arguments because nginx looks for a semi-colon to end statements. If it doesn't find one, it drops down to the next line and interpret that as further arguments for the last line.

Gavus netinkamos konfigūracijos pranešimą reikia peržiūrėti rezultate pateikto failo sintakse, ties nurodyta eilute. Bei pakartotinai atlikti konfigūracijos tikrinimą, tai atlikinėti tol kos konfigūracijos testavimas nurodys teigiamą rezultatą.

Ar sukonfigūruoti prievadai yra atidaryti/pasiekiami?

Įprastai web serveriai klausosi 80 prievado, o TLS/SSL susijungimams naudoja 443 prievadą. Siekiant pasiekti serveryje esančias svetaines, šie prievadai turi būti atidaryti/pasiekiami.

Tai patikrinti galime tiek naudojant prieš tai nurodytą netstat komandą:

sudo netstat -plunt | grep apache2

Tiek naudojant netcat įrankį, vykdant šią komandą:

sudo nc -z 111.111.111.111 80

Pastaba: vykdomoje komandoje pakeičiame 111.111.111.111 į mūsų serverio IP adresą, o 80 į pageidaujamą patikrinti prievadą.

Jeigu prievadas yra atidarytas/pasiekiamas, tuomet nc komandos rezultatas bus grąžintas beveik iš karto. Kitu atveju netcat įrankis bandys pakartotinai vykdyti susijungimą daugybę kartų. Taigi pageidaujant nutraukti nc komandos vykdymą galime tai atlikti nuspaudus klavišų kombinaciją CTRL+C.

Jeigu prievadai nėra pasiekiami vertėtų peržiūrėti serverio ugniasienės taisykles. Tikėtina, jog jose yra nurodytas draudimas pasiekti serverį 80 ir 443 prievadais.

Ar DNS nukreipimai yra atlikti korektiškai?

Jeigu svetainė yra pasiekiama naudojant tiesioginį serverio IP adresą, tačiau to nepavyksta atlikti naudojant svetainės domeną vertėtų peržvelgti domeno DNS nustatymus.

Siekiant per domeną pasiekti pageidaujamą svetainę, domeno DNS nustatymuose turi būti "A" arba "AAAA" (IPv6 atveju) tipo įrašas nukreipiantis domeną į mūsų serverį.

Patikrinti "A" tipo įrašą pageidaujamam domenui galime naudojant dig įrankį:

host -t A example.com

Numatomas rezultatas:

example.com has address 93.184.216.119

Grąžinamame rezultate IP adresas turi atitikti mūsų serverio IP adresą.

Atliekant pakeitimus domeno aptarnaujamuose DNS serverių nustatymuose būtina atsižvelgti, jog pakeitimams įsigalioti yra reikalingas pakankamai nemažas laiko tarpas kol informacija apie naują domeno nukreipimą bus išplatinta tarp visų DNS serverių.

Ar yra tinkamai nurodytas svetainės šakninis katalogas?

Jeigu DNS nustatymai yra tinkami, vertėtų patikrinti pačios tarnybos konfigūraciją. T.y. peržiūrėti ne tik sintaksę, tačiau ir parametrų nustatytas vertes. Kadangi tiek teisingai sukonfigūruoti Apache virtual host failai tiek Nginx server block failai užtikrina tinkamą užklausų apdorojimą.

Apache virtual host poskyris atrodytų daug maž taip:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

Šis virtual host yra sukonfigūruotas atsakinėti į bet kokias užklausas ateinančias example.com domeną per 80 prievadą.

Panašiu principu veikia iš Nginx server block, kurie atrodytų daug maž taip:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

Šis server block yra sukonfigūruotas atsakinėti į identikas užklausas, kaip ir prieš tai nurodytas Apache virtual host.

Taip pat šiuose konfigūracijų segmentuose yra itin svarbus šakninio katalogo parametras, kuris nurodo kuriame serverio kataloge Apache ar Nginx web serveriai ieškos pačios svetainės failų kas kartą kai gaus užklausas.

Apache atveju tai būtų šis parametras:

DocumentRoot /var/www/html

Šiuo atveju svetainės failų būtų ieškoma /var/www/html/ kataloge.

Nginx atveju tai būtų šis parametras:

root /usr/share/nginx/html;

Šiuo atveju svetainės failų būtų ieškoma /usr/share/nginx/html/ kataloge.

Ar web serveris pateikia tinkamus indekso failus?

Jeigu svetainės šakninis katalogas yra nurodytas teisingas, tuomet galimai problemą sukelia blogai nurodytas konfigūracijoje svetainės indekso failas. Tai yra pradinis failas kuris yra pateikiamas lankytojui apsilankius domeną, kuris veda į mūsų serverį.

Apache atveju indekso failai yra nurodomi DirectoryIndex parametru:

<Directory /var/www/html>
...
    DirectoryIndex index.html index.php
...
</Directory>

Nginx atveju indekso failai yra nurodomi index parametru:

server {
...
    index index.html index.htm;
...

Šiuo atveju abiejose pavyzdinėse parametrų vertėse yra nurodyta iš pradžių ieškoti index.html indekso failo, kurio neradus būtų ieškoma index.php failo šakniniame svetainės kataloge.

Ar svetainės failų ir katalogų teisės bei savininkai yra nurodyti teisingai?

Viena iš dažniausiai pasitaikančių problemų, kurios yra atsakingos už svetainių neatvaizdavimą yra netinkamai nurodyti katalogų ir failų savininkai bei teisės. Siekiant jog web serveris galėtų pasiekti ir nuskaityti svetainės failus svetainės failai ir katalogas turi priklausyti tinkamai vartotojų grupei, bei turėti atitinkamas teises.

Vartotojų ir vartotojų grupės reikalingos tam jog web serveris galėtų pasiekti ir nuskaityti svetainės failus gali kisti priklausomai nuo naudojamos operacinės sistemos distribucijos.

Ubuntu ar Debiant įprastai tai yra www-data vartotojas/grupė. Tiek Apache, tiek Nginx atveju.

CentOS ar Fedora įprastai tai yra apache vartotojas/grupė. Nginx atveju būtų vartotojas grupė - nginx.

Peržiūrėti failų ar katalogų teises bei savininkus galime naudojant šią komandą:

ls -l /path/to/web/root

Siekiant pakeisti savininką naudojame komandą paremtą šia sintakse:

sudo chown savininkas_vartotojas:savininkas_grupe /kelias/iki/failo/

Siekiant pakeisti savininką rekursyvai pridedamas -R parametras.

Pvz.:

sudo chown -R savininkas_vartotojas:savininkas_grupe /kelias/iki/failo/

Ar per konfigūracinius failus nėra ribojama prieiga?

Verta įsitikinti jog priegia prie svetainės nėra apribota per svetainės šakniname kataloge esantį .htaccess failą ar pačioje Apache konfigūracijoje.

Apache konfigūracijoje ribojimas būtų matomas <Directory> direktyvoje:

<Directory /usr/share>
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

Nginx atveju priegos ribojimas būtų aprašomas tokiu principu:

location /usr/share {
    deny all;
}

Jeigu svetainė naudoja duomenų bazes, ar duomenų bazių tarnyba yra paleista?

Taip pat kaip ir tikrinant ar web serverio tarnyba yra paleista atveju kai svetainė naudoja duomenų bazes yra reikalinga patikrinti ar duomenų bazių tarnyba yra paleista.

MySQL atveju patikrinti galime naudojant šią komandą:
sudo netstat -plunt | grep mysql

Numatomas rezultatas:

tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

Ar svetainė sėkmingai prisijungia prie reikalingos duomenų bazės?

Atsižvelgiant į tai jog turinio valdymo sistemoms yra reikalinga galimybė prisijungti prie konfigūracijoje nurodytos duomenų bazės. Patikrinti pagal pvz. Wordpress config.php faile nurodytus parametrus galime patikrinti ar susijungimas vykdomas korektiškai.

Tai galime atlikti naudojant šia sitakse paremtą komandą:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

Ar web serveris yra tinkamai sukonfigūruotas atvaizduoti dinaminį turinį?

Svetainėje pateikiant dinaminį turinį (pvz. PHP), serveryje turi būti įdiegti užklausas į tokį turinį galintys apdoroti paketai.

Apache web serveriui Ubuntu ar Debian aplinkoje tai atlikti galime naudojant šias komandas:

sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo a2enmod php5

Apache web serveriui CentOS ar Fedora aplinkoje tai atlikti galime naudojant šias komandas:

sudo yum install php php-mysql
sudo service httpd restart

Su Nginx web serveriu yra šiek tiek sudėtingiau, kadangi Nginx neturi PHP modulio kuris gali būti tiesiog įjungtas. Todėl reikia įsitikinti, jog php-fpm yra įdiegtas mūsų konfigūracijoje.

Nginx web serveriui Ubuntu ar Debian aplinkoje tai atlikti galime naudojant šias komandas:

sudo apt-get update
sudo apt-get install php5-fpm php5-mysql

Nginx web serveriui CentOS ar Fedora aplinkoje tai atlikti galime naudojant šią komandas:

sudo yum install php-fpm php-mysql