Dovecot: This binary should probably be called with process group set to XXX instead of XXX

Подобная ошибка иногда возникает на серверах, причины могут быть различными, чтобы решить ее, нужно выставить права на dovecot-lda. Группа, в данном случае mgrsecure обычно фигурирует в строке ошибки, поэтому у Вас она может отличаться, но проверить ее наличие можно в файле /etc/group

Ошибка выглядит следующим образом:

Feb 17 12:43:24 srv dovecot: lda(admin@nagg.ru): Fatal: setgid(501(mail)) failed with euid=97(dovecot), gid=500(mgrsecure), egid=500(mgrsecure): Operation not permitted (This binary should probably be called with process group set to 501(mail) instead of 500(mgrsecure))

Решаем проблему:

chown root:mgrsecure /usr/libexec/dovecot/dovecot-lda
chmod 04750 /usr/libexec/dovecot/dovecot-lda

Выглядеть должен следующим образом:

-rwsr-x--- 1 root mgrsecure 19K Янв  5 09:55 /usr/libexec/dovecot/dovecot-lda

Теперь все будет работать!

Nginx: принудительное кэширование сайта

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

Включаем кэширование в nginx:

proxy_cache_path  /var/lib/nginx/cache  levels=1:2   keys_zone=pagecache:180m  max_size=500m inactive=7d;
proxy_cache_key "$scheme$request_method$host$request_uri";
proxy_cache_use_stale error timeout invalid_header http_500;

