Nginx / PHP-FPM „Odmowa dostępu”. błąd

14

Próbuję skonfigurować świeżo zainstalowany serwer Ubuntu (12.04), ale nie mogę uruchomić plików PHP przez php-fpm. Bez względu na to, co robię, zawsze pojawia się komunikat „Odmowa dostępu”. strona (zwykły tekst, a nie HTML lub cokolwiek).

Zainstalowane pakiety:

nginx
nginx-common
nginx-full
php5
php5-cli
php5-common
php5-fpm

Szczegóły konfiguracji:

PHP-FPM:

user = www-data
group = www-data
listen = /var/run/php5-fpm.sock

Nginx:

user www-data;
worker_processes 3;
events { worker_connections 1024; }

Domena domyślna / testowa:

server {
    listen       80;
    server_name  localhost;
    root         /extra/htdocs/default;
    index        index.html index.php

    access_log   /extra/logs/default/access.log;
    error_log    /extra/logs/default/error.log;

    location / {
        try_files  $uri $uri/ /index.html;
    }

    location ~ \.php
    {
        fastcgi_split_path_info  ^(.+\.php)(/.+)$;

        include fastcgi_params;

        fastcgi_index   index.php;
        fastcgi_pass    unix:/var/run/php5-fpm.sock;
        fastcgi_param   PATH_INFO         $fastcgi_path_info;
        fastcgi_param   PATH_TRANSLATED   $document_root$fastcgi_path_info;
        fastcgi_param   SCRIPT_FILENAME   $document_root$fastcgi_script_name;
    }
}

/extra/htdocs/default/index.php:

<?php
phpinfo();

Cała reszta jest domyślna. Zarówno dzienniki Nginx, jak i php-fpm nie wykazują błędów. Jednak po załadowaniu pojawia http://<server-ip>/index.phpsię strona „Odmowa dostępu”.

Rozwiązywanie problemów:

  • Plik index.html działa dobrze. Dlatego musi to być albo php-fpm, albo wiązanie fastcgi między Nginx i php-fpm.
  • Dla pewności ustawiłem własność (zarówno użytkownika, jak i grupę) na cały /extrakatalog www-data, a własność na 777, tylko dla pewności (obniżę go, gdy to zadziała). Z pewnością nie jest to kwestia uprawnień
  • To nie jest kwestia security.limit_extensions , którą często widzę: domyślnie jest ustawiona na .php, dokładnie o to proszę. Wyraźnie ustawiłem to .php .html, z tym samym rezultatem.

Naprawdę mam tego dość, już dwukrotnie instalowałem tę konfigurację (choć na maszynach OSX) i wszystko działało bezbłędnie. Czy jest coś, co przeoczam?

Zawartość dziennika:

Dziennik błędów Nginx jest pusty.

Dziennik dostępu Nginx (usunięty adres IP):

<ip> - - [17/Jul/2012:11:21:25 +0200] "GET /favicon.ico HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11"
<ip> - - [17/Jul/2012:11:21:28 +0200] "GET /index.php HTTP/1.1" 403 46 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11"
<ip> - - [17/Jul/2012:11:21:34 +0200] "-" 400 0 "-" "-"

dziennik php-fpm:

[17-Jul-2012 10:44:14] NOTICE: fpm is running, pid 4969
[17-Jul-2012 10:44:14] NOTICE: ready to handle connections
Peter Kruithof
źródło

Odpowiedzi:

33

W końcu to naprawiłem.

Winowajcą była ta linia w mojej konfiguracji:

fastcgi_param   PATH_TRANSLATED     $document_root$fastcgi_path_info;

Jeśli skomentowałem ten wiersz, wszystko działało dobrze. Widziałem to jednak w prawie każdym poście, który czytałem o konfiguracjach Nginx, więc mnie to niepokoiło. Patrząc na moje konfiguracje po raz milionowy, zauważyłem, że cgi.fix_pathinfo(in php.ini) było ustawione na 0, gdzie powinno być 1. Domyślna wartość PHP używa również 1, więc musiałem to zmienić w godzinach debugowania, ponieważ ja pamiętaj o przeczytaniu o tej wartości i pomyślałem, że została ustawiona poprawnie.

W każdym razie, może to pomoże każdemu Google'owi w rozwiązaniu tego problemu.

Peter Kruithof
źródło
5
Dziękujemy za udostępnienie rozwiązania. Zaleca się, aby nie ufać samouczkom, ponieważ mogą one zawierać niezabezpieczone konfiguracje. Te konfiguracje mogą jednak nadal działać poprawnie.
Pothi Kalimuthu
Dzięki za link, kilka razy się z tym spotkałem i zastosowałem się do tych instrukcji. Pomyłka była prawdopodobnie moja w szale debugowania (po x godzinach zaczynasz tracić świadomość niektórych rzeczy, które zmieniłeś).
Peter Kruithof
Mój był chownproblemem.
Jürgen Paul,
Dziękuję bardzo. Pracowałem nad tym problemem przez wiele godzin i cgi.fix_pathinfoustawiłem na 0 (konfiguracja domyślna) był problemem.
Mauvis Ledford
2
cgi.fix_pathinfo = 0jest zalecany przez wiele samouczków, ponieważ pomaga złagodzić luki, szczególnie luki w zabezpieczeniach wykonujących kod php za pośrednictwem dowolnych plików. Więc jeśli ustawisz tę wartość na 1, upewnij się, że wiesz, co robisz lub określ inne środki zaradcze, które to nadrobią. Znalazłem ten post, który zawiera dobre wyjaśnienie tego problemu: nealpoole.com/blog/2011/04/…
MikeD