Apache: “Arquivo não encontrado” depois de configurar o chroot do php-fpm

Question

Estou lutando com o passo final na implementação de um chroot no php-fpm com o Apache 2.4 rodando no CentOS 7.

Eu tenho configuração bem-sucedida e tested a conexão php-fpm sem o chroot. Mas assim que eu adiciono a diretiva chroot no meu arquivo conf em /etc/php-fpm.d/file.conf, recebo um "Arquivo não encontrado" como muitas outras pessoas experimentaram .

Aqui está o meu arquivo php-fpm conf:

[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

Como você pode ver, depois de definir o chroot, mudei a diretiva chdir para que seja relativa à raiz do PHP. (O caminho do sistema seria /home/www/site1.com/www e foi o que definiu como chdir antes de ativar a diretiva chroot ).

Aqui está o meu arquivo http.d / site1.conf:

<VirtualHost *:80>
        ServerAdmin [email protected]
        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>

Eu acessei o LogLevel no meu arquivo httpd.d / site.conf, e aqui está uma saída interessante:

  [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 (*)

Nada está aparecendo no arquivo de log de erros do php.

Então, depois de tudo isso,

• Por que ainda recebo uma mensagem de erro "Arquivo não encontrado"?
• Melhor ainda, como corrigi-lo ou, no mínimo, como solucionar o problema?

Answer 1

Isso está resolvido. Houve dois problemas com o código acima.

Problema nº 1 - Somente o Apache 2.4.10 e superior podem suportar soquetes

A versão padrão do Apache que vem nos repositórios base do CentOS ( Apache 2.4.6 ) suporta apenas portas TCP. O código acima é, portanto, incorreto, e a diretiva listen no arquivo de configuração do php-fpm precisava ser alterada para algo como isto:

listen = 127.0.0.1:9001

Também fiz a alteração apropriada no meu arquivo http.d conf, mas, além disso, também mudei para a diretiva ProxyPassMatch , em vez de usar a diretiva FilesMatch . Então meu código então se tornou:

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

Observe que esse código ainda está errado ... veja abaixo

Continuando ...

Problema # 2 - Caminhos Relevantes

O caminho na diretiva ProxyPassMatch (ou, no caso do meu código antigo usando a diretiva FilesMatch ) dentro do meu arquivo http.d conf torna-se relativo ao chroot . Não é relativo à raiz do documento www (se diferente).

Então meu código no meu arquivo http.d conf se tornou:

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

E voila! Eu tenho um chroot php-fpm.

    

Answer 2

php-fpm tem um bug com chroot e caminho.

por exemplo, com index.php em www

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

com esta configuração, o php-fpm escreve este caminho:

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

uma solução é criar um link simbólico no shell:

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

mas não está limpo.

link

link

    

Answer 3

Você tem o SElinux ativado? O getenforce deve ser capaz de lhe dizer isso. Se esse for o caso, o setenforce 0 o desabilitaria e, em seguida, você precisaria editar o / etc / sysconfig / selinux e definir o SELINUX como desativado, por isso é persistente após a reinicialização.

    

Answer 4

Algumas pessoas podem receber esse erro por causa de duas coisas.

• Caminhos relativos errados no php.ini
  Caso você especifique open_basedir, doc_root, user_dir, session.save_path, upload_tmp_dir (e outros) no seu PHP-FPM.conf, esses caminhos devem ser relativos ao chroot.
  Por exemplo:

chroot = /var/www
php_admin_value[doc_root] = /htdocs
;All paths must be relative to chroot since after chrooting PHP does not know about the absolute path

• cgi.fix_pathinfo = 1 no php.ini
  TL; DR apenas alterá-lo para 0.
  Por algumas razões, este valor afeta seu PHP-FPM, mesmo que este parâmetro seja apenas para CGI.
  Você deve ler mais sobre este parâmetro, pois ele pode quebrar outras coisas também, mais aqui