Install vestacp on ubuntu 18.04

Базовые рекомендации по настройке своего хостинга

Потихоньку заканчиваю статью по настройке своего хостинга. Все основное я уже описал. Перечислю отдельно некоторые важные моменты.

1. Закрывайте с помощью firewall все не публичные доступы — ssh, панель управления proxmox, phpmyadmin и т.д. Я долгое время не делал этого, так как боялся не получить доступ в экстренной ситуации, когда я не смогу зайти через доверенный ip адрес. На практике это не было никогда проблемой. Обычно разрешаю к подключению свой статический ip адрес и 2 vpn сервера тоже со статичными внешними адресами.
2. Настраивайте мониторинг всех критичных вещей — состояние рейда, актуальность бэкапов, подключения по ssh к  серверам и т.д. Не делайте много уведомлений — только реально важные вещи. Если будет спам от мониторинга, толку от него становится мало. Делайте повторяющиеся уведомления для некритичных событий, которые часто откладываешь и забываешь исправить.
3. Если занимаетесь работами по ускорению работы сайтов, можно в отдельной виртуальной машине настроить локальную версию сервиса webpagetest для объективной оценки скорости сайта без внешних сетевых задержек.
4. Когда обновляете систему на виртуальной машине, сделайте ее snapshot. После установки, если все в порядке, не забудьте его удалить. Это простое правило может очень сильно выручить в случае нештатной ситуации. Кстати, обновления я всегда делаю вручную, не через ansible или какие-то еще средства автоматизации. Если нет полного дублирования функционала с автоматическим переключением на работающий сервис, предпочитаю вручную контролировать установку обновлений. К сожалению, не такая уж и редкость, когда обновление что-то ломает. Пример — elk stack или bitrixenv. Если обновление прошло без ошибок — это удача. Обычно что-то ломается.

Публикация баз 1С на веб сервере

Идем на виртуалку с windows и работаем там с 1С. Кстати, если хотите обойтись вообще без windows, то есть возможность настроить публикацию баз 1С на linux на примере Centos.

Для начала устанавливаем технологическую платформу и не забываем выбрать Модули расширения веб-сервера.

Создаем там необходимую вам базу данных. Я покажу на примере публикации типовой базы Бухгалтерия 3.0. При первом запуске необходимо будет установить на этот компьютер софтовые лицензии. Они будут использоваться при доступе к базам через браузер.

Установка и настройка Apache 2.4 в Windows

Теперь устанавливаем apache 2.4. С ним опубликовать базы 1С проще и быстрее, чем с iis. Качаем apache отсюда — https://www.apachelounge.com/download/

Если у вас не установлен Visual C++ Redistributable for Visual Studio 2015-2019, то скачайте дистрибутивы там же. Бинарники apache скачали, теперь распакуем их в папку C:/apache24/. Затем идем в конфигурационный файл apache C:\Apache24\conf\httpd.conf, открываем его блокнотом и изменяем там несколько параметров:

ServerName localhost:80
ErrorLog "|C:/apache24/bin/rotatelogs.exe -l C:/apache24/logs/errorlog.%Y-%m-%d.log 2592000"

Последняя строка это автоматическая ротация логов. Рекомендую ее сразу настроить, а не откладывать на потом. Если у вас по какой-то причине нет возможности использовать стандартный порт 80, потому что он занят кем-то другим, то можно использовать любой другой, например 81. Я всегда так и делал раньше. Но с недавних пор это стало приводить к ошибке, так как после публикации баз 1c через reverse proxy с https, стали вылезать ссылки вида https://1c.server.ru:81. Подобные ссылки невозможно открыть. Это приводит к ошибкам в работе некоторых разделов базы, где эти ссылки вылезают. Подробнее этот момент я рассмотрю ниже, в разделе с возможными ошибками.

Если вы настраиваете apache на Windows Server, то скорее всего 80-й порт у вас будет занимать Служба веб-публикаций (World Wide Web Publushing Service) или W3SVC. Ее можно остановить и отключить.

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

