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

php-fpm не мог найти скрипт, пока я не перешел в конкретный каталог

Этим утром у меня возникла странная проблема с поиском файлов сценариев php с помощью Nginx и Php-fpm.

Я решил, но не понимал, в чем проблема.

Некоторые подробности: я использую Arch Linux и использую PHP-FPM 7.3.9 и Nginx 1.16.1.

Я хотел попробовать Grav CMS, поэтому настроил nginx и php-fpm по мере необходимости. Случилось так, что php-fpm не смог найти файл index.php, вернув ошибку 404.

Мои файлы конфигурации довольно просты: я взял стандартные и изменил пару параметров.

Мой файл /etc/nginx/nginx.conf - это

user http;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
worker_connections  1024;
}


http {
include       mime.types;
default_type  application/octet-stream;

#log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
#                  '$status $body_bytes_sent "$http_referer" '
#                  '"$http_user_agent" "$http_x_forwarded_for"';

#access_log  logs/access.log  main;

sendfile        on;
#tcp_nopush     on;

#keepalive_timeout  0;
keepalive_timeout  65;

#gzip  on;

include sites-enabled/*;
}

Это Nginx по умолчанию в Arch Linux, где я удалил пример блока server {} (для включения с включенных сайтов, как в Debian и других) и некоторые комментарии.

И мой файл конфигурации для конкретного виртуального сервера Grav был

server {
#listen 80;
index index.html index.php;

## Begin - Server Info
root /home/MYUSERNAME/Desktop/grav;
server_name localhost;
## End - Server Info

## Begin - Index
# for subfolders, simply adjust:
# `location /subfolder {`
# and the rewrite to use `/subfolder/index.php`
location / {
    try_files $uri $uri/ /index.php?$query_string;
}
## End - Index

## Begin - Security
# deny all direct access for these folders
location ~* /(\.git|cache|bin|logs|backup|tests)/.*$ { return 403; }
# deny running scripts inside core system folders
location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
# deny running scripts inside user folder
location ~* /user/.*\.(txt|md|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
# deny access to specific files in the root folder
location ~ /(LICENSE\.txt|composer\.lock|composer\.json|nginx\.conf|web\.config|htaccess\.txt|\.htaccess) { return 403; }
## End - Security

## Begin - PHP
location ~ \.php$ {
    # Choose either a socket or TCP/IP address
    fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
    # fastcgi_pass unix:/var/run/php5-fpm.sock; #legacy
    # fastcgi_pass 127.0.0.1:9000;

add_header  x-full-path $document_root$fastcgi_script_name;

fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_index index.php;
include fastcgi_params;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

}
## End - PHP
}

Как вы можете заметить из комментариев, это файл конфигурации по умолчанию, предоставляемый самим Grav. Вы можете проверить это Вот.

Я только что отредактировал корневой каталог и скорректировал путь к сокету в соответствии с моим php-fpm.

Никакой конфигурации php-fpm я не трогал.

В результате я получил «Файл не найден». без ссылки на nginx. Я уже сталкивался с этой страницей раньше и знал, что это страница с ошибкой php-fpm.

Действительно, когда я изменил конфигурацию nginx, чтобы он указывал на какой-то index.html, это сработало.

Поэтому я попытался проверить, была ли это проблема с разрешением (но это показалось странным, я ожидал другого сообщения об ошибке): я проверил, что и nginx, и php-fpm работают от одного и того же пользователя (в данном случае http) и я изменил режим владения и доступа на myusername: http 775, чтобы предоставить как моему пользователю, так и пользователю http все разрешения (я знаю, что это не очень хорошая практика, но я тестировал).

Все та же ошибка.

Я также попытался отладить параметры, переданные nginx в строке

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

прокомментировав эту строку и добавив заголовок со значением параметра.

Путь был правильным. Я скопировал его на терминал, чтобы проверить, нет ли опечаток, но нет. Все хорошо.

Я также пытался передать абсолютный путь индексного файла в php-fpm (в директиве выше), но ничего.

На этом этапе я попробовал еще одну вещь: я переместил папку grav из моего dekstop в / srv / http (которая в Arch является папкой по умолчанию в конфигурации nginx) и соответствующим образом отредактировал файлы конфигурации nginx. Разрешения там http: myusername 664.

И это сработало.

Поэтому я начал искать все, что могло вызвать ошибку в файлах конфигурации php-fpm.

Я узнал чдир вариант в /etc/php/php-fpm.d/www.conf. В комментарии говорится

Chdir в этот каталог в начале. Примечание: можно использовать относительный путь. Значение по умолчанию: текущий каталог или / при chroot

Поскольку я не устанавливал chroot (я проверил, это вариант выше в файле), он должен быть /.

Но даже если он искал файлы из корня, не имеет смысла, что он не может найти индекс, потому что я всегда передавал абсолютные пути. Я не смог найти в Google ничего о том, как fpm интерпретирует пути в соответствии с параметром chdir.

Итак, вопрос: что случилось? Почему он работал в одном каталоге, а не в другом?

Это была не проблема с php-fpm, это была проблема с разрешением веб-сервера. По умолчанию на сервере Arch nginx работники запускаются как пользователь http, вы можете увидеть это в начале своего nginx.conf файл:

user http;
worker_processes  1;

Таким образом, пользователь http не мог получить доступ к файлам в каталоге / home / MYUSERNAME / Desktop / grav;

Когда вы переместили файлы в каталог, к которому у пользователя http был доступ, это сработало. Вы также можете изменить пользователь директива в nginx.conf файл и запустить воркеры от имени другого пользователя.