Nginx сегодня становится все более популярным, он быстрее и легче Apache. Но вот подходы к настройкам у Apache и nginx настолько различаются, что при переносе установок по аналогии делаешь обычно все напрямую, а в итоге все получается очень сложно: оно не работает или работает еще хуже. Между тем nginx отлично ладит со всеми CMS, на сайтах доступны инструкции по настройке под самые разные случаи, но в нестандартных ситуациях приходится немного повозиться.
 

Запускаем сайты от разных пользователей в связке nginx + PHP-FPM

Сегодня нередко берут VDS в складчину и на одном сервере размещают свои сайты несколько пользователей. В итоге получается дешевле при большей суммарной мощности сервера на один сайт. Или как вариант: к серверу, помимо админа, нужен доступ разработчику для сопровождения сайта. Осталось обеспечить всем возможность доступа только к своим файлам, но таким образом, чтобы пользователи не могли прочитать файлы друг друга.

Если физический доступ к файлам легко настраивается с помощью стандартной системы прав *nix и домашних каталогов, то с веб-сайтами чуть сложнее. В Apache для решения этой задачи прибегают к suEXEC или suPHP, которые позволяют запускать процессы от имени нужной учетной записи. При установке стандартной связки LEMP используется один пул PHP-FPM, обрабатывающий все PHP-скрипты для всех сайтов от имени одной учетной записи (обычно совпадающей с той, под которой работает веб-сервер).

Это создает несколько проблем. Пользователи не могут нормально и безопасно работать только со своими сайтами, ведь для доступа придется включать всех в группу веб-сервера. Даже с очень строгими ограничениями в этом случае можно получить доступ ко всем сайтам. Если нельзя напрямую зайти в каталог, то делается симлинк на своем сайте, и можно читать чужие файлы через веб-сервер. Скомпрометированный сайт может служить проблемой для всех остальных приложений на этом сервере. Зараженные мини-хостинги — это, поверь, далеко не редкость. Хакер, взломав один, может получить доступ к файлам конфигурации и БД абсолютно всех.

Документация nginx часто дает ответы на нужные вопросы
Документация nginx часто дает ответы на нужные вопросы

При использовании nginx доступ разграничивают, создавая отдельные PHP-FPM-пулы для каждого пользователя. Процесс при этом запускается с правами конкретного пользователя, и он будет без проблем редактировать свои файлы в FTP-клиенте, не рискуя, что кто-то еще может к ним подобраться. Создаем учетную запись и подкаталоги для работы:

$ sudo adduser example
$ mkdir -p /home/example/example.org/{tmp,logs}

Единственный момент: если используются домашние каталоги пользователей, то веб-сервер и PHP должны получать доступ на чтение списка файлов и к каталогам выше (как минимум право на выполнение — х). Традиционно пулы PHP располагаются в каталоге /etc/php5/fpm/pool.d. Сам каталог подключается в /etc/php5/fpm/php-fpm.conf инструкцией include (она бывает закомментирована):