netstat -ao

Дальше через диспетчер задач смотрите, какой процесс имеет указанный pid. В моем случае это apache. Если это какой-то системный процесс, у него будет pid 4.

Итак, конфиг apache отредактировали, порт 80 указали. Теперь установим apache 2.4 как службу windows

Для этого открываем командную строку от администратора (это важно), переходим в каталог C:\Apache24\bin и выполняем:

httpd.exe -k install

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

Errors reported here must be corrected before the service can be started.
AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using fe80::955f:6a46:c404:c1f7. Set the 'ServerName' directive globally to suppress this message.

Переходим в оснастку windows Службы и запускаем Apache2.4.

Убедимся, что веб сервер нормально работает. Для этого в браузере достаточно открыть страницу http://localhost.

Вы должны увидеть сообщение It works! Если видите, то все в порядке.

Дальше выполняем непосредственно публикацию базы 1С через web сервер apache. Открываем базу через Конфигуратор, выбираем Администрирование -> Публикация на веб-сервере. В качестве каталога можно указать тот же, где лежит сам файл с базой.

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

После этого можно зайти в браузере по адресу http://localhost/buh3 и увидеть локальную файловую базу, которую мы только что опубликовали.

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

Использование ssl сертификата letsencrypt

Сейчас повсеместно распространены ssl сертификаты для сайта. Начинать новый проект имеет смысл сразу на https. Панель управления vesta cp предоставляет возможность в автоматическом режиме получать бесплатные сертификаты от Let’s Encrypt.

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

Если у вас домен третьего уровня, как у меня http://vesta.zeroxzed.ru, уберите в свойствах сайта алиас www.vesta.zeroxzed.ru, так как его не существует. Если же у вас домен второго уровня, то алиас с www можно оставить.

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

Настройка редиректа http на https

После установки сертификата, сайт стал доступен по обоим адресам — с http и https. Но нам нужно, чтобы сайт всегда открывался по https. К сожалению, по-умолчанию, в vestacp нет автоматической переадресации http на https. Нам придется ее настроить самостоятельно.

В инструкциях на сайте разработчиков есть руководство на тему того, как сделать принудительную переадресацию http на https — . Предлагается установить отдельный шаблон для nginx и использовать его. Но тогда все остальные шаблоны, созданные под cms не будут работать. То есть получится просто универсальный шаблон с переадресацией.

Я решил поступить проще и просто добавить пару строк в конфиг nginx. Для этого заходим на сервер по ssh от пользователя root или администратора панели управления. Открываем конфигурационный файл nginx пользователя, которому принадлежит сайт. В моем случае адрес такой — /home/user1/conf/web/nginx.conf. Находим там такую строку:

server_name vesta.zeroxzed.ru ;

Перед ней добавляем новую строку со следующим условием:

