Этим утром у меня возникла странная проблема с поиском файлов сценариев 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.
Мои файлы конфигурации довольно просты: я взял стандартные и изменил несколько параметров.
Мои / и т. Д. Это файл /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, где я удалил пример блока сервера {} (для включения с разрешенных сайтов, как в 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.
Я обнаружил chdir в /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 был доступ, это сработало. Вы также можете изменить директиву user в файле nginx.conf и запустить worker от имени другого пользователя.