Назад | Перейти на главную страницу

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

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

Если не возникают ошибки или исключения php, похоже, оба сайта работают нормально. В случае с tershronalds.com wordpress есть несколько ошибок или исключений, обычно не проблема. Пользовательская кодовая база 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;
    }
}

Мой собственный опыт работы с 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/.