Glashkoff.com

Полезные советы, софт для Windows и Android, создание сайтов на WordPress

Создание сайтов

VestaCP и WordPress: несколько советов по настройке

Как настроить шаблоны VestaCP так, чтобы сайт работал только по HTTPS протоколу, и подружить плагины WordPress с nginx.

Панель управления сервером VestaCP - достаточно хорошая штука. Она бесплатна и относительно легко устанавливается. Однако есть подводные камни, связанные с файлами конфигурации. О них я упоминал в инструкции по настройке WordPress + Nginx + VestaCP, сейчас будет подробнее.

У панели управления две проблемы - глючность и малое количество шаблонов настроек. Первое искоренить вряд ли удастся, т.к. авторы не могут у себя воспроизвести большую часть проблем, о которых пишут пользователи, зато с шаблонами настроек ситуация поправима.

Примечание: статья написана на примерах Ubuntu 16.10 на VPS от Scaleway, в других ОС пути к файлам могут немного отличаться. Apache у меня нет, только Nginx! Не рекомендую применять эти шаблоны при работающем Apache, сайты могут перестать работать.

Шаблоны настроек Nginx

Шаблоны выбираются при создании или редактировании домена в разделе WEB:VestaCP и WordPress: несколько советов по настройке

Все шаблоны находятся в папке /usr/local/vesta/data/templates/web/nginx/php-fpm

VestaCP и WordPress: несколько советов по настройке 1

При создании домена настройки сохраняются в папке /home/admin/conf/web (вместо "admin" может быть другой пользователь). Файлы с настройками будут иметь названия:

  • nginx.conf - настройки сайтов, доступных по http.
  • snginx.conf- настройки сайтов для доступа по https.
  • nginx.*.com.conf_custom - дополнительные файлы настроек, можно редактировать вручную.
  • nginx.*.com.conf_letsencrypt - нужно для получения и обновления сертификата Let's Encrypt.

Если заглянуть в nginx.conf, можно увидеть строчки:

include /etc/nginx/conf.d/phpmyadmin.inc*;
include /etc/nginx/conf.d/phppgadmin.inc*;
include /etc/nginx/conf.d/webmail.inc*;

Если сайтов у вас несколько, строчки будут повторяться в разделе каждого домена. Похоже, это своеобразный костыль, позволяющий работать встроенному интерфейсу почты и администратору баз данных PhpMyAdmin. Я ими не пользуюсь, поэтому в моих конфигах они удалены.

В чем проблема VestaCP: редактирование любого конфига, кроме *conf_custom, приведёт к повреждению этих файлов, если после изменять настройки через панель управления. Использование файла *conf_custom, на мой взгляд, не самый удобный способ, потому что не все настройки можно перекрыть своими, да и вносит путаницу.

А самое главное - в шаблонах Весты не включен протокол HTTP/2, который ой как нужен сайтам в современном интернете. Протокол HTTP/2 работает только на защищенных по https сайтах и позволит сайту быстрее открываться в браузерах посетителей, так как все картинки, скрипты и стили будут загружаться параллельно.

Исправим ситуацию, создав два новых шаблона: универсальный force-https для большинства сайтов и force-https-wp, оптимизированный под WordPress.

1) Шаблон для работы только по протоколу HTTPS

Создайте в папке /usr/local/vesta/data/templates/web/nginx/php-fpm файл force-https.tpl со следующим содержанием:

server {
 listen %ip%:%web_port%;
 server_name %domain_idn% %alias_idn%;
 root %docroot%;
 location / {
 rewrite ^(.*) https://%domain_idn%$1 permanent;
 }

include %home%/%user%/conf/web/nginx.%domain%.conf*;
}

Это тот минимум, благодаря которому при попытке открытия сайта по протоколу http произойдёт перенаправление на https. Например, вместо http://glashkoff.com откроется https://glashkoff.com.

Строчка include %home%/%user%/conf/web/nginx.%domain%.conf*; необходима, без нее SSL-сертификат Let's Encrypt обновляться не будет!

Теперь нужно создать force-https.stpl, чтобы генерировался конфиг для snginx.conf. У меня вот такой, подходит для большинства сайтов:

