Quantcast
Channel: Nginx Forum - Nginx Mailing List - Russian
Viewing all 3102 articles
Browse latest View live
↧

Вопрос про multi_accept при работе с NFS (2 replies)

November 3, 2017, 12:26 pm
$
0
0
Добрый вечер!

Нужен совет -- стоит-ли использовать multi_accept когда файлы (статические)
сервятся с NFS?
Время ответа прыгает довольно сильно и, соответственно, я пытаюсь
результаты кешировать и, если есть уже закешированный контент, то сначала
отдать а уже потом проверять (а если на весь бедлам уходит больше 10 секунд
то просто сдастся).

Два сервера в одном конфиге, на разных портах. Внешний (куда ходит за
контентом CDN) кэш-проксирует на внутренний (который непосредственно
смотрит в NFS через root).

Worker process выставлен в штук 200. Такое впечатление, что когда у NFS
затык (сетевой? не совсем ясно) то текущий процесс соответственно ждёт пока
всё вернётся. Стоит ли делать в таких случаях multi_accept? Или комбинацию
из accept_mutex on и multi_accept off? (use epoll включено, живёт на AMI то
бишь CentOS-вариант)

Насколько я понимаю worker process обслуживают и то и другое одновременно,
и если у NFS "затык" то такой момент может схавать все процессы?

Для прокси выставлено

proxy_cache_lock on;
proxy_cache_revalidate on;
proxy_cache_background_update on;
proxy_connect_timeout 10s;
proxy_read_timeout 10s;
proxy_cache_lock_timeout 10s;
proxy_cache_use_stale error timeout updating http_500 http_502
http_503 http_504;
proxy_http_version 1.1;



--
Best wishes,
Max
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
Search

Regexp длинной строки в Map (no replies)

November 4, 2017, 6:18 pm
$
0
0
Здравствуйте,

Определяю мобильного посетителя с помощью Map, заметил, что одна длинная строка гораздо сильнее нагружает Nginx, чем разбитая на части. Пробовал увеличить буфер map_hash_max_size до 4096, но разницы не заметил. Получается, что на многоядерном сервере (в моем случае 8 ядер), эффективней разбивать длинные строки на более мелкие части или все-таки необходимо увеличить какой-то буфер?

