Веб-сервер на основе Nginx и PHP-FPM. Nginx настройка wordpress

Инструкции по настройке обратного прокси-сервера Nginx, Apache и WordPress

Ожидание несчастья, может быть, худшее несчастье, чем самое несчастье (Т. Тассо).

Apache не известен своей скоростью. Напротив, Apache собрал репутацию весьма раздутой и хорошо работает под высоким трафиком. Тем не менее, Apache по-прежнему самый популярный веб-сервер во всем мире и используется многими хостинговыми компаниями из-за его знакомство и htaccess. Если вы все еще любите Apache по какой-то причине, и хотите, ускорить ваш WordPress сайт, вы можете поместить решение кэширования обратным прокси Nginx перед Apache, чтобы предоставить пользователям более быстрый вариант.

Nginx как обратный прокси-кэш работает перед Apache. Nginx прослушивает порт 80, а Apache прослушивает порт 8080. Nginx будет обслуживать любое содержимое, может кэшировать, в то время как все остальные запросы направляются в Apache для обработки PHP с MySQL или MariaDB.

Примечание: Это руководство не будет работать идеально для WooCommerce, новое руководство будет опубликовано для Nginx, который работает для WooCommerce.

Инструкции по настройке обратного прокси-сервера Nginx, для Apache и кэша WordPress

Общие сведения об установке

Инструкции по настройке Apache для обратного прокси-сервера Nginx

Файл открытых портов Apache

sudo nano /etc/apache2/ports.conf

Изменение порта на 8080

Откройте виртуальный хост Apache

nano /etc/apache2/sites-available/wordpress.conf

Изменение порта 8080 в виртуальном хосте

Нажмите Ctrl + X, Y и Enter, чтобы сохранить

Вам нужно будет изменить все ваши виртуальные хосты Apache, чтобы прослушивать порт 8080.

Apache будет возобновлен после того, как будет установлен и настроен, чтобы избежать каких-либо простоев Nginx.

Установка Nginx

Установите Nginx и Nginx-extras, чтобы получить модуль ngx_cache_purge, который сделает его легче управлять Nginx прокси – кэшэм.

sudo apt-get install nginx nginx-extras -y

Создание конфигурации Nginx

sudo nano /etc/nginx/sites-available/reverse

Вставьте конфигурацию Nginx, нам нужен буфер в верхней части, чтобы предотвратить эту ошибку ( источник )

upstream sent too big header while reading response header from upstream errors with buffers

Вот реальная конфигурация кэша Nginx прокси, обратите внимание, что он не оптимизирован для WooCommerce.

#fix 504 gateway timeouts, can go in nginx.conf proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600; #set the location of the cached files, zone, name, size (1000 MB) and how long to cache for 600 minutes proxy_cache_path /var/run/proxy_cache levels=1:2 keys_zone=WORDPRESS-PROXY:10m max_size=1000m inactive=600m; proxy_cache_key $scheme$host$request_uri; #prevent header too large errors proxy_buffers 256 16k; proxy_buffer_size 32k; #httpoxy exploit protection proxy_set_header Proxy ""; server { listen 80 default; access_log /var/log/nginx/proxy-access.log; error_log /var/log/nginx/proxy-error.log; add_header X-Cache $upstream_cache_status; set $do_not_cache 0; set $bypass 0; #security for bypass if ($remote_addr ~ "^(127.0.0.1|Web.Server.IP)$") { set $bypass $http_secret_header; } if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) { set $do_not_cache 1; } location / { proxy_set_header Host $host; proxy_redirect off; proxy_cache WORDPRESS-PROXY; proxy_cache_revalidate on; proxy_ignore_headers Expires Cache-Control; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504; proxy_cache_bypass $bypass $do_not_cache; proxy_no_cache $do_not_cache; proxy_cache_valid 200 301 302 500m; proxy_cache_valid 404 1m; #can rename PURGE to whatever you want, should restrict it to backend server requests for security proxy_cache_purge PURGE from 127.0.0.1 Web.Server.IP; proxy_pass http://127.0.0.1:8080; } location ~ /purge(/.*) { allow 127.0.0.1; allow Web.Server.IP; deny all; proxy_cache_purge WORDPRESS-PROXY $scheme$host$1; } }

#fix 504 gateway timeouts, can go in nginx.conf

proxy_connect_timeout 600;

proxy_send_timeout 600;

proxy_read_timeout 600;

send_timeout 600;

#set the location of the cached files, zone, name, size (1000 MB) and how long to cache for 600 minutes

proxy_cache_path /var/run/proxy_cache levels=1:2 keys_zone=WORDPRESS-PROXY:10m max_size=1000m inactive=600m;

proxy_cache_key $scheme$host$request_uri;

#prevent header too large errors

proxy_buffers 256 16k;

proxy_buffer_size 32k;

#httpoxy exploit protection

proxy_set_header Proxy "";