server {
 listen %ip%:%web_ssl_port% http2;
 server_name %domain_idn% %alias_idn%;
 root %sdocroot%;
 index index.php index.html index.htm;
 access_log /var/log/nginx/domains/%domain%.log combined;
 access_log /var/log/nginx/domains/%domain%.bytes bytes;
 error_log /var/log/nginx/domains/%domain%.error.log error;

ssl on;
 ssl_certificate %ssl_pem%;
 ssl_certificate_key %ssl_key%;

location / {

location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ {
 expires max;
 }

location ~ [^/]\.php(/|$) {
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 if (!-f $document_root$fastcgi_script_name) {
 return 404;
 }

fastcgi_pass %backend_lsnr%;
 fastcgi_index index.php;
 include /etc/nginx/fastcgi_params;
 }
 }

location ~* "/\.(htaccess|htpasswd)$" {
 deny all;
 return 404;
 }

include %home%/%user%/conf/web/snginx.%domain%.conf*;
}

После этого достаточно выбрать шаблон force-https в настройках домена, чтобы сайт открывался не только по https, но и работало перенаправление с небезопасной http версии. Также обратите на слово http2 в параметре listen - это включит протокол HTTP/2.

2) Шаблон VestaCP для работы сайта на WordPress только по протоколу HTTPS

Если у вас сайт на WordPress, нужен немного другой шаблон настроек.

Файл force-https-wp.tpl будет точно такого же содержания, как force-https.tpl выше:

server {
 listen %ip%:%web_port%;
 server_name %domain_idn% %alias_idn%;
 root %docroot%;
 location / {
 rewrite ^(.*) https://%domain_idn%$1 permanent;
 }

include %home%/%user%/conf/web/nginx.%domain%.conf*;
}

А вот содержимое force-https-wp.stpl будет более интересным:

server {
 listen %ip%:%web_ssl_port% http2;
 server_name %domain_idn% %alias_idn%;
 root %docroot%;
 index index.php index.html index.htm;
 access_log /var/log/nginx/domains/%domain%.log combined;
 access_log /var/log/nginx/domains/%domain%.bytes bytes;
 error_log /var/log/nginx/domains/%domain%.error.log error;

ssl on;
 ssl_certificate %ssl_pem%;
 ssl_certificate_key %ssl_key%;

location = /favicon.ico {
 log_not_found off;
 access_log off;
 }

location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 }

location / {
 try_files $uri $uri/ /index.php?$args;

location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ {
 expires max;
 }

location ~ [^/]\.php(/|$) {
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 if (!-f $document_root$fastcgi_script_name) {
 return 404;
 }

fastcgi_pass %backend_lsnr%;
 fastcgi_index index.php;
 include /etc/nginx/fastcgi_params;
 }
 }

location /error/ {
 alias %home%/%user%/web/%domain%/document_errors/;
 }

location ~* "/\.(htaccess|htpasswd)$" {
 deny all;
 return 404;
 }

