То, что Роскомнадзор банит без разбора ip-адреса налево и направо это полный идиотизм. Это как если бы рождаемость начали повышать принудительным осеменением всех девушек от 18 до 25 лет. Вызывали бы к доктору в поликлиннику и оплодотворяли. А на все отказы — привод милицией через силу. Но полагаю ни один врач (я очень на это надеюсь) не согласился бы делать такое, остался верен клятве Гиппократа. Так какого лешего «айтишники» готовы утворить (и утворили) аналогичное?

Попал мой дроплет дигиталоушена под раздачу 18 апреля 2018 года. Тогда было забанено более 120 тысяч(!) ip-адресов. Узнал об этом я не сразу, а через полгода примерно. Я пробовал в рамках родной локации дроплета перейти на другой ip-адрес, но они все попадали в пул заблокированных. Перепробовал таким образом более 35 адресов — ни один не был из белого списка.

В итоге я решил сменить локацию. Но для этого требуется заново создать систему и настроить ее. Это нужны знания и время. Я откладывал это до последнего. В итоге для своего проекта на Россию был вынужден вернуться к этому вопросу. И вот вчера засел за работу. Локация Германии не подошла — там тоже айпишники из черного списка. В итоге выбрал США. Создал пару дроплетов — каждый был в белом списке.

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

Итак, 12 февраля 2019 — новый сервак :)

PS добавил на сайт https/2 — теперь быстрее у вас открывается сайт и меньше нагрузка на сервер.

PPS настроил обработку php через php-fpm (вместо cgi). Пришлось помучаться.

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

Как известно, гугл начинает учитывать защищенный протокол (https), как хороший фактор ранжирования. Иными словами, если у вас есть сертификат защищенного соединения, то ваш сайт будет показываться в поиске выше.

Получение сертификата

Сертификат я бесплатно получил на startssl.com. Это достаточно просто. Идете на сайт, регистрируетесь. Подтверждаете домен, скачиваете программу для генерации ключей (под Windows), генерируете секретный ключ (я выбрал 4096 бит и sha512) и загружаете обратно запрос на сертификат. Через минуту вам дают скачать сертификат.

В итоге у вас есть файл секретного ключа site.key и файл сертификата site.crt

Настройка сервера apache

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

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

Для решения этой проблемы я настроил Апач следующим образом. Во-первых в файле конфигурации включаем прослушивание помимо порта 80 еще и порта 443:

Listen 80 
Listen 443

Для вашего сайта, для которого вы получили ключ и сертификат, в файле конфигурации apache вы прописываете:

<VirtualHost *:80>
ServerName secure-site.by
ServerAlias  www.secure-site.by
ServerAdmin admin@localhost
…
</VirtualHost>

<VirtualHost *:443>
UseCanonicalName On
ServerName secure-site.by
ServerAlias  www.secure-site.by
ServerAdmin admin@localhost
SSLEngine on
SSLCertificateFile /etc/configs/apache/secure-site.crt
SSLCertificateKeyFile /etc/configs/apache/secure-site.key
…
</VirtualHost>

Эти настройки позволяют показывать наш сайт по защищенному соединению.

Далее всех остальных сайтов на хостинге (которые у вас без сертификата) обязательно прописываем блоки virtualhost следующего вида:

<VirtualHost *:80>
ServerName site.by
ServerAlias  www.site.by
ServerAdmin admin@localhost
…
</VirtualHost>

<VirtualHost *:443>
UseCanonicalName On
ServerName site.by
ServerAlias  www.site.by
ServerAdmin admin@localhost
RewriteCond %{HTTP_HOST} ^site.by
RewriteRule ^/(.*)$ http://site.by/$1 [L,R=301]
SSLEngine on
SSLCertificateFile /etc/configs/apache/secure-site.crt
SSLCertificateKeyFile /etc/configs/apache/secure-site.key
…
</VirtualHost>

Это позволяет Апачу отдавать правильный сайт как для соединения по http, так и по https. Во втором случае апач принимает соединение на сайт (без поддержки https) и переадресовает на протокол http.

После изменения конфигурационного файла апача его необходимо перезапускать — service apache2 restart

Чтобы вкурить это и настроить потребовалась 6 часов. Вполне возможно, что есть косяки с настройкой, но пока работает :)

На самом деле у дигиталоушен есть один плюс — у вас полноценный сервер, хоть и виртуальный.

К счастью, минут тоже один — вы в полном ответе за судьбу сервера, вам некуда позвонить с вопросом, почему письма не отправляются или сайт не работает.

Делюсь своим опытом.

На простейшем тарифном плане размещено более 10 сайтов. Часть на чистом html, часть на Wordpress, часть на Egea.

Первая проблема. Корневая.

DO позволяет выбрать десяток разных дистрибутивов Linux. Я решил поставить rpm-based. Да еще от RedHat. Поставил CentOS на свою голову. Во-первых не весь софт заточен под отдельные дистрибутивы, во-вторых множество инструкций написано под популярные дистрибутивы.

Мучался два дня и поставил популярную Ubuntu 14.04 LTS x64. И не жалею. Вывод — ставьте популярные решения, они и обновляются чаще и найти помощь по ним легче.

Вторая проблема — не желание платить за cpanel.

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

Проблема с панелью управления сервером в том, что каждая панель использует за основу либо Apache, либо Nginx. Всю жизнь я провел на Апаче, поэтому мне он роднее. Тем более, что Нгинкс все равно только для статики работает и „пробрасывать“ php5-fpm не лучший вариант для большого количества сайтов, который разрабатывались изначально под Апач.

Использовать frontend Nginx, а backend Apache именно в моем случае лишено смысла, т. к. создает бесполезную лишнюю нагрузку на сервер. Поэтому вместо красивой Ajenti V, я поставил аскетичную Sentora.

Третья проблема — падение MySQL сервера.

Каждые 5-8 дней без видимых причин, без нагрузок на сервер. Все советы сводились к нехватке памяти. Переключаться на более дорогой тариф не хотел. Поэтому пришлось создать своп-файл.

Сначала проверьте, не установлен ли у вас своп командой free -m. Если Swap 0, то последовательность команд следующая:

sudo fallocate -l 4G /swapfile — создали файл на 4 гигабайта
sudo chmod 600 /swapfile — ограничили доступ к свопу только root
sudo mkswap /swapfile — объяснили системе, что это своп.
sudo swapon /swapfile — включили режим использования свопа

Не забудьте отредактировать /etc/fstab, чтобы после перезагрузки система не теряла своп:

/swapfile none swap sw 0 0

После этих манипуляций падение базы данных не происходило. Тьфу-тьфу-тьфу

Четвертая проблема — взлом сайтов.

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

Проблема пятая — администрирование.

Раньше отдельный человек занимался сервером. Теперь это делаю я. В панели DO обновляю версию ядра, а в самой Ubuntu обновляю пакеты, благо это очень легко:

sudo apt-get update
sudo apt-get upgrade

Проблема шестая — это лучшее, что есть на рынке.

Да, он — выше всех похвал. Рекомендую попробовать digitalocean — по ссылке вам дадут бесплатные 10$ (хватит на два месяца).