Отзыв о cloud4box.com

Данный пост — предостережение тем, кто решил приобрести у них какие-либо услуги, и услуги VPS — в частности. Тем, кто перед оплатой решил поискать о них отзывы. Ниже будет аргументированное мнение, почему они являются куском говна:

  1. Нет информации про юрлицо, лицензии и т.д.;
  2. Покупают положительные отзывы. Мне предлагали зачисление на мой баланс месячной стоимости аренды VPS сервера за позитивный пост об их услугах в блоге или соц. сетях. Это сразу насторожило, но сперва не придал этому значения. А зря;
  3. Ужасная поддержка. Телефон не отвечает. Система тикетов — убогая. Для управления учетной записью и серверами, что прикреплены к этой учетной записи — две отдельных панели с разными логинами/паролями. Нет уведомлений об ответах на тикеты — вот сиди и сам проверяй — ответил тебе кто-нибудь, или нет;
  4. Выдают IP адреса, находящиеся в черных списках, спам-листах и т.д. Такое ощущение, что они сами не стесняются заниматься спамом и «чернухой», или их клиенты их же используют в основном именно для этого;
  5. Выделяемые ресурсы не соответствуют заявленным. На сервере крутил только 3proxy крайней версии собранный из исходников. Через сутки сервер просто умирал в прямом смысле этого слова. Только рестарт через панель управления спасал ситуацию, и то — только на сутки. Не верите? Вот ссылка на скриншот. Для эксперимента снёс всё, и поставил чистую ОС. Ресурсы даже на чистой ОС просто утекают куда-то в линейной прогрессии!
  6. Сервер доступен не отовсюду. Cо своего рабочего IP не мог подключиться к серверу! Поддержка говорит «А мы ничего не знаем, проблема не с нашей стороны», хотя проблема ТОЛЬКО с ними;
  7. Разводят на более дорогие тарифы;
  8. Чтоб написать в саппорт — надо ПОКУПАТЬ РАЗРЕШЕНИЯ! ПОКУПАТЬ, КАРЛ (скриншот)!
  9. Деньги не возвращают, даже при обосновании того что они не оказали заказанные услуги в полном объеме;

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

Поднимаем свой, приватный прокси-сервер

your-proxy-wide

Сегодня мы будем поднимать анонимный и действительно шустренький proxy/socks сервер для себя-любимого. Так чтоб настроить его один раз, да и забыть — пускай пыхтит да нам на радость.

Будем считать что ты уже приобрел себе простенький vps, в качестве ОС выбрал Cent OS 7 и подцепился к нему по SSH, наблюдая девственную чистоту. Первым делом тюним SSH:

Подробнее под катом

Дружим rclone с Яндекс.Диском

rclone-yandex-wide

Сегодня мы поговорим об одном интересном, простом в обращении и в какой-то мере уникальном инструменте. Знакомьтесь: rclone. Разработчики описывают его краткой и ёмкой фразой — «rsync для облачных хранилищ».

Основная функция rclone — это синхронизация данных в хранилище и на локальной машине. Утилита несомненна окажется полезной для широкого круга пользователей облачного хранилища. Её можно использовать и для резервного копирования, и в работе со статическими сайтами, и для удобного доступа к файлам на яндекс.диске (да и не только).

Подробнее под катом

Создать зеркало обновлений для Eset Nod32?

nod32mirror-wide

Однажды я уже писал об этом, но с того момента над скриптом было проведено не мало работы. Скажу более — он был переписан чуть менее чем полностью, и как следствие — выяснились некоторые очень «интересные» моменты. Один из них заключается в том, что старая версия скрипта хоть и работала, но совсем не так, как надо.

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

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

А что же теперь? А теперь мне удалось избавиться и от этих проблем, и попутно (с момента публикации этого поста уже произошли какие-то изменения, однозначно) повысить стабильность. Не получилось пока реализовать авто-обновление, но я над этим думаю. Традиционно скрипт умеет сам искать ключи.

Подробнее под катом

Автоматический деплой WordPress темы/плагина с Bitbucket

auto-wp-theme-plugin-deploy-from-bitbucket

