Назад | Перейти на главную страницу

Ошибки PHP (через FastCGI) с Nginx в Ubuntu Linode

Я устанавливаю LEMP (Linux, Nginx, MySQL и PHP) на сервере Ubuntu 10.04 из Linode со следующим руководством: http://library.linode.com/lemp-guides/ubuntu-10.04-lucid

По сути, я загрузил свои PHP-скрипты в каталог (/srv/www/mysite.com/public_html) указанные в /etc/nginx/sites-available/mysite.com.conf.

Посещение сайта в браузере дает мне внутреннюю ошибку сервера 500. Я предполагаю, что в коде PHP есть какая-то ошибка, и это нормально. Однако я совершенно не понимаю, как это отлаживать, потому что есть несколько компонентов: PHP, FastCGI и Nginx.

У меня вопрос: как мне отобразить эти ошибки в браузере или, по крайней мере, в журнале, чтобы я мог понять, что происходит? Я не уверен, нужно ли мне указывать Nginx, чтобы он где-то регистрировал ошибки, или FastCGI, или редактировать php.ini.

Для решения этой проблемы у меня есть полный root-доступ к серверу. Однако я не уверен, как перезапустить PHP / FastCGI (хотя я знаю, как перезапустить Nginx), поскольку в руководстве, которому я следовал, используется какой-то демон.

Большое спасибо за любую помощь, которую вы можете мне оказать.

Короткий ответ:

Наиболее вероятный сценарий заключается в том, что у вас есть небольшая неправильная конфигурация в Nginx, которая приводит к отправке неверного пути в PHP-FPM. Убедитесь, что ваша корневая директива находится за пределами блока местоположения, включите fastcgi_intercept_errors, увеличьте подробность вашего error_log (например, чтобы заметить) и обратитесь к этим журналам для получения дополнительной информации.

Длинный ответ - диагностика проблемы

Во-первых, я не человек Ubuntu (скорее, CentOS), поэтому вы меня простите, если несколько путей / пакетов не так специфичны для вашей операционной системы, как было бы идеально.

Как вы сказали, ваша установка состоит из нескольких частей, которые должны работать вместе.

Nginx - должен иметь возможность получать и обрабатывать запрос - самый простой тест - это статический файл.
FastCGI - должен иметь возможность общаться с PHP.
PHP - должен иметь возможность успешно интерпретировать ваш файл.

При таком подходе к диагностике мы хотим упростить задачу - не проверять ее, пытаясь загрузить CMS, такую как Wordpress - нам нужен один независимый файл.

Тестовые файлы:

Статический - давайте возьмем текстовый файл с именем test.txt.

test.txt:

Hello world

PHP - перейдем к функции phpinfo ().

test.php:

<?php
    phpinfo();
?>

Тестирование Nginx:

Если Nginx может обслуживать статический файл, мы можем подтвердить, что базовая настройка и программное обеспечение работают.

server {
        listen *:80 default;
        server_name mysite.com www.mysite.com;
        root  /srv/www/mysite.com/public_html;
        error_log /var/log/nginx/mysite.com/error.log notice;
        access_log /var/log/nginx/mysite.com/access.log main;
}

Несколько упоминаний:

Я добавил «по умолчанию» в строку прослушивания - это, надеюсь, обеспечит использование этого серверного блока (если, конечно, у вас есть другие серверные блоки, в которых указано «по умолчанию», что является другой проблемой).
Я увеличил подробность error_log до 'notice' - я хочу видеть любые проблемы, которые могут возникнуть
Я указал access_log - я хочу иметь возможность подтвердить, что любой файл, к которому я пытаюсь получить доступ, отображается либо в access_log, либо в error_log - ничего неучтенного.

Скопируйте test.txt в /srv/www/mysite.com/public_html, убедитесь, что он доступен для чтения пользователю nginx (который является пользователем по умолчанию, от имени которого запускается nginx), разрешения 644 должно быть достаточно. Убедитесь, что все каталоги выше public_html имеют права на выполнение для «других» (т.е. «другие» могут перемещаться по структуре каталогов).

Перезапустите Nginx, чтобы изменения конфигурации вступили в силу (при желании вы можете перезагрузить вместо перезапуска).

Тестируйте с того же сервера, на котором установлен nginx:

curl --header "Host: mysite.com" 127.0.0.1/test.txt

Примечательные моменты здесь:

Путем тестирования с того же сервера, на котором установлен nginx, мы можем устранить проблемы с DNS и сетью.
127.0.0.1, конечно же, localhost (но для работы localhost требуется спецификация в файле hosts)
Поскольку мы получаем доступ к сайту через IP-адрес, мы должны сообщить серверу «доменное имя», к которому мы пытаемся получить доступ (здесь это не обязательно, так как наш серверный блок настроен по умолчанию, но это хорошая практика).
Наконец, нам нужно указать путь к файлу - относительно нашей корневой директивы (из нашего серверного блока).

В идеале приведенная выше команда вернет «Hello world» - текст, который вы ввели в текстовый файл.

PHP:

