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.

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

Мои / и т. Д. Это файл /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.

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

0
задан 17 September 2019 в 13:41
1 ответ

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

user http;
worker_processes  1;

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

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

0
ответ дан 5 December 2019 в 00:48

Теги

Похожие вопросы