Времена, когда приходилось ручками заливать изменения файлов на prod-сервер — стремительно проходят, и на смену им приходят системы контроля версий и автоматизированный деплой. Ведь это чертовски удобно, когда ты один или с командой можешь работать над проектом, обкатывать изменения на локальном/тестовом сервере, и уже протестированный код отправлять на «боевой» сервер простым коммитом или слиянием. Ничего более не запуская, Карл!
Временами так же приходиться работать над проектами, построенными на (пускай и по дизайну очень убогому) WordPress, у которого очень низкий порог вхождения как у разработчиков, так и у конечных заказчиков (с первого раза правильно прочитал «конечных заказчиков»?).
Почему бы не настроить автоматический деплой кода из приватного репозитория на Bitbucket.org (или GitHub — не принципиально, но на нем нет халявных бесплатных репозиториев) на «боевой» сервер под управлением этой CMS?

Давай сперва определимся с некоторыми моментами:

  • В репозитории будет храниться только тема. Хранить в репозитории код самого WP и плагинов с wordpress.org смысла не имеет, так как авто-обновление (надеюсь, включенное и настроенное по умолчанию) делает это совершенно бессмысленным. Можно аналогичным способом деплоить и кастомные плагины;
  • Конфиги для nginx так же в репозиторий не попадают. Да, можно было бы подключать их директивой include /path/to/theme/config/*nginx*.conf, но это и потенциальная возможность править от имени пользователя php конфиги nginx, и необходимость ему же дать право перезапускать его. Нельзя так делать;
  • Использовать мы будем webhooks, а это ещё тот костыль по большому счету, так как не дает гарантии корректного выполнения кода на prod-сервере по причине отсутствия контроля состояния запроса;
  • Синхронизацию БД придется делать любыми другими средствами, если они необходимы. О миграциях и прочих «вкусных» штучках задумываться есть смысл при разработке именно плагина, и реализовывать их придется самостоятельно;
  • Придется разрешить php выполнять функцию exec().

Но не смотря на озвученные выше очевидные минусы — это в дохрена раз удобнее, чем ничего. Работать будем под CentOS 7.

Подробнее под катом

LEMP + CentOS = ❤

lemp-wide

Данный пост скорее заметка для самого себя, дабы не забыть чего при новой итерации. Нового в ней ничего нет, ставим пакеты да настраиваем. У нас имеется новый и девственно чистый сервер под управлением CentOS 7.2 (minimal). Задача — поставить на него nginx + php + php-fpm + mysql и чтоб всё это шустро работало, да обновлялось самостоятельно из репозиториев (при возможности). Так же необходим тот же phpMyAdmin и настроенная отправка почты с сервера. В общем — минимальный web-stack, на котором хоть разработкой занимайся, хоть что-то вордпресо-подобное разворачивай. Сервер, к слову, располагается на hetzner.de.
Подробнее под катом

Собираем и настраиваем msmtp

msmtp-wide

msmtp — это простой консольный клиент для отправки сообщений электронной почты по протоколу SMTP.

Можно, конечно, пойти сложным путем и поставить полноценный почтовый сервер, но зачем? Нам ведь требуется просто позволить скриптам и демонам отправлять почту, а заморачиваться с DKIM, SPF, заголовками и прочим — крайне лень. Поэтому мы будем отправлять почту с помощью почтового ящика на yandex.ru, и поможет нам в этом приложение под названием msmtp.

Важное замечание — в моем случае домен уже делегирован на яндекс, в DNS имеются все необходимые записи, почтовый ящик создан на странице pdd.yandex.ru, к нему прописаны алиасы вида no-reply, noreply, donotreply, do-not-reply для того, что бы была возможность иметь почтовый ящик с именем [email protected], но успешно отправлять письма от имени, например, [email protected].

Единственное но — в репозиториях находится старая и бажная версия. Самый критичный для нас баг — это неизменяемое поле Sender, т.е. мы не можем указать имя (или адрес? не помню) отправителя. Смотрим что есть в репозиториях:

$ yum info msmtp
# ...
Name        : msmtp
Version     : 1.4.32
Release     : 1.el7
Size        : 120 k
# ...

Смотрим информацию о релизах на официальном сайте — на момент написания этих строк это версия 1.6.5 (уже без описанного выше бага).

Все манипуляции производились на «чистой» системе CentOS 7.2.

Скачаем исходники и соберем приложение ручками.
Подробнее под катом