include=/etc/php5/fpm/pool.d/*.conf

После установки внутри обычно находится один файл www.conf, настройки которого и используются всеми процессами. Его можно взять как шаблон, скопировав и изменив параметры:

$ cd /etc/php5/fpm/pool.d
$ sudo cp www.conf example.org.conf

Правим под новый сайт:

$ sudo nano example.org.conf

[example.org]
listen = /var/run/php5-example.org.sock
listen.mode = 0664
# Пользователь и группа, под которыми будет работать пул
user = example
group = example
# По умолчанию сокет работает под теми же учетками, что указаны в user/group, nginx должен его читать
# Иногда нужно использовать другие учетные данные
listen.owner = nginx
listen.group = nginx
chdir = /home/example/example.org
error_log = /home/example/example.org/logs.азь-php.error.log
# Под планируемую нагрузку проставляем количество процессов
pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 6

И при необходимости указываем специфические для сайта установки PHP:

php_admin_value[session.save_path] = /home/example/example.org/tmp
php_admin_value[open_basedir] = "/home/example/example.org/"
php_admin_value[post_max_size] = 100M
php_admin_value[cgi.fix_pathinfo] = 0
Настраиваем пул PHP-FPM
Настраиваем пул PHP-FPM

Теперь процесс фактически заперт внутри каталога, с четко установленными правами. Все параметры файла можно найти в документации.

Настройки сайта для nginx в целом стандартные. Необходимо лишь указать сокет, который будет использоваться для обработки PHP:

$ sudo /etc/nginx/sites-available/example.org.conf

server {
    listen 80;
    server_name example.org;
    root   /home/example/example.org/;
    ...
    location ~ \.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass unix://var/run/php5-example.org.sock;
    }
    ...
}

$ ln -s sudo /etc/nginx/sites-available/example.org.conf /etc/nginx/sites-enabled/example.org.conf

Перезапускаем PHP-FPM и nginx:

$ sudo /etc/init.d/php5-fpm restart
$ sudo /etc/init.d/nginx reload

Если вместо сокета нужно использовать сетевое соединение, то для каждого пула указывается отдельный сетевой порт:

$ sudo nano example.org.conf

[example.org]
listen = 127.0.0.1:9001
...

$ sudo /etc/nginx/sites-available/example.org.conf

location ~ \.php$ {
    include /etc/nginx/fastcgi_params;
    fastcgi_pass 127.0.0.1:9001;
    ...
}

Осталось залить на сервер файлы и установить права: 640 на файлы и 750 на каталог.

 

Настраиваем WordPress в подпапке домена nginx

Нередко портал использует несколько CMS, доступ к которым организован из меню Landing Page. При размещении в поддомене с ссылкой вроде blog.example.org проблем нет, настраивается это стандартными правилами. А в случае использования подкаталога (http://example.org/blog) стандартные установки уже не подходят.

Разберем на примере WordPress. В инструкции на сайте WP при таком расположении предлагается переместить index.php и .htaccess из каталога с WordPress в корневой каталог сайта и указать в index.php новое расположение сайта. Вместо

require('./wp-blog-header.php');

вписать новый путь:

require('./blog/wp-blog-header.php');

Загвоздка в том, что в корневом каталоге уже может быть такой файл от основного сайта или нужно подключать несколько CMS со своими ссылками. В Apache это не проблема, а вот в nginx придется чуть отойти от стандартной конфигурации.

В начале идет основной сайт. Здесь все как обычно:

server {
    server_name  .example.org;
    root /var/www/;
    ...
}

Блог на WP к основному сайту подключается как location. В параметре root указываем полный путь к каталогу. В случае nginx нет ничего плохого в размещении root-каталога внутри location. Для проверки наличия файлов в nginx есть очень полезная инструкция try_files, которая просматривает существование файлов в указанном порядке и при первом совпадении использует его для обработки. Обработка делается в контексте этого же location в соответствии с директивами root и alias. Если в конце имени указать слеш, то проверяется каталог (например, $uri/). Если совпадения не найдены, то делается внутреннее перенаправление на uri, заданное последним параметром.

Переменная $uri, используемая в конфигурации, указывает на текущий URI запроса в нормализованном виде, при обработке запроса его значение может изменяться. $uri вообще очень полезная директива, при помощи которой можно перенаправлять запросы, блокировать доступ к файлам, перенаправлять на 404, если файла нет, и многое другое.

location ^~ /blog {
    root /var/www/blog;
    index index.php;
    try_files $uri $uri/ /blog/index.php?$args;
    access_log /var/log/nginx/blog.access.log;
}

location ~* .php$ {
    include fastcgi_params;
    fastcgi_index  index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
}

Если сайт расположен в пределах корневого каталога веб-сайта, такая схема работает без проблем. Но если location находится вне корневого каталога веб-сервера (что, кстати, очень не рекомендуют сами разработчики), то у него не будет доступа к корневому каталогу. То есть описанная конфигурация работать не станет. Например, не будут грузиться картинки или стили, и нужно дополнительно указать веб-серверу, где их искать.

Основная часть кода остается без изменений, правим только ту, что касается самого блога:

location /blog {
    root /home/blog/;
    index index.php;
    try_files $uri $uri/ /blog/index.php?$args;
    access_log /var/log/nginx/blog.access.log;
    error_log /var/log/nginx/blog.error.log;

    location ~* ^/blog/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt|woff|ttf))$ {
        root /home/blog/;
    }
}

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


1 комментарий

Подпишитесь на ][, чтобы участвовать в обсуждении

Обсуждение этой статьи доступно только нашим подписчикам. Вы можете войти в свой аккаунт или зарегистрироваться и оплатить подписку, чтобы свободно участвовать в обсуждении.

Check Also

Как работает Linux: от нажатия кнопки включения до рабочего стола

Лучший способ понять, как работает операционная система, — это проследить поэтапно ее загр…