Проблема :
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.
В процессе работы появилась задача организовать порядка 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 код. Ура.
Конечно, в коде нет проверки на корректность подключения и доступность самого редиса, но это черновой вариант с рабочей логикой, который расширить не составит никакого труда.
1. Вылетел диск :
cat /proc/mdstat
Personalities : [raid1] [raid10] [raid0] [raid6] [raid5] [raid4]
md0 : active raid1 sdb1[1] sda1[2](F)
4200896 blocks [2/1] [_U]
md1 : active raid1 sdb2[1] sda2[2](F)
2104448 blocks [2/1] [_U]
md2 : active raid1 sdb3[1] sda3[2](F)
286728000 blocks [2/1] [_U]
unused devices:
2. Видим, что вылетел /dev/sda. Удаляем вылетевший диск из массивов :
mdadm /dev/md0 --remove /dev/sda1
mdadm /dev/md1 --remove /dev/sda2
mdadm /dev/md2 --remove /dev/sda3
3. Меняем вылетевший диск. Переносим таблицу разделов на новый чистый диск
!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!! Очень внимательно смотрим направление копирования таблицы разделов, иначе затрем все данные
sfdisk -d /dev/sdb | sfdisk /dev/sda
4. Ставим граб на новый диск :
grub-install /dev/sda
5. Вносим в массивы новый диск :
mdadm /dev/md0 -a /dev/sda1
mdadm /dev/md1 -a /dev/sda2
mdadm /dev/md2 -a /dev/sda3
6. Смотрим за синхронизацией :
cat /proc/mdstat