Исключения PHP приводят к тому, что nginx пропускает виртуальных хостов друг в друга

У меня на сервере настроено несколько виртуальных хостов nginx. На tershronalds.com запущена ванильная версия Wordpress 4.3, а на staging.ninjawars.net - пользовательская кодовая база php. Оба полагаются на php5-fpm.

Если нет ошибок или исключений php, оба сайта работают нормально. В случае WordPress tershronalds.com, есть несколько ошибок или исключений, обычно нет проблем. Пользовательская php кодовая база staging.ninjawars.net использует файл auto_prepend_file для фронтальной загрузки различных библиотек:

fastcgi_param PHP_VALUE "auto_prepend_file=/path/to/ninjawars/deploy/lib/base.inc.php \n session.cookie_domain=staging.ninjawars.net \n date.timezone=America/New_York \n default_charset=UTF-8 \n";

Однако, если пользовательская кодовая база php выдает ошибку или возникает исключение, nginx начинает плохо себя вести! Он начинает делиться конфигурацией между виртуальными хостами, ломая сайт WordPress tershronalds.com:

2015/09/04 13:37:58 [error] 13145#0: *17413 FastCGI sent in stderr:
"PHP message: PHP Fatal error:  Cannot redeclare validate_username() (previously declared in /path/to/ninjawars/deploy/lib/control/lib_auth.php:317) in /path/to/tersh/www/wp-includes/user.php on line 1792" while reading response header from upstream, client: 10.183.252.21, server: tershronalds.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "tershronalds.com"

Другими словами, nginx сходит с ума, и сайт WordPress начинает ломаться, потому что он включает в себя код из пользовательской базы кода ninjawars, который вызывает дублирование функций!

Я думал о попытке обновить nginx, чтобы обойти его, но nginx, похоже, в его последней версии, и то же самое с php5-fpm (возможно). Конфигурации виртуального хоста действительно работают и кажутся действительными...... до тех пор, пока не возникнет ошибка / исключение php. Что еще я должен изучить, чтобы попытаться обойти это ошибочное поведение?

Информация о версии программного обеспечения:

apt-cache policy nginx nginx:   Installed: 1.4.6-1ubuntu3.3   Candidate: 1.4.6-1ubuntu3.3   Version table:  *** 1.4.6-1ubuntu3.3 0
        500 http://mirror.rackspace.com/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.4.6-1ubuntu3.1 0
        500 http://mirror.rackspace.com/ubuntu/ trusty-security/main amd64 Packages
     1.4.6-1ubuntu3 0
        500 http://mirror.rackspace.com/ubuntu/ trusty/main amd64 Packages admin@megaman:~$ apt-cache policy php5-fpm php5-fpm:   Installed: 5.5.9+dfsg-1ubuntu4.11   Candidate: 5.5.9+dfsg-1ubuntu4.11  Version table:  *** 5.5.9+dfsg-1ubuntu4.11 0
        500 http://mirror.rackspace.com/ubuntu/ trusty-updates/universe amd64 Packages
        500 http://mirror.rackspace.com/ubuntu/ trusty-security/universe amd64 Packages
        100 /var/lib/dpkg/status
     5.5.9+dfsg-1ubuntu4 0
        500 http://mirror.rackspace.com/ubuntu/ trusty/universe amd64 Packages

И версия WordPress является последней 4.3, не то, чтобы я ожидал, что это будет важным фактором.

Отредактируйте, если я отключу эту конфигурацию виртуального хоста nginx, все будет работать нормально (кроме, конечно, полного закрытия субдомена staging.ninjawars.net).

Staging.ninjawars.net:

server {
        listen 80;
        server_name staging.ninjawars.net www.ninjawars.net ninjawars.net nw.local nw.remote;

        root /path/to/ninjawars/deploy/www;

        error_page 404 /404.php;

        # redirect server error pages to the static page /50x.html
        #
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
                root /usr/share/nginx/html;
        }

        index index.php;

        location / {
                try_files $uri $uri/ =404; # /index.php?$args;
        }

        location ~ \.php$ {
                fastcgi_param PHP_VALUE "auto_prepend_file=/path/to/ninjawars/deploy/lib/base.inc.php \n session.cookie_domain=staging.ninjawars.net \n date.timezone=America/New_York \n default_charset=UTF-8 \n";
                try_files $uri =404;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;
        }
}

Вот несколько длиннее и перенаправить все на

no-www, сайт https tershronalds.com:

server {
    listen 80;
    server_name         tershronalds.com;
    return 301          https://tershronalds.com$request_uri;
}
server {
    listen 80;
    server_name         www.tershronalds.com;
    return 301          https://tershronalds.com$request_uri;
}
server {
    listen 80;
    server_name         tershronalds.net www.tershronalds.net tershart.net www.tershart.net;
    return 302          https://tershronalds.com$request_uri;
    # Temporarily redirect these domains for now.
}

server {
    listen 443 ssl;
    server_name tershronalds.com www.tershronalds.com tersh.remote;
    root /path/to/tersh/www;
    index index.php

#   ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers various_cyphers_here
    ssl_certificate /somecrt;
    ssl_certificate_key /somekey;


    #location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        #try_files $uri $uri/ =404;
        # Uncomment to enable naxsi on this location
        # include /etc/nginx/naxsi.rules
    #}


    error_page 404 /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }

    error_page  401  https://tershronalds.com/forbidden.html;

    # Standard wordpress includes !!!
    include global/wordpress.conf;


    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    location ~ /\.ht {
        deny all;
    }
}

1 ответ

Решение

Мой собственный опыт работы с Ubuntu 14.04 и PHP показывает, что определенные операции в файлах, включенных auto_prepend_file может не работать с включенным расширением opcache. Попробуйте отключить расширение, удалив символическую ссылку: /etc/php5/fpm/conf.d/05-opcache.ini (изначально указывающую на ../../mods-available/opcache.ini). Это может снизить производительность, но ничего не должно нарушать.

Я мало знаю nginx, поэтому не могу сказать, правильный ли ваш метод для настроек PHP для каждого сайта, но использование разделов php.ini может улучшить читаемость, а также устранить проблему, если она связана с подключением PHP <-> nginx.

Более того, вы можете создавать отдельные экземпляры демона PHP-FPM, каждый из которых обрабатывает один веб-сайт. Это требует немного больше оперативной памяти, но полностью отделяет обработку кода ваших веб-приложений. С open_basedir а также disable_functions Этот подход обеспечивает дополнительную безопасность для каждого приложения. Экземпляры FPM определены в /etc/php5/fpm/pool.d/.

Другие вопросы по тегам