map $http_user_agent $ua_device {
default 'desktop';
~*SM-N|Tapatalk|PDA|PPC|SAGEM|mmp|pocket|psp|symbian|Smartphone|smartfon|treo|up.browser|up.link|vodafone|wap|nokia|Series40|Series60|S60|SonyEricsson|N900|MAUI.*WAP.*Browser|LG-P500|iPhone.*Mobile|iPod|iTunes|BlackBerry|\bBB10\b|rim[0-9]+|HTC|HTC.*(Sensation|Evo|Vision|Explorer|6800|8100|8900|A7272|S510e|C110e|Legend|Desire|T8282)|APX515CKT|Qtek9090|APA9292KT|HD_mini|Sensation.*Z710e|PG86100|Z715e|Desire.*(A8181|HD)|ADR6200|ADR6425|001HT|Inspire\ 4G|Android.*\bEVO\b|Nexus\ One|Nexus\ S|Galaxy.*Nexus|Android.*Nexus.*Mobile|Dell.*Streak|Dell.*Aero|Dell.*Venue|DELL.*Venue\ Pro|Dell\ Flash|Dell\ Smoke|Dell\ Mini\ 3iX|XCD28|XCD35|\b001DL\b|\b101DL\b|\bGS01\b|sony|SonyEricsson|SonyEricssonLT15iv|LT18i|E10i|Asus.*Galaxy|PalmSource|Palm|Vertu|Vertu.*Ltd|Vertu.*Ascent|Vertu.*Ayxta|Vertu.*Constellation(F|Quest)?|Vertu.*Monika|Vertu.*Signature|IQ230|IQ444|IQ450|IQ440|IQ442|IQ441|IQ245|IQ256|IQ236|IQ255|IQ235|IQ245|IQ275|IQ240|IQ285|IQ280|IQ270|IQ260|IQ250|\b(SP-80|XT-930|SX-340|XT-930|SX-310|SP-360|SP60|SPT-800|SP-120|SPT-800|SP-140|SPX-5|SPX-8|SP-100|SPX-8|SPX-12)\b|PANTECH|IM-A|VEGA\ PTL21|PT003|P8010|ADR910L|P6030|P6020|P9070|P4100|P9060|P5000|CDM8992|TXT8045|ADR8995|IS11PT|P2030|P6010|P8000|PT002|IS06|CDM8999|P9050|PT001|TXT8040|P2020|P9020|P2000|P7040|P7000|C790|Samsung|BGT-S5230|GT-B2100|GT-B2700|GT-B2710|GT-B3210|GT-B3310|GT-B3410|GT-B3730|GT-B3740|GT-B5510|GT-B5512|GT-B5722|GT-B6520|GT-B7300|GT-B7320|GT-B7330|GT-B7350|GT-B7510|GT-B7722|GT-B7800|GT-C3|GT-C5010|GT-C5212|GT-C6620|GT-C6625|GT-C6712|GT-E|GT-I|GT-M3510|GT-M5650|GT-M7500|GT-M7600|GT-M7603|GT-M8800|GT-M8910|GT-N7000|GT-P6810|GT-P7100|GT-S|GT-S8530|GT-S8600|SCH-A310|SCH-A530|SCH-A570|SCH-A610|SCH-A630|SCH-A650|SCH-A790|SCH-A795|SCH-A850|SCH-A870|SCH-A890|SCH-A930|SCH-A950|SCH-A970|SCH-A990|SCH-I100|SCH-I110|SCH-I400|SCH-I405|SCH-I500|SCH-I510|SCH-I515|SCH-I600|SCH-I730|SCH-I760|SCH-I770|SCH-I830|SCH-I910|SCH-I920|SCH-LC11|SCH-N150|SCH-N300|SCH-R100|SCH-R300|SCH-R351|SCH-R4|SCH-T300|SCH-U|SCS-26UC|SGH-A|SGH-B|SGH-C|SGH-D307|SGH-D|SGH-D807|SGH-D980|SGH-E105|SGH-E200|SGH-E315|SGH-E316|SGH-E317|SGH-E335|SGH-E590|SGH-E635|SGH-E715|SGH-E890|SGH-F300|SGH-F480|SGH-I|SGH-J150|SGH-J200|SGH-L170|SGH-L700|SGH-M110|SGH-M150|SGH-M200|SGH-N|SGH-N7|SGH-P|SGH-Q105|SGH-R210|SGH-R220|SGH-R225|SGH-S105|SGH-S307|SGH-T|SGH-U|SGH-V|SGH-X|SGH-Z130|SGH-Z150|SGH-Z170|SGH-ZX10|SGH-ZX20|SHW-M110|SPH-A|SPH-D600|SPH-D700|SPH-D710|SPH-D720|SPH-I300|SPH-I325|SPH-I330|SPH-I350|SPH-I500|SPH-I600|SPH-I700|SPH-L700|SPH-M|SPH-N100|SPH-N200|SPH-N240|SPH-N300|SPH-N400|SPH-Z400|SWC-E100|SCH-i909|GT-N7100|GT-N8010|Motorola|\bDroid\b.*Build|DROIDX|Android.*Xoom|HRI39|MOT-|A1260|A1680|A555|A853|A855|A953|A955|A956|Motorola.*ELECTRIFY|Motorola.*i1|i867|i940|MB200|MB300|MB501|MB502|MB508|MB511|MB520|MB525|MB526|MB611|MB612|MB632|MB810|MB855|MB860|MB861|MB865|MB870|ME501|ME502|ME511|ME525|ME600|ME632|ME722|ME811|ME860|ME863|ME865|MT620|MT710|MT716|MT720|MT810|MT870|MT917|Motorola.*TITANIUM|WX435|WX445|XT3|XT502|XT530|XT531|XT532|XT535|XT6|XT7|XT8|XT9/i 'mobile';
}
↧
↧

Как передать в image_filter другой путь до картинки? (no replies)

November 5, 2017, 4:57 pm
$
0
0
Подскажите можно ли как то передать в image_filter другой путь до картинки или что то другое придумать?
У меня есть 2 копии картинок, одна оригинальная другая уменьшенная, мне нужно сделать так что если высота изображения меньше 350px брать ее из папки /thumb/ для последующей ее обработки в image_filter, а не из папки original. Все ради того чтобы создавать маленькие копии с копий, а не обрабатывать большое изображение ради маленькой копии.

На бекенде я проверяю высоту и присваиваю картинке соответствующий route для nginx, если высота меньше 350px, то к ссылке на картинку я добавляю GET запрос (route=resizethumb)

Пример url: /original/99/image.jpg?w=300&h=200&route=resizethumb
И нужно чтобы по url выше бралась картинки из /thumb/99/ без изменения URL

В конфиге сделал следующее

location ~* \.(gif|jpg|png)$ {
if ($arg_route = "resizethumb") { return 410; }
error_page 410 = @img_resize;
}

location @img_resize {
# Тут берутся картинки из папки /original/ по ссылке приведенной выше
# но мне нужно взять картинку из папки /thumb/ и передать ее в image_filter
image_filter resize - $arg_h;
}


