Проблема :
bitbucket работает за nginx. При скачивании репозитория через https больше, чем 1Гб , гит сбрасывает соединение с ошибкой.
Решение :
Требуется либо отключить буферизацию на стороне nginx, либо отключить/увеличить лимит у proxy_max_temp_file_size , который стандартно как раз и выставлен в 1Гб.
apt-get install libssl1.0-dev
wget http://download.aircrack-ng.org/aircrack-ng-1.2-beta1.tar.gz
tar -zxvf aircrack-ng-1.2-beta1.tar.gz
cd aircrack-ng-1.2-beta1
make
Это крайне странно, так как molecule по сути вызывает обычный ansible. Оказывается, для работы этого набора требуется пакет iproute.
1. Добавляем репо эластика
wget -qO — https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add —
echo «deb https://artifacts.elastic.co/packages/6.x/apt stable main» > /etc/apt/sources.list.d/elastic-6.x.list
apt-get install apt-transport-https
2. Ставим Java JDK
apt-get update
apt-get install openjdk-8-jdk
3. Ставим логстеш
apt-get install logstash
4. Кладём наш конфиг logstash.conf в /etc/logstash/conf.d/
5. Активируем автостарт и стартуем logstash
systemctl enable logstash
systemctl restart logstash
В процессе работы появилась задача организовать порядка 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 код. Ура.
Конечно, в коде нет проверки на корректность подключения и доступность самого редиса, но это черновой вариант с рабочей логикой, который расширить не составит никакого труда.