server {

Freeswitch установка на Ubuntu 14.04

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

Не обязательно, правим локаль:

locale-gen en_US.UTF-8
dpkg-reconfigure locales

Обязательно требуется выполнить обновление системы:

apt-get update
apt-get upgrade

Устанавливаем зависимости:

apt-get install autoconf automake devscripts gawk g++ git-core libjpeg-dev libncurses5-dev libtool make python-dev gawk pkg-config libtiff5-dev libperl-dev libgdbm-dev libdb-dev gettext libssl-dev libcurl4-openssl-dev libpcre3-dev libspeex-dev libspeexdsp-dev libsqlite3-dev libedit-dev libldns-dev libpq-dev

Собираем Freeswitch (используем сборку из исходников, чтобы подключить необходимые модули):

cd /usr/src
git clone -b v1.4 https://freeswitch.org/stash/scm/fs/freeswitch.git
cd /usr/src/freeswitch
./bootstrap.sh –j

Уязвимость CVE-2015-0235

Уязвимость была найдена в библиотеке GNU C Library (glibc) и срабатывает в результате переполнения буфера, при вызове функций gethostbyname() и gethostbyname2(), название GHOST не кажется странным.

Для проверки уязвимости Вашего сервера существует скрипт:

wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c
gcc gistfile1.c -o CVE-2015-0235
./CVE-2015-0235

Либо можно одной строкой:

curl -o ghost-test.sh https://gist.githubusercontent.com/adamenger/1cd5a8bb462f1c824f21/raw/8a19de2e4b9d56c4daf35d5f4d30200444d8725d/gistfile1.sh && sh ghost-test.sh

Результатом работы скрипта должне быть вывод: not vulnerable или vulnerable.
Обращаю внимание, что скрипт производит компиляцию, поэтому потребуется установить gcc: yum install gcc

Для устранения уязвимости достаточно обновить пакет glibc:

yum update glibc  -y

Желательно перезагрузить сервер, но после обновления скрипт проверки выдает что уязвимость закрыта.
Версия glibc-2.12-1.149 и выше не подвержена уязвимости.

Проксирование запросов с помощью Nginx

Например стоит задача спроксировать через свой домен (mydomain.ru) ссылки вида:

https://proxy.domain.com/v1/button?label=pocket&count=horizontal&align=center&v=1&url=*custom link*

На адрес типа http://mydomain.ru/pocket/?url=*custom link*

Для решения данной задачи, опишем локейшен /pocket следующим образом:


location /pocket {
	set $args ?label=pocket&count=horizontal&align=center&v=1&$args;
        proxy_pass https://proxy.domain.com/v1/button;
        proxy_redirect off;
        proxy_set_header Host proxy.domain.com;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout 1800;
        proxy_buffer_size 16k;
        proxy_buffers 32 16k;

    }

PHP:PEAR Non-static method Mail::factory() should not be called statically

Нечасто встретишь, но многие до сих пор пользуются отправкой почты с помощью PHP:PEAR, а как результат, иногда получают вот такие ошибки (например после обновления версии PHP):

Strict Standards: Non-static method Mail::factory() should not be called statically in /path/XXXXX.php on line 111

Все можно поправить, пускай руками, но зато метод рабочий. Приступаем:

vi /usr/share/pear/Mail.php + 74

- function &factory($driver, $params = array())
+ static function &factory($driver, $params = array())

vi /usr/share/pear/Mail.php +253

- $addresses = Mail_RFC822::parseAddressList($recipients, 'localhost', false);
+ $Mail_RFC822 = new Mail_RFC822();
+ $addresses = $Mail_RFC822->parseAddressList($recipients, 'localhost', false);

vi /usr/share/pear/PEAR.php +250

- function isError($data, $code = null)
+ static function isError($data, $code = null)

Проверяем и теперь все работает как нужно.
Удачи Вам и используйте функцию PHP mail.

Mac OS error: git-credential-osxkeychain died of signal 11

Установка клиента git под MacOS описывалась в смежной статье: http://nagg.ru/2014/08/ustanovka-git-klienta-mac-os-x-lion/
В данной статье я хочу разобрать ошибки при работе git-клиента:

$ git pull
error: git-credential-osxkeychain died of signal 11
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.

Для решения ошибки, нам потребуется внести следующие правки:

curl http://github-media-downloads.s3.amazonaws.com/osx/git-credential-osxkeychain -o git-credential-osxkeychain
sudo mv git-credential-osxkeychain /usr/local/bin
sudo chmod u+x /usr/local/bin/git-credential-osxkeychain
git config --global credential.helper osxkeychain

Теперь проверяем и видим что ошибка исчезла:

$ git pull
Already up-to-date.

Nginx защита от DDoS атак – продолжение

Обычно атака ботов происходит на любой участок сайта, обычно это сотни и тысячи различных IP.
Как уже рассказывалось в первой части статьи, защититься можно ограничив подключение к сайту для пустых реферер, это самый простой способ.
Что если реферер у ботов оформлен корректно? Вида: «http://mgg23.ru», «http://trew5un.com» и т.п. Выход есть, напишем правило блокировки такий ботов по следующему принципу – в реферер присутствуют буквы и цифры, конечно, оставлять такое правило на постоянной основе нельзя, но на время атаки – это самых простой выход.

server {

    # DDoS Protect from bad referer
    if ($http_referer ~* (\d\w\d|\d\d|\w\w\d\w|\d\w\w|\w\d\.)) {
        return 403;
    }

Передача HTTPS приложению в связке Nginx Apache

Иногда при работе по защищенному HTTPS-соединению, приложение не может определить тип соединения.
Для исправления ошибки, нужно внести правки в конфигурацию Nginx и Apache:

Nginx:

location / {

        proxy_set_header X-Forwarded-Proto $scheme;

    }

Apache:

<VirtualHost *>

    SetEnvIf X-Forwarded-Proto https HTTPS=on

TCP: time wait bucket table overflow (CTXXX)

Если Вы используете виртуализацию OpenVZ и возникает данная ошибка, Вам нужно поправить параметр tcp_max_tw_buckets_ub.

Проверяем и сохраняем текущие значения:

# sysctl -a | grep tw

net.ipv4.tcp_max_tw_buckets = 720000
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_kmem_fraction = 384
net.ipv4.tcp_max_tw_buckets_ub = 16536

Для решения проблемы увеличиваем tcp_max_tw_buckets_ub:

# echo 65536 > /proc/sys/net/ipv4/tcp_max_tw_buckets_ub

Проверяем что изменения применились:

# sysctl -a | grep tw

net.ipv4.tcp_max_tw_buckets = 720000
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_kmem_fraction = 384
net.ipv4.tcp_max_tw_buckets_ub = 65536