Как можно это осуществить? Можно ли изменить место расположения файла до обработке через image_filter?
↧

rate limiter and rewrite together (1 reply)

November 8, 2017, 12:00 pm
$
0
0
Коллеги,


что-то мы мальца сломали мозг и явно не видим очевидного.

Есть ситуация, когда все транзитные HTTP запросы клиента перехватываются и
отправляются в специальный nginx, котогрый показывает специальную страничку.

Но -- хочется этот поток ограничить, ибо иначе nginx начинает жрать
процессор как не в себя, потому что клиент-то тупой запросов шлёт гору.

и -- не получается.

текущий вариант был таков:


http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
error_log /var/log/nginx-error.log notice;
proxy_buffering off;

log_format rdr '[$time_local] $remote_addr [$http_host$request_uri] $server_name $server_port [$rdr] $status $body_bytes_sent';
limit_req_log_level info;
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

server {
listen 127.0.0.1:8001;
server_name localhost;
access_log /var/log/nginx-access.log rdr;
limit_req zone=one nodelay;
limit_req_status 444;
return 302 http://rinet.ru/nomoney/redirect.html?;
}
}

не лимитит.

чего мы не замечаем и где тупим? ;)

--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Nanjing Huiguang Lighting Co., Ltd (no replies)

November 9, 2017, 12:04 am
$
0
0
Huiguang lighting is a company that specializes in the design, production and sales of lighting products. As a result, the company advocates energy conservation and environmental protection, economical and green lighting concept.We are committed to providing professional, dedicated and specialized lighting solutions for our customers.
Founded in 2000, the company has more than 210 employees, covering a total area of 16,500 square meters. The company and products have passed the certification of ISO9001 quality system, EMC, CE, ROHS, IP68, CCC and CQC, and have more than 20 patents. Company has complete testing equipment for product safety testing, product environment adaptability test, light distribution test, life test, IP waterproof dustproof test, can provide customers with OEM, ODM services.
Our mission is to provide professional lighting products and services to create value for society.
Our vision is to be the best partner in the field of professional lighting in the world. http://www.hgledlight.com/
↧
↧

Upstream непонятно поведение (no replies)

November 9, 2017, 12:32 am
$
0
0
Приветсвую!
Столкнулся со странной проблемой:


# nginx -V
nginx version: nginx/1.12.1
built with OpenSSL 1.0.2l 25 May 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_addition_module --with-http_auth_request_module --add-module=/wrkdirs/usr/ports/www/nginx/work/ngx_http_geoip2_module-2.0 --with-http_geoip_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_realip_module --with-http_stub_status_module --add-module=/wrkdirs/usr/ports/www/nginx/work/ngx_devel_kit-0.3.0 --add-module=/wrkdirs/usr/ports/www/nginx/work/lua-nginx-module-0.10.8 --with-pcre --with-http_ssl_module


server {
listen 80;
server_name test.example.com;
error_log /var/log/nginx/test.error_log;
access_log /var/log/nginx/test.access_log main;

location / {
proxy_pass http://test;
proxy_next_upstream error timeout invalid_header non_idempotent http_500 http_503 http_502 http_504;
}
}

server {
listen 127.0.0.1:22001 default_server ;
error_log /var/log/nginx/test1.error_log;
return 500;
}

server {
listen 127.0.0.1:22002 default_server ;
error_log /var/log/nginx/test2.error_log;

default_type text/html;
return 200 "<br> <center><H1> TEST2 </h1></center>";
}

upstream test {
server 127.0.0.1:22001;
server 127.0.0.1:22002 backup;
}

