Автоматический деплой WordPress темы/плагина с 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 = ❤

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

Вывод актуальной информации при логине в систему по SSH

В репозитории ubuntu подсмотрел одну замечательную штуку, название которой landscape-sysinfo. Суть её заключается в том что при логине пользователя выводится довольно много интересной и что самое главное — актуальной информации. В результате, например, вход в систему может выглядеть так:

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

Захотелось нечто аналогичное прикрутить и к CentOS, но ничего подходящего для этого с ходу не нашел.

Велосипеды писать нам не в первой, и при помощи одного небольшого скрипта (который будет выполняться при входе пользователя в систему) добьемся поставленной цели.

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

SSH Honeypot — просто и со вкусом

Honeypot («Ловушка») (англ. горшочек с мёдом) — ресурс, представляющий собой приманку для злоумышленников. (wikipedia.org)

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

$ nmap google.com

Starting Nmap 6.47 ( http://nmap.org ) at 2050-01-11 00:00 GMT
Nmap scan report for google.com (173.194.71.138)
Host is up (0.010s latency).
Other addresses for google.com (not scanned): 173.194.71.139 173.194.71.113 173.194.71.101 173.194.71.100 173.194.71.102
rDNS record for 173.194.71.138: lb-in-f138.1e100.net
Not shown: 998 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.92 seconds

Из которого мы видим, что на целевой системе открыты 2 порта (стелс-сканирование и прочее мы пока опустим — не к чему оно сейчас): 80/tcp и 443/tcp и это означает, что там наверняка крутится web-сервер, который работает по http и https.

Теперь подойдем к более интересному моменту.

Довольно часто администраторы используют для доступа к своим серверам SSH. Стандартный порт для SSH — 22/tcp. Если администратор хоть чуть-чуть «шарит», то после установки системы он сразу же перевешивает SSH на не стандартный порт (например 454545), запрещает логин от рута и настраивает авторизацию по сертификату вместо пароля. И оно совершенно правильно — держать SSH на стандартном порту, да без какой-либо дополнительной защиты — потенциально огромная брешь в безопасности.

А что если повесить на этот самый 22 порт ещё один ssh-демон, но при этом все попытки логина по нему сразу отправлять в fail2ban? Обычным нашим пользователям SSH не нужен, мы ходим через порт 454545, значит тот, кто будет ломиться на 22 порт — бот или злоумышленник, которого необходимо забанить по IP на довольно длительное время. Обойти это ограничение можно будет лишь заюзав VPN, прокси или другое средство смены IP, ну или дождаться пока не пройдет время бана которое мы установим.

Данную задачу будем решать в 3 этапа:

  1. Настроим и запустим дополнительный sshd-демон, который будет висеть на 22 порту;
  2. Настроим fail2ban, который будет читать логи на попытку коннекта по ssh на 22 порту;
  3. Поставим всё это дело в автозапуск;

Все манипуляции буду производить на CentOS 7, разница с другими дистрибутивами — минимальна

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

Установка LAMP на CentOS 7

Так уж получилось, что хостер, где ранее размещались все сайты и некоторые сервисы, оказался жлоб и пидарас. Жлоб, потому как на самом дорогом тарифе выделял лишь сраные 256Mb под всё, а пидарас — потому как и с поддержкой — не очень хорошо, и хосты частенько лежали, и отношение к клиентам — далеко не лучшее. Да, речь о Nic.ru.

Было решено переезжать. Но куда? В России достойное по соотношению цена/качества — не находилось, а “за бугром”, по рекомендациям хабра — был выбран hetzner.de.

Сказано — сделано. Только куплен не хостинг, а виртуальный выделенный сервер, с характеристиками:

  • Камень: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
  • Кэш камня: 4096 KB
  • Память: 994.1 MB
  • Сеть: добрые 50 МБит
  • ОС: на выбор, но я ставил CentOS Linux 7.0.1406 (x64)

После того что было — есть где разгуляться. А самое главное — почти за те же деньги. Остается всё поставить и настроить.

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

Флаги запуска «PuTTY»

-load "название сессии" Загрузить сохраненную сессию. Если в названии сессии есть пробелы, оно заключается в кавычки.
-ssh, -telnet, -rlogin, -raw Выбор протокола соединения
-v Выводить отладочную информацию
-l login Задать логин
-pw MyPaSsWoRd Задать пароль
-L, -D, -R Включить перенаправление портов:
-L 5110:popserver.example.com:110 Перенаправить локальный порт 5110 на порт 110 удаленного сервера
-R 5023:mytelnetserver.myhouse.org:23 Перенаправить удаленный порт 5025 на порт 23 локального сервера

-m script.file Исполнить команду. Параметр — путь к тектовому файлу со списком команд, которые требуется исполнить
-P port Задать порт для соединения, если он отличается от стандартного порта для заданного протокола
-X, -x Включить (-X) или выключить (-x) перенаправление X в SSH
-T, -t Выделять (-T) или не выделять (-t) псевдо-терминал при SSH соединении
-N Запретить запуск команды или командной оболочки. Актуально для перенаправления портов
-C Включить сжатие данных

Например:

putty.exe -ssh -l root -pw welc0me -C 192.168.1.2 По протоколу SSH с логином “root” и паролем “welc0me” (+опция сжатия данных) подключиться к серверу с адресом 192.168.1.2

Полный список и ещё примеры можете найти по этой ссылке.

Создание бэкапа на nic.ru

Хреновенький, не очень удобный, но работающий скрипт для создания бэкапа всех сайтов + БД на хостинге, имя которому — nic.ru. Хосинг ущербный, и использовать что-то более и менее адекватное на нем — проблематично. Перейдем к телу:

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