Установка и настройка сертификатов Let’s Encrypt

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

До недавних пор большой популярностью пользовались сертификаты от SlartSSL и WoSign, однако, многие браузеры перестали им доверять и большинство сайтов оказалось с нерабочими, но валидными SSL-сертификатами. Толку от них нет, если пользователь видит ошибку при открытии сайта, если бы не решение от Let’s Encrypt, то в нашем арсенале остался бы только один вариант – покупать сертификат :)

Итак, приступим к установке и настройке Let’s Encrypt:

rpm -ihv http://rpms.southbridge.ru/southbridge-rhel6-stable.rpm
yum clean all
yum install letsencrypt -y

CentOS: udev renamed network interface eth0 to em1

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

Проверено на системе CentOS release 6.9. Для начала, добавим в загрузчик (grub.conf) директивы net.ifnames=0 и biosdevname=0

kernel /boot/vmlinuz-2.6.32-696.el6.x86_64 ro
root=UUID=357f2c79-f7eb-4318-be69-da573fab5198
rd_NO_LUKS ...
net.ifnames=0 biosdevname=0 crashkernel=auto ...

Далее переименуем конфиг и обновим имя интерфейса:

mv /etc/sysconfig/network-scripts/ifcfg-em1 /etc/sysconfig/network-scripts/ifcfg-eth0
sed -i 's/em1/eth0/g' /etc/sysconfig/network-scripts/ifcfg-eth0

Удаляем файл:

rm -f /etc/udev/rules.d/70-persistent-net.rules

Перезагружаем сервер и видим наш eth0!

Nginx: автоматическая защита от парсинга и DDoS-атак

В своей прошлой статье я писал о возможности применения данного способа защиты от атак с помощью модуля Nginx testcookie. Сегодня мы более подробно остановимся на реализации скрипта, который автоматически будет включать защиту, обновляя конфиг и отправляя уведомление на email при срабатывании.

Устанавливаем и включаем модуль:

yum install nginx-module-testcookie

# /etc/nginx/module.inc.conf
load_module modules/ngx_http_testcookie_access_module.so;

Скрипт /srv/scripts/check_ddos.sh выглядит следующим образом и работает довольно просто. Он мониторит LA и количество коннектов к nginx. При превышении установленных порогов LA_ACTIVATE или NGINX_CONNECT включает тесткуку и отправляет письмо на email. При снижении LA ниже порога LA_DEACTIVATE, скрипт выключает тесткуку:

#!/bin/sh

NGINX_CONF=/srv/www/nagg.ru/conf/nginx.conf
MAIL="" # true is enable send mail
MAILTO=root
LA_ACTIVATE=17
LA_DEACTIVATE=5
NGINX_CONNECT=1000

########################################################
TMPLOG=/tmp/testcookie_module.tmp
NGINXCONN=`curl -s http://localhost/nginx-status | grep "Active" | awk '{print($3)}'`
LA=`cat /proc/loadavg | awk -F '.' '{print($1)}'`

function e {
    echo -en $(date "+%F %T"): "$1"
}

if [ ! -f $TMPLOG ];then echo 0 > $TMPLOG; fi
LASTRESULT=`cat $TMPLOG`

if [ -n "$NGINXCONN" ]; then
  if [ $NGINXCONN -gt $NGINX_CONNECT ]; then
    ALERT1="1"
  fi
fi

if [ -n "$LA" ]; then
  if [ $LA -gt $LA_ACTIVATE ]; then
    ALERT2="1"
  fi
fi

ALERT=$ALERT1$ALERT2

if [ -n "$ALERT" -a $LASTRESULT -eq 0 ]; then
    e; printf "Nginx connect: %-4s LA: %-3s | Activate testcookie\n" "$NGINXCONN" "$LA"
    sed -i 's/.*##-AUTO-DDOS-LABEL-##/\ttestcookie on; ##-AUTO-DDOS-LABEL-##/g' $NGINX_CONF
    /sbin/service nginx reload >/dev/null 2>&1
    echo 1 > $TMPLOG
    if [ "$MAIL" = "true" ];then
        echo "Nginx connect $NGINXCONN, LA $LA. Nginx test-cookie enable" | mail -s "`hostname` DDOS detected. Nginx test-cookie enable" $MAILTO
    fi
fi

if [ $LA -le $LA_DEACTIVATE -a $LASTRESULT -eq 1 ]; then
    e; printf "Nginx connect: %-4s LA: %-3s | Dectivate testcookie\n" "$NGINXCONN" "$LA"
    sed -i 's/.*##-AUTO-DDOS-LABEL-##/\ttestcookie off; ##-AUTO-DDOS-LABEL-##/g' $NGINX_CONF
    /sbin/service nginx reload >/dev/null 2>&1
    echo 0 > $TMPLOG
