Вопросы Теги

Apache: «Файл не найден» после настройки chroot php-fpm

Я борюсь с последним шагом в реализации chroot на php-fpm с Apache 2.4, работающим на CentOS 7.

Я успешно установил и ] протестировал соединение php-fpm без chroot. Но как только я добавляю директиву chroot в свой файл conf в /etc/php-fpm.d/file.conf, я получаю «Файл не найден» , как и многие другие люди .

Вот мой файл конфигурации php-fpm: 

[site1.com]
user = user1
group = user1
listen = /var/run/php-fpm/site1.com.sock
listen.owner = user1
listen.group = user1
php_admin_value[disable_functions] = exec,passthru,shell_exec,system
php_admin_flag[allow_url_fopen] = on
php_admin_value[short_open_tag] = On
php_admin_value[doc_root] = /
php_admin_value[error_log] = /logs/php-errors
php_admin_flag[log_errors] = on
pm = ondemand
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
chroot = /home/www/site1.com
chdir = /www
catch_workers_output = yes

Как видите, после того, как я установил chroot, Я изменил директиву chdir так, чтобы она относилась к корню PHP. (Системный путь будет /home/www/site1.com/www , и это то, что было установлено для chdir до включения директивы chroot ).

Вот мой соответствующий файл http.d / site1.conf: 

<VirtualHost *:80>
        ServerAdmin admin@my-host.com
        ServerName site1.com
        ServerAlias www.site1.com
        DocumentRoot /home/www/site1.com/www
        <Directory "/home/www/site1.com/www">
                Options Includes FollowSymLinks
                DirectoryIndex index.php
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
ErrorLog /home/www/site1.com/logs/errors
CustomLog /home/www/site1.com/logs/access_log common
        <FilesMatch "\.php$">
                SetHandler "proxy:unix:///var/run/php-fpm/site1.com.sock|fcgi://site1.com"
        </FilesMatch>
LogLevel trace3
</VirtualHost>

Я включил LogLevel в моем файле httpd.d / site.conf, и вот некоторые из этих интересных результатов: 

  [Mon Nov 02 10:42:52.665284 2015] [proxy:trace2] [pid 14286] proxy_util.c(2007): [client 74.221.189.99:16486] *: found reverse proxy worker for unix:///var/run/php-fpm/site1.com.sock|fcgi://site1.com/home/www/site1.com/www/index.php
    [Mon Nov 02 10:42:52.665292 2015] [proxy:trace2] [pid 14286] proxy_util.c(2041): [client 74.221.189.99:16486] *: rewrite of url due to UDS(/var/run/php-fpm/site1.com.sock): fcgi://site1.com/home/www/site1.com/www/index.php (proxy:fcgi://site1.com/home/www/site1.com/www/index.php)
    [Mon Nov 02 10:42:52.665295 2015] [proxy:debug] [pid 14286] mod_proxy.c(1117): [client 74.221.189.99:16486] AH01143: Running scheme unix handler (attempt 0)
    [Mon Nov 02 10:42:52.665300 2015] [proxy_ajp:debug] [pid 14286] mod_proxy_ajp.c(713): [client 74.221.189.99:16486] AH00894: declining URL fcgi://site1.com/home/www/site1.com/www/index.php
    [Mon Nov 02 10:42:52.665304 2015] [proxy_fcgi:debug] [pid 14286] mod_proxy_fcgi.c(948): [client 74.221.189.99:16486] AH01076: url: fcgi://site1.com/home/www/site1.com/www/index.php proxyname: (null) proxyport: 0
    [Mon Nov 02 10:42:52.665307 2015] [proxy_fcgi:debug] [pid 14286] mod_proxy_fcgi.c(955): [client 74.221.189.99:16486] AH01078: serving URL fcgi://site1.com/home/www/site1.com/www/index.php
    [Mon Nov 02 10:42:52.665311 2015] [proxy:debug] [pid 14286] proxy_util.c(2200): AH00942: FCGI: has acquired connection for (*)
    [Mon Nov 02 10:42:52.665316 2015] [proxy:debug] [pid 14286] proxy_util.c(2253): [client 74.221.189.99:16486] AH00944: connecting fcgi://site1.com/home/www/site1.com/www/index.php to site1.com:8000
    [Mon Nov 02 10:42:52.665320 2015] [proxy:debug] [pid 14286] proxy_util.c(2286): [client 74.221.189.99:16486] AH02545: fcgi: has determined UDS as /var/run/php-fpm/site1.com.sock
    [Mon Nov 02 10:42:52.665420 2015] [proxy:debug] [pid 14286] proxy_util.c(2419): [client 74.221.189.99:16486] AH00947: connected /home/www/site1.com/www/index.php to httpd-UDS:0
    [Mon Nov 02 10:42:52.668135 2015] [proxy_fcgi:error] [pid 14286] [client 74.221.189.99:16486] AH01071: Got error 'Primary script unknown\n'
    [Mon Nov 02 10:42:52.668179 2015] [proxy_fcgi:trace1] [pid 14286] util_script.c(599): [client 74.221.189.99:16486] Status line from script 'index.php': 404 Not Found
    [Mon Nov 02 10:42:52.668237 2015] [http:trace3] [pid 14286] http_filters.c(992): [client 74.221.189.99:16486] Response sent with status 404
    [Mon Nov 02 10:42:52.668284 2015] [proxy:debug] [pid 14286] proxy_util.c(2215): AH00943: FCGI: has released connection for (*)

