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

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

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

Примечание №2: приведённые мной шаблоны могут не заработать. Возможно, разработчики что-то поменяли. Переписать конфиги не могу, потому что окончательно и бесповоротно перешёл на Webinoly. 

Примечание №3: смотрите заметку «VestaCP: тёмная сторона панели управления сервером«, чтобы быть в курсе недостатков.

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

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

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

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

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

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

[uix_code language=’plain’]

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

[/uix_code]

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

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

[su_note note_color=»#fff» radius=»0″ class=»vnimanie»]А самое главное — в шаблонах Весты не включен протокол HTTP/2, который ой как нужен сайтам в современном интернете. Протокол HTTP/2 работает только на защищенных по https сайтах и позволит сайту быстрее открываться в браузерах посетителей, так как все картинки, скрипты и стили будут загружаться параллельно.[/su_note]

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

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

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

[uix_code language=’plain’]

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*;
}

[/uix_code]

Это тот минимум, благодаря которому при попытке открытия сайта по протоколу 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. У меня вот такой, подходит для большинства сайтов:

[uix_code language=’plain’]

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*;
}

[/uix_code]

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

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

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

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

[uix_code language=’plain’]

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*;
}

[/uix_code]

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

[uix_code language=’plain’]

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;
}

[/uix_code]

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

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

Обратите внимание — из-за подхвата файлов *.conf строчка «#include %home%/%user%/conf/web/nginx.%domain%.conf*;» закомментирована.

[su_spoiler title=»Почему это сделано» style=»fancy» icon=»chevron»]

Дело в том, что строка ниже закомментированной подключает файлы с правилами nginx, которые могут быть созданы плагинами Вордпресса. Из-за этого иногда возникает ситуация, что в файлах начинают дублироваться правила. Например, nginx будет ругаться ошибкой «rule override already configured rule», если в nginx.conf в каталоге сайта окажутся такие строчки:

[uix_code language=’plain’]

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; }

[/uix_code]

Эти очень полезные правила доступа создаются плагином iThemes Security, когда включена опция защиты файлов.

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

[uix_code language=’plain’]

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; }

[/uix_code]

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

«Забить» на данный нюанс не получится — ошибка «rule override already configured rule» не даёт Nginx запуститься и сайт окажется недоступен.

[/su_spoiler]

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

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

[su_note note_color=»#fff» radius=»0″ class=»vnimanie»]Совет: если вы редактируете шаблон, который уже выбран для какого-то домена, для пересоздания файлов настроек в консоли сервера введите поочередно две команды:

[uix_code language=’plain’]

v-update-web-templates 
service nginx restart

[/uix_code]

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

Починка Cron в WordPress

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

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

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

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

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

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

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

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

[uix_code language=’shell’]

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

[/uix_code]

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

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

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

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