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

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

Есть ли у вас план, мистер Фикс? ... Да у меня целых три плана!

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

• Второй вопрос — выбираем маршрут и пассажиров: нужно определиться, кто едет, в какую очередь, когда.

• Третий вопрос — подготовительный: структуру и будущих пользователей лучше всего завести заранее.

• Четвертый вопрос — тестовая синхронизация, можно сделать на части пользователей. К примеру у меня была история, когда imapsync не синхронизировал вложенные папки, нужно было подбирать параметры.

• Пятый вопрос — синхронизация данных, её можно и нужно в зависимости от объемов корреспонденции проводить не один раз, чтобы не потерять данные.

• Шестой вопрос — переключение почтовых реквизитов у клиента, если вопрос не удалось решить в DNS.

Такой вот не хитрый план.

Я просто оставлю здесь эту памятку для самопроверки по настройке почты:

• 0. Корректная MX запись на ваш почтовый сервер.

• 1. В конфигурации по доменам (/home/login/conf/web/apache2.conf или /home/login/conf/web/httpd.conf — внутри Directory) сделать корректную отправку с обратным адресом (желательно, чтобы этот адрес существовал):

php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f info@domain.ru"

• 2. Корректный PTR для вашего сервера (оно же обратная зона, обычно делается вашим провайдером)

• 3. Корректный SFP (ip в качестве примера)

v=spf1 a mx ip4:192.168.0.1 ~all

• 4. Если не используется IPv6, то разумнее его отключить. Одна строка в exim. (Если используется, то не забыть п.3 и п.2 для IPV6 адресов.)

disable_ipv6 = true

• 5. Использовать корректный хостнейм, который резолвится (отзывается хоть как-нибудь), а также не забыть использовать резолвер для внешних ресурсов. Примеры:
  /etc/hosts

127.0.0.1 localhost.localdomain localhost
192.168.0.1 domain.ru        domain

• /etc/resolv.conf

nameserver 77.88.8.8
nameserver 8.8.8.8
nameserver 77.88.8.1
nameserver 8.8.4.4

====================================

Проверьте, не в спамлистах ли вы:

• https://mxtoolbox.com/blacklists.aspx
• https://www.dnsbl.info

Не люблю неадекватную рекламу и её частоту, стараюсь по возможности избежать, только не всегда удается. Мой любимый тестовый провайдер, где я чаще всего беру для проверок виртуальные серверы, не кисло проспамил в ленте о промокодах в «киберпонедельник». Догадывался я, что дело это гиблое и вранье маркетинговое, но попробовал и, естественно, промокод не сработал. Техподдержка традиционно косит под роботов ответами а-ля: «А в чем собственно проблема» и «Активация возможна только для новых пользователей, которые ранее не активировали другие промокоды». Однако в рекламе об этом не было ни слова — ни в объявлении, ни на самом сайте. Попробовал зайти с другой стороны, мол, раз такое дело — исправьтесь как-то со стороны отдела маркетинга: твиты удалите к примеру, извинитесь публично. Однако за неделю из соответствующего отдела не шелохнулись.

К списку грешков vscale.io добавляется не только недобросовестная реклама, но и изрядная неповоротливость в плане работы над ошибками. Маленькая компания, большая компания — грабли они везде одинаковые.

Перед тем как отдать старый сервер в плане переезда значилось: «не забыть почистить данные на дисках». Редко, но все же случаются оказии, когда клиенту вместо чистого сервера достается бывший в употреблении и не переустановленный экземпляр. На моей памяти была пара таких эпизодов. Не смотря на то, что особой секретности данные вроде бы не представляют, пароли на новом сервере новые, как-то не безопасненько отдавать сервер как есть.

Сначала удалили данные пользователей и самих пользователей. Потому удалили и деинсталлировали базу данных, apache2 / nginx и некоторые другие. Затем удалили конфигурационные файлы и данные. Проверили, что рейд синхронизировался, и на втором диске то же, что и на первом. Для уверенности «dd if=/dev/zero of=/dev/drive bs=4M» на обоих дисках. Более простым вариантом, чтобы слегка потешить паранойю, загрузились с внешнего диска и вновь прошлись dd по обоим дискам. Подозрительность может спать спокойно, враг не пройдет.

Сложно найти что-то менее увлекательное, чем чтение логов по вечерам: ага, без изменений, угу, хорошо и так далее. Самым же интересным является чтение auth.log — в нем указываются попытки входа в систему, чаще всего по ssh. Не смотря на то, что под root не войти, и на то, что логин разрешен только нескольким пользователям да и то с определенных адресов, поток желающих не прекращается. Их даже fail2ban особо не пугает. Даже не знаю, чем объяснить такое внимание. Раньше у меня ssh также был на стандартном порту, но интереса такого не вызывал.

Приходил какой-то странный человек с Linode. На жалобу саппорт вежливо слился, ничего не предпринимая. Какие-то несколько провайдеров мелкошапочных из России. Они мои просьбы игнорировали, как и провайдеры остальных атакующих. В основном лезут китайцы (HANGZHOU SRT TECHNOLOGY CO., LTD и CHINANET-JS), их много и они до сих пор пытаются убедить, что пароль от root у меня MAO. Был, правда, и курьез, пришел самый настоящий японец, судя по всему от токийского провайдера (ASAHI-NET), чем несказанно порадовал. Впрочем, жаловаться после недели или двух стало скучно — толку от писем явно никакого. Провайдеры игнорируют обращения с жалобами на абонентов. Никакой обратной связи не дают. Дело хоть и благородное, но совершенно бесполезное.

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

Настало время посмотреть, как все будет себя вести на новом месте в длительной перспективе. Предварительные результаты воодушевляют. Из-за процессорных мощностей, но самое главное — быстрых SSD, работает все визуально быстрее. Базе данных можно спокойно отдать примерно треть оперативной памяти и не жалеть. Значения в попугаях в виде LA тоже не выходят чаще всего за пределы единички.

За последние пять лет мы с пожитками переезжали раза три-четыре. Сначала жили на виртуальном выделенном сервере (память подводит, возможно, их был два или три), потом на маленьком «атомчике» с одним жестким диском, пока не попали на нормальный сервер в Hetzner. Последние два года обитали там, в тишине и относительном покое. Время не стоит на месте, железо обновилось так же, как и тарифные планы. Решили идти в ногу со временем, обновив оборудование. Вместо SATA-дисков взяли SSD, вместо 8Gb оперативной памяти — 32Gb. Несколько мощнее стал мощнее процессор.

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

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