server {

listen 80 default;

access_log /var/log/nginx/proxy-access.log;

error_log /var/log/nginx/proxy-error.log;

add_header X-Cache $upstream_cache_status;

set $do_not_cache 0;

set $bypass 0;

#security for bypass

if ($remote_addr ~ "^(127.0.0.1|Web.Server.IP)$") {

set $bypass $http_secret_header;

}

if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {

set $do_not_cache 1;

}

location / {

proxy_set_header Host $host;

proxy_redirect off;

proxy_cache WORDPRESS-PROXY;

proxy_cache_revalidate on;

proxy_ignore_headers Expires Cache-Control;

proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;

proxy_cache_bypass $bypass $do_not_cache;

proxy_no_cache $do_not_cache;

proxy_cache_valid 200 301 302 500m;

proxy_cache_valid 404 1m;

#can rename PURGE to whatever you want, should restrict it to backend server requests for security

proxy_cache_purge PURGE from 127.0.0.1 Web.Server.IP;

proxy_pass http://127.0.0.1:8080;

}

location ~ /purge(/.*) {

allow 127.0.0.1;

allow Web.Server.IP;

deny all;

proxy_cache_purge WORDPRESS-PROXY $scheme$host$1;

}

Нажмите Ctrl + X, Y и Enter

Создадим символические ссылки кэша Nginx обратного прокси для WordPress виртуального хоста, чтобы его включить, когда мы перезапустим Nginx

sudo ln -s /etc/nginx/sites-available/reverse /etc/nginx/sites-enabled/reverse

Unlink Nginx виртуального хоста по умолчанию

unlink /etc/nginx/sites-enabled/default

Перезапустите Apache и Nginx

sudo service apache2 restart sudo service nginx restart

sudo service apache2 restart

sudo service nginx restart

Тестирование Nginx обратного прокси-кэша

Мы можем использовать curl, чтобы проверить, что обратный прокси-кэш Nginx работает на нашем WordPress сайте.

sudo apt-get install curl -y

Теперь Curl установлен, мы можем начать тестирование Nginx обратного прокси перед Apache.

Используйте SSH на веб-сервере, чтобы запустить команду cURL. Это позволит проверить, что ваша домашняя страница кэшируется обратным прокси-сервером, а флаг -I гарантирует, что мы получаем заголовки ответа назад от обратного прокси-сервера

curl -I https://andreyex.ru/

Ключевое значение здесь статус X-Cache

HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: HIT

HTTP/1.1 200 OK

Server: nginx/1.8.1

Date: Fri, 03 Feb 2017 13:28:26 GMT

Content-Type: text/html; charset=UTF-8

Connection: keep-alive

Vary: Accept-Encoding

X-Cache: HIT

Если домашняя страница не кэшируется, вы получите в ответе X-Cache

HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: MISS

HTTP/1.1 200 OK

Server: nginx/1.8.1

Date: Fri, 03 Feb 2017 13:28:26 GMT

Content-Type: text/html; charset=UTF-8

Connection: keep-alive

Vary: Accept-Encoding

X-Cache: MISS

Иногда вам может понадобиться cURL тот же URL дважды, чтобы получить ответ HIT.

Магазин Nginx Кэша

Если вы посмотрите в папке proxy_cache_path вы увидите кучу случайных букв и цифр, которые решаются на уровне = 1: 2. Это может показаться странным, поскольку изначально Nginx хранит кэш в виде md5 хэшей URL-адреса на основе proxy_cache_key. мы используем $scheme$host$uri, где

$scheme=http
$host=domain
$request_uri=URL

Так что для этой страницы https://andreyex.ru/kontakty

$scheme is https
$host is andreyex.ru
$request_uri is /kontakty

Мы можем передать это через md5 генератор на Debian

echo https://andreyex.ru/kontakty | md5sum

Он генерирует эту сумму md5

c301d2e9d39fa7434a56322a09dbab17

Который Nginx использует для создания структуры папок на основе уровней proxy_cache_path = 1: 2

c301d2e9d39fa7434a56322a09dbab17

Из уровней = 1: 2, 1 становится папка верхнего уровня и 2 становится его подкаталог, с оригинальным md5 хэшэм имя файла

/var/run/proxy-cache/7/b1/c301d2e9d39fa7434a56322a09dbab17

Зная, как работает Nginx кэш означает, что мы можем выборочно удалить элементы из обратного прокси-кэша

Очистка и недействительность в Nginx обратного прокси-кэша

Благодаря модулю ngx_cache_purge, который включен в модуль Nginx-extras, у нас есть несколько способов привести к выборочному аннулированию кэша. Наша цель состоит в том, чтобы иметь весь сайт в кэше, используя этот плагин так что ваш WordPress сайт полностью кэшируются и всегда быстро. Когда мы обновляем контент мы хотим, чтобы очистить кэш для этих постов, страниц или категорий, которые изменяются и заменить эти старые элементы свежими новыми сразу, так что ваши пользователи получают самый быстрый возможный опыт.

Nginx прокси кэш хранится в структуре папок в папке /var/run/proxy-cache, в котором мы можем выборочно удалить определенные элементы или удалить все, чтобы очистить весь кэш
BYPASS позволяет принудительно обновить посты или страницы, задавая веб-серверу, где предлагается WordPress для новой версии
- Обновленный элемент заменит устаревший элемент в Nginx обратного прокси-кэша
Метод PURGE, proxy_cache_purge позволяет использовать не RFC методы HTTP для очистки конкретных элементов из кэша
URL /purge, метод позволяет присоединять URL к месту очистки, чтобы очистить определенный элемент

Очистить весь кэш в обратном прокси-сервере Nginx

Если вы хотите очистить весь кэш, вы можете просто удалить содержимое папки прокси-кэша вручную

rm -R /var/run/proxy-cache/*

Можно также удалить определенные элементы, если вы хотите путем создания MD5 хэша полного URL, или вы хотите очистить и удалить конкретную папку и вложенную папку рекурсивно в папке proxy_cache_path.

Если вы хотите очистить весь кэш с помощью регулярных выражений (также известный как групповые символы) ваш единственный вариант заключается в использовании Nginx Plus, который стоит денег. Инженеры Nginx Plus знают, что иметь высокую производительность WordPress сайта означает сохранение всего сайта в кэше все время так, крупные компании будут платить за гибкое управления кэшем.

Обновить продукты в обратном прокси-сервере Nginx с помощью метода BYPASS

Bypass, безусловно, лучший способ обновления Nginx кэша обратного прокси-сервера. С proxy_cache_bypass вы принудительно принесете новую версию URL с веб-сервера под управлением WordPress и замените старую устаревшую версию с новой свежей версии. Ваши пользователи никогда не получат старый контент таким образом, и никогда не будет получать медленную компиляцию PHP на лету с вашего веб-сервера (если только они не являются кэшируемым).

В блоке выше мы реализовали proxy_cache_bypass только для запросов, которые приходят с нашего веб – сервера или сам обратный прокси – сервер

Мы позволили секретный заголовок для входящих запросов от веб-сервера и обратный прокси-сервер, поэтому мы можем проверить с помощью секретного заголовка с Curl из этих серверов.

curl -I https://andreyex.ru -H "secret-header: true"

Вы увидите этот вывод , показывающий BYPASSвX-Cache header

HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: BYPASS

HTTP/1.1 200 OK

Server: nginx/1.8.1

Date: Fri, 03 Feb 2017 13:28:26 GMT

Content-Type: text/html; charset=UTF-8

Connection: keep-alive

Vary: Accept-Encoding

X-Cache: BYPASS

Если попробовать ту же Curl команду с другого сервера вы просто увидите ответ HIT

HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: HIT

HTTP/1.1 200 OK

Server: nginx/1.8.1

Date: Fri, 03 Feb 2017 13:28:26 GMT

Content-Type: text/html; charset=UTF-8

Connection: keep-alive

Vary: Accept-Encoding

X-Cache: HIT

Обновление элементов в обратном прокси-сервере Nginx с помощью метода PURGE

Метод PURGE любезно предоставлен модулем ngx_cache_purge в пакете Nginx-extras.

Для работы этого метода я нашел proxy_cache_key, который должен был быть установлен в $scheme$host$request_uri, но ваш опыт может варьироваться.

Чтобы отправить запрос на PURGE, используйте этот синтаксис, модуль proxy_cache_purge будет переводить запрос в md5 хэш URL и удалит элемент из папки proxy_cache_path указанного в Nginx обратного прокси-сервера виртуального хоста.

curl -X PURGE -I https://andreyex.ru

Если обратный прокси-сервер имеет файл, то вы получите ответ 200, что означает, успешным

HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 277 Connection: keep-alive

HTTP/1.1 200 OK

Server: nginx/1.8.1

Date: Fri, 03 Feb 2017 13:38:26 GMT

Content-Type: text/html

Content-Length: 277

Connection: keep-alive

Если Nginx обратный прокси-сервер не имеет такой закэшированный специфический URL то вы получите 404

HTTP/1.1 404 Not Found Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 168 Connection: keep-alive

HTTP/1.1 404 Not Found

Server: nginx/1.8.1

Date: Fri, 03 Feb 2017 13:38:26 GMT

Content-Type: text/html

Content-Length: 168

Connection: keep-alive

Если Nginx обратный прокси-сервер обнаруживает, что на вашем IP-адресе не разрешено выполнять запросы PURGE вы получите ответ: 403 Forbidden

HTTP/1.1 403 Forbidden Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 168 Connection: keep-alive

HTTP/1.1 403 Forbidden

Server: nginx/1.8.1

Date: Fri, 03 Feb 2017 13:38:26 GMT

Content-Type: text/html

andreyex.ru

Веб-сервер на основе Nginx и PHP-FPM

Существуют различные схемы построения веб-серверов для передачи данных по протоколу HTTP. Среди них достойное место по производительности занимают схемы с использованием «Nginx» в качестве внешнего (кэширующего, front-end) сервера. «Nginx» разработан для отдачи статических данных, при этом, он показывает высокое быстродействие и нагрузочную способность (см. Nginx vs Cherokee vs Apache vs Lighttpd), генерировать же динамическое содержимое он не способен. Поэтому, он часто применяется в связке с внутренним (back-end) сервером для обработки динамических данных которые потом отдаются «Nginx» как статические без участия внутреннего сервера. В качестве внутреннего сервера может применяться «Apache2» или, что и рассматривается в данной статье, «PHP-FPM».

В данной статье рассматривается установка и настройка связки Nginx и PHP-FPM на локальной ЭВМ, если требуется работа на выделенном сервере, то следует обратится к более серьезным инструкциям или/и непосредственной помощи специалистов

Данная статья написана любителем, никто из профессионалов её не проверял, она может содержать ошибки и вредные советы и потому нацелена на тех, кто хочет поиграться

Сервер «Nginx» поставляется в одноименном пакете «nginx» и его установка производится, например, командой в терминале

sudo apt-get install nginx nginx-extras

Установку же «PHP-FPM» можно произвести, например, командой

sudo apt-get install php5-cli php5-common php5-mysql php5-gd php5-fpm php5-cgi php5-fpm php-pear php5-mcrypt

Наряду с уязвимостями присущими ПО сервера, присутствуют также те, что обусловлены неосторожностью администратора сервера. Для их устранения следует соблюдать меры предосторожности:

Должно быть запрещено выполнение PHP-кода из открытых для записи директорий. Например, директории для загрузки аватаров, файлов или директории доступные также FTP-серверу, который позволяет произвести запись в них.
Следует следить за логами работы сервера, это позволяет выявить попытку взлома как можно раньше и минимизировать угрозу дальнейшего ущерба.
Необходимо обновлять ПО (в том числе «CMS» — системы управления содержимым сайтов), но не обязательно тогда когда выходят новые версии (они тоже могут содержать новые уязвимости), а, прежде всего, тогда, когда обновление связано с устранением серьезной уязвимости.
Обязательное наличие файлов для отката состояния сервера (в том числе, конфигурационных файлов).

Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами

sudo service nginx stop sudo service php5-fpm stop

Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой

sudo nano /etc/php5/fpm/php.ini

после чего, найти строчку содержащую «cgi.fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)

;cgi.fix_pathinfo = 1

и привести её к виду

cgi.fix_pathinfo = 0

Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.gif/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP).

Если планируется загрузка больших файлов (важно для ownCloud версий < 8, в новой версии 8 и выше имеется отдельный файл для этих настроек), то можно увеличить максимальный объем загружаемых данных, например, до 200 МБ

post_max_size = 200M

и ниже

upload_max_filesize = 200M

Затем сохранить изменения в файле.

Далее, необходимо отрыть для редактирования файл «/etc/php5/fpm/pool.d/www.conf», например, командой

sudo nano /etc/php5/fpm/pool.d/www.conf

найти строчку с параметров «security.limit_extensions» и привести её к виду

security.limit_extensions = .php .php3 .php4 .php5

Эта настройка ограничит выполнение файлов по расширению имени. В этом же файле найти строчку с параметром «listen» и привести её к виду

listen = /var/run/php5-fpm.sock

Это определит файл для связи «Nginx» с «PHP-FPM» (сокет). В целях безопасности запрещаем какой-попало программе писать в сокет (см. Обновление PHP 5.5.12 с устранением уязвимости в PHP-FPM ) путём указания прав доступа к сокету. Находим строчки с описанием параметров «listen.owner», «listen.group» и «listen.mode» (по-умолчанию они закомментированы) и приводим их к виду

listen.owner = www-data listen.group = www-data listen.mode = 0660

Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой

sudo service php5-fpm restart

Можно убедится в том, что права доступа к сокету установлены верно:

ls -la /var/run/php5-fpm.sock

Права доступа должны быть «srw-rw—-», владелец «www-data» (группа «www-data»), например,

srw-rw---- 1 www-data www-data 0 May 2 16:36 /var/run/php5-fpm.sock

Основные настройки «Nginx» хранятся в файле «/etc/nginx/nginx.conf». Настройки базового сайта хранятся в файле «/etc/nginx/sites-available/default». Базовый конфигурационный файл сайта принято помещать в папку «/etc/nginx/sites-available/» и затем включить его путём добавления символической ссылки на этот файл в папке «/etc/nginx/sites-enabled/». Например, создадим конфигурационный файл для сайта с доменным именем (для примера выбрано «example.com») в названии для удобства

sudo touch /etc/nginx/sites-available/example.com sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

и откроем его для редактирования

sudo nano /etc/nginx/sites-available/example.com При редактировании данного файла необходимо учитывать синтаксис конфигурации «Nginx» (см. HttpCoreModule), готовые советы по настройке связки «Nginx + PHP-FPM» (см. PHPFcgiExample) и следовать некоторым правилам/рекомендация для достижения эффективной работы сервера (см. Pitfalls).

Описывать конфигурацию сайта в одном файле не очень удобно, для увеличения читабельности конфигурационного файла и гибкости настройки можно воспользоваться директивой «include» позволяющей указать «Nginx», что следует загрузить другой конфигурационный файл и затем продолжить чтение текущего. Создадим в папке «/etc/nginx/» каталог «common», где будут хранится общие настройки для сайта, которые затем будут подгружаться из основного конфигурационного файла «/etc/nginx/sites-available/example.com» с помощью директивы «include»

sudo mkdir /etc/nginx/common

Некоторые запросы «Nginx» будет перенаправлять к «PHP-FPM», который в данном случае называется сервером выгрузки данных (upstream). Укажем как следует это делать. Создадим файл конфигурации с описанием серверов выгрузки данных

sudo touch /etc/nginx/common/upstream

и откроем его для редактирования

sudo nano /etc/nginx/common/upstream

и добавим в него строчки

upstream php-fpm { # PHP5-FPM сервер server unix:/var/run/php5-fpm.sock; }

где «php-fpm» – название для сервера выгрузки данных, для удобства.

Редактируем файл «/etc/nginx/sites-available/example.com». Добавляем строчку

include common/upstream;

для загрузки созданого выше конфигурационного файла. Как можно видеть – допускается указание относительного пути к файлу.

Далее описываем перенаправление от HTTP к HTTPS, если, конечно, это планируется. В таком случае необходимо наличие сертификатов для HTTPS (см. Сертификаты)

server { listen 80; server_name example.com www.example.com; return 301 https://$server_name$request_uri; }

иначе, можно опустить эти строчки.

Начинаем описывать конфигурацию сайта

server {

Сетевой порт для приема соединений: 80 — обычный HTTP; 443 — HTTPS (см. выше)

# Порты listen 80; listen 443 ssl; # использовать шифрование для этого порта

Корневая директория сайта работающего на данном сервере

root /var/www;

Возможные имена индексных файлов (их «Nginx» пытается открыть если он получил запрос вида «example.com/», вместо явного «example.com/index.html»)

index index.php index.html index.htm;

Имя сервера – обычно доменное имя Вашего сервера

server_name example.com www.example.com;

Шифрование

Необходимо наличие сертификата «*.crt» или «*.pem» и приватного секретного ключа «*.key» (см. Сертификаты). Самоподписанный сертификат можно сгенерировать командой в терминале (см. man openssl, man req)

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout example.com_nginx.key -out example.com_nginx.crt

При этом программа запросит данные, среди них «commmon name» — следует указать доменное имя сервера. Можно использовать шаблон, если необходимо учесть домены нижнего уровня, например, «*example.com». Иначе могут возникнуть проблемы с некоторыми программами, например, «davfs2» (см man davfs2.conf).

Но можно пойти дальше и воспользоваться сервисом «StartSSL» где выдают бесплатные сертификаты для личного пользования (см. startssl.com и Получение и установка бесплатного SSL-сертификата), но сам приватный ключ (который нельзя никому показывать) лучше сгенерировать самому, например, так

openssl genrsa -out example_nginx.com.key 4096

затем сформировать файл запроса на подпись (при этом прийдётся вводить те же данные что и для генерации самоподписанного сертификата, но это не важно, т.к. сервис «StartSSL» проигнорирует все кроме публичного ключа)

openssl req -new -sha256 -key example.com_nginx.key -out example.com.csr

открыть полученный файл текстовым редактором

nano example.com.csr

и скопировать его содержимое в текстовое поле на сайте «StartSSL» для запроса сертификата (см. ссылки на подробные инструкции выше). Файл *.csr больше не нужен. Затем загружаем подписанный сертификат (например, файл называется signed.crt) и объединяем его с сертификатом того кто этот сертификат подписал

wget https://www.startssl.com/certs/sub.class1.server.ca.pem cat signed.crt sub.class1.server.ca.pem > example.com_nginx.crt

Файл «signed.crt» можно удалить.

Копируем секретный ключ в системную папку и выставляем права доступа

sudo cp example.com_nginx.key /etc/ssl/private/ sudo chown www-data:www-data /etc/ssl/private/example.com_nginx.key sudo chmod 400 /etc/ssl/private/example.com_nginx.key

И в соседнюю папку сам сертификат

sudo cp example.com_nginx.crt /etc/ssl/certs/

Для пущей надежности можно сгенерировать ключ Диффи-Хеллмана (тоже секретный файл который очень долго генерируется)

openssl dhparam -out example.com.dh.key 4096 sudo cp example.com_nginx.dh.key /etc/ssl/private/ chown www-data:www-data example.com_nginx.dh.key chmod 400 example.com_nginx.dh.key

Продолжаем редактировать конфигурационные файлы.

Для удобства описываем настройки шифрования во внешнем файле «/etc/nginx/common/ssl»

sudo touch /etc/nginx/common/ssl

Редактируем файл «/etc/nginx/common/ssl»

sudo nano /etc/nginx/common/ssl

Файлы сертификатов для «HTTPS»

ssl_certificate /etc/ssl/certs/example.com_nginx.crt; # сертификат (можно свободно распространять) ssl_certificate_key /etc/ssl/private/example.com_nginx.key; # приватный ключ (секретный файл - НИКОМУ НЕ ПОКАЗЫВАТЬ)

Дополнительные параметры требуемые для «HTTPS»

ssl_dhparam /etc/ssl/private/example.com_nginx.dh.key; # писать эту строчку только если файл есть ssl_session_timeout 20m; # время 20 минут ssl_session_cache shared:SSL:20m; # размер кеша 20МБ ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;

На этом настройки «SSL» в «Nginx» завершены, сохраняем и закрываем файл. После завершения описания конфигурации (см. ниже) можно будет проверить надежность сервисом «SSLLabs»

Продолжаем редактировать файл «/etc/nginx/sites-available/example.com». Подгружаем созданный выше конфигурационный файл с описанием настроек SSL

# Настройка шифрования SSL include common/ssl;

Прочие настройки

Указание максимального размера запроса – необходимо если сервер будет использоваться для загрузки больших файлов (например, для построения небольшого облачного хранилища на основе «ownCloud», эта строчка по сути делает то же что и указанные выше при настройке «PHP-FPM», только теперь для «Nginx»)

client_max_body_size 200m; # увеличение максимального объема файла для загрузки до 200МБ

Ещё одна опция

# Buffers fastcgi_buffers 64 4K;

Безопасность

Опишем настройки безопасности в отдельном файле

sudo touch /etc/nginx/common/security sudo nano /etc/nginx/common/security

И укажем в нём

add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff";

Сохраним и закроем файл, а затем подключим его строкой

include common/security;

Сжатие

Для экономии трафика лучше включить сжатие (иногда со влючённым сжатием могут возникать проблемы, например, у «ownCloud», см. ниже). Опишем настройки сжатия в отдельном файле

sudo touch /etc/nginx/common/gzip sudo nano /etc/nginx/common/gzip

и введём

gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_min_length 1100; gzip_buffers 16 8k; gzip_proxied any; gzip_types text/plain application/xml text/css text/js text/xml application/x-javascript text/javascript application/javascript application/json application/xml+rss;

Следует сохранить, закрыть и затем подключить этот файл срочкой

include common/gzip;

Директории сайта

Далее указание директорий сайта и правил работы с ними с использованием директив «location». Данная директива может обрабатывать регулярные выражения «Perl» (см. Регулярные выражения (шаблоны))

Важно учитывать порядок проверки директив «location» (см. location)

Блокировать доступ к файлам и подпапкам обычно следует посредством регулярных выражений

Корневая директория

location "/" { index index.php index.html index.htm; # варианты индексных файлов если имя файла в запросе не задано try_files $uri $uri/ =404; # проверить есть ли файл из запроса на диске, иначе - вернуть ошибку 404 }

К примеру, если хочется построить сайт на основе «WordPress», то можно описать корневую директорию так

location "/" { index index.php index.html index.htm; try_files $uri $uri/ /wordpress/; # проверяем существования файла или папки, иначе перенаправляем к example.com/wordpress rewrite "^/$" "/wordpress/" redirect; # перенаправляем запрос example.com/ к example.com/wordpress }

Соответственно сам сайт должен размещаться в каталоге «/var/www/wordpress/»

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

include common/locations/*.inc;

которая укажет «Nginx», что нужно подключить все файлы в директории «/etc/common/locations/» которые соответствуют шаблону «*.inc», таким образом, если один из файлов нужно будет временно отключить, то его можно просто переименовать убрав расширение в имени. Создадим директорию где будут хранится эти файлы

sudo mkdir /etc/nginx/common/locations

Некая директория «/var/www/restricted» доступная только авторизованным пользователям сервера. Создадим для неё файл конфигурации «/etc/nginx/common/locations/restricted.inc»

sudo touch /etc/nginx/common/locations/restricted.inc sudo nano /etc/nginx/common/locations/restricted.inc

со строчками

location ^~ "/restricted/" { auth_basic "Access to this folder is restricted"; auth_basic_user_file htpasswd; autoindex on; allow all; try_files $uri $uri/ =404; }

Синтаксис «^~» указывает, что при совпадении здесь директивы «location» ниже проверяться не будут.

Этот конфигурационный файл подключится автоматически, за счёт шаблона (см. выше).

Wordpress

Для более полной информации по настройке «Nginx» для «WordPress» следует обратиться к официальной документации (см. codex.wordpress.org/Nginx и wiki.nginx.org/WordPress)

Натройки «Wordpress», который, в данном примере, находится в папке «/var/www/wordpress» будут описаны в файле «/etc/nginx/common/locations/wordpress.inc»

sudo touch /etc/nginx/common/locations/wordpress.inc sudo nano /etc/nginx/common/locations/wordpress.inc

Указываем виртуальную директорию (используется для удобства и читабельности) в которую будут перенаправляться запросы при необходимости

location @wordpress { rewrite "^/wordpress/(.*)$" "/wordpress/index.php?q=$1" last; }

Аналогично примеру выше предотвращаем обработку остальных директив «location»

location ^~ "/wordpress/" { root "/var/www"; index index.php; try_files $uri $uri/ @wordpress; # проверить существует ли файл, иначе направить в виртуальную директорию # Ограничение доступа к секретному файлу location ~* "^/wordpress/wp-config.php(/.*)?$" { deny all; return 404; } # Ни в коем случае не выполнять файлы php в папках куда их может кто-то загрузить # Проще всего просто заблокировать любые операции с такими файлами регулярным выражением location ~* "/(uploads|files)/.*\.php.?(/.*)?$" { deny all; return 404; } # Перенаправление php-файлов к серверу «PHP-FPM» см. ниже по статье location ~ "^(/wordpress/.+?\.php)(/.*)?$" { # Проверяем существование файлов, пробуем исправить если нет, иначе выдаём ошибку # $1 указывает на первую скобку в регулярном выражении выше - собственно адрес запрошенного php файла try_files $1 $uri $uri/ $uri/index.php =404; include common/php-fpm; } # Другие настройки, см. ниже по статье include common/deny; include common/cache; }

Сохраняем и закрываем этот файл. Опять же, он будет подключён автоматически.

ownCloud

Для наиболее полной информации следует обратится к официальному руководству «OwnCloud» (см. Nginx Configuration). К примеру, «ownCloud» находится в папке «/var/www/owncloud».

Создадим файл настроек для «ownCloud» и отредактируем его

sudo touch /etc/nginx/common/locations/owncloud.inc sudo nano /etc/nginx/common/locations/owncloud.inc

Многое аналогично примеру для «Wordpress»

location ^~ "/owncloud/" { root "/var/www"; index index.php index.html index.htm; try_files $uri $uri/ =404; # ownCloud предоставляет свои красивые страницы для ошибок 404 и 403 - используем их error_page 403 /owncloud/core/templates/403.php; error_page 404 /owncloud/core/templates/404.php; # Отключаем сжатие - оно создаёт проблемы для клиента синхронизации ownCloud gzip off; # Переопределяем глобальную настройку описанную в главном файле # увеличиваем максимальный размер загружаемых файлов client_max_body_size 16G; # Запрещаем читать секретные файлы location ~* "^/owncloud/(\.user\.ini|data|config|db_structure\.xml|README)(/.*)?$" { deny all; return 404; } location ~ "^(/owncloud/.+?\.php)(/.*)?$" { try_files $1 $uri $uri/ $uri/index.php =404; include common/php-fpm; } include common/deny; include common/cache; }

Начиная с версии «ownCloud» 8 появился отдельный файл для переопределения некоторых настроек «PHP-FPM» взамен указанных в «/etc/php5/fpm/php.ini». Открыть его можно командой

sudo nano /var/www/owncloud/.user.ini

и в нем найти строчки

upload_max_filesize=513M post_max_size=513M

и поменять значения на требуемые.

Базовые ограничения

Выше была написана строчка для подключение файла «/etc/nginx/common/deny»

include common/deny;

рассмотрим его содержание. В нём идет запрет доступа к некоторым стандартным файлам. Создадим этот файл

sudo touch /etc/nginx/common/deny sudo nano /etc/nginx/common/deny

с содержанием

# Запрет доступа к .htaccess и .htpasswd файлам location ~* "/\.(htaccess|htpasswd)$" { deny all; # запретить все для всех return 404; # вернуть код ошибки }

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

Следует переписать все файлы «.htaccess» в директивы «Nginx». Найти эти файлы среди файлов сайта можно, например, командой

sudo find /var/www/ -name .htaccess

Вызов PHP-FPM

В примерах выше использовался файл «/etc/nginx/common/php-fpm» — в нём идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»

В файле «php.ini» должно быть установлено «cgi.fix_pathinfo = 0;» Также, в файле »/etc/php5/fpm/pool.d/www.conf» должно присутствовать ограничение на разширение имени исполняемых скриптов - «security.limit_extensions = .php .php3 .php4 .php5»

Создаём этот файл

sudo touch /etc/nginx/common/php-fpm sudo nano /etc/nginx/common/php-fpm

с содержанием

# Настройки порта или сокета PHP-FPM производятся в файле "/etc/php5/fpm/pool.d/www.conf" fastcgi_pass php-fpm; # Порядок важен - строчка "include fastcgi_params" должна быть первой include fastcgi_params; fastcgi_split_path_info ^(.+?\.php)(/.*)?$; # Вместо переменной "$document_root" можно указать адрес к корневому каталогу сервера и это желательно (см. http://wiki.nginx.org/Pitfalls) fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name; # См. http://trac.nginx.org/nginx/ticket/321 set $path_info $fastcgi_path_info; fastcgi_param PATH_INFO $path_info; # Additional variables fastcgi_param SERVER_ADMIN [email protected]; fastcgi_param SERVER_SIGNATURE nginx/$nginx_version; fastcgi_index index.php;

Кеширование

Выше, в примерах, был упомянут файл «/etc/nginx/common/cache»

Сайт работает значительно лучше когда часть контента сохранена на стороне клиента с прошлого посещения сайта. Не все файлы можно кешировать. Поэтому описание кеширования производится в самом конце (т.е. эти настройки будут иметь наименьший приоритет и есть шанс что это не повлияет на правильную работу сайта). Создадим файл с параметрами для кеширования

sudo touch /etc/nginx/common/cache sudo nano /etc/nginx/common/cache

где укажем

location ~* ".+\.(?:ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|css|swf|js|atom|jpe?g|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$" { access_log off; log_not_found off; expires max; }

Окончание

Закрываем фигурные скобки директивы «server» в «/etc/nginx/sites-available/example.com»

}

На этом правка файла «/etc/nginx/sites-available/example.com» завершена. Убедитесь в том, что все фигурные скобки «{ }» закрыты корректно и части файла верно вложены друг в друга («location» внутри «server» и т.п.).

Сохраняем все изменённые файлы.

Теперь можно перезапустить демоны

sudo service nginx restart sudo service php5-fpm restart

Проверить свой сайт можно создав файл «info.php» с содержанием

<?php phpinfo(); ?>

затем скопировав его, например, в «/var/www/wordpress/wp-content/uploads/», затем открыв адрес в браузере «http://example.com/wordpress/wp-content/uploads/info.php», если он выполнится вместо того чтобы просто сохранится — то что-то настроено неправильно, в этой директории php файлы выполняться не должны ни в коем случае (она доступна для загрузки)

Проверить свой сайт на скорость и прочее можно тут:

help.ubuntu.ru

Настройка сервера Ubuntu + Nginx + PHP-FPM + WordPress — Bobrowski Think

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

Не сидим под рутом

По умолчанию нам предлагается сидеть под root-ом, что не очень хорошо по соображениям безопасности.

1. создаем пользователя под которым будем работать(самый простой способ):

# adduser user

где user — имя пользователяДалее мы увидим диалог что-то вроде:

Добавляется пользователь «user» ... Добавляется новая группа «user» (1001) ... Добавляется новый пользователь «user» (1001) в группу «user» ... Создаётся домашний каталог «/home/user» ... Копирование файлов из «/etc/skel» ... Введите новый пароль UNIX: Повторите ввод нового пароля UNIX: passwd: пароль успешно обновлён Изменение информации о пользователе user Введите новое значение или нажмите ENTER для выбора значения по умолчанию Полное имя []: Номер комнаты []: Рабочий телефон []: Домашний телефон []: Другое []: Данная информация корректна? [Y/n] Y

Пишем сложный пароль(который вы не забудете!) и заполняем данные которые считаем нужными, или просто нажимаем enter.

2. Разрешаем user выполнение sudoДобавляем user в специальную группу sudo:

где собственно user — имя пользователя.Всё, можем выходить и логинится под user

$ ssh [email protected] -p 22

и в дальнейшем уже использовать sudo если нужны привилегии root-а

Установка phpMyAdmin

sudo apt-get install phpmyadmin sudo ln -s /usr/share/phpmyadmin/ /usr/share/nginx/html sudo service nginx restart

Создание вирнуальных хостов

sudo useradd bobrowski -b /home/ -m -U -s /bin/false sudo mkdir -p -m 755 /home/bobrowski/www sudo usermod -a -G bobrowski www-data

Создание пользоветелей и баз MySQL

mysql -u root -p

Создадим пользоветаля user c паролем password

create user 'test'@'localhost' identified by 'password';

Проверим пользователей

select user,host,password from mysql.user;

Создадим базу данных

CREATE DATABASE `testdb` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Предоставим пользователю test все права на базу testdb

grant all on testdb.* to 'test'@'localhost'

Вдруг че то удалим пользователя test так:

drop user 'test'@'localhost'

mysql -uroot -p -A < bobrwski.ru.sql

Джерела:

bobrowski.ru

Настройка кеширования в nginx + php-fpm на примере Wordpress

Добавляем в конфиг nginx в секцию http такие строки:

## FastCGI Cacheopen_file_cache max=1000 inactive=20s;open_file_cache_valid 30s;open_file_cache_min_uses 2;open_file_cache_errors on;fastcgi_cache_path /tmp/nginx/cache levels=2 keys_zone=sites:100m inactive=1d max_size=10g;и в описание вирт хоста в секцию сервер пишем:

### Fast-CGI Cache

location / {if ($request_uri ~* "\.(ico|css|js|gif|jpe?g|png)$") {expires max;

}}

if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {set $do_not_cache 1;}

fastcgi_cache_bypass $do_not_cache;fastcgi_no_cache $do_not_cache;fastcgi_pass_header Cookie;fastcgi_cache sites;fastcgi_cache_key $request_method|$host|$request_uri;fastcgi_cache_valid 301 8h;fastcgi_cache_valid 404 1h;fastcgi_cache_valid 200 1h;

Создаем каталог для кеша и выставляем права:mkdir -p /tmp/nginx/cachechmod -R 777 /tmp/nginx/cache

Перезапускаем nginx :

/usr/local/etc/rc.d/nginx restart

Лазаем по сайту и смотри в каталог с кешем:

deathstar# ls /tmp/nginx/cache00 0e 1c 2a 38 46 54 62 70 7e 8c 9a a8 b6 c4 d2 e0 ee fc01 0f 1d 2b 39 47 55 63 71 7f 8d 9b a9 b7 c5 d3 e1 ef fd02 10 1e 2c 3a 48 56 64 72 80 8e 9c aa b8 c6 d4 e2 f0 fe03 11 1f 2d 3b 49 57 65 73 81 8f 9d ab b9 c7 d5 e3 f1 ff04 12 20 2e 3c 4a 58 66 74 82 90 9e ac ba c8 d6 e4 f205 13 21 2f 3d 4b 59 67 75 83 91 9f ad bb c9 d7 e5 f306 14 22 30 3e 4c 5a 68 76 84 92 a0 ae bc ca d8 e6 f407 15 23 31 3f 4d 5b 69 77 85 93 a1 af bd cb d9 e7 f508 16 24 32 40 4e 5c 6a 78 86 94 a2 b0 be cc da e8 f609 17 25 33 41 4f 5d 6b 79 87 95 a3 b1 bf cd db e9 f70a 18 26 34 42 50 5e 6c 7a 88 96 a4 b2 c0 ce dc ea f80b 19 27 35 43 51 5f 6d 7b 89 97 a5 b3 c1 cf dd eb f90c 1a 28 36 44 52 60 6e 7c 8a 98 a6 b4 c2 d0 de ec fa0d 1b 29 37 45 53 61 6f 7d 8b 99 a7 b5 c3 d1 df ed fbdeathstar# du -sxh /tmp/nginx/cache11M /tmp/nginx/cachedeathstar# Каталог занимает 11МБ . Вот и все действия для настройки кеширования силами nginx’а

deathstar.name

Веб-сервер на основе Nginx и PHP-FPM. Nginx настройка wordpress

Инструкции по настройке обратного прокси-сервера Nginx, Apache и WordPress

Общие сведения об установке

Инструкции по настройке Apache для обратного прокси-сервера Nginx

Установка Nginx

Тестирование Nginx обратного прокси-кэша

Магазин Nginx Кэша

Очистка и недействительность в Nginx обратного прокси-кэша

Очистить весь кэш в обратном прокси-сервере Nginx

Обновить продукты в обратном прокси-сервере Nginx с помощью метода BYPASS

Обновление элементов в обратном прокси-сервере Nginx с помощью метода PURGE

Веб-сервер на основе Nginx и PHP-FPM

Шифрование

Прочие настройки

Безопасность

Сжатие

Директории сайта

Wordpress

ownCloud

Базовые ограничения

Вызов PHP-FPM

Кеширование

Окончание

Настройка сервера Ubuntu + Nginx + PHP-FPM + WordPress — Bobrowski Think

Не сидим под рутом

Установка phpMyAdmin

Создание вирнуальных хостов

Создание пользоветелей и баз MySQL

Джерела:

Настройка кеширования в nginx + php-fpm на примере Wordpress

Смотрите также