Убедиться, что PHP работает правильно, довольно просто:

Создайте файл test.php (как указано выше) в папке public_html и запустите:

php /srv/www/mysite.com/public_html/test.php

Вы должны получить длинный вывод, содержащий всю информацию, которую вы обычно видите на странице phpInfo ().

Если вышеуказанное не работает:

Если вы получаете какую-то ошибку «файл не найден», укажите абсолютный путь к php и проверьте путь к вашему файлу.
Если вы получаете ошибку разрешений, убедитесь, что у вашего текущего пользователя есть необходимые разрешения - php на самом деле не требует разрешения на выполнение для файла при доступе таким образом.
Перемена display_errors on и увеличьте подробность error_reporting в вашем файле php.ini (во-первых, найдите правильный файл php.ini, используя php -i | grep 'Loaded Configuration')

Надеюсь, теперь вы убедились, что PHP и ваш простой тестовый файл работают.

PHP-FPM:

К сожалению, FastCGI не «говорит» обычный текст. Здесь нам нужен переводчик. Вам нужен cgi-fcgi двоичный. (В CentOS он доступен в пакете fcgi от EPEL; я считаю, что в Ubuntu есть пакет libfcgi что обеспечивает то же самое).

cgi-fcgi считывает переменные среды и передает правильный запрос нашему менеджеру процессов FastCGI (PHP-FPM).

Во-первых, давайте настроим PHP-FPM: глобальных параметров по умолчанию в основном должно хватить, однако, включите ведение журнала - при отладке нам нужно столько информации, сколько мы можем получить (префикс журнала по умолчанию - / var).

error_log = log/php-fpm.log
log_level = notice

Настройте базовый пул, указав:

[www]
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1

pm = dynamic
pm.max_children = 5
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 2

user = nginx
group = nginx

(Конечно, вы можете - и, вероятно, должны использовать сокет вместо прослушивателя TCP, но я считаю, что этот подход легче проверить (т.е. меньше проблем с разрешениями) - очевидно, убедитесь, что на выбранном вами порту больше ничего не прослушивает ). Нам нужно разрешить доступ к нему только локальному компьютеру, настроить основные параметры диспетчера процессов и предоставить пулу владельца (конечно, вы измените все в соответствии со своими потребностями позже).

Запустите PHP-FPM (устраните любые ошибки, возникающие при его запуске)
- FPM - это менеджер процессов FastCGI для PHP, это отдельная служба, которая запускается - обычно service php-fpm restart будет работать (использовать reload вместо этого, если вам когда-нибудь понадобится сделать это в производственной среде). (Для этого может быть сценарий инициализации в /etc/init.d)
Установите cgi-fcgi, если вы еще этого не сделали

Выполните следующее:

SCRIPT_NAME=/test.php \
SCRIPT_FILENAME=/srv/www/mysite.com/public_html/test.php \
QUERY_STRING= \
REQUEST_METHOD=GET \
cgi-fcgi -bind -connect 127.0.0.1:9000

Здесь мы сообщаем PHP-FPM путь к файлу и имя файла, а также тип запроса (GET), а затем инструктируем cgi-fcgi подключиться к нужному хосту и порту.

Он должен вернуть вам тот же результат, что и раньше, но на этот раз вместо прямого использования двоичного файла php он использовал FastCGI. Если это работает, значит, вы успешно проверили каждый компонент своей установки.

Если вы получаете сообщения об ошибках, проверьте свой журнал ошибок по адресу /var/log/php-fpm.log.

Собираем все вместе: Если каждая часть настройки работает, вам необходимо убедиться, что все части могут работать вместе. На самом деле здесь осталась только одна часть - заставить Nginx общаться через FastCGI.

В простейшей форме нам нужно добавить только один блок местоположения к существующему блоку сервера nginx:

    location ~ \.php {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
    }

Для поддержки этого необходим файл fastcgi_params. Действительно важные строки:

    fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
    fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

Фактически вы можете включить необходимые директивы FastCGI непосредственно в блок местоположения, но я считаю, что внешний файл намного проще поддерживать, когда вы получаете более сложные настройки. Здесь вы заметите, что путь зависит от $ document_root - если он не установлен правильно (корневая директива), за пределами вашего блока местоположения, вы обычно столкнетесь с проблемами при настройке.

Для некоторых настроек также может потребоваться такая строка, как:

 fastcgi_split_path_info ^(.+\.php)(/.+)$;

Одна полезная директива для отладки ошибок настройки FastCGI: fastcgi_intercept_errors On. Это позволит nginx регистрировать ошибки (например, файл не найден и т. Д.).

Наконец, попробуйте загрузить свою страницу PHP через nginx:

curl --header "Host: mysite.com" 127.0.0.1/test.php

Надеюсь, вы получите вывод phpinfo (). Если нет, вы знаете, что проблема в вашей настройке nginx (потому что каждый другой компонент работает сам по себе). Начните проверять журналы ошибок nginx, у вас должно быть более чем достаточно информации, зарегистрированной на этом этапе, чтобы определить проблему.