fi

Docker + Consul. Начало

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

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

Для начала работы нам потребуется дистрибутив Centos7-minimal.
Далее переходим к установке и настройке Docker. Внимание, инструкция работает только для Docker версии 1.12 и выше (это на будущее :)!

Как в Linux найти и рекурсивно заменить строку во всех файлах?

Допустим нам требуется заменить email: root@mail.domain.ru на sf@nagg.ru во всех файлах в каталоге /home/www.
Наиболее оптимальным вариантом выглядит следующая конструкция:

find /home/www -type f -print0 | xargs -0 sed -i 's/root@mail\.domain\.ru/sf@nagg.ru/g'

В данной конструкции используется print0, ниже выдержка из man find:

-print0 (GNU find only) tells find to use the null character (\0)
instead of whitespace as the output delimiter between pathnames found.
This is a safer option if you files can contain blanks or other special character.
It is recommended to use the -print0 argument to find if you use -exec command or xargs
(the -0 argument is needed in xargs.).

После выполнения, мы можем проверить что root@mail.domain.ru более нигде не прописан (файлов в выводе не должно быть):

grep -rl 'root@mail.domain.ru' /home/www/

Supervisord – как запустить PHP воркер?

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

Установка Supervisord на CentOS:

yum install supervisor -y
chkconfig supervisord on

Настройка Supervisord:

В файле конфигурации (/etc/supervisord.conf), можно не вносить никакие правки, обычно настроек по-умолчанию достаточно.
Создаем наш конфигурационный файл в подключенной директории: /etc/supervisord.d/

/etc/supervisord.d/php-queue-worker.ini
[program:worker]
command=/usr/bin/php /srv/www/application/push-server.php
numprocs=1
directory=/srv/www/application/
stdout_logfile=/var/log/supervisor/push-server.log
autostart=true
autorestart=true
user=apache
stopsignal=KILL

OpenVZ: полезные команды для работы с контейнерами

Решил собрать все в одном месте, потому что часто что-то начинаешь искать и не находишь :)
В продолжение статьи OpenVZ: полезные команды на заметку пишу дополнения!

Установить для контейнера c CTID 10 512МБ ОЗУ и 1G SWAP:

vzctl set 10 --ram 512M --swap 1G --save

Установить для контейнера с CTID 10 2 ядра CPU:

vzctl set 10 --cpus 1 --save

Скрипт проброса портов: OpenVZ + iptables

Один из механизмов автоматизации, когда на твоем сервере очень много OpenVZ-контейнеров с серыми IP, чаще всего им требуется не только доступ к интернет, но и проброс портов, чтобы извне заходить в сами контейнеры по SSH / FTP или любому другому протоколу, не важно. Конечно, как вариант, подходит ручная правка /etc/sysconfig/iptables и reload сервиса, но это не очень удобно и все-таки допускает «человеческий фактор», в данному случае скрипты автоматизации помогают нам.
Недавно наткнулся на интересную реализацию скрипта iptables, который смотрит запущенные контейнеры OpenVZ и автоматически пробрасывает порты на каждый контейнер, это очень удобно!

Рассмотрим его работу на примере, допустим у нас есть 3 контейнера OpenVZ:

# vzlist
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
        20         11 running   10.11.0.20      test1
        21         11 running   10.11.0.21      test2
        22         11 running   10.11.0.22      test3

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

# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 19 packets, 1451 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 12 packets, 947 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Git push fails: RPC failed; result=22, HTTP code = 411

If you attempt to push a large set of changes to a Git repository with HTTP or HTTPS, you may get an error message such as error: RPC failed; result=22, HTTP code = 411. This is caused by a Git configuration default which limits certain HTTP operations to 1 megabyte.
To change this limit run within your local repository

git config http.postBuffer *bytes*

where bytes is the maximum number of bytes permitted. For exmaple, set 500MB:

git config http.postBuffer 524288000

If you are using gitlab, you may need to change your nginx config too (/etc/nginx/sites-available/gitlab). More info: https://github.com/gitlabhq/gitlabhq/issues/3099

Мониторинг репликации Postgresql

Встроенная репликация в PostgreSQL 9 реализована благодаря журналу опережающей записи (WAL — Write-Ahead Log) с помощью пересылки XLOG-ов с главного сервера на подчиненный. При настроенной репликации на мастере и слейве запускаются дополнительные процессы: «postgres: wal sender process» и «postgres: wal receiver process», соответственно.
Судить о времени отставания slave-сервера от master-сервера можно сопоставляя текущие позиции записей журнала WAL: текущей на мастере и принятой/примененной на слейве. Их можно получить используя pg_current_xlog_location и pg_last_xlog_receive_location/pg_last_xlog_replay_location, соответственно.

Для работы скрипта необходимо будет установить bc

yum install bc