Блог Ваганова Николая

Штатно количество отображаемых записей регулируется GET параметром SIZEN_1 , соответственно, нам требуется узнавать параметр и в случае его превышения сбрасывать до стандартного значения. Так как в стандартном решении nginx нет необходимого компаратора, то решение написал на lua ( соответственно этот модуль должен быть включен в nginx ). Вставляем решение в location ~ \.php$ :

    set $rew 0;
    rewrite_by_lua_block {
      local rf = ngx.var.request_filename
      local args = ngx.var.args
      if rf == ngx.var.document_root .. "/bitrix/admin/sale_order.php" then
        if ngx.var.arg_SIZEN_1 and tonumber(ngx.var.arg_SIZEN_1) > 50 then
          newargs, n, err = ngx.re.gsub(args, [[\bSIZEN_1=[^&]*&?]], "SIZEN_1=50&", "jo")
          if n and n > 0 then
            ngx.var.args = newargs
            local urito = ngx.var.scheme .. "://" .. 
ngx.var.server_name .. "/bitrix/admin/sale_order.php?" .. ngx.var.args
            ngx.redirect(urito)
          end
        end
        if ngx.var.arg_SHOWALL_1 and tonumber(ngx.var.arg_SHOWALL_1) > 0 then
          newargs, n, err = ngx.re.gsub(args, [[\bSHOWALL_1=[^&]*&?]], "SIZEN_1=50&", "jo")
          if n and n > 0 then
            ngx.var.args = newargs
            local urito = ngx.var.scheme .. "://" .. 
ngx.var.server_name .. "/bitrix/admin/sale_order.php?" .. ngx.var.args
            ngx.redirect(urito)
          end
        end
      end
    }

Проблема :

bitbucket работает за nginx. При скачивании репозитория через https больше, чем 1Гб , гит сбрасывает соединение с ошибкой.

Решение :

Требуется либо отключить буферизацию на стороне nginx, либо отключить/увеличить лимит у proxy_max_temp_file_size , который стандартно как раз и выставлен в 1Гб.

В процессе работы появилась задача организовать порядка 1500 редиректов для сайта. Конечно, можно просто сгенерировать локейшены и подцепить их инклудом, но подобное решение во-первых является не совсем красивым, а во-вторых довольно медленным, ведь nginx придется проходить для каждого запроса все локейшены. Выбор упал на lua + redis , так как redis является inmemory СУБД ( хоть и nosql ) и довольно быстра.
Итак, мы собрали nginx с модулем lua и готовы творить.
У меня получился вот такой конфиг :

server {
listen 80;
location / {
access_by_lua '
local redis = require "resty.redis"
local red = redis:new()
red:set_timeout(1000)
local ok, err = red:connect("127.0.0.1", 6379)
local key = ngx.var.request_uri
local res, err = red:get(key)
if res ~= ngx.null then
ngx.redirect(res, 301)
end
';
rewrite ^(.*)$ /index.html break;
}
location /value1 { return 505; }
}


Долго мучался с access_by_lua , так как глубоких знаний lua у меня пока нет, а во всех источниках люди пишут content_by_lua. В итоге, прошерстив документацию, я пришел к выводу, что content_by_lua можно использовать только тогда, когда в этом же локейшене нет других рерайтов, proxy_pass и прочего от nginx . В текущем конфиге с content_by_lua я получал безусловный рерайт на /index.html не учитывая мою логику lua. А access_by_lua учитывает подобное поведение, что мне на руку. Дополнительный локейшен /value1 использую для теста конфига. Если в redis есть ключ со значением /value1 , то мы получим редирект и 505 код, если же ключа не существует, то нам просто отдастся стандартная страница openresty ( я использовал docker образ openresty/openresty:alpine для тестирования ).

Итак,

стартуем образ nginx :

docker run --net host -d -v /srv/docker/nginx/:/etc/nginx/conf.d openresty/openresty:alpine

далее стартуем наш редис :

docker run --net host -d redis

вносим в redis наши данные :

redis-cli set /v1234 /value1


Проверяем :
http://localhost/v123 — ( нет такого ключа в редисе ) — получаем индексную страницу
http://localhost/v1234 — ( есть такой ключ со значением /value1 ) — получаем 301 редирект и 505 код. Ура.

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

Если moodle установлен в корень сайта ( DOCROOT ) и доступен как, http://site.com/ , то для активации slash arguments нужно в nginx в конфиге сайта в блоке server прописать :

rewrite ^/(.*\.php)(/)(.*)$ /$1?file=/$3 last;


1. Ставим само ПО letsencrypt :

cd /usr/src
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto

В процессе установки попросят ввести ящик. Он потребуется для продления сертификата или при утере данных
2. Генерируем сертификаты для работы :

cd /usr/src
service nginx stop
./letsencrypt-auto certonly --standalone
service nginx start

В процессе генерации ключей нас попросят ввести список доменов, если нам нужно разместить более одного домена второго уровня, тогда нужно будет запустить еще раз утилиту, так как для всего списка создается один сертификат. Перед генерацией сертификата нужно останавливать вебсервер.
3. Создаем минимальный конфиг nginx для ssl :

server {
listen my.ip.ad.dre.ss:443 ssl;
server_name example.com www.example.com;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
set $root /var/www/example.com/;
ssl on;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
root $root;
}
}

сертификат fullchain.pem уже включает и сертификат домена и цепочку сертификатов.