if ($scheme = http) { return 301 https://vesta.zeroxzed.ru$request_uri; }

Сохраняем файл и перезапускаем nginx, выполнив команду в консоли:

# service nginx restart

Теперь можно проверять переадресацию. При заходе по адресу http, вас должно автоматически перенаправлять на https.

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

Как выбрать панель управления хостингом?

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

Мало выбрать хороший хостинг, у него должна быть и удобная панель управления. Ниже разберем характеристики «хорошей» ПУ. Ориентируясь на них, вам будет проще понять, какой должна быть панель управления. А значит, будет проще выбрать что-то подходящее для себя, не имея значительного опыта работы с подобными инструментами прежде.

Понятный интерфейс

Если вы пообщаетесь с опытными вебмастерами, опробовавшими с десяток-другой хостингов, и спросите, что их больше всего раздражало, то от львиной доли респондентов вы услышите что-то в духе «панель управления такая, что черт ногу сломит».

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

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

Хорошая поддержка

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

Ключевое правило при оценке отдела технической поддержки таково – администрация хостинга не должна сутками игнорировать пользователя. Нужен быстрый ответ с готовым решением, а не автоматическая отписка с бесконечным временем ожидания. Если специалисты окажутся слишком медленными или менее компетентными, чем заказчик, то никакое удобство не спасет выбранный хостинг.

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

Богатый набор встроенных функций

ПУ нужна, чтобы управлять сервером. А чтобы им управлять нужны: 

• Механизмы для создания, удаления и изменения доменов.

• Интерфейс для управления файлами, хранящимися на сервере.

• Система контроля пользователей, подключившихся и пытающихся подключиться к ПУ.

• Автоматизация часто выполняемых задач.

• Автообновление CMS, MySQL, PHP и т.п. 

  

  

  

  

  

  

  

  

  

  

• Удобный интерфейс для создания и удаления баз данных и управления ими же.

• Функция сбора статистики и подробный журнал событий, происходящих на серверах.

Стабильность и надежность

Важные параметры для любого бизнеса и IT-структуры. Некачественный код в любом сегменте сервера может привести к заметным издержкам

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

Даже временно недоступная ПУ нередко становится причиной затяжных проблем с администрируемым ресурсом в целом. Иногда они возникают из-за некорректной настройки, но зачастую причина кроется в разработчиках программного обеспечения. В связи с этим возникает еще одна важная потребность для панели управления – грамотная команда разработчиков, оперативно устраняющая баги в своем детище. 

Эта же оперативность должна распространяться на выпуск патчей безопасности. Уязвимости в программном обеспечении надо устранять сразу же после обнаружения.

Шаг 2. Поднимаем MySQL

Теперь следует использовать наш готовый шаблон для создания всех необходимых серверов из связки LAMP. Напомню, что нам нужны будут отдельные серверы для nginx, выступающего в роли реверс-прокси, для Apache/PHP, MySQL и memcached, если таковой необходим. Начнем с настройки Apache/PHP. Чтобы создать новую ВМ на базе уже существующей, используем команду virt-clone:

Так мы получим новую ВМ, аналогичную уже существующей. Теперь наша задача — запустить эту машину, зайти на нее с помощью все того же virt-viewer, а дальше — установить и запустить на ней связку Apache/PHP. Запускаем и входим:

Вторую команду следует выполнять опять же с удаленной машины, имеющей графический интерфейс. Первое, что делаем, войдя на машину, — это изменяем ее IP-адрес, который достался в наследство от шаблонной ВМ:

Теперь устанавливаем и настраиваем MySQL:

Также сразу добавляем в файл необходимые строки конфигурации (обсуждение того, какие именно, выходит за рамки данной статьи) и перезапускаем сервер:

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

Чтобы настройки вступили в силу после перезагрузки, эти строки следует добавить в /etc/rc.local (без sudo, естественно).

Перед использованием libvirt следует проверить возможности виртуализации машины с помощью команды virsh capabilities

Хранение логов в ELK Stack

Я складываю все логи в elasticsearch. У меня есть статья про установку и настройку ELK Stack. Недавно я обновил инструкцию по установке, но скрины оставил старые. Очень хлопотно их заменять. Сам процесс установки отражен правильно, так как я регулярно пользуюсь своей статьей. У меня есть несколько примеров того, как можно анализировать логи различных сервисов.

В контексте данной статьи по настройке приватного хостинга нас будет интересовать сбор web логов и их анализ:

• Dashboard для логов Nginx в Kibana+Elasticsearch
• Мониторинг производительности бэкенда с помощью ELK Stack

Статьи немного устарели в том плане, что в процессе эксплуатации мои дашборды изменились, но принцип тот же. Главное его понять, а дальше уже не будет проблем делать так, как удобно лично вам. Например, я не настраиваю GEO карты. В реальности они мне не нужны. Так, для красоты только. Ниже пример моего актуального дашборда для этого сайта.

По дашборду я сразу получаю актуальную информацию о состоянии сайта — информация о средней скорости ответа на php запросы и карта распределения ответов по шкале. Почти все запросы укладываются в интервалы до 300 мс, что считаю хорошим результатом. Напоминаю, что это информация только о php запросах. На сайте настроено кэширование, так что большинство страниц уходят к посетителю значительно быстрее напрямую через nginx, минуя обработчик php.

Тут же можно сделать выборку по медленным запросам, по запросам с определенных ip адресов, посмотреть запросы с различными кодами ошибок и т. д. В общем, без такого дашборда я ощущаю себя слепым. Я не понимаю, как понять, что с сайтом все в порядке, или наоборот узнать, какие у него проблемы, если у тебя нет под рукой подобной информации. Сайт может начать сыпать пятисотыми ошибками, а тебе надо как-то вручную грепать access log и пытаться понять, проблема единичная или масштабная. А тут все под рукой.

Я так привык в ELK, что на сервера почти не хожу. Все логи собираю в нем (обязательно системные) и там же просматриваю. Плюс к этому мониторинг и управление через ansible, но об этом позже. Ходить на сервера по ssh практически нет необходимости.

Такой подход очень хорошо масштабируется, поэтому я его и использую, хотя на моих масштабах это и не так актуально, но тем не менее, хочется все делать правильно с заделом на будущее. У меня был проект, который начался с одного сервера и нескольких докер контейнеров, а закончился примерно сотней виртуалок. Я очень пожалел, что с самого начала не начал автоматизировать процессы. Просто не был готов к этому. Не было опыта и понимания. Все росло постепенно и каждый раз вручную сделать было быстрее. Но в какой-то момент я стал просто зашиваться. Повезло, что проект в итоге усох, но не по моей вине

На фронте у меня логи всех сайтов складываются в одну директорию /var/log/nginx и оттуда единым шаблоном уходят в filebeat, а с него в logstash и далее в elasticsearch в один общий индекс, который бьется по дням. Раньше я каждый сайт отправлял в отдельный индекс, но со временем понял, что это не удобно. Так приходится для каждого индекса создавать свои визуализации и дашборды. Когда сайтов много это хлопотно, хотя и можно автоматизировать, но большого смысла нет на моих масштабах.

Сейчас я собираю все в один индекс, делаю единый dashboard и в нем уже с помощью фильтров просматриваю данные по разным сайтам. Я вывел в лог nginx информацию об имени виртуального домена. Это удобно и быстро настраивается. Для каждого нового сайта не надо вообще ничего делать. Filebeat автоматом забирает его логи. С помощью фильтра в Kibana просматривается информация в логах.

Очень хороший хостинг сайтов

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

Обычно, когда встает задача поднять среднестатистический веб-сервер, администратор выбирает одну достаточно производительную виртуальную или физическую машину, которая способна справиться с ожидаемой нагрузкой, и поднимает на ней стек LAMP, включающий в себя Apache, PHP, MySQL, а также, возможно, memcached, nginx и реверс-прокси. Однако это далеко не самый эффективный и безопасный сценарий, лучшим решением будет разнести все компоненты стека по разным виртуальным машинам.

Frontend сервер nginx

В данном случае не обязательно использовать именно Nginx. В некоторых ситуациях более актуальным будет взять HAProxy. Но в общем случае подойдет Nginx. На frontend сервер будут поступать все внешние http запросы. На него будут проброшены порты 80 и 443. Расскажу, для чего использовать отдельный frontend сервер. Ведь можно обойтись и без него.

1. Удобство эксплуатации и обновления. К примеру, я хочу попробовать какую-то новую настройку — изменение ядра, модуля nginx и т.д. Я делаю копию frontend, настраиваю на нем все, что нужно и переключаю на него трафик. Если все в порядке, то оставляю в работе, либо переношу настройки на основной сервер. Если возникают какие-то проблемы, я просто переключаю проброс порта на старый сервер и все сразу начинает работать как прежде. В общем случае, frontend сервер очень маленький (20-30 гб под систему и логи).
2. На frontend удобно работать с внешними запросами — контролировать, обрабатывать, блокировать, предотвращая доступ к бэкенду с данными. Например, можно настроить ipset и блокировать отдельные страны. Можно выстроить простейшую защиту от ddos. Можно настроить отдельный модуль ModSecurity для Nginx. Когда у вас frontend отдельно, вам проще настраивать и обновлять компоненты, не боясь нарушить работу сайтов.
3. Frontend сервер аккумулирует все логи с внешних запросов и передает в ELK. Далее я покажу, как их удобно в автоматическом режиме сразу все передавать на хранение, а потом удобно анализировать.
4. В общем случае с отдельным frontend сервером безопаснее. Все внешние запросы приходят к нему. Многие зловреды (как и легальные компоненты и плагины) не понимают, как работать на бэкенде, который стоит за frontend. Это как плюс так и минус в некоторых случаях, так как усложняется эксплуатация. Особенно хлопотно с битриксом, так как у него много сервисов и проверок, которые напрямую стучатся по внешнему ip домена и не понимают, что делать, когда попадают на фронтенд. Но это все решаемо.

На frontend настраиваются бесплатные сертификаты от Let’s Encrypt. Так как весь трафик от фронта до бэка крутится в рамках одного гипервизора, смысла передавать его в шифрованном виде нет. Так что на backend он идет по http.

С frontend я отправляю в ELK логи запросов только к php скриптам. Именно они представляют для меня полезную информацию, так как позволяют оценить скорость работы сайта. Информация от отдачи статики лично мне не нужна. В общем случае, я ее не собираю, а включаю отдельно по мере необходимости. Это позволяет не раздувать лог файлы. Чем меньше их объем, тем удобнее и быстрее с ними работать.

Виды хостингов

Виртуальный хостинг

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

Этот тип услуг самый распространённый и справляется с задачами большинства пользователей. Его мощностей достаточно для обслуживания сайтов с посещаемостью до 3 000 посетителей в сутки.

Плюсы:

• Низкая цена;
• Простота управления, не требуется ничего настраивать самостоятельно;
• Домены и поддомены — неограниченно;
• Сложные для пользователя задачи решает служба поддержки.

Минусы:

• Не подходит для тяжёлых порталов с большой посещаемостью;
• Большая нагрузка соседних сайтов может снизить скорость загрузки.

VPS / VDS — Выделенный виртуальный хостинг

Virtual Private Server. Это изолированный от соседей выделенный виртуальный сервер, подходит для порталов с посещаемостью до 10 000 человек в сутки. Среднее звено между общим и выделенным сервером.

Также используется для других целей кроме размещения сайтов. К примеру: Размещение торгового терминала, на котором установлен робот для круглосуточной торговли на бирже, различные программы.

Плюсы:

• Возможность установки требуемого специфического ПО (программного обеспечения);
• Индивидуальные настройки;
• Соседние сайты не влияют на работу;
• Самостоятельное администрирование.

Минусы:

• Цена выше чем в первом варианте;
• За администрирование придётся доплачивать, если этого не делать самому.

Примерные требования к ресурсам в зависимости от посещаемости.

Выделенный сервер

Плюсы:

• Конфигурация собирается по запросу клиента;
• Высокая степень безопасности;
• Личное администрирование.

Минусы:

• Высокая цена;
• Требуется специалист для настройки и запуска системы.

Облачный хостинг

Более современная версия VPS c применением облачной технологии, которая в нужное время может добавить мощности за счёт сети других серверов. Для сайтов с посещаемостью более 10 000 посетителей в сутки. особенность в том, что у него почасовая оплата и производится от фактической нагрузки.

Плюсы:

• Высокая надёжность;
• Дешевле выделенного сервера при схожих характеристиках;
• Возможность экономить при низкой посещаемости и нагрузке.

Минусы:

• Невозможно предварительно сделать расчёт стоимости;
• Ограниченные права для администрирования.

Облачный сервер предоставляют не все компании, одна из таких, кто имеет этот вид хостинга REG.ru — один из крупнейших регистраторов доменов.

Version 0.9.8-17

• System Config Editor
• Let’s Encrypt SSL GUI
• User notifcation panel
• Google Nearline expiremental backup support
• Ubuntu 16.04 with php7.0 support
• Georgian language support
• i18n updates
• Filemanager improvements
• IMAP/SMTP JS helpers
• 55 bugs closed / 73 pull requests merged
• Language files update thanks to
  Clark Chen,
  Didier Roy,
  Flatta,
  Selim Can CABA,
  Nguyen Ngoc Phuong
• Thanks to
  Tjebbe Lievens,
  n1trux,
  Orwah Issa,
  SysVoid,
  vestingpanel,
  drsdre,
  martijnded,
  Rune Laenen,
  Azuya,
  olshek,
  Martin Raiola,
  rumi55,
  Flatta,
  Roman Florea,
  Roman Sadoyan,
  Maks Skamasle,
  Nikolay Didenko,
  dpeca,
  LionSec
  and all our contributors

Released on Friday Nov 25, 2016

Состояние веб-сервера

Затем нужно убедиться, что веб-сервер запущен.

Есть много способов узнать, запущен ли он. Один из общих методов – команда netstat.

Она покажет вам все процессы, которые используют порты сервера. Затем можно использовать grep, чтобы найти имя требуемого процесса.

Примечание: Вместо apache2 укажите имя искомого процесса веб-сервера.

Если вы видите такую строку, как в примере выше, это значит, что процесс запущен и работает. Если вы не получили никакого вывода, значит, вы запросили неправильный процесс или ваш веб-сервер не запущен.

В таком случае нужно запустить его.

Чтобы запустить Apache2 в Ubuntu, введите:

В CentOS для этого нужно ввести:

Состояние веб-сервера можно снова проверить с помощью netstat.

Не загружаются данные из внешних источников на сервере

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

Еще одна частая проблема — сайт обращается сам к себе. Например, на сайте с условным именем TEST.RU может встречаться код, при помощи которого разработчик хочет подключить еще один файл к скрипту на языке PHP:

require_once(“https://test.ru/somefile.txt”).

Таких обращений следует избегать, так как они выполняются дольше, чем считывание файла локально с диска. 

Диагностировать подобные проблемы через консоль браузера не получится. Потребуется подключение к хостингу по SSH и диагностика с помощью netstat — утилиты, которая собирает и выводит состояния сетевых соединений. Без специальных навыков это будет довольно сложно сделать, лучше пригласить веб-мастера или обратиться в поддержку хостинга. 

Обновление phpmyadmin

Для начала напомню, как в vestacp зайти в phpmyadmin. Я не сразу нашел соответствующую ссылку. Она в разделе DB.

Конфигурационный файл находится на сервере по адресу /etc/phpmyadmin/config.inc.php. Vesta использует в своей работе обычную версию phpmyadmin, которую можно установить из подключенных репозиториев в системе.

Таким образом, для обновления phpmyadmin в vestacp достаточно воспользоваться стандартным пакетным менеджером в системе (apt, yum и т.д.) и выполнить соответствующую команду по обновлению системного пакета.

Если по какой-то причине не хочется использовать репозиторий, можно просто положить свежие исходники в соответствующий каталог — /usr/share/phpMyAdmin.

Проблемы со скриптами и базой данных

Оптимизация скриптов. На их выполнение должно уходить минимум оперативной памяти и времени. Вот несколько советов: 

• Кешируйте данные, которые редко обновляются. Если для генерации страницы нужно выполнить запрос к БД, данные которой не обновляются каждые несколько минут, имеет смысл сохранять результаты запроса в файле. Если файл небольшой, получить готовый результат из файла проще, чем обратиться к БД. Можно кешировать результаты генерации HTML-кода, как описано выше.
• Используйте актуальную версию PHP. Переход на новую версию PHP почти всегда повышает производительность сайта. К тому же с новым релизом закрываются уязвимости и появляются новые возможности, удобные для разработчиков. Но учтите, что смена версии PHP — это сложно, долго и часто требует доработки кода сайта. Но замена версии PHP оправдана, если другие способы повышения производительности не сработали. 

Оптимизация запросов к БД. Главные требования:

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

Чем быстрее сервер базы данных выполняет запросы, тем быстрее он получит необходимые данные, сформирует ответ клиенту и освободит память.

Все эти данные для каждого из запросов можно получить с помощью команды EXPLAIN в соответствии с документацией по MySQL.

Иногда медленные запросы появляются случайно, например, как результат мгновенной нагрузки на сервере. Но если ситуация повторяется системно, значит, проблема в неэффективных запросах. Для сайтов на WordPress проверить наличие медленных запросов к базе можно с помощью плагинов Query Monitor или Debug Bar. 

Очистка базы от неактуальных данных. Иногда сайт медленно работает из-за того, что БД хранит слишком много лишней информации. Например, неактивные учетные записи пользователей, созданные ботами и спам-комментарии.

Мы советуем периодически проверять базу данных, считать число записей в таблицах и удалять лишние и неактуальные. Для сайтов на WordPress для таких задач подойдет плагин WP-Sweep. 

Проанализировать код и запросы к базе данных, выявить и исправить ошибки может только профессиональный разработчик сайта.

Общая настройка vesta cp

Сразу после установки можно выполнить несколько базовых настроек.

Включаем русский язык

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

Добавляем ip адрес

У меня на сервере 2 внешних ip адреса. Во время установки панели, был выбран только один. Добавлю сейчас второй. Для этого в верхнем меню выбираем IP, нажимаем на зеленый плюс и вводим настройки дополнительного ip.

Теперь при добавлении сайта можно будет выбирать, на каком ip адресе он будет работать.

Отключаем автообновления

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

Идем в раздел обновление и жмем «Выключить автообновление»

Увеличение времени бана

В vestacp используется популярный инструмент fail2ban для блокировки тех, кто пытается подобрать логины с паролями для доступа к различным сервисам. Время бана используется по-умолчанию — 600 секунд, т.е. 10 минут. Тот, кто 5 раз ввел неверные регистрационные данные для доступа к ssh, панели управления vesta или другим сервисам, получает бан на уровне фаервола на 10 минут.

По ssh боты будут постоянно долбиться, поэтому их можно банить минимум на час. Для этого нужно открыть конфиг fail2ban и добавить туда новое значение. Идем в раздел Сервер, находим там в самом низу fail2ban и жмем configure.

В секцию  добавляем новый параметр:

bantime = 3600

Сохраняем изменения. При желании, можете добавить этот же параметр для других служб. Тут же можно увеличить количество неправильных попыток ввода пароля. В принципе, можно для всех служб увеличить кол-во неправильных попыток до 15 и сделать бан сразу на сутки. Вряд ли вменяемый человек будет ошибаться 15 раз подряд. Но если уж это случилось, то у него явно какие-то проблемы и постоянными попытками ввода учетки их уже не решить.

Подготовка

Поскольку эта статья посвящена установке и настройке уже существующего VPS/выделенного сервера, у вас имеется сервер по умолчанию. Не называя конкретных поставщиков, мой личный выбор — ovh.ie, но вы можете свободно выбирать любого. Единственное, что я рекомендую, это убедиться, что поставщик имеет сильную глобальную инфраструктуру, то есть присутствует как минимум на пяти континентах (извините, Антарктида). Чем более она развита, тем больше выгод вы будете иметь из его ресурсов и цен.

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

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

Перед покупкой сервера также следует подумать о доставке контента CDN (content delivery network). Если на вашем веб-сайте много файлов, которые вы будете предоставлять на весь мир, CDN требуется для повышения эффективности веб-сайта. Вы всегда можете получить отдельное решение CDN, так что это не должно влиять на выбор сервера.