Apache: “Serviço não disponível” depois de configurar o chroot do php-fpm

Question

Eu estou executando o Debian Jessie com o Apache 2.4.10. Eu passei pelo problema "Arquivo não encontrado" e acabei referenciando esta questão . A única diferença entre a minha configuração e a dele é que eu REALMENTE (por várias razões) prefiro usar UDS em vez de soquetes TCP, e usar a solução ProxyPassMatch não está dando muito certo, embora não tenha certeza do motivo.

Aqui está minha linha na configuração:

ProxyPassMatch "^/(.*\.php)$" "unix:/var/run/myappname.sock|fcgi://localhost/webroot/$1"

E aqui está a saída de depuração:

AH00944: connecting fcgi://localhost/webroot/index.php to localhost:8000, referer: http://myapp.com
AH00947: connected /webroot/index.php to localhost:8000, referer: http://myapp.com
(111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed

Se eu tentar usar um endereço diferente de, por exemplo. localhost Recebo uma falha de DNS, mas quando uso SetHandler , posso usar uma string arbitrária como o endereço com sucesso. Eu não entendo a diferença. Aqui está um exemplo de trabalho (sem chroot ) usando SetHandler e FilesMatch em vez de ProxyPassMatch .

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/var/run/myappname.sock|fcgi://myappname/"
</FilesMatch>

    

Answer 1

Eu tentei várias maneiras diferentes de fazer isso funcionar, principalmente tentando evitar voltando a este método conhecido . No final, é a única maneira que me foi bem sucedida.

cd /full/path/to/chrootdir
mkdir -p full/path/to
cd full/path/to
# only as many dots as your setup requires
ln -s ../../.. chrootdir

Usar SetHandler funciona melhor para mim:

<FilesMatch ".*\.php$">
    SetHandler "proxy:unix:/var/run/php-fpm-myapp.sock|fcgi://myapp"
</FilesMatch>

No final, isso não é tão ruim, e a recompensa vale a pena para mim.

Explicação : mod_proxy_fcgi passa o caminho completo do script php. Portanto, o php-fpm recebe a instrução para interpretar o arquivo em /full/path/to/chrootdir/script.php , mas não consegue encontrá-lo porque está em uma cadeia chroot. O link simbólico relativo liga o caminho completo de volta à raiz da cadeia chroot.

    

Answer 2

Corrigir

Existe uma solução melhor do que criar uma árvore de links simbólicos dentro da sua cadeia chroot.

Em vez disso:

ProxyPassMatch "^/(.*\.php)$" "unix:/var/run/myappname.sock|fcgi://localhost/webroot/$1"

Use isto:

ProxyPassMatch "^/(.*\.php)$" "unix:/var/run/myappname.sock|fcgi://localhost/webroot"

Em suma, remova o /$1 no final, não é necessário. Isso pode ser necessário para outra versão do Apache, mas para o 2.4.25, pelo menos, esse bit causará os erros 503 que você descreve.

ProxyPassMatch vs FilesMatch

A diferença entre FilesMatch e ProxyPassMatch é que o último passa um caminho de script relativo para o processo fcgi, enquanto o primeiro envia o caminho completo como visto pelo Apache, que inclui o caminho até onde o chroot está localizado .

Depuração

O uso do comando strace foi útil na depuração desse problema. Quando o processo de trabalho do PHP tenta ler um arquivo, o rastreamento mostrará o caminho completo do arquivo que ele está tentando ler.

Usando FilesMatch :

lstat("/srv/jail/var/www/index.php", 0x7ffeb3069390) = -1 ENOENT (No such file or directory

Como o processo de trabalho do PHP é preso dentro de /srv/jail , o comando falha.

Usando ProxyPassMatch :

lstat("/var/www/index.php") {st_mode=S_IFREG|0644, st_size=96, ...}) = 0

O processo consegue ler o arquivo.

Você pode lançar strace da seguinte maneira e exibirá um rastreamento do php-fpm e seus processos filho / trabalhador:

strace -f $(pgrep -f php-fpm | sed 's/\([0-9]*\)/\-p /g')