Теоретически, после первого обращения все последующие запросы в течении 10 секунд перенаправляются сразу на бэкап, и так оно и происходит на тестовом сервере:
192.168.1.1 - - [08/Nov/2017:18:47:44 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:47:44 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:47:44 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.001" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.001" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:47:55 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"

Но на боевом сервере с теми же конфигами и версией софта картина почему-то меняется:
192.168.1.1 - - [08/Nov/2017:18:50:32 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:32 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:33 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:33 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:34 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:34 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:34 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:35 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:35 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:36 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:36 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:36 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:37 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:37 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:38 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:38 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:38 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:39 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx"
192.168.1.1 - - [08/Nov/2017:18:50:39 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx"

Подскажите, почему может отличатся поведение на разных машинах, если софт и конфиги идентичны? Разница только в том, что один нагружен, другой нет, ну и в железе?
↧

ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf (17 replies)

November 9, 2017, 8:34 am
$
0
0
Здравствуйте, All!

В чем смысл директивы

ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf

в файле /usr/lib/systemd/system/nginx.service ?

У меня из-за этой фигни nginx не поднялся после того,
как сервер перезапустился. В логах вот такая запись:

Nov 09 13:26:30 example.com nginx[851]: nginx: [warn] "ssl_stapling"
ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org"
in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem"
Nov 09 13:26:51 example.com nginx[851]: nginx: [warn] "ssl_stapling"
ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org"
in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem"
Nov 09 13:27:11 example.com nginx[851]: nginx: [warn] "ssl_stapling"
ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org"
in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem"
Nov 09 13:27:31 example.com nginx[851]: nginx: [warn] "ssl_stapling"
ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org"
in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem"
Nov 09 13:27:40 example.com systemd[1]: nginx.service start-pre
operation timed out. Terminating.
Nov 09 13:27:40 example.com systemd[1]: Failed to start nginx - high
performance web server.
Nov 09 13:27:40 example.com systemd[1]: Unit nginx.service entered
failed state.
Nov 09 13:27:40 example.com systemd[1]: nginx.service failed.

После того как вручную сделал systemctl restart nginx - все поднялось.

Может быть имеет смысл убрать строчку

ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf

из файла /usr/lib/systemd/system/nginx.service ?

Ведь никаких проблем эта строка ExecStartPre= не решает,
а только создает новые.

Или я ошибаюсь, и для чего-то эта строчка ExecStartPre= там нужна?

Для чего?

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

nginx repos Ubuntu 17.10 artful (no replies)

November 9, 2017, 11:16 pm
$
0
0
Здравствуйте.

Не могли бы вы приготовить пакеты для Ubuntu 17.10?

Спасибо!

--
WBR,
Vadim Lazovskiy
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
Search

помогите с проксированием (1 reply)

November 12, 2017, 11:40 am
$
0
0
Есть nginx который занимается проксированием на бекенд.
как сделать так чтобы при запросе
xyz.com/site1
на бекенд ушел запрос вида xyz.com, но при этом в браузере клиент видел
xyz.com/site1
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Вопрос по дебагу (1 reply)

November 13, 2017, 6:40 am
$
0
0
Доброго времени суток!
Подскажите, плиз, где можно почитать нормальную документацию про сообщения в дебаг логе.
Перерыл весь гугол, ничего толком нет. Честно, надоело играть в угадайку.

Например, что означают такие записи в режиме debug_http:

1. 2017/11/13 07:41:37 [debug] 624#0: *244736 rewrite phase: 3
    2017/11/13 07:41:37 [debug] 624#0: *244736 post rewrite phase: 4
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 5
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 6
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 7
    2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 8

    2017/11/13 07:41:37 [debug] 624#0: *244736 http script var: "Q^Y,m"
    2017/11/13 07:41:37 [debug] 624#0: *244736 limit conn: 4B30596F 1
    2017/11/13 07:41:37 [debug] 624#0: *244736 access phase: 9
    2017/11/13 07:41:37 [debug] 624#0: *244736 access phase: 10
    2017/11/13 07:41:37 [debug] 624#0: *244736 post access phase: 11

2. 2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: "Connection: close^M"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
    2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""
Последние 4 пустых строки

3. 2017/11/13 07:41:37 [debug] 624#0: *244736 http cleanup add: 0000000001F02220
    2017/11/13 07:41:37 [debug] 624#0: *244736 get rr peer, try: 1
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream connect: -2
    2017/11/13 07:41:37 [debug] 624#0: *244736 http finalize request: -4, "/?" a:1, c:2
    2017/11/13 07:41:37 [debug] 624#0: *244736 http request count:2 blk:0
    2017/11/13 07:41:37 [debug] 624#0: *244736 http run request: "/?"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream check client, write event:1, "/"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream recv(): -1 (11: Resource temporarily unavailable)

Здесь особо интересует (11: Resource temporarily unavailable). Запрос делался в корень методом HEAD
Потому что дальше, вроде бы, все в порядке:
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream request: "/?"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request handler
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request body
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream request: "/?"
    2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream process header
    2017/11/13 07:41:37 [debug] 624#0: *244736 http proxy status 200 "200 OK"

4. 2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter: l:1 f:0 s:298
    2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter limit 0
    2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter 0000000000000000
    2017/11/13 07:41:37 [debug] 624#0: *244736 finalize http upstream request: 0
    2017/11/13 07:41:37 [debug] 624#0: *244736 finalize http proxy request
    2017/11/13 07:41:37 [debug] 624#0: *244736 free rr peer 1 0
    2017/11/13 07:41:37 [debug] 624#0: *244736 close http upstream connection: 5
    2017/11/13 07:41:37 [debug] 624#0: *244736 http finalize request: 0, "/?" a:1, c:1
    2017/11/13 07:41:37 [debug] 624#0: *244736 set http keepalive handler
    2017/11/13 07:41:37 [debug] 624#0: *244736 http close request

Спасибо.
--_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

почему в лог не пишется request_body ? (2 replies)

November 16, 2017, 8:16 am
$
0
0
Всем привет, скажите пожалуйста, а какие есть ограничения на запись в
лог request_body кроме тех кто написаны вот тут?
http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_request_body

# nginx -v
nginx version: nginx/1.12.0

у меня вот есть такой конфиг (не мое. в наследство достался)


log_format format_json escape=json
'{"remote_addr":"$remote_addr","remote_user":"$remote_user","time_local":"$time_iso8601","msec":
$msec,"request":"$request","request_uri":"$request_uri","status":"$status","body_bytes_sent":"$body_bytes_sent",
"referer":"$http_referer","user_agent":"$http_user_agent",
"req_time":$request_time,"uid_got":"$uid_got","uid_set":"$uid_set",
"apic":"$cookie_spjsapicall","sndraw":"$cookie_spsenderaway","upstream_time":
$upstream_response_time, "request_body": "$request_body",
"content_length":"$content_length","request_body_file":"$request_body_file","upstream_addr":"$upstream_addr","ssl_protocol":"$ssl_protocol"}';

server {
listen 80;
server_name xxx.ru;

location ~ ^/integration/xxx/ {
proxy_pass
http://mybackend_integrations_xxx;
proxy_set_header Host $host;
proxy_http_version 1.1;
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

access_log /home/nginx/log/xxx-integration-json.log format_json;
client_max_body_size 30m;
client_body_buffer_size 1m;
client_body_in_file_only off;
client_body_in_single_buffer on;
}

}

почему в логе у меня пишется вот такое?

"request_body":
"","content_length":"105715","request_body_file":"/var/cache/nginx/client_temp/0006557331","upstream_addr":"10.216.130.28:80","ssl_protocol":""}


выглядит так будто директивы client_body_* для моего location просто
не срабатывают и все все равно пишется в tmp файл?
что еще я забыл?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Соединение с Upstream занимает 1 секунду. (no replies)

November 17, 2017, 4:50 am
$
0
0
Здравствуйте, столкнулся со следующей проблемой.
Связка nginx + uwsgi, на продакшн сервере соединение с upstream($upstream_connect_time) занимает 1 секунду (+-3ms), бывает раз в 20-30 запросов проскакивает запрос с временем соединения в 0 сек, промежуточных значений замечено небыло.
Запросы логируются только с 1го IP.
Upstream обслуживает http API.

Статика отдается моментально.
Соединение с websocket upstream (тоже uwsgi) сервером занимает 0 секунд.

Так же, в системном журнале никаких предупреждений нет.

В чем может быть проблема ?

nginx.conf:
https://pastebin.com/WipnHPkd

Конфиг сервера:
https://pastebin.com/bfVCxP78

Текущий stub_status:
Active connections: 19993
server accepts handled requests
359071 359071 1362273
Reading: 0 Writing: 10343 Waiting: 9639


Для примера залогировал один запрос.

Nginx debug log:
https://pastebin.com/sN30E6Ye

tcpdump:
https://imgur.com/a/ntC4h

Версия nginx:
nginx version: nginx/1.13.6
built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
built with OpenSSL 1.0.2g 1 Mar 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'

До этого стоял 1.12.1, было тоже самое.


Спасибо !
↧

Нужна помощь в настройке nginx (no replies)

November 17, 2017, 11:49 am
$
0
0
Доброго времени суток.
Есть небольшая проблема, пока что не получается ее решить.
VPS Debian 9
Если зайти по адресу sait_com/engine/index.php то сайт откроется.
А если по sait_com то будет 403 Forbidden.

Вот конфиг:
server {
server_name sait.com www.sait.com;
charset off;
index index.html index.php;
disable_symlinks if_not_owner from=$root_path;
include /etc/nginx/vhosts-includes/*.conf;
include /etc/nginx/vhosts-resources/sait.com/*.conf;
access_log /var/www/httpd-logs/sait.com.access.log;
error_log /var/www/httpd-logs/sait.com.error.log notice;
ssi on;
set $root_path /var/www/site/data/www/sait.com;
root $root_path;
listen 151.151.151.151:80;

location / {
location ~ [^/]\.ph(p\d*|tml)$ {
try_files /does_not_exists @php;
}
}



location @php {
fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f webmaster@sait.com";
fastcgi_param SCRIPT_FILENAME /var/www/site/data/www/sait.com/engine/index.php;
fastcgi_param HTTPS $http_x_forwarded_https if_not_empty;
fastcgi_pass unix:/var/www/php-fpm/site.sock;
try_files $uri =404;
include /etc/nginx/fastcgi_params;
}
}

И мне дали старые настройки на которых этот сайт работать но под другим доменом, а так как домен сменился то и перенести нужно на другой серв:

server {
listen 192.192.192.192:80;
server_name www.mysite.net;
root /home/www/mysite.net/static.www/;
error_log /var/log/nginx/mysite.net-error.log warn;
access_log /var/log/nginx/mysite.net-access.log detailed;

location / {
error_page 404 = @php;

location ~ \. {
expires 24h;
}
return 404;
}

location @php {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME /home/www/mysite.net/engine/index.php;
fastcgi_param HTTPS $http_x_forwarded_https if_not_empty;
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
}
}

server {
listen 192.192.192.192:80;
server_name mysite.net;
root /home/www/mysite.net/static/;
error_log /var/log/nginx/mysite.net-error.log warn;
access_log /var/log/nginx/mysite.net-access.log detailed;

location = / {
return 301 https://www.mysite.net/;
}

location /
{
add_header Cache-control public;
add_header Access-Control-Allow-Origin https://www.mysite.net;
expires 24h;
error_page 404 = @php;
log_not_found off; }

location @php {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME /home/www/mysite.net/engine/static.php;
fastcgi_param HTTPS $http_x_forwarded_https if_not_empty;
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
}
}

На старом mysite_net был SSL на новом не используют.
Я вот пробовал менять настройки, но так не не получилось запустить на главном новом домене.
Чтобы сайт открывался при sait_com. и если пробовать открыть через sait_com/engine/index.php то чтобы кидало на главную страницу sait_com.
↧
↧

Непонятки с ответом 400 (2 replies)

November 20, 2017, 4:44 am
$
0
0
Доброго дня!

Собственно, классическая секция server, принимающая запросы с неправильным $host:

server {
    listen <IP сервера>:80 default_server;
    listen <IP сервера>:443 default_server;
    server_name _;
    return 444;
    access_log .... здесь лог, что попадет в эту секцию
}

Формат этого лога:
[$remote_addr] [$host] [$http_host] [$request] [$status] [$http_user_agent] [$server_name] [$server_port]

Там такая запись:
[155.94.254.143] [<IP сервера>] [<IP сервера>] [GET /OWA-AUTODISCOVER-EWS HTTP/1.1] [400] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80]

В error логе вижу такое:
[info] 7455#0: *356814 client prematurely closed connection while reading client request headers, client: 155.94.254.143, server: _, request: "GET /OWA-AUTODISCOVER-EWS HTTP/1.1", host: "<IP сервера>"

Хорошо, откуда 400, если должно быть 444?
Пытаюсь эмулировать ситуацию:
echo -e 'GET /OWA-AUTODISCOVER-EWS HTTP/1.1\n''host:<IP сервера>\n''user-agent:Mozilla/5.0 Project 25499 (project25499.com)\n'| ncat <IP сервера> 80

И получаю ожидаемое 444. Т.е. за исключением ответа 444 и моего IP, все аналогично:
[<мой IP>] [<IP сервера>] [<IP сервера>] [GET /OWA-AUTODISCOVER-EWS HTTP/1.1] [444] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80]

Вот такая печалька...
Что я упускаю и как получить 400?

Спасибо.

--_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Помогите разобраться с proxy_pass uri decode (1 reply)

November 21, 2017, 4:04 am
$
0
0
Уже, кажется, все идеи перепробовал, ничего не помогает.
Попробую максимально точно описать проблему: На вход фронтенда приходит урл с encoded символами, среди которых есть %20. На proxy_pass этот %20 обращается обратно в пробел и всё ломается.
В простейшей конфигурации имеем:
Nginx:

location ~ ^/api(.*) {
proxy_pass http://backend/api.php?q=$1;
}

Apache (backend):
"GET /api.php?q=blabla1 blabla2"...


Ну и в логе ошибка "/api.php?q=blabla1 не валидный запрос без blabla2".
Я уже бессчётное количестко подходов сделал к экранированию и переписыванию переменных, нужен divine intervention, который скажет, как правильно, видимо.

nginx version: nginx/1.10.2
built with OpenSSL 1.0.1f 6 Jan 2014
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_secure_link_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads --add-module=/build/nginx-1.10.2/debian/modules/headers-more-nginx-module --add-module=/build/nginx-1.10.2/debian/modules/nginx-auth-pam --add-module=/build/nginx-1.10.2/debian/modules/nginx-cache-purge --add-module=/build/nginx-1.10.2/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-1.10.2/debian/modules/nginx-development-kit --add-module=/build/nginx-1.10.2/debian/modules/nginx-echo --add-module=/build/nginx-1.10.2/debian/modules/ngx-fancyindex --add-module=/build/nginx-1.10.2/debian/modules/nginx-http-push --add-module=/build/nginx-1.10.2/debian/modules/nginx-lua --add-module=/build/nginx-1.10.2/debian/modules/nginx-upload-progress --add-module=/build/nginx-1.10.2/debian/modules/nginx-upstream-fair --add-module=/build/nginx-1.10.2/debian/modules/ngx_http_substitutions_filter_module --add-module=/build/nginx-1.10.2/debian/modules/nginx_http_upstream_check_module --add-module=/build/nginx-1.10.2/debian/modules/graphite-nginx-module --add-module=/build/nginx-1.10.2/debian/modules/nginx-module-vts --add-module=/build/nginx-1.10.2/debian/modules/nginx-fluentd-module
↧
Search

Re: Помогите разобраться с proxy pass uri decode (no replies)

November 21, 2017, 5:20 am
$
0
0
Hello!

On Tue, Nov 21, 2017 at 05:11:54AM -0500, bodomic wrote:

> Уже, кажется, все идеи перепробовал, ничего не помогает.
> Попробую максимально точно описать проблему: На вход фронтенда приходит урл
> с encoded символами, среди которых есть %20. На proxy_pass этот %20
> обращается обратно в пробел и всё ломается.
> В простейшей конфигурации имеем:
> Nginx:
>
> location ~ ^/api(.*) {
> proxy_pass http://backend/api.php?q=$1;
> }
>
> Apache (backend):
> "GET /api.php?q=blabla1 blabla2"...
>
>
> Ну и в логе ошибка "/api.php?q=blabla1 не валидный запрос без blabla2".
> Я уже бессчётное количестко подходов сделал к экранированию и переписыванию
> переменных, нужен divine intervention, который скажет, как правильно,
> видимо.

Проблема в том, что location работает с раскодированным URI
запроса (и соответственно в $1 попадает раскодированная часть
URI), а proxy_pass с переменными ожидает полностью сформированный
и правильно закодированный URI, как например в конструкции

proxy_pass http://127.0.0.1$request_uri;

Для задачи "поменять URI запроса на /api.php?q=..." проще всего
использовать rewrite, благо он умеет правильно кодировать URI при
его изменении.

Как-то так должно заработать (untested):

location /api/ {
rewrite ^/api(/.*) /api.php?q=$1? break;
proxy_pass http://backend;
}

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

nginx-1.13.7 (4 replies)

November 21, 2017, 4:14 pm
$
0
0
Изменения в nginx 1.13.7 21.11.2017

*) Исправление: в переменной $upstream_status.

*) Исправление: в рабочем процессе мог произойти segmentation fault,
если бэкенд возвращал ответ "101 Switching Protocols" на подзапрос.

*) Исправление: если при переконфигурации изменялся размер зоны
разделяемой памяти и переконфигурация завершалась неудачно, то в
главном процессе происходил segmentation fault.

*) Исправление: в модуле ngx_http_fastcgi_module.

*) Исправление: nginx возвращал ошибку 500, если в директиве
xslt_stylesheet были заданы параметры без использования переменных.

*) Изменение: при использовании варианта библиотеки zlib от Intel в лог
писались сообщения "gzip filter failed to use preallocated memory".

*) Исправление: директива worker_shutdown_timeout не работала при
использовании почтового прокси-сервера и при проксировании
WebSocket-соединений.


--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

systemd: PID file /var/run/nginx.pid not readable (yet?) after start. (no replies)

November 21, 2017, 12:48 pm
$
0
0
Здравствуйте, All!

nginx установлен из официального репозитория nginx.org, CentOS 7.4

В логах вот такое наблюдается при перезапуске nginx 1.13.6:

systemd: Starting nginx - high performance web server...
nginx: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: nginx: configuration file /etc/nginx/nginx.conf test is successful
systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument
systemd: Started nginx - high performance web server.

И вот такое при запуске nginx 1.13.7:

systemd: Starting nginx - high performance web server...
systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
systemd: Started nginx - high performance web server.

Как это можно победить, чтобы в логах такого не было?

Рекомендуют вот такой workaround: https://stackoverflow.com/a/42084804
И еще вот такое нашлось заодно: https://stackoverflow.com/a/42555993

Но это наверное неправильно будет, добавлять sleep 0.1 в юнит-файл?

Обе эти ошибки возникают в systemd функции service_load_pid_file()
https://github.com/systemd/systemd/blob/master/src/core/service.c#L815
Когда systemd не может прочитать pid-файл.

Насколько я понял из комментариев в функции service_enter_start()
https://github.com/systemd/systemd/blob/master/src/core/service.c#L1909

/* For forking services we wait until the start
* process exited. */

И в функции service_sigchld_event():
https://github.com/systemd/systemd/blob/master/src/core/service.c#L2959

/* Forking services may occasionally move to a new PID.
* As long as they update the PID file before exiting the old
* PID, they're fine. */

Systemd считает что сервис запустился
после того как start process exited ?

А у nginx получается так, что start process exited,
а pid файл еще не создан и это создает проблемы systemd?

Можно ли как-то исправить поведение nginx,
чтобы systemd не флудил в логи сообщениями об ошибках?

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Проблемы при написании модуля-замены TLS для NGINX (NoiseSocket) (no replies)

November 23, 2017, 1:54 am
$
0
0
Приветствую, меня зовут Алексей. Я работаю в компании VirgilSecurity и
являюсь разработчиком протокола NoiseSocket (noisesocket.com).
Так же наша компания занимается разработкой модуля для NGINX, реализующего
протокол NoiseSocket.
Я хотел бы описать цели, результаты и узнать мнение о решениях и спросить
совета о других путях решения задачи.
Протокол NoiseSocket позиционируется как более простая в реализации и
быстрая альтернатива TLS. Одной из его главных фич является возможность
установки безопасного соединения без использования сертификатов, используя
лишь "сырые" приватные\публичные ключи. Это необходимо для IoT, бекендов,
p2p и многих других задач.
Основной целью создания модуля для NGINX - это обеспечение функциональности
reverse proxy и load balancing, где соединение между прокси-сервером и
backend серверами осуществляется по протоколу NoiseSocket. Второй целью
является возможность принимать входящие соединения по протоколу NoiseSocket,
то есть обеспечивать поддержку протокола на стороне backend с помощью NGINX.
Для обеспечения нужного функционала модуль должен обеспечить:
1 При создании соединения на стороне noise client инициировать и отработать
handshake phase по алгоритму noise initiator.
2 При входящем соединении на стороне noise server ответить на входящие
handshake сообщения и отработать handshake phase по алгоритму noise .
3 После успешного завершения handshake phase упаковывать/распаковывать
сетевой траффик в NoiseSocket transport messages.
Сначала была рассмотрена возможность создания модуля для контекста http,
однако здесь траффик для сторонних модулей предоставляется в виде
составляющих http, что не дает возможности для работы протокола, имеющего
более низкий уровень, чем http.
Затем был рассмотрен вариант для контекста stream. Однако предоставляемый
функционал для сторонних модулей здесь оказался весьма ограничен. Здесь для
работы протокола уровня представления есть возможность только на стороне
noise server, когда появляется входящее соединение и можно прицепить модуль
к одной из фаз обработки входящего запроса. На стороне noise client такой
возможности нет, потому что здесь имеется функционал только для custom load
balancing. Мы можем добавить свой обработчик:
ngx_stream_session_t->peer.get(ngx_peer_connection_t *pc,void *data);
Однако его вызов осуществляется до создания соединения:
В файле ngx_event_connect.c:
ngx_int_t ngx_event_connect_peer(ngx_peer_connection_t *pc)
{
:.
rc = pc->get(pc, pc->data);
:.
c = ngx_get_connection(s, pc->log);
:
}
Таким образом нет никакой возможности инициировать процедуру handshake и
назначить свои обработчики recv, send, recv_chain, send_chain для обработки
траффика средствами стороннего модуля.
В итоге было принято решение создать модуль, реализующий собственный
контекст по обработке траффика. За основу был взят код контекста stream, где
был убран TLS, и добавлен NoiseSocket.
Для обработки траффика только по протоколу NoiseSocket приемлема следующая
конфигурация, которая наиболее оптимальна по быстродействию:

https://i.imgur.com/fucb9J0.png

В итоге для сохранения существующего функционала NGINX по обработке http
контента определена следующая конфигурация:

https://i.imgur.com/6vnOdwd.png

или
https://i.imgur.com/WpMhdKh.png

Так как подобная конфигурация не оптимальна в плане быстродействия, то
хотелось бы узнать о более перспективных вариантах внедрения протокола
уровня представления для NGINX в качестве модуля.
Рабочий вариант спецификации для NoiseSocket:
http://noisesocket.com/spec/noisesocket/
Репозиторий с кодом модуля
https://github.com/VirgilSecurity/virgil-NGINX-noise-socket
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm (no replies)

November 26, 2017, 7:10 pm
$
0
0
[root@centos-7-4 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)

rpmbuild --rebuild nginx-1.13.7-1.el7_4.ngx.src.rpm

sh: lsb_release: command not found
error: /root/rpmbuild/SPECS/nginx.spec:28: bad %if condition
↧
Viewing all 3102 articles
Browse latest View live
Search