#Yoast SEO Sitemaps
location ~ ([^/]*)sitemap(.*).x(m|s)l$ {
## this redirects sitemap.xml to /sitemap_index.xml
rewrite ^/sitemap.xml$ /sitemap_index.xml permanent;
## this makes the XML sitemaps work
rewrite ^/([a-z]+)?-?sitemap.xsl$ /index.php?xsl=$1 last;
rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last;
rewrite ^/([^/]+?)-sitemap([0-9]+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
}

#include %home%/%user%/conf/web/nginx.%domain%.conf*;
include %home%/%user%/web/%domain%/public_html/*.conf;
}

Это то, что сейчас используется на сайте glashkoff.com. Отличия от универсального шаблона:

  1. Есть настройки для популярного плагина поисковой оптимизации Yoast SEO (источник).
  2. Подгружаются файлы *.conf, которые создаются некоторыми плагинами для WordPress специально для nginx.

Обратите внимание - строчка "#include %home%/%user%/conf/web/nginx.%domain%.conf*;" закомментирована.

Почему это сделано

Дело в том, что nginx будет ругаться ошибкой "rule override already configured rule", если в nginx.conf будут такие строчки:

location = /wp-admin/install\.php { deny all; }
location = /nginx.conf { deny all; }
location ~ /\.htaccess$ { deny all; }
location ~ /readme\.html$ { deny all; }
location ~ /readme\.txt$ { deny all; }
location ~ /wp-config.php$ { deny all; }
location ~ ^/wp-admin/includes/ { deny all; }
location ~ ^/wp-includes/[^/]+\.php$ { deny all; }
location ~ ^/wp-includes/js/tinymce/langs/.+\.php$ { deny all; }
location ~ ^/wp-includes/theme-compat/ { deny all; }

Эти очень полезные правила доступа создаются плагином iThemes Security, когда включена опция защиты файлов. Если вам не нужен nginx.conf в папке сайта, чтобы обезопасить сайт, раскомментируйте вышеуказанную строку и добавьте конфиг в файл /home/имяпользователя/conf/webnginx.имядомена.conf:

location = /wp-admin/install\.php { deny all; }
location ~ /\.htaccess$ { deny all; }
location ~ /readme\.html$ { deny all; }
location ~ /readme\.txt$ { deny all; }
location ~ /wp-config.php$ { deny all; }
location ~ ^/wp-admin/includes/ { deny all; }
location ~ ^/wp-includes/[^/]+\.php$ { deny all; }
location ~ ^/wp-includes/js/tinymce/langs/.+\.php$ { deny all; }
location ~ ^/wp-includes/theme-compat/ { deny all; }

После применения шаблона не забудьте перезапустить сервис nginx командой service nginx restart или через VestaCP, раздел "Сервер".

VestaCP и WordPress: несколько советов по настройке 2

Если вдруг сделали что-то не так (или в конфиге опечатка, что странно), вы всегда можете вернуться на предыдущие шаблоны настроек.

Совет: если вы редактируете шаблон, который уже выбран для какого-то домена, для пересоздания файлов настроек в консоли сервера введите поочередно две команды:
v-update-web-templates 
service nginx restart

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

Починка Cron в WordPress

С этим я столкнулся, перейдя с веб-сервера Apache на Nginx. Не знаю точно, почему это происходит (то ли слишком агрессивно кэшируются страницы, то ли в Nginx есть какая-то настройка), но у меня даже на чистой конфигурации WordPress перестаёт работать Cron. Эта штука нужна для периодического выполнения задач обслуживания сайта, а также, что важно для меня - отложенной публикации.

Дело в том, что я не хочу публиковать записи в блоге сразу после написания. Самое продуктивное для меня время - между одиннадцатью и часом ночи, тогда и создаются большинство постов. Вряд ли кому-то будет приятно, если оповещение моего канала Telegram разбудит в столь поздний час. Но планировщик (WP-Cron) сайта очень капризный и может не сработать при использовании Nginx.

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

1. Установите плагин WP Missed Schedule. По какой-то причине он недоступен в официальном каталоге плагинов, поэтому нужно скачать со страницы https://github.com/sLaNGjI/wp-missed-schedule/ ZIP-архив:

VestaCP и WordPress: несколько советов по настройке 3

И поставить вручную через админку сайта:

VestaCP и WordPress: несколько советов по настройке 4

Не забудьте его активировать!

Как только кто-нибудь посетит ваш сайт, плагин WP Missed Schedule посмотрит, есть ли пропущенные задачи, которые следует выполнить, и запустит их.

2. Чтобы Cron срабатывал не только тогда, когда кто-нибудь посещает сайт (вдруг он у вас ещё не раскручен), нужно периодически обращаться к wp-cron.php. В VestaCP в разделе CRON добавьте задание:

wget -q -O - https://адрес_вашего_сайта/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Не забудьте указать адрес вашего сайта. Получится вот так (на скриншоте периодичность раз в 15 минут, этого достаточно):

VestaCP и WordPress: несколько советов по настройке 5

С этими настройками сервер будет открывать страницу wp-cron.php, которая принудительно запускает Cron, раз в 15 минут. Таким образом будет исключена ситуация, когда ваш сайт никто не посещает и Cron не сработал вовремя, раз в 15 минут плагин WP Missed Schedule так или иначе запустит пропущенное задание.

Подведя итоги

VestaCP - хороший инструмент с обширными функциями, но развивается довольно медленно. Возможно, когда-нибудь в комплекте появятся нормальные шаблоны для WordPress и HTTP/2 будет изначально включён, а пока придётся допиливать.

Похожие записи:

6 комментариев

  1. Виктор

    Благодарю за очередную толковую статью! Было очень полезно! Но у меня тут появился вопрос – Вы слышали про новую панельку [удалено модератором]? Вроде как ничего такая штука? Пробовали уже? Хочется услышать ваше мнение об этом продукте, может быть она менее глючная в сравнении с вестой? Было бы интересно почитать ваше мнение на этот счет, а особенно, если это будет в формате отдельной статьи!

    Ответить

    • Дмитрий Глашков

      Спасибо за комментарий. Посмотрел панель, которую вы предложили. Знаете, бесплатный сыр бывает только в мышеловке. Использовать не рекомендую. Исходный код закрыт, что для серверного софта не есть хорошо. Разработчики этой панели не удаляют безопасности должного внимания. Поэтому удалил название из вашего комментария, не хочу даже косвенно рекламировать этот продукт.

      Ответить

  2. Кирилл

    Статья просто замечательная, очень подробная, но возник вопрос.

    Обратите внимание – строчка «#include %home%/%user%/conf/web/nginx.%domain%.conf*;» закомментирована.

    Почему это сделано

    Я как не ломал голову, так и не смог понять, почему строчка закоментирована и как она может вызывать ошибку «rule override already configured rule».

    Ведь это вроде как к летскрупт относится, а строчки те, что приведены ниже, для защиты сайта, они подключаются с файла, что располагается в корне самого сайта (создаётся iThemes Security).
    И если строку раскомментировать, что отвечает за летскрупт, то следующую за ней надо закомментировать? Т.к. по идее именно она отвечает за «подхват» настроек из файла, что создаётся плагином iThemes Security.

    Так может эти строки, что усиливают безопасность, сразу вписать в шаблон или, к примеру, в «nginx.*.com.conf_custom» а не в «/home/имяпользователя/conf/webnginx.имядомена.conf:» который вроде как судя из статьи нельзя редактировать вручную...

    Жёсткое недопонимание вызвал этот момент.

    Ответить

    • Дмитрий Глашков

      Не знаю почему, но если ссылаться сразу на именно эти два конфига, nginx не стартует, ругаясь упомянутой выше ошибкой. Возможно, это поправят в будущем, поэтому обратил внимание читателей на этот факт.
      Перенести содержимое файла nginx.conf в «nginx.*.com.conf_custom» нельзя, потому что конфиг может временами обновляться. Например, у меня туда пишут правила плагины iThemes Security и W3 Total Cache. Поэтому можно периодически «дёргать» nginx командой nginx -s reload, чтобы подхватился новый конфиг, но лично я просто рестартую сервер из-за глюка одной софтины, не связанной с сайтами вообще.

      Ответить

  3. Сергей

    Здравствуйте, статья отличная Дмитрий. Есть правда пару вопросов:
    Все сделал «Шаблоны настроек Nginx», не много подправил:
    у вас было include %home%/%user%/conf/web/nginx.%domain%.conf*;
    у меня стало include %home%/%admin%/conf/web/%domain%.nginx.conf*;
    только с окончанием _letsencrypt уже такие же как у вас nginx.%domain%.conf_letsencrypt и snginx.%domain%.conf_letsencrypt (странно как то почему так). Их я не трогал,т.к. понял, что к ним ваши шаблоны тоже будут обрашаться? Так вроде все работает, я подключал https уже на работаюши 2 сайта c http и один из них на вордпрессе и теперь подключая Шаблон Web NGINX-force-https-wp в Veste происходит редирек на https все отлично, но при попытке зайти на админку вордпресса меня так же перебрасывает сразу на главную страницу сайта на https. Возможно это как то исправить правильно?

    Ответить

    • Дмитрий Глашков

      Имена файлов конфигураций «придумывает» панель управления, так что да, что-то могло поменяться.
      Конфиги *.conf_letsencrypt используются самой панелью при генерации сертификата Let’s Encrypt, к шаблонам отношения не имеют.
      По поводу редиректа из админки: ничего связанного с этим в моём или другом шаблоне быть не может. Проверьте логи доступа и ошибок сайта в момент редиректа. Скорее всего сбоит какой-то плагин WP.

      Ответить

Написать комментарий

Правила:
  • 1. Пожалуйста, будьте вежливы. Мат и оскорбления запрещены.
  • 2. Обсуждать нелицензионные версии софта нельзя.
  • 3. Комментарии с ссылками видны только после проверки модератором.

Тема Rowling от Anders Norén. Копирование материалов сайта разрешается только с указанием автора и активной ссылкой на источник.