21 апреля 2023 Nginx


После покупки коммерческого SSL сертификата должны появится следующие файлы

  • domanname.ru.ca-bundle - цепочка корневых сертификатов
  • domanname.ru.crt - публичный ключ
  • domanname.ru.csr - запрос сертификата
  • domanname.ru.nokey - закрытый ключ

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

cat domanname.ru.crt domanname.ru.ca-bundle > domanname.ru.pem

Затем добавить в файл настройки домена NGINX необходимо добавить (можно сразу после директивы listen 80;)

    listen 443 ssl; 
    ssl_certificate /home/domainname/ssl/domainname.ru.pem;
    ssl_certificate_key /home/domainname/ssl/domainname.ru.nokey;

Затем перезапустить NGINX


27 октября 2022 Nginx Angie


При сборке на свежей системе может возникнуть ошибка

./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with Angie by using --with-pcre=<path> option.

Эта ошибка проявляется если сборщик не может найти библиотку перловых регулярных выражений, решается проблема легко

sudo apt install libpcre3-dev


 


27 июля 2022 Nginx


Недавно подключил к одному сайту ещё несколько доменов и получил вот такое значение

server_name www.server-name.ru www.server-name.it server-name.it server-name.ru servername.ru www.servername.ru www.server-name.ae www.servername.ae;

после чего сделал nginx reload и сервер начал работать как обычно, но после перезагрузки всего сервера Nginx не запустился и вы давал вот такую ошибку

nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 32

суть ошибки в том, у nginx по умолчанию определён небольшой размер буфера для хранения и обработки server_name

если определить размер этого буфера через переменную server_names_hash_bucket_size в разделе http файла /etc/nginx/nginx.conf то сервер будет нормально перезапускаться и работать


12 января 2021 Nginx


certbot --dry-run --manual --agree-tos --preferred-challenges dns certonly --server https://acme-v02.api.letsencrypt.org/directory  -d *.sitename.ru -d sitename.ru -m webmaster@sitename.ru

в два захода добавляем TXT записи с именем _acme-challenge и выводимыми утилитой значениями

certbot --manual --agree-tos --preferred-challenges dns certonly --server https://acme-v02.api.letsencrypt.org/directory  -d *.sitename.ru -d sitename.ru -m webmaster@sitename.ru

добавляем ещё одно значение _acme-challenge

cat  /etc/letsencrypt/live/sitename.ru/fullchain.pem /etc/letsencrypt/live/sitename.ru/privkey.pem >  /etc/haproxy/certs/www.sitename.ru.pem

генерируем контейнер и перезапускаем балансировщик

haproxy -c -V -f /etc/haproxy/haproxy.cfg && service haproxy reload

 


28 сентября 2018 17 марта 2022 Nginx CNAME тип A wildcard dns-алиасы


Не все знают зачем к имени сайта добавляют префикс www., по мимо субъективных причин, про world wide web и удобство парсинга урлов есть совершенно объективная причина использовать алиас WWW.

Всё дело в структуре протокола DNS, когда происходит преобразование доменного имени обычного домена первого уровня, то происходит запрос к корневому серверу зоны, а корневые сервера зон обновляются достаточно редко, например в зоне .RU обновление происходит 4 раза в день, а при преобразовании домена третьего уровня, про выполняется запрос к DNS серверу контролирующему домен, а он обновляется быстрее чем корневые сервера зоны.

Таким образом, если у вас отключили сервер сайта, и вы меняете IP адрес парковки домена на IP адрес резервного, то вашим клиентам придётся ждать обновления корневого DNS, а если меняется IP адрес у алиаса WWW.yourdomain то обновление произойдёт гораздо быстрее, в некоторых случаях сразу

UDP: типа записи для алиаса www лучше указывать как A, потому что тип CNAME требует дополнительного DNS запроса для получения IP адреса


28 мая 2018 Nginx



Есть стереотип, что жители китая любят копировать готовое, а значит необходимо защищать от них контент, особенно медиа контент. Обычно это делается так:

  • CMS во время создания сессии новоми клиенту сайта проверяет IP клиента на принадлежность стране запрета
  • во время этой проверки делается либо запрос в базу данных, либо API запрос на внешний сервер (но в любом случае получаются временные издержки на запрос)
  • если IP входит в запрещённую сеть, то пользователь перенаправляется на страницу заглушку либо генерируется ошибка 403 или 404
  • иначе пользователь продолжает просматривать страницы сайта вместе с включёнными в них картинками

Но в случае применения такого метода остаётся возможность получить доступ через Proxy/VPN либо воспользовать кешем любого поисковика, а они подтянут с сайта все защищаемые картинки

При  этом необходимо так же следить за актуальностью базы данных IP адресов или за состояние API сервиса

Если такие условия и ограничения не являются приелимыми, то можно воспользоваться возможностью веб-сервера Nginx фильтровать входящие запросы по HTTP-заголовкам. Суть этого метода в том, что у любого человека его родной язык включён в список языков его веб-браузера, таким образом у китайца среди всех языков, которые он использует есть китайский, а значит в его запросе на сайт будет присутвовать вот такой HTTP-заголовок

Accept-language: zh,ru;q=0.8,en-US;q=0.5,en;q=0.3

Значит нужно научить веб-сервер выделять таких клиентов и направлять их туда куда нужно, я сделал это вот так

map $http_accept_language $lang {
    default ru;
    ~by by;
    ~ru ru;
    ~zh zh;
}

location /media/ {
        # если китаец
        set $redir  0;
        if ( $lang ~* 'zh' ){
            set $redir  1;
        }
        # если запрос фотографии
        if ( $request_uri ~* \.(jpeg|jpg|png)$ ){
            set $redir  2$redir;
        }
        if ( $redir = 21 ){
            rewrite /media/(.*) /media_v/$1?lang=$lang&redir=$redir&$http_referer;
        }

        alias /webapps/centrsvet/media/;
    }

location /media_v/ {
            image_filter_jpeg_quality 10;
            image_filter resize 700 600;
            alias /webapps/centrsvet/media/;
    }

  • Здесь в первая конструкция определяет переменную $lang
  • вторая конструкция определяет поведение веб-сервера при обращении к директирии с фотографиями, тут "накапливаются" тесты в переменной $redir и если среди языков присутвует китайский и он запрашивает какое либо изображение, то происходит редирект в директорию media_v
  • в правило директории media_v уменьшает качество и размер изображения с помощью встроенного в nginx модуля обработки изображений

защита фотографий от китайцев

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