Конфигурация nginx + cloudflare

При использовании Cloudflare для правильного определения адреса клиента в nginx нужно настроить ngx_http_realip_module. Конфигурация следуюшая:

# Cloudflare
set_real_ip_from   199.27.128.0/21;
set_real_ip_from   173.245.48.0/20;
set_real_ip_from   103.21.244.0/22;
set_real_ip_from   103.22.200.0/22;
set_real_ip_from   103.31.4.0/22;
set_real_ip_from   141.101.64.0/18;
set_real_ip_from   108.162.192.0/18;
set_real_ip_from   190.93.240.0/20;
set_real_ip_from   188.114.96.0/20;
set_real_ip_from   197.234.240.0/22;
set_real_ip_from   198.41.128.0/17;
set_real_ip_from   162.158.0.0/15;
set_real_ip_from   104.16.0.0/12;
set_real_ip_from   2400:cb00::/32;
set_real_ip_from   2606:4700::/32;
set_real_ip_from   2803:f800::/32;
set_real_ip_from   2405:b500::/32;
set_real_ip_from   2405:8100::/32;
real_ip_header     CF-Connecting-IP;

Gist с конфигурацией

Боремся с referer спамом

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

map $http_referer $bad_referer {
    hostnames;
    default                         0;
    .semalt.com                     1;
    .kambasoft.com                  1;
    .savetubevideo.com              1;
    .descargar-musica-gratis.net    1;
    .7makemoneyonline.com           1;
    .baixar-musicas-gratis.com      1;
    .iloveitaly.com                 1;
    .iloveitaly.co                  1;
    .fbdownloader.com               1;
    .econom.co                      1;
    .buttons-for-website.com        1;
    .srecorder.co                   1;
    .darodar.com                    1;
    .priceg.com                     1;
    .blackhatworth.com              1;
    .adviceforum.info               1;
}

В конфигурацию атакуемого сервера добавляем:

if ($bad_referer) {
    return 444;
}

Gist с конфигурацией

Свой прокси-сервер для flibusta.net

Поднял свой прокси-сервер для Флибусты. Сделать это может абсолютно любой человек с vps и nginx за пару минут. Конфиг проще некуда:

server {
    server_name flibusta.lagman.su;
    listen 80;

    location / {
        proxy_pass                 http://flibusta.net;
        proxy_set_header Host      flibusta.net;
        proxy_set_header X-Real-IP $remote_addr;
        add_header X-Robots-Tag    noindex;
    }
}

Почему я не люблю линукс

Простой пример из повседневной эксплуатации:

Требуется nginx c модулем ngx_cache_purge в убунте. Окей, не вопрос: подключаем ppa, ставим nginx-extras оттуда. Внезапно оказывается, что ngx_cache_purge в этой поставке отсутствует. И это несмотря на «full set of core modules and extras». Окееей, где наша не пропадала. Гуглим немножко, ставим dpkg-dev. Жить становится еще веселей:

# apt-get build-dep nginx-extras
Reading package lists... Done
Building dependency tree
Reading state information... Done
Picking 'nginx' as source package instead of 'nginx-extras'
The following packages have unmet dependencies:
 libpcre3-dev : Depends: libpcre3 (= 8.02-1) but 8.12-3ubuntu2 is to be installed
E: Build-dependencies for nginx-extras could not be satisfied.

В такие моменты хочется плюнуть в лицо десижнмейкерам и всякого рода школоте, которые истекают желчью, не имея опыта эксплуатации НОРМАЛЬНЫХ операционных систем. В которых подобная задача решается за 1 команду.

Реврайты nginx для dokuwiki

На этот раз дружим с nginx dokuwiki:

    location /wiki {
        index index.php;
        access_log logs/wiki.log;
        error_log logs/wiki-error.log;

        rewrite ^/wiki/_media/(.*) lib/exe/fetch.php?media=$1 last;
        rewrite ^/wiki/_detail/(.*) lib/exe/detail.php?media=$1 last;
        rewrite ^/wiki/_export/([^/]+)/(.*)     doku.php?do=export_$1&id=$2 last;

        if (!-e $request_filename) {
            rewrite ^/wiki/(.+)$ /wiki/doku.php?id=$1 last;
        }

        if ($request_uri ~ ^/wiki/(bin|conf|data|inc)) {
            return 403;
        }

        rewrite ^/wiki/index.php$ doku.php;
    }

Пускаем redmine в nginx с помощью passenger модуля

Ура! В кои веки нашел нормальный таск менеджер и трекер времени — redmine.
Он хоть и хоть и написан на богомерзком руби, но работает шустро и локализован просто отлично.
В портах его можно найти в /usr/ports/www/redmine

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

config/email.yml:

production:
  delivery_method: :smtp
  smtp_settings:
    tls: true
    enable_starttls_auto: true
    address: "smtp.gmail.com"
    port: '587'
    domain: "smtp.gmail.com"
    authentication: :plain
    user_name: "foo@gmail.com"
    password: "bar"

Научить nginx работать с redmine тоже очень просто. Достаточно собрать nginx с модулем passenger и настроить конфигурацию следующим образом:

В секции http описываем глобальные настройки passenger:

passenger_root /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15;
passenger_ruby /usr/local/bin/ruby;

И добавим сервер, который будет обрабатывать к redmine:

server
{
    listen 1.2.3.4:80;
    server_name redmine.domain.tld;
    charset utf-8;
    passenger_enabled on;
    root /usr/local/www/redmine/public;
}

Flash Policy Daemon на nginx

Реализация Flash Policy Daemon на nginx проста и изящна:

# FLASH POLICY DAEMON
# returns crossdomain.xml on any request

server {
    listen 843;
    server_name  localhost;

    location / {
        rewrite ^(.*)$ /crossdomain.xml;
        }

    error_page 400 /crossdomain.xml;

    location = /crossdomain.xml {
        root html;
        }
    }

Организация горячего кэширования статики в nginx

В определенных ситуациях требуется быстро раздавать фиксированный набор статических файлов, например при раздаче swf файлов flash/flex приложений.
Для того, чтобы снизить нагрузку на диски и уменьшить время реакции, можно организовать горячее кэширование файлов в оперативной памяти:

Создадим хранилище для кэша на md диске:

mkdir /var/tmp/nginx
chown www:www /var/tmp/nginx
echo "md /var/tmp/nginx mfs rw,-s128m,late 2 0" >> /etc/fstab
mount /var/tmp/nginx

Организуем локальный сервер для раздачи статики, с которого будет заполняться кэш:

server
{
    listen 127.0.0.1:80;
    root /usr/local/www/site;
}

В контексте http описываем зону кэширования:

proxy_cache_path /var/tmp/nginx/store levels=1:2 keys_zone=STATIC:10m inactive=1d max_size=128m;

В контексте server добавляем location для статики, которую будем кэшировать:

location ~\.swf$ {
    proxy_pass http://127.0.0.1:80;
    expires 30d;
    proxy_intercept_errors on;
    proxy_cache STATIC;
    proxy_cache_min_uses 1;
    proxy_cache_valid 1d;
    proxy_ignore_client_abort on;
    proxy_temp_path /var/tmp/nginx/tmp;
    proxy_cache_use_stale updating;
}

Перегружаем сервер и запрашиваемые swf файлы начинают кэшироваться на md диске:

/usr/local/etc/rc.d/nginx reload