• Связаться
  • Поблагодарить
  • Главная
  • Блог
  • Софт
  • Администрирование
  • Создание сайтов
  • SEO
No Result
View All Result
  • Главная
  • Блог
  • Софт
  • Администрирование
  • Создание сайтов
  • SEO
No Result
View All Result
Glashkoff.com
Home Администрирование

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

Дмитрий Глашков by Дмитрий Глашков
22 июня 2017 - Updated On 14 марта 2020
in Администрирование
0 0
20
VestaCP и WordPress: несколько советов по настройке
6
VIEWS
Share on FacebookShare on Twitter

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

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

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

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

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

Шаблоны настроек 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, можно увидеть строчки:

[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, раздел «Сервер».

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

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

[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-архив:

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

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

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

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

Как только кто-нибудь посетит ваш сайт, плагин 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 минут, этого достаточно):

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

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

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

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

Tags: LinuxUbuntuVPSWordPress
ShareTweetShare
Previous Post

Почему флешки перестают работать и что с этим делать

Next Post

Программы для записи, трансляции игр и создания видеоуроков

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

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

Автор блога glashkoff.com

Related Posts

Как выбрать VPS хостинг — несколько советов

Как выбрать VPS хостинг — несколько советов

16 марта 2022 - Updated On 22 января 2023
WooCommerce: недостатки, о которых следует знать

WooCommerce: недостатки, о которых следует знать

8 января 2022 - Updated On 22 января 2023
Недостатки WordPress и как их обойти

Недостатки WordPress и как их обойти

22 августа 2019 - Updated On 25 января 2023
Как настроить Shadowsocks для защиты сети

Как настроить Shadowsocks для защиты сети

19 апреля 2019 - Updated On 25 января 2023
Load More

Comments 20

  1. Виктор says:
    5 лет ago

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

    Ответить

    • Дмитрий Глашков says:
      5 лет ago

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

      Ответить

  2. Кирилл says:
    5 лет ago

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

    Обратите внимание – строчка «#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:» который вроде как судя из статьи нельзя редактировать вручную…

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

    Ответить

    • Дмитрий Глашков says:
      5 лет ago

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

      Ответить

    • KRV says:
      3 года ago

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

      Ответить

      • Дмитрий Глашков says:
        3 года ago

        Вам не моё замечание подпортило статью, а коммент, где смешалось всё — и Let’s Encrypt, и строчки конфига, и iThemes Security. Так бывает, что в nginx.conf в каталоге сайта плагины прописывают правила, дублирующие правила из файла, который я «отключил» комментированием строки. Из-за дублей появляется ошибка «rule override already configured rule» при рестарте службы Nginx, сайты становятся недоступны. Проще написать в конфиге закомментированную строку (кому надо — раскомментирует), чем объяснять всем заглянувшим, что не мой конфиг виноват, а дублирование правил в двух местах.

        Ответить

  3. Сергей says:
    5 лет ago

    Здравствуйте, статья отличная Дмитрий. Есть правда пару вопросов:
    Все сделал «Шаблоны настроек 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. Возможно это как то исправить правильно?

    Ответить

    • Дмитрий Глашков says:
      5 лет ago

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

      Ответить

  4. Виктор says:
    5 лет ago

    Дмитрий, прочитал вашу статью и попробовал внедрить ваши шаблоны на своем ВПС. И никак не могу заставить работать force-https-wp. При включении шаблона force-https-wp в Весте сайт выдает: «Сайт domain.com выполнил переадресацию слишком много раз.», а как только возвращаюсь на шаблон WordPress2 — он опять работает. Что посоветуете?

    Ответить

    • Дмитрий Глашков says:
      5 лет ago

      Я перешёл на другую панель управления и оперативно решить этот вопрос не могу. Пользуйтесь WordPress2, если с ним всё вас устраивает.

      Ответить

  5. Александр says:
    4 года ago

    nginx: [emerg] invalid number of arguments in «fastcgi_pass» directive in /home/admin/conf/web/site.ru.nginx.ssl.conf:26
    nginx: configuration file /etc/nginx/nginx.conf test failed

    Получил вот такую ошибку при попытке рестарта nginx
    ——
    И если не секрет, на какую панель вы поменяли весту ?

    Ответить

    • Дмитрий Глашков says:
      4 года ago

      Спасибо за комментарий. Добавлю в статью предупреждение, что конфиг, возможно, уже не подходит, потому что разработчики что-то поменяли. А перешёл я на Webinoly.

      Ответить

      • Александр says:
        4 года ago

        Webinoly хорош, но пугает отсутствие поддержки CentOS, а он как то ближе

        Ответить

      • Дмитрий Глашков says:
        4 года ago

        Тогда обратите внимание на Centmin Mod. У этого средства богатый список возможностей, вдруг придётся по душе.

        Ответить

      • ASG says:
        3 года ago

        Какую панель теперь используете?

        Ответить

  6. KRV says:
    3 года ago

    v-update-web-templates — скидают полностью все шаблоны по умолчанию. Если отредактировать, например, wordpress2 и сохранить, затем применить данную комманду — настройки скинуться к начальным.

    Ответить

  7. KRV says:
    3 года ago

    Спасибо за ответ. В итоге я выбрал wordpress2 и просто добавил к шаблону поддержку http2. Все работает ок.

    Ответить

  8. ASG says:
    3 года ago

    Не могу решить проблему. Установлены два диска. На один установлена Vesta + Ngix без Apache.
    Второй диск (более медленный) примонтирован в папку /backup/ и использовался для бэкапов. Необходимо, чтобы на нем работал сайт под управлением весты.
    Веста создает все сайты в одной папке /home/admin/web
    Как сделать так, чтобы файлы со второго диска из папки /backup/web/second.ru/public_html без физического дублирования использовались в весте на сайте /home/admin/web/primary.ru/public_html
    Примонтировать диск повторно в папку /home/admin/web/primary.ru/public_html не выход из положения, поскольку надо использовать не весь диск, а только папку с него.
    Другими словами, как держать сайт на втором диске и использовать с него файлы из определенной папки для домена в весте?
    Создание нового шаблона и изменения конфига:
    server {
    root %sdocroot%;

    на:
    server {
    root /backup/web/second.ru/public_html;

    эффекта не дало. Ошибка 404.
    Подскажите, может быть кто-то сталкивался? Или может быть еще где-то надо внести изменения?

    Ответить

    • Дмитрий Глашков says:
      3 года ago

      1. Можно примонтировать каталог как каталог, не только диск как каталог (mount —bind).
      2. Ошибка 404 может быть из-за того, что на каталог public_html или находящиеся выше у пользователя, под которым запускается Nginx, нет доступа. Подробнее смотрите в логах Nginx.

      Ответить

      • ASG says:
        3 года ago

        Спасибо большое! Все получилось! Век живи — век учись! Благодарю!

        Ответить

Добавить комментарий Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

I agree to the Terms & Conditions and Privacy Policy.

Темы записей:

Советы Интернет Безопасность Web-разработка WordPress Linux Ubuntu VPS Интернет-сервисы Хостинги...Показать все
  • Пользовательское соглашение
  • GDPR Access Request

© 2012-2023 Дмитрий Глашков

  • Login
  • Главная
  • Блог
  • Софт
  • Администрирование
  • Создание сайтов
  • SEO
No Result
View All Result

© 2012-2023 Дмитрий Глашков

Welcome Back!

Login to your account below

Forgotten Password?

Retrieve your password

Please enter your username or email address to reset your password.

Log In
This website uses cookies. By continuing to use this website you are giving consent to cookies being used. Visit our Privacy and Cookie Policy.

Вставить/изменить ссылку

Введите адрес назначения (URL)

Или сделайте ссылку на существующий материал

    Поисковый запрос не задан. Показаны недавние элементы. Воспользуйтесь поиском или клавишами вверх/вниз, чтобы выбрать элемент.