Ничего не отображается в файле журнала ошибок php.

Итак, после всего этого,

  • Почему я все еще получаю сообщение об ошибке «Файл не найден»?
  • Еще лучше, как мне это исправить, или, по крайней мере, , как мне лучше устранить мою проблему?
6
задан 23 May 2017 в 15:41
4 ответа

Проблема решена. В моем приведенном выше коде возникли две проблемы.

Проблема №1 - Только Apache 2.4.10 и выше может поддерживать сокеты

Версия Apache по умолчанию, которая входит в базовые репозитории CentOS ( Apache 2.4.6 ) поддерживают только TCP-порты. Таким образом, приведенный выше код неверен, и директиву listen в конфигурационном файле php-fpm необходимо было изменить на что-то вроде этого: 

listen = 127.0.0.1:9001

Я также внес соответствующие изменения в свой файл http.d conf, но кроме того, я также переключился на использование директивы ProxyPassMatch вместо директивы FilesMatch . Таким образом, мой код стал: 

ProxyPassMatch "^/(.*\.php)$" "fcgi://127.0.0.1:9001/site1.com"

Обратите внимание, что этот код все еще неверен ... см. Ниже

Продолжение ...

Проблема № 2 - Соответствующие пути

Путь в ProxyPassMatch (или, в случае моего старого кода, использующего директиву FilesMatch ) внутри моего файла http.d conf становится относительным к chroot . Он не относится к корню документа www (если отличается).

Итак, мой код в моем файле http.d conf стал: 

ProxyPassMatch "^/(.*\.php)$" "fcgi://127.0.0.1:9001/www/$1"

И вуаля! У меня chroot php-fpm.

5
ответ дан 3 December 2019 в 00:09

У вас включен SElinux? getenforce должен вам это сказать. В этом случае setenforce 0 отключит его, а затем вам нужно будет отредактировать / etc / sysconfig / selinux и отключить SELINUX, чтобы он оставался постоянным после перезагрузки.

1
ответ дан 3 December 2019 в 00:09

php-fpm имеет ошибку с chroot и путем.

например, с index.php в www 

chroot = /home/www/site1.com
chdir = /www

с этой конфигурацией php-fpm напишите этот путь: 

/home/www/site1.com/home/www/site1.com/www

одно решение создать символическую ссылку в оболочке: 

cd /home/www/site1.com
mkdir -p home/www
cd home/www
ln -s /home/www/site1.com site1.com

, но он не чистый.

https://bugs.php.net/bug.php?id=55322

https://bugs.php.net/bug.php?id = 62279

4
ответ дан 3 December 2019 в 00:09

Некоторые люди могут получить эту ошибку по двум причинам.

  • Неправильные относительные пути в php.ini
    Если вы укажете open_basedir, doc_root, user_dir, session.save_path, upload_tmp_dir (и другие) в вашем PHP-FPM.conf, тогда эти пути должны быть относительно chroot.
    Например:

chroot = / var / www
php_admin_value [doc_root] = / htdocs
; Все пути должны быть относительно chroot, так как после chroot PHP не знать об абсолютном пути

  • cgi.fix_pathinfo = 1 в php.ini
    TL; DR просто измените его на 0.
    По некоторым причинам это значение влияет на ваш PHP-FPM, даже если этот параметр предназначен только для CGI.
    Вам следует узнать больше об этом параметре, так как он может нарушить и другие функции, подробнее здесь
2
ответ дан 3 December 2019 в 00:09

Теги

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