Re: Тест nginx -- сколько сообщений в log syslog без потерь?

[Pavel Yakovlev]

В конфиг сислога добавлено вот это ?

$SystemLogRateLimitInterval 0
$SystemLogRateLimitBurst 0

Всё точно идёт сразу в  syslog/rsyslog напрямую, а не через 
systemd-journal ?



18.01.2024 19:13, Anatoliy Melnik via nginx-ru пишет:

Фиксировал разными средствами.
Этот "порог" наблюдается и на rsyslog, и на syslog-ng
Сливал с 2-х nginx в один syslog -- получилось, расхождения в статистике 
пошли с 100тыс/сек, т.е. вероятнее всего nginx теряет на этапе генерации 
сообщения, а не на этапе транспортировки или приема rsyslog-ом.


Результат не зависит от того, идет ли передача по udp или в unixSocket.
Если сделать 2 записи аccess_log
access_log 
syslog:server=unix:/tmp/syslog01,nohostname,facility=local5,severity=debug,tag=nginx_sts02 st01 if=$var0;
access_log 
syslog:server=unix:/tmp/syslog02,nohostname,facility=local5,severity=debug,tag=nginx_sts02 st01 if=$var1;


С условием "if" так, что бы половина уходила в один syslog, а половина в 
другой (2 независимых rsyslog-а на одном сервере, слив хоть по UDP, хоть 
по unix:socket в любой комбинации)

Все равно примерно на уровне 50тыс/сек начинается расхождение в количестве.


*От: *"Илья Шипицин" 
*Кому: *"nginx-ru" 
*Отправленные: *Среда, 17 Январь 2024 г 15:31:49
*Тема: *Re: Тест nginx -- сколько сообщений в log syslog без потерь?



ср, 17 янв. 2024 г. в 12:49, Anatoliy Melnik via nginx-ru 
mailto:nginx-ru@nginx.org>>:


Здравствуйте.
Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам.
Логи льются в syslog (слив в файлы напрямую из nginx не желателен).
По косвенным методам контроля вылезла проблема:
До примерно 50 тыс/сек сообщений статистика прокси и бекэндов
сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения.
nginx->syslog фиксирует меньше событий, чем сумма по бекэндам.
Чем выше интенсивность запросов, тем больше расходятся данные.
Сначала грешил на syslog, но детальные разборы полетов говорят, что
скорее всего проблема в nginx.


а можно раскрыть, что имеется в виду под "детальные разборы полетов 
говорят" ?
по идее, проведя детальное расследование, которое что-то скажет, вы уже 
получили ответ


У кого-то что-то такое наблюдалось или нет?
При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно
100тыс/сек, т.е. скорее всего syslog не виноват.
Кто-то с таким сталкивался?
___
nginx-ru mailing list
nginx-ru@nginx.org 
https://mailman.nginx.org/mailman/listinfo/nginx-ru




___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru


--
Павел
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-ldap-auth

[Pavel]

20.04.2020 9:04, de...@webmaster.spb.ru пишет:
Я так понимаю, ldap не использует никто, даже разработчики собственный 
модуль... Если оно официально мертво, может закрыть репу 
https://github.com/nginxinc/nginx-ldap-auth?



Тебе лично приятнее будет, если будет меньше открытого кода?

Мне вот "иногда" очень непонятно, с чего люди решают, что им кто-то 
что-то должен?


Вам нужна техподдержка, а это значит вам туда: 
https://www.nginx.com/contact-sales/




15.04.2020, 03:30, "de...@webmaster.spb.ru" :

Добрый день
Есть в амазоне кластер, с приватной сетью, вход через OpenVPN,
после входа у всех один внутренний айпи.
Используем nginx-ldap-auth, но у меня получилось завести его в 2
режимах:
1) авторизуется 1 человек, и все кто через впн могут работать от
его имени (cache включен?)
2) Вроде с авторизацией всё хорошо, но на каждый запрос через
nginx идёт десяток запросов в AD
Можно сделать, чтобы выставлялось что-то более уникальное? Я так
понимаю, мне в браузер нужна кука. И хотя есть отдельная опция
proxy_set_header X-CookieName "nginxauth"; - я не вижу чтобы она
работала как надо. Что-то забыто? Или штатно это не сделать и
нужны модули вроде https://github.com/sto/ngx_http_auth_pam_module ?

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



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

Re: взаимодействие Nginx с fcgi БЕЗ пхп-файлов

[Pavel]

27.03.2020 19:30, Valery Kholodkov пишет:

fastcgi вообще-то бинарный протокол. Используй libfcgi. Вот пример:

https://github.com/vkholodkov/fcgi-cpp-appserver
https://github.com/vkholodkov/fcgi-cpp-appserver/blob/master/src/server/fcgi_server.cpp 



Извините за оффтоп, но не подскажет ли кто готового решения простого 
клиента fastcgi (отправить запрос за статистикой php fpm) на pure C
(ищется для использования в  Collectd модуле php-fpm). Как-то не нахожу 
времени самому разобраться и написать, а готового не подвернулось.


Заранее благодарен.



On 27-03-20 12:11, greenwar wrote:

Всем привет )
тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в
ответ шлёт ему соответствующую HTML-строку...
и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям
везде...
Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку.
И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст:
(тут очевидно BB-кодов нет, так что сорри, как есть...):

[I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892)
count = 872
data:;
   QUERY_STRINGREQUEST_METHODGET
    CONTENT_TYPECONTENT_LENGTH
SCRIPT_NAME/
REQUEST_URI/
DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 


  SERVER_SOFTWAREnginx/1.14.2
REMOTE_ADDR127.0.0.1
   REMOTE_PORT53664
   SERVER_ADDR127.0.0.1
 SERVER_PORT80
 SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive
HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0 


(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 


4096
count = -1
return false
count = 0
[I] Close 5
[I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894)
count = 832
data:▒
   QUERY_STRINGREQUEST_METHODGET
    CONTENT_TYPECONTENT_LENGTH

SCRIPT_NAME/favicon.ico

    REQUEST_URI/favicon.ico

DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 


DOCUMENT_URI/favicon.ico
  SERVER_SOFTWAREnginx/1.14.2
REMOTE_ADDR127.0.0.1
   REMOTE_PORT53664
   SERVER_ADDR127.0.0.1
 SERVER_PORT80
 SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive
HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8
HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
4096
count = -1
return false
count = 0
[I] Close 5


ну вот к этой строке у меня и возникают вопросы...
1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт 
разный

2 раза)
это 2 запроса делает браузер, или Nginx, или мой демон?

2. нет пробела между названием переменной и значением

3. а тут ещё и переноса строк нет:
HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT

4. подразумевается эти параметры обрабатывать регекспом?

5. мне столько параметров не надо, как убрать половину?

6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт 
результата... Я

шлю буквально следующее:
HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n

Прошу знающих поделиться мудростью )





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

Re: Как записать ключи pre-master от tls-соединений, обрабатываемых nginx?

[Pavel]

Здравствуйте.

> Hello!
>
> On Tue, Aug 27, 2019 at 11:50:18PM +0300, Pavel wrote:
>
>> Мы  состоим  в  реестре  организаторов  распространения  информации  и
>> поэтому обязаны предоставлять в надзорный орган ключи tls сессий.
>> 
>> Для  таких случаев существует механизм по перехвату вызовов библиотеки
>> openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/
>> Суть  простая - перед запуском демона, обрабатывающего TLS-соединения
>> клиентов,   через   LD_PRELOAD   подгружается  эта  библиотека  и  она
>> сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи 
>> pre-master.
>> 
>> Эта  схема  срабатывает с апачем, но с энжинксом ключи не пишутся. Нет
>> ли  идей  или подсказок из-за чего это может быть и как вообще  можно 
>> записать
>> эти самые pre-master keys в энжинксе?
>
> [...]
>
>> [Service]
>> Environment=SSLKEYLOGFILE=/tmp/premaster.txt
>> Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so
>
> [...]
>
>> но  тем  не  менее  ключи  в файл при обращении к энжинксу по https не
>> пишутся.
>
> Скорее всего причина в том, что переменные 
> окружения очищаются при запуске, подробнее тут:
>
> http://nginx.org/r/env
>

Огромное спасибо!

Ключи начали записываться когда добавил в nginx.conf
env LD_PRELOAD=/usr/local/lib/libsslkeylog.so;
env SSLKEYLOGFILE=/tmp/premaster.txt;


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

Re: Ошибка "[warn] conflicting server name "site.ru" on 0.0.0.0:80, ignored"

[Pavel]

02.09.2019 20:38, grey пишет:

Приветствую.

[cut]

В результате получаю ошибку "[warn] conflicting server name "www.site.ru" on
0.0.0.0:80, ignored". Ругает на строку "server_name  www.site.ru;", но как
сделать по другому - не пойму. Убрать строку наверно будет не правильно,
т.к. хостов может быть много, а мне нужно для конкретного хоста сделать те
или иные манипуляции.

Подскажите, плз, что я делаю не так?


Насколько я понял по комментарию "редирект с www на non-www",
первый блок используется для httP,
второй блок используется для httpS  с "www",
третий блок используется для httpS без "www".

Тогда во втором блоке отсутствует директива "listen 443 ssl;" и 
настройка сертификата.



__

My ICQ 12.27





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

Как записать ключи pre-master от tls-соединений, обрабатываемых nginx?

[Pavel]

Здравствуйте.

Мы  состоим  в  реестре  организаторов  распространения  информации  и
поэтому обязаны предоставлять в надзорный орган ключи tls сессий.

Для  таких случаев существует механизм по перехвату вызовов библиотеки
openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/
Суть  простая - перед запуском демона, обрабатывающего TLS-соединения
клиентов,   через   LD_PRELOAD   подгружается  эта  библиотека  и  она
сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи 
pre-master.

Эта  схема  срабатывает с апачем, но с энжинксом ключи не пишутся. Нет
ли  идей  или подсказок из-за чего это может быть и как вообще  можно записать
эти самые pre-master keys в энжинксе?

Заранее спасибо.

P.S.
Пример файла с записанными ключами:
# SSL key logfile generated by sslkeylog.c
SERVER_HANDSHAKE_TRAFFIC_SECRET 
077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 
080b47a6fea27728f15c4cb70bc7478aa4e9bf5b554e8018d9462a48fff90e9514ca6dc410154c730
CLIENT_HANDSHAKE_TRAFFIC_SECRET 
077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 
883ec12435f3d53bc0e42f5fd0a26d006955064747786e21cda18bfa4e2b5fffe147860114036881d
EXPORTER_SECRET 
077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 
267a950066d3c4bcc2fd3bb50287b045c213737d018f15c166dc82ce7eab5f4b4dcb3939bc11db1ec7c918a321b5d9f7
SERVER_TRAFFIC_SECRET_0 
077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 
cdd2a750c617a721dc93595b99852a4a2436a4fb2f843617b51f7bc0de3b9a88faa5b2b5256fa4230df7fdf9f
CLIENT_TRAFFIC_SECRET_0 
077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 
0afb1f7f7c5d8fc9aefc8aae3111045d7e837e3f87de600fcf44a583f45a313d703235e6c80f51d1fa614d96f


P.P.S.
Запускаю энжинкс с этой библиотекой для записи ключей через systemd так:

#cat /etc/systemd/system/nginx.service.d/override.conf
[Service]
Environment=SSLKEYLOGFILE=/tmp/premaster.txt
Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so

Через  lsof  видно,  что  эта  библиотека  для  записи ключей энжиксом
подгружается (здесь я проверяю и мастер и воркер):
# lsof -n -p 10313 |grep ssl
nginx   10313 root  memREG  254,1   442984   3255 
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
nginx   10313 root  memREG  254,114224  20914 
/usr/local/lib/libsslkeylog.so
# lsof -n -p 10314 |grep ssl
nginx   10314 www-data  mem   REG  254,1   442984   3255 
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
nginx   10314 www-data  mem   REG  254,114224  20914 
/usr/local/lib/libsslkeylog.so


но  тем  не  менее  ключи  в файл при обращении к энжинксу по https не
пишутся.

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

Re: Баланс Ирочка по имени хоста

[Pavel via nginx-ru]

On Mon, 03 Dec 2018 09:41:29 -0500
 "firedragon"  wrote:

Привет, всем.


Как я понял при получении запроса nginx дальше 
балансирует запрос на сервер iis по IP адресу. 


Можете подсказать как решить проблему?



Привет.

Вам нужно использовать директиву

proxy_set_header Host $host;

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header

Разберитесь с этим.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Бинарные пакеты под ARM64 для Ubuntu 18.04

[Pavel Odintsov]

Добрый день!

ОГРОМНОЕ спасибо за столь быструю реакцию :) Пакеты проверили - работает
прекрасно!

On Thu, Nov 22, 2018 at 11:57 AM Konstantin Pavlov  wrote:

> Здравствуйте,
>
> 13.11.2018 0:38, Pavel Odintsov wrote:
> > Добрый день!
> >
> > Update: добавил рассылку в копию
> >
> > Спасибо за ответ! Будем ждать пакетов :)
>
> И Вам спасибо.
>
> Пакеты для stable и mainline готовы и выложены, в будущем будут
> выпускаться для каждого релиза в общем порядке.
>
> --
> Konstantin Pavlov
> https://www.nginx.com/
>


-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Бинарные пакеты под ARM64 для Ubuntu 18.04

[Pavel Odintsov]

Добрый день!

Update: добавил рассылку в копию

Спасибо за ответ! Будем ждать пакетов :)

Да, как и сказали выше, не сказать, что сильно экзотичная архитектура. У
нас есть довольно большое число различных плат на данной архитектуре, в
основном небольшие SBC с 2-4 ядрами 4GB памяти. Сейчас используем Nginx из
Ubuntu 18.04, но для consistency мы предпочитаем использовать именно Ваши
сборки, чтобы на всех версиях ОС держать идентичные версии Nginx.

Задача, которую решаем довольно обычная - легкий веб сервер / роутер API.

Какое-то время назад также тестировали Cavium Thunder от
https://www.worksonarm.com/ с 96 ядрами, уже довольно серьезное железо под
серьезную нагрузку (в отличие от платок, на которых довольно сложно что-то
серьезное бывает запустить)

Спасибо!

On Mon, Nov 12, 2018 at 4:39 PM Konstantin Pavlov  wrote:

> Здравствуйте,
>
> 12.11.2018 0:22, Pavel Odintsov wrote:
> > Добрый день!
> >
> > Успешно использовали ARM64 билды Nginx на Ubuntu 16.04, но после
> > апгрейда на 18.04 неожиданно заметили, что пакетов для новых версий нету.
> >
> > И правда, согласно http://nginx.org/en/linux_packages.html пакетов Nginx
> > для ARM64 под Ubuntu 18.04 не заявлено. Отсутствие
> > пакетов http://nginx.org/packages/ubuntu/dists/bionic/ для ARM64 это,
> > собственно, подтверждает.
> >
> > В связи с чем вопрос, есть ли планы их добавить?
>
> Добавим. Прямых запросов на сборки для 18.04 на ARM64 до Вас не было,
> так что нам будет необходимо подготовить инфраструктуру сборки.
> Каких-то конкретных сроков пока пообещать не могу, постараемся побыстрее.
>
> Если не секрет, для чего Вы используете наши пакеты на этой довольно
> экзотической архитектуре?  Меняете или используете as-is?
>
> Спасибо,
>
> --
> Konstantin Pavlov
> https://www.nginx.com/
>


-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Бинарные пакеты под ARM64 для Ubuntu 18.04

[Pavel Odintsov]

Добрый день!

Успешно использовали ARM64 билды Nginx на Ubuntu 16.04, но после апгрейда
на 18.04 неожиданно заметили, что пакетов для новых версий нету.

И правда, согласно http://nginx.org/en/linux_packages.html пакетов Nginx
для ARM64 под Ubuntu 18.04 не заявлено. Отсутствие пакетов
http://nginx.org/packages/ubuntu/dists/bionic/ для ARM64 это, собственно,
подтверждает.

В связи с чем вопрос, есть ли планы их добавить?

Спасибо!

-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Отключение SSL, если нет сертификатов

[Pavel]

On Thu, 8 Nov 2018 12:10:57 +0300 Sergey Bondarev 
 wrote:


соответсвенно  приходится  сначала  руками  добавлять 
конфиг nginx без  SSL,  запускать  cert-bot


Настройте конфиг таким образом, чтобы в хосте по-умолчанию 
отдавались правильные

ответы на запросы проверки домена.


 для  получения  сертификата, менять конфиг
nginx, добавляя туда listen ssl и сертификаты.


После получения сертификата всёравно будет необходимо 
изменение конфига и reload.


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


Всё это не требует никаких промежуточных самоподписанных 
автоматически формируемых сертификатов.


Жизнеспособна  ли  такая  идея  ?  Если  при  запуске 
nginx не находит сертификатов  по  тем  путям,  что  есть в конфиге он 
пишет ворнинг, и генерирует самоподписанный сертификат, который и 
начинает использовать для обслуживания хоста.


Описанная идея приведет к усложнению обнаружения ошибок и, 
как следствие, к хаосу.

Я бы так делать не рекомендовал.
Напишите себе правильные скрипты.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx, ошибки.

[Pavel-1]

nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,281707,281722#msg-281722

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

Re: Nginx, ошибки.

[Pavel-1]

ошибки те же, что и при проверке статуса.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,281707,281714#msg-281714

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

Re: Nginx, ошибки. (Debian 9)

[Pavel-1]

Pavel-1 Wrote:
---
> привет.
> 1) отправляю команду - 
> service nginx start
> 
> 2) вот такой ответ - 
> Job for nginx.service failed because the control process exited
> with error code.
> See "systemctl status nginx.service" and "journalctl -xe" for
> details.
> 
> 3) отправляю команду - 
> service nginx status
> 
> 4) вырезал из ответа - 
> Active: failed (Result: exit-code) since Sat 2018-10-27 19:55:47
> +09; 1min 31s ago
> Docs: http://nginx.org/en/docs/
> Process: 7561 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
> (code=exited, status=1/FAILURE)
> окт 27 19:55:47 Tigina-Debian nginx[7561]: nginx: [emerg] still
> could not bind()
> окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Control
> process exited, code=exited status=1
> окт 27 19:55:47 Tigina-Debian systemd[1]: Failed to start nginx -
> high performance web server.
> окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Unit
> entered failed state.
> окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Failed
> with result 'exit-code'.
> 
> Посоветуйте как решить проблему с запуском. !!Версию показывает
> нормально!!
> 
> P.S. много форумов просмотрел, пока проблему не решил.
> P.S.S. если кто может помочь решить ошибку в реальном времени, пишите
> в личку свой скайп.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,281707,281708#msg-281708

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

Nginx, ошибки.

[Pavel-1]

привет.
1) отправляю команду - 
service nginx start

2) вот такой ответ - 
Job for nginx.service failed because the control process exited with
error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

3) отправляю команду - 
service nginx status

4) вырезал из ответа - 
Active: failed (Result: exit-code) since Sat 2018-10-27 19:55:47 +09;
1min 31s ago
Docs: http://nginx.org/en/docs/
Process: 7561 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
(code=exited, status=1/FAILURE)
окт 27 19:55:47 Tigina-Debian nginx[7561]: nginx: [emerg] still could
not bind()
окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Control process
exited, code=exited status=1
окт 27 19:55:47 Tigina-Debian systemd[1]: Failed to start nginx - high
performance web server.
окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Unit entered
failed state.
окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Failed with
result 'exit-code'.

Посоветуйте как решить проблему с запуском. !!Версию показывает нормально!!

P.S. много форумов просмотрел, пока проблему не решил.
P.S.S. если кто может помочь решить ошибку в реальном времени, пишите в
личку свой скайп.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,281707,281707#msg-281707

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

Re: secure_link + realip + if

[Pavel]

On Wed, 22 Aug 2018 04:28:39 +0300 Maxim Dounin 
 wrote:



Hello!

В случае, если модуль realip включён на уровне location, 
он  работает после окончательного выбора конфигурации, 
частью какового  выбора являются директивы модуля rewrite.  
В результате в такой конфигурации $remote_addr будет использоваться до 
переопределения модулем realip.


Понятно, спасибо за разъяснение!
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

secure_link + realip + if

[Pavel]

Здравствуйте.

Спасибо за Nginx!

В процессе использования появился вопрос по совместному 
использованию
модулей ngx_http_secure_link_module и 
ngx_http_realip_module, с использованием
проверки доступа через if (Да, "if is evil", но есть ли 
другой способ?).


Ранее модуль ngx_http_secure_link_module использовался для 
проверки

доступа в самостоятельной конфигурации, без realip_module.
Теперь сервис переезжает за дополнительный прокси в целях 
защиты от DDOS,
и для получения реального айпи браузера добавился 
ngx_http_realip_module.


Проблема в следущем: если в одном локейшне используются 
два вышеуказанных
модуля + директива if, то переопределение remote_addr не 
происходит.

Если if не использовать - переопределение работает.


Тестовая конфигурация:

user www-data;
worker_processes  1;

error_log  /var/log/nginx/tst.error.log notice;
pid/var/run/nginx.tst.pid;

events {
worker_connections  1024;
# multi_accept on;
}

http {
include  /etc/nginx/mime.types;
access_log /var/log/nginx/tst.access.log;


server {
listen 127.0.0.1:80;
server_name vhost;

root /tmp;

location / {
set_real_ip_from 127.0.0.1/32;
real_ip_header X-Forwarded-For;

secure_link $arg_st;
secure_link_md5 "${remote_addr}_$uri";
if ($secure_link = "") {
return 403;
}

add_header X-App-Secure-Uri $uri always;
add_header X-App-Secure-St $arg_st always;
add_header X-App-Secure-Addr $remote_addr always;
add_header X-App-Secure-RealIP 
$realip_remote_addr always;
add_header X-Forwarded-For $http_x_forwarded_for 
always;

}
}

}

nginx -c /tmp/nginx.tst.cfg
kill `cat /var/run/nginx.tst.pid`


Тестовый файл:

echo "tst.txt" > /tmp/tst.txt


При закомментированном if имеем ожидаемый ответ с 
переопределением remote_addr, что видно по заголовку 
X-App-Secure-Addr в ответе:


# curl -v -H "Host: vhost" -H "X-Forwarded-For: 8.8.8.8" 
http://127.0.0.1/tst.txt

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)

GET /tst.txt HTTP/1.1
Host: vhost
User-Agent: curl/7.57.0
Accept: */*
X-Forwarded-For: 8.8.8.8


< HTTP/1.1 200 OK
< Server: nginx/1.10.3
< Date: Mon, 20 Aug 2018 17:51:31 GMT
< Content-Type: text/plain
< Content-Length: 8
< Last-Modified: Mon, 20 Aug 2018 17:47:59 GMT
< Connection: keep-alive
< ETag: "5b7afecf-8"
< X-App-Secure-Uri: /tst.txt
< X-App-Secure-Addr: 8.8.8.8
< X-App-Secure-RealIP: 127.0.0.1
< X-Forwarded-For: 8.8.8.8
< Accept-Ranges: bytes
<
tst.txt
* Connection #0 to host 127.0.0.1 left intact


Если разкомментировать if, то что-то ломается.
Судя по заголовкам ответа, переопределение значения 
remote_addr не происходит,
и в модуле secure_link также используется IP подключения, 
а не из заголовка X-Forwarded-For.
Модуль secure_link разрешает доступ, если подпись 
сформирована для 127.0.0.1


# echo -n "127.0.0.1_/tst.txt" | openssl md5 -binary | 
openssl base64 | tr +/ -_ | tr -d =

AEfp-bT-tHrEfZN8lwDJGQ

# curl -v -H "Host: vhost" -H "X-Forwarded-For: 8.8.8.8" 
http://127.0.0.1/tst.txt?st=AEfp-bT-tHrEfZN8lwDJGQ

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)

GET /tst.txt?st=AEfp-bT-tHrEfZN8lwDJGQ HTTP/1.1
Host: vhost
User-Agent: curl/7.57.0
Accept: */*
X-Forwarded-For: 8.8.8.8


< HTTP/1.1 200 OK
< Server: nginx/1.10.3
< Date: Mon, 20 Aug 2018 18:05:09 GMT
< Content-Type: text/plain
< Content-Length: 8
< Last-Modified: Mon, 20 Aug 2018 17:47:59 GMT
< Connection: keep-alive
< ETag: "5b7afecf-8"
< X-App-Secure-Uri: /tst.txt
< X-App-Secure-St: AEfp-bT-tHrEfZN8lwDJGQ
< X-App-Secure-Addr: 127.0.0.1
< X-App-Secure-RealIP: 127.0.0.1
< X-Forwarded-For: 8.8.8.8
< Accept-Ranges: bytes
<
tst.txt
* Connection #0 to host 127.0.0.1 left intact

Ожидалось, что доступ будет разрешаться для IP 8.8.8.8, 
значение которого

передается через X-Forwarded-For. Этого не происходит:


# echo -n "8.8.8.8_/tst.txt" | openssl md5 -binary | 
openssl base64 | tr +/ -_ | tr -d =

WEpfZcYFo9shAa3_pwtACw


# curl -v -H "Host: vhost" -H "X-Forwarded-For: 8.8.8.8" 
http://127.0.0.1/tst.txt?st=WEpfZcYFo9shAa3_pwtACw

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)

GET /tst.txt?st=WEpfZcYFo9shAa3_pwtACw HTTP/1.1
Host: vhost
User-Agent: curl/7.57.0
Accept: */*
X-Forwarded-For: 8.8.8.8


< HTTP/1.1 403 Forbidden
< Server: nginx/1.10.3
< Date: Mon, 20 Aug 2018 18:07:14 GMT
< Content-Type: text/html
< Content-Length: 169
< Connection: keep-alive
< X-App-Secure-Uri: /tst.txt
< X-App-Secure-St: WEpfZcYFo9shAa3_pwtACw
< X-App-Secure-Addr: 127.0.0.1
< X-App-Secure-RealIP: 127.0.0.1
< X-Forwarded-For: 8.8.8.8
<

403 Forbidden

403 Forbidden
nginx/1.10.3


* Connection #0 to host 127.0.0.1 left intact

Какие будут рекомендации?

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

Re: Аналог функционала IncludeOptional в Apache2

[Pavel]

On Fri, 22 Jun 2018 13:23:21 +0300 Dmitriy Kovalkov 
 wrote:



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


Не вижу сложности не создавать большое количество пустых 
файлов.


При заполнении custom.include проверить/актуализировать 
конфиг виртхоста пользователя, добавив недостающий 
include.


Cоответственно при операции nginx reload потребуется 
меньше проверок и она будет происходить чуть быстрее.




Спасибо!
---
Respectfully, Dmitrii Kovalkov
FASTVPS technical department


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

Re: Как запустить nginx на IP, которое выделяется через OpenVPN

[Pavel V.]

Здравствуйте, digger.

Вы писали 27 февраля 2018 г., 19:36:49:

> Мне нужно запустить nginx на адресе IP, который выделяется клиентом
> OpenVPN.
> Проблема в том, что этот адрес появляется не сразу после загрузки хоста, а
> через некоторое время.

Это у вас неправильная конфигурация.

Настройте систему, чтобы она автоматически создавала и конфигурировала 
интерфейс при старте.

должно быть аналогичное тому, что сделает пара команд:

openvpn --mktun --dev tap0
ifconfig tap0 inet 192.168.1.2/24
 маршрутизация...


В конфиге OpenVPN:

dev tap0
#dev tun0
ifconfig-noexec

Но есть нюанс - этот айпи не "выделяется клиентом" а "прибит гвоздями", что,
впрочем, не слишком противоречит вашему сообщению, т.к. если бы он был бы
неизвестен, то не был бы и указан в конфиге nginx.

> Соответственно, nginx видит, что адреса IP, прописанного в конфиге, нет, и
> не запускается.
> Руками потом запустить можно, но должно запускаться автоматически сразу, как
> только IP будет доступен.

> Подскажите, пожалуйста, как лучше организовать такой запуск?
> Если через crontab, то как проверять, что nginx запущен, и как его
> запустить, если он не работает?
> Спасибо!




-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: $is_args

[Pavel Sinitskiy]

Добрый день,

Вас тире смущает? если хочется отсутствие тире, если нет аргументов, то
можно попробовать примерно так:
map $is_args $r_args {
  default '';
  '?' '?$args';
}

log_format full '$remote_addr - $remote_user [$time_local] "$request_method
$uri$r_args $server_protocol" $status $body_bytes_sent "$http_referer”

не проверено

5 декабря 2017 г., 22:23 пользователь Vladimir Sopot <j...@jdwuzhere.ru>
написал:

> Привет!
>
> Есть вот такой формат лога
>
> log_format full '$remote_addr - $remote_user [$time_local]
> "$request_method $uri$is_args$args $server_protocol" $status
> $body_bytes_sent "$http_referer”
>
> При этом при запросе без параметров в лог пишется вот такой
>
> 93.190.229.25 - - [05/Dec/2017:22:20:27 +0300] "GET /login.php- HTTP/1.1"
> 200 2253 "http://example.com”
>
> хотя в доках указано
>
> $is_args
> “?” if a request line has arguments, or an empty string otherwise
>
> Баг или ЧЯДНТ?
>
> С уважением,
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 

best reguards
Pavel Sinitskiy
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Pavel V.]

Здравствуйте!

> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
> будет глючить на системах, где nginx запускается в виде SysV сервиса.

Никогда не возникало желания выполнить команду

"/etc/init.d/nginx start ; /etc/init.d/nginx stop"

Что я делаю не так, или чего не делаю?


> - Доктор, когда я вот-вот-так делаю - у меня болит! :((
> - А вы вот-вот-так - не делайте. :-|



-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: unit-0.2 beta release

[Pavel V.]

Здравствуйте, Andrey.

Вы писали 21 октября 2017 г., 0:33:01:

> Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но
> на нем еще много чего написано и пишется.

Было бы интересно.

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: unit-0.2 beta release

[Pavel V.]

Здравствуйте, Maksim.

Вы писали 20 октября 2017 г., 20:42:54:

> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого 
> пользователя.
> Если я ошибаюсь - скиньте, плиз, линку на почту где можно подробнее почитать 
> об опасности
> запуска одного мастер-процесса для разных пользователей.

Помнится мне, opcache держит кеш в shared memory, создаваемой родительским
процессом, и, соответственно, общей для всех дочерних процессов - для всех 
пулов.

Именно из-за этого мы делаем отдельный fpm instance для каждого _собственного_ 
проекта.

Поправьте меня, если заблуждаюсь...

> На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
> php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный
> php-fpm процесс со своим userid то и не важно какой версии PHP он будет -
> всё-равно его запускать придётся. Так что если используется php-fpm то 
> никакой экономии ресурсов не будет

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Ошибки при установке NGINX

[Pavel V.]

Здравствуйте, Andrey_Bushman.

Вы писали 18 августа 2017 г., 17:00:26:

> Спасибо, вечером попробую проверить. Я по книжкам изучаю Linux и Nginx. Вот
> со вторым столкнулся с попыткой установки, т.к. предполагал, что он не
> установлен, в виду того, что команды `which nginx` и` whereis nginx` не
> возвращали полного имени файла.

У Вас также может быть установлен другой сервис, использующий (слушающий) порт
80, например Apache.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: client_body_temp_path - permissions

[Pavel V.]

Здравствуйте.

> Я уточню чтобы меня понимали.

> Мы используем директиву - client_body_in_file_only clean; для получения
> файлов от клиента при аплодинге, указываем директорию в директиве
> client_body_temp_path, все работает хорошо, только пермишены файлов в этой
> папке 0600.

Да, теперь увидел информацию об этой возможности.

В описании директивы "client_body_temp_path" про такую возможность не сказано ни
слова. 

При наличии директивы "client_body_in_file_only" и переменной
"request_body_file" ограничение 0600 конечно излишне жесткое и вот это шаманство
в коде nginx:

  if (r->request_body_file_group_access) {
  tf->access = 0660;
  }

выглядит несколько забавно.

Т.е. директиву client_body_in_file_only и переменную $request_body_file 
добавили, а
прав на файлы - добавить забыли.

Т.к. нигде не указано, что этими директивой/переменной можно пользоваться только
при использовании DAV (это единственный случай, когда файл создается с правами
0660), то явно требуется изменение прав по-умолчанию.

На мой взгляд, в имеющейся ситуации нужно безусловно создавать файлы с правами
доступа 0660, без создания дополнительных "рычажков".

> Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
> всегда патчить новые версии Nginx, и потом тестировать...
> Будет очень хорошо если его закомитят и будет работать из коробки.

Конечно это было бы очень хорошо, но и иметь возможность запатчить и
использовать - это лучше чем не иметь такой возможности.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: client_body_temp_path - permissions

[Pavel V.]

Здравствуйте

> Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
> всегда патчить новые версии Nginx, и потом тестировать...
> Будет очень хорошо если его закомитят и будет работать из коробки.

Как-то не вполне ясно, почему вы считаете, что файл в client_body_temp_path

>должен быть обработан в другом процессе

Это временный файл процесса nginx, и, насколько я понимаю, никакая обработка в
других процессах не предусматривается. В силу этого же права выставлены в 0600 и
другого быть не может.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Указатель на произвольные данные в структуре ngx_connection_s

[Pavel Balaev]

Добрый день.

Я пытаюсь написать модуль, который должен хранить некоторые произвольные
данные на протяжении времени жизни сессии (keep-alive). В структуре 
ngx_connection_s есть
пул памяти, при первом реквесте я аллоцирую память для ctx =
ngx_pcalloc(r->connection->pool,..., но проблема в том, что полученный
адрес негде прикрепить. Локально я пропатчил структуру ngx_connection_s и 
сохраняю
указатель в r->connection->ctx. У меня есть подозрения, что я делаю
что-то не так. 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: merge_slashes

[Pavel V.]

Здравствуйте.

Вы писали 20 марта 2017 г., 21:41:04:

> Можно ли сделать в директиве merge_slashes параметр redirect,
> чтобы из урла с несколькими слешами в канонический урл
> преобразование происходило путем 301 редиректа?

Локейшном с регуляркой ситуация не разыгрывается?


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: proxy_cache_purge unknown directive nginx from official repo

[Pavel V.]

Здравствуйте, Василий.

> nginx: [emerg] unknown directive "proxy_cache_purge" in 
> /etc/nginx/nginx.conf:80
> При этом nginx поставлен из официального репозитория nginx (debian jessie).


Логично, что этого плагина нет в официальном репозитории, т.к. плагин не
официальный: https://github.com/FRiCKLE/ngx_cache_purge

Попробуйте поставить дебиановский пакет, вроде бы там этот плагин есть.

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: nginx performance problem on linux

[Pavel Mihaduk]

binmR6sk73Mvd.bin
Description: PGP/MIME Versions Identification


encrypted.asc
Description: OpenPGP encrypted message
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопрос по модулю stream - хочу проксировать TCP в UDP

[Pavel Odintsov]

Неа, скорость критична

On Thursday, 29 September 2016, Vadim A. Misbakh-Soloviov <ng...@mva.name>
wrote:

> А вы не думали над использованием perl/njs/lua модулей и прогоном через
> них?
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <javascript:;>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопрос по модулю stream - хочу проксировать TCP в UDP

[Pavel Odintsov]

Добрый день!

Нет ли новостей на этот счет? Все же хочется транслировать tcp udp запросы
изве в бэкенд, который умеет только udp (dns сервис).

On Wednesday, 6 July 2016, Pavel Odintsov <pavel.odint...@gmail.com> wrote:

> Тут вопрос сложный. Конкретно мне от TCP нужна возможность принять от
> клиента не более XX байт запроса, передать их бэкэнду, забрать его
> ответ и раздать клиенту по TCP. Мне нужен spoon feeding в чистом виде.
>
> Если клиент прислал запрос по TCP больше, чем 65к (сколько предельно
> лезет в UDP) вполне разумно ожидать, что в этом случае он будет
> дропнут.
>
> 2016-07-06 19:26 GMT+03:00 Konstantin Tokarev <annu...@yandex.ru
> <javascript:;>>:
> >
> >
> > 06.07.2016, 17:48, "Pavel Odintsov" <pavel.odint...@gmail.com
> <javascript:;>>:
> >> Очень жаль, но технических преград получается этому нету?
> >
> > Протоколы, основанные на UDP, часто зависят от того, что каждая
> датаграмма содержит независимое сообщение. Примитивное преобразование TCP
> -> UDP, которое можно было бы сделать в универсальном сервере вроде Nginx,
> будет разбивать непрерывный TCP-поток на датаграммы произвольным образом.
> Если этот вариант устраивает, тогда технических препятствий действительно
> нет. В противном случае в nginx придется реализовать отдельный протокол для
> пересылки датаграмм через TCP, а это уже более серьезная доработка
> >
> >> Вопрос сугубо в том, что нет опции для поддержки этой фичи?
> >>
> >> On Wednesday, 6 July 2016, Roman Arutyunyan <a...@nginx.com
> <javascript:;>> wrote:
> >>> Добрый день,
> >>>
> >>> On Wed, Jul 06, 2016 at 04:55:38PM +0300, Pavel Odintsov wrote:
> >>>> Всем привет!
> >>>>
> >>>> Очень нравится модуль stream - прекрасная фишка ;)
> >>>>
> >>>> Но захотелось немного странного, имеется UDP сервер, к которому
> >>>> хочется добавить "быстрый" TCP и TLS силами Nginx.
> >>>>
> >>>> Но проблема в том, что  при вот такой конфигурации:
> >>>> stream {
> >>>> upstream backend {
> >>>> server 127.0.0.1:1122 weight=5;
> >>>> server 127.0.0.22:1122 weight=1;
> >>>> }
> >>>> server {
> >>>> # Listen UDP
> >>>> listen 127.0.0.1:53 udp;
> >>>> # Listen TCP
> >>>> listen 127.0.0.1:53;
> >>>>
> >>>> # Listen TLS/SSL
> >>>> listen 127.0.0.1:853 ssl;
> >>>> proxy_connect_timeout 1s;
> >>>> proxy_timeout 3s;
> >>>> proxy_pass backend;
> >>>> ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
> >>>> ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
> >>>> }
> >>>> }
> >>>>
> >>>> Если запрос на Nginx приходит по UDP, то он отправляется на бэкэнд по
> >>>> UDP. Если приходит по TCP либо SSL - он уходит по TCP на бэкэнд.
> >>>>
> >>>> Мне вот нужно, чтобы связь с бэкэндом была сугубо по UDP, но как этого
> >>>> достичь - не понимаю.
> >>>
> >>> Пока никак.  Протокол проксирования всегда тот же, что и протокол
> клиента.
> >>>
> >>> На текущий момент не ясно, насколько востребовано проксирование по
> >>> другому протоколу.
> >>>
> >>> --
> >>> Roman Arutyunyan
> >>>
> >>> ___
> >>> nginx-ru mailing list
> >>> nginx-ru@nginx.org <javascript:;>
> >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >> --
> >> Sincerely yours, Pavel Odintsov
> >> ,
> >>
> >> ___
> >> nginx-ru mailing list
> >> nginx-ru@nginx.org <javascript:;>
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> > --
> > Regards,
> > Konstantin
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org <javascript:;>
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> Sincerely yours, Pavel Odintsov
>


-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не работает map c переменными $status и $upstream status

[Pavel V.]

Здравствуйте, YuriV.

Вы писали 3 августа 2016 г., 0:08:13:

> Доброго времени суток.
> Возникла тут задачка кэшировать на nginx ТОЛЬКО 200-е ответы от апстрима, но
> при условии, что поддерживаются заголовки кэширования от бэкэнда.

Вы хотите странного - придумали какие-то "заголовки кэширования от
бэкенда", но смысла их так и не объяснили.

В чем в вашем понимании разница между "бэкэнд" и "апстрим"?

Кеш - это кеш. Он предназначен для уменьшения количества запросов на бэкенд.
Если бэкэнд отдал ответ, то отдавать ответ из кеша уже не имеет смысла.
Ответ бэкенда более актуален, чем то, что находится в кеше, так что надо отдать
ответ бэкенда, а кеш надо обновить.

Не вполне ясно, чего вы пытаетесь достичь.

> Сделал вывод в кустомный лог переменной $do_cache - независимо от статуса,
> который приходит с апстрима, она всегда равна дефолту мапы...

Мапа вычисляется и сохраняется момент первого обращения к переменной.
Оно происходит во время обработки директивы proxy_cache_bypass. В это время
$upstream_status не равен 200, т.к. обращения к апстриму не происходило.

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Apache не видит remote host посетителя

[Pavel Mihaduk]

Хост у nginx определяется из remote_addr, им же подставляется в X-Real-IP 
(X-Forwarded-For), а в remote_addr уходит айпишник самого nginx.


> On 23 июля 2016 г., at 06:22, veris <nginx-fo...@forum.nginx.org> wrote:
> 
> Pavel Mihaduk Wrote:
> ---
>> Поставить и настроить mod_rpaf или использовать mod_remoteip (если у
>> вас apache 2.4)
> 
> Но ip определяется нормально. А хост должен из ip определяться, если я
> правильно понял ман.
> Не может ли это с еще с PHP быть связано? Натыкался на ман cgi, что если
> хост не задан, то выводит локалхост.
> Попробую включить remoteip, хотя чет сомневаюсь. Конфиг стандартный как при
> неопределяющимся ip ?
> 
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,268430,268434#msg-268434
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re: Apache не видит remote host посетителя

[Pavel Mihaduk]

Поставить и настроить mod_rpaf или использовать mod_remoteip (если у вас apache 
2.4)
> On 22 июля 2016 г., at 18:31, veris  wrote:
> 
> Доброго времени суток!
> 
> Такая петрушка:
> 
> Debian 8, apache + nginx (frontend) (если нужны точные версию, то попозже
> напишу)
> все это автоматом ставилось вместе с ispmanager 5
> 
> ip посетителя определяет нормально
> а вот remote_host всегда localhost (HostnameLookups включен)
> 
> гугление не помогло, везде про ip написано
> 
> такое впечатление что nginx не передает хосты, может что тоже включить надо?
> 
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,268429,268429#msg-268429
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re: помощь proxy bind transparent

[Pavel Odintsov]

Боюсь, что то, чего вы добиваетесь называется иностранным словом IP
spoofing со всеми вытекающими следствиями из трактования данного
слова.

2016-07-06 23:40 GMT+03:00 jtiq <nginx-fo...@forum.nginx.org>:
> Roman Arutyunyan Wrote:
> ---
>> On Wed, Jul 06, 2016 at 03:26:34PM -0400, jtiq wrote:
>> > Roman Arutyunyan Wrote:
>> > ---
>> > > On Wed, Jul 06, 2016 at 02:26:11PM -0400, jtiq wrote:
>> > > > Roman Arutyunyan Wrote:
>> > > > ---
>> > > > > Добрый день,
>> > > > >
>> > > > > On Sun, Jul 03, 2016 at 04:57:51PM -0400, jtiq wrote:
>> > > > > > Здравствуйте, есть такой параметр proxy_bind
>> > > > > >
>> > >
>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind
>> > > > > >
>> > > > > > Параметр transparent (1.11.0) позволяет задать нелокальный
>> > > IP-aдрес,
>> > > > > который
>> > > > > > будет использоваться в исходящих соединениях с проксируемым
>> > > > > сервером,
>> > > > > > например, реальный IP-адрес клиента:
>> > > > > >
>> > > > > > proxy_bind $remote_addr transparent;
>> > > > > >
>> > > > > > Для работы параметра необходимо запустить рабочие процессы
>> nginx
>> > > с
>> > > > > > привилегиями суперпользователя, а также настроить таблицу
>> > > > > маршрутизации ядра
>> > > > > > для перехвата сетевого трафика с проксируемого сервера.
>> > > > > >
>> > > > > > Помогите настроить таблицу маршрутизации ядра для перехвата
>> > > сетевого
>> > > > > > трафика...
>> > > > > >
>> > > > > > ОС Ubuntu 14.04
>> > > > >
>> > > > > https://www.kernel.org/doc/Documentation/networking/tproxy.txt
>> > > > >
>> > > > > --
>> > > > > Roman Arutyunyan
>> > > > >
>> > > > > ___
>> > > > > nginx-ru mailing list
>> > > > > nginx-ru@nginx.org
>> > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> > > >
>> > > > Вообще реально ли слать запросы от IP клиента на сторонний
>> > > сервер/сайт через
>> > > > свой nginx сервер?
>> > >
>> > > На сторонний у вас врядли получится т.к. обратные пакеты пойдут на
>> IP
>> > > клиента
>> > > и вы не сможете их перехватить.  Вам надо сделать так, чтобы
>> обратные
>> > > пакеты с
>> > > бекенда шли через nginx.  Вы перехватите эти пакеты, настроив
>> роутинг
>> > > по
>> > > приведенной выше ссылке и пакеты в итоге будут доставлены в nginx.
>> > >
>> > > --
>> > > Roman Arutyunyan
>> > >
>> > > ___
>> > > nginx-ru mailing list
>> > > nginx-ru@nginx.org
>> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> > т.е. мне бессмысленно вообще что то делать тогда? это только для
>> локальных
>> > нужд?
>>
>> Да.
>>
>> --
>> Roman Arutyunyan
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> а вообще такое реально?
>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,268018,268131#msg-268131
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: некоторые запросы держат соединение до бесконечности

[Pavel Mihaduk]

Готово. Только на wgshop почему-то 504 :)

> On 16 июня 2016 г., at 16:10, Иван Мишин  wrote:
> 
> Нет, файрвола нет. nginx и httpd крутятся на одном сервере.
> 
> 16 июня 2016 г., 15:32 пользователь Илья Шипицин  > написал:
> а между nginx и httpd фаирвол ?
> 
> 16 июня 2016 г., 17:05 пользователь Иван Мишин  > написал:
> Всем привет.
> Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи.
> Есть nginx, за ним httpd.
> 
> Делаю wget или curl на www.example.com/test/request 
>  (за этим урлом стоит php процесс)
> Обычно все обрабатывается нормально, но в некоторых случаях curl  и wget 
> повисают, после долгой паузы получаю
> 
> Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания 
> соединения истекло) в заголовках.
> Повтор.
> После чего происходит автоматически новая попытка. Соединение постоянно 
> открыто. Может так висеть днями.
> 
> strace nginx процесса на котором весит соединение выдает
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, 
> ptr=0x1}} ---
> rt_sigreturn()  = -1 EINTR (Interrupted system call)
> epoll_wait(36, 27293b0, 512, 500)   = -1 EINTR (Interrupted system call)
> 
> strace wget показывает
> select(4, [3], NULL, NULL, {275, 67022}
> 
> Помогите разобраться кто виноват в этой связке. 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org 
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> 
> 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org 
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re: Валидация кэша на Nginx

[Pavel V.]

Здравствуйте, Steven3009.

Вы писали 5 июня 2016 г., 20:20:32:

> Если бы я разбирался в кэшировании, то наверное бы сюда не писал, верно?

> Плохо, что далеко не все, кто отвечают, сами в нем разбираются... :

Извините, но как вы определяете, кто разбрается, а кто нет, если вы сами не
разбираетесь?

Вам слишком многое _кажется_.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: geoip и прокси

[Pavel V.]

Здравствуйте, Илья.

Вы писали 4 февраля 2016 г., 2:32:16:

> мы пишем вот такую штуку 

> map $http_x_forwarded_for $r_ip {
> '' $remote_addr;
> default $http_x_forwarded_for;
> }

В такой конфигурации вы абсолютно доверяете присланному вам (кем угодно)
заголовку X-Forwarded-For. Атакующий может подставить туда любые данные, в т.ч и
не IP. Использовать полученное таким образом в качестве "настоящего IP
пользователя" категорически нельзя.

> чем в данном случае помогает то, что я знаю ip-адрес серверов оперы или 
> яндекса ?

Указав список этих адресов, вы можете принимать заголовок X-Forwarded-For 
только от них.
Полученному таким образом значению IP пользователя можно доверять в несколько 
большей
степени.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: geoip и прокси

[Pavel V.]

Здравствуйте, Илья.

Вы писали 4 февраля 2016 г., 9:38:13:

> а не лучше будет отличать оперу и яндекс по useragent?
> который мы знаем с большей степенью достоверности, чем адреса этих проксей.

Useragent можно подделывать точно так же, как и X-Forwarded-For.

Адреса можно подтвердить по AS num, а также можно собрать статистику по
отправляемым ими заголовкам с целью подтверждения/детектирования новых
"достоверных проксей". 

Например, опера турбо отправляет заголовок "X-Content-Opt", по которому её можно
определять. 

Однако, я сейчас провел быстрый тест работы опера турбо и получил неожиданный
результат. К моему серверу с 82.145.208.146 пришел следующий запрос:

GET /?opera HTTP/1.1
Host: my.host.example.com
accept-language: ru-RU,ru;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate
accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png,
 image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
user-agent: Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.17
X-Forwarded-For: 141.0.15.155
X-Content-Opt: Turbo/4.29.5717

Указанный в X-Forwarded-For 141.0.15.15 - это совершенно не мой IP.

# host 82.145.208.146
146.208.145.82.in-addr.arpa domain name pointer z10-15.opera-mini.net.

# host 141.0.15.155
155.15.0.141.in-addr.arpa domain name pointer z09-04-11.opera-mini.net.

Так что не всё там гладко, как хотелось бы.




-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Улучшение ngx_http_limit_req_module

[Pavel V.]

Здравствуйте, Валентин.

>> Перевод в боевой режим может только уменьшить число запросов, поступающих на
>> учет нетестовые зоны, что является ожидаемым поведением в силу более жесткого
>> ограничения во включаемой зоне.
>> 
> [..]

> Да, и это влияние на учет запросов в других зонах может сказаться на
> поведении.

> Скажем вот в такой конфигурации:

>   location /one {
>   limit_req zone=soft; # rate=100r/s
>   limit_req zone=hard; # rate=1r/s
>   }

>   location /two {
>   limit_req zone=soft; # rate=100r/s
>   }

> Переключение limit_req zone=hard из режима dry-run в основной по вашей
> схеме может привести к тому, что в location /two начнет попадать существенно
> больше запросов.

> Этот эффект может быть нежелателен.

Такой эффект не зависит от схемы, может произойти и в случае, если в "location
/one" будет добавлена директива "limit_req_dry_run on;", и в случае, если
"limit_req zone=hard;" будет просто добавлена, без тестирования вовсе.

> Переключение .. может привести к тому, что в location /two начнет попадать
> существенно больше запросов.
> ... , а dry-run работающий в рамках  одной зоны его просто не покажет.

Эффект заключается в том, что ограничение в location /two сможет _пропускать_
существенно больше запросов. Однако возникает вопрос - откуда они возьмутся,
чтобы его смог показать какой-либо из режимов тестирования?

>> Цель добавления зоны test -  увидеть, какое количество запросов будет
>> задержано/отклонено, если мы уменьшим rate с 2r/s до 1r/s в зоне one.

> А вот и не получится увидеть.  1r/s в режиме dry-run может отклонить
> существенно меньше запросов, чем в обычном режиме.  Произойти это может
> из-за того, что часть запросов, которые могли бы попасть под ограничение
> в zone=test будут отклонены в зонах one и two.

Да, согласен - при наличии отклонений в зонах one и two количество увидеть не
получится. Часть запросов (по одинаковому ключу) в зоне test не будет учтена, 
т.к.
сработает ограничение зоны test, а часть не будет учтена, т.к. сработает
ограничение зоны one.

Чтобы подсчитать количество, необходимо добавлять в limit_req_zone параметр
warn_rate, в limit_req - warn_burst, а затем вести подсчеты превышений
ограничений по этим параметрам параллельно основным подсчетам. Такой вариант
когда-либо рассматривался?

Однако я исхожу из предположения, что мы имеем зону one, которая не ограничивает
никого лишнего, и хотим убедится, что изменение её настроек также никого лишнего
ограничивать не будет. Также предполагаем, что со второй зоной two тоже всё в
порядке и она также никого лишнего не ограничивает.

Для этих целей мы заводим зону test с таким же ключем, как и в зоне one.

Т.е. все манипуляции тестирования нацелены на детектирование факта отсутствия
предупреждений от тестовой зоны, в условиях отсутствия предупреждений от боевых
зон.

В этих условиях отсутствия (критически малого числа) отклонений запросов в зонах
one и two предлагаемый мной подход по оценке применимости настроек зоны test
вполне жизнеспособен и весьма актуален.


> Работа ограничений в зонах one и two изменится при выключении dry-run в
> зоне test.

По задумке, в боевой режим будут переводиться _параметры_, а не зона
test - т.е. по результатам теста будет производиться коррекция параметров зоны
one, а зона test будет удалена.


>> Я думаю, что вполне понятно то, что если в контексте есть ограничение с зоной
>> one с rate=2r/s, то добавление ограничения с тестовой зоной test с rate=3r/s 
>> не
>> покажет "количества ограничений", но это и не ожидается и не требуется.

> Зависит от критерия, по которому производится ограничение.

Предполагается, что у тестируемой и боевой зоны одинаковый критерий.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Проблема с HTTPS - много сайтов на одном IP

[Pavel V.]

Здравствуйте, alexandre_frolov.

Вы писали 2 февраля 2016 г., 16:22:55:

> Вообще HTTP сайтов на этом сервере очень много, а HTTPS - только один. И там
> еще стоит панель ISPmanager, которая не должна сломаться от сильно
> кастомизированного конфига nginx...

> Подскажите, пожалуйста, а как сделать редирект на http версию сайта в таком
> конфиге?

Никак. Чтобы сделать редирект, клиенту должен быть предоставлен корректный 
сертификат.

Выделяйте для не-HTTPS-ных сайтов отдельный IP на котором не будет никакого 
HTTPS.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Улучшение ngx_http_limit_req_module

[Pavel V.]

Здравствуйте, Валентин.

> Невозможно добавить или убрать ограничение, не повлияв на работу остальных.

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

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

> Если директива приводит к отклонению запроса, то он не будет учтен во всех
> зонах. Если мы сделаем режим таким, что при этом запрос будет учтен, но не
> будет отклонен, то это не даст нам возможности оценить работу директивы,
> поскольку всё будет работать несколько не так, как если бы dry-run был 
> выключен
> и не позволит оценить реальное влияние директивы на количество пропущенных
> запросов.

Тестовое ограничение не может приводить к отклонению запроса, значит запрос
может быть отклонен только другой, не тестовой директивой.

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

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

Если другие, не тестовые директивы, отклоняют запросы, а тестовая зона не
отклоняет - значит тестируемая зона имеет менее жесткие ограничения, что
является для нас метрикой допустимости перевода её в боевой режим.

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

> Если мы будем действовать также, как без режима dry-run, но только пропускать
> запрос, то это повлияет на работу сервера парадоксальным образом - более
> жесткое ограничение в режиме dry-run будет приводить к пропусканию сервером
> большего количества запросов, чем при его отсутствии.

Другие, не тестовые директивы, могут отклонить запрос.

Я вижу применение например следующим:

limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s;  #perip
limit_req_zone $server_name zone=two:10m rate=10r/s;#perserver

limit_req_zone $binary_remote_addr zone=test:10m rate=1r/s dry-run;  #test zone

location / {
  limit_req zone=test; # rate = 1 r/s, dry run
  limit_req zone=one;  # rate = 2 r/s
  limit_req zone=two;  # rate = 100 r/s
}

Цель добавления зоны test -  увидеть, какое количество запросов будет
задержано/отклонено, если мы уменьшим rate с 2r/s до 1r/s в зоне one.

Я думаю, что вполне понятно то, что если в контексте есть ограничение с зоной
one с rate=2r/s, то добавление ограничения с тестовой зоной test с rate=3r/s не
покажет "количества ограничений", но это и не ожидается и не требуется.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Улучшение ngx_http_limit_req_module

[Pavel V.]

Здравствуйте.

> Это не может быть параметром limit_req или limit_req_zone, поскольку 
> ограничения не работают по отдельности.  Если в location задано несколько 
> директив limit_req, то применяется наиболее жесткое ограничение.  При этом, 
> если в результате запрос отклоняется, то он не учитывается во всех зонах.

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

Именно это и является целью мероприятия - отключить правило наиболее жесткого
ограничения, если это ограничение идет из тестируемой зоны.

> Приведу пример:

>  location / {
>  limit_req zone=one;  # rate = 1 r/s
>  limit_req zone=two;  # rate = 100 r/s
>  }

> Представьте себе, что вы включили тестовый режим для zone=one, что тогда
> будет?  Фактически под это ограничения могут попасть и те запросы, что раньше 
> попадали под zone=two, но если раньше они были отклонены, то теперь из-за 
> режима работы zone=one они окажутся пропущены.

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

Предлагаемый мной вариант более гибкий в этом аспекте, им можно добиться того
же поведения, что и директивой уровня location - если нужно, то для zone=two
_тоже можно_ включить тестовый режим.

> Если же мы будем просто игнорировать работу zone=one и продолжать учитывать 
> запрос в zone=two, то опять же не получим реальной картины.

Реальная картина зависит от того, как мы отвечаем внешнему миру. Если
включив параметр dry-run мы поменяем свое поведение, то абсолютно реальной
картины мы не получим никак, куда бы мы не вынесли параметр dry-run.

Не менять свое поведение как раз и позволяет вынос параметра dry-run на
уровни limit_req / limit_req_zone.

Нам реальная картина и не нужна, нам нужна оценка.

Цель включения режима dry-run - увидеть, не являются ли тестируемые ограничения
более жесткими, чем уже имеющиеся. Поэтому нам достаточно увидеть факт того,
что запросы (не)подпадают под ограничения зоны one. То, что от этого больше
запросов будет учтено в зоне two - ожидаемое явление.

> Т.е. тестировать по отдельности, без влияния на уже настроенные ограничения,
> не получится в любом случае.

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

> Также хочется обратить внимание, что ограничения чаще всего настраиваются к 
> конкретному ресурсу, т.е. под конкретный location, а следовательно и 
> тестировать имеет смысл в рамках этого блока location.

Если "ограничения чаще всего настраиваются к конкретному ресурсу, т.е. под
конкретный location", то это значит, что зона выделена именно под конкретный
ресурс, а значит вынос ограничения на уровень limit_req_zone подходит для
решения задачи тестового режима.

Однако зона - штука общая, и  может применяться и к разным ресурсам/location.
Например, у нас есть куча разных server {} языковых версий одного сайта и мы
знаем, что один реальный пользователь может одновременно находится на только на
одном из них - т.е. применяем одну зону сразу в большом наборе location всех
этих server {}. 

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

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Улучшение ngx_http_limit_req_module

[Pavel V.]

Здравствуйте, Maxim.

Вы писали 2 февраля 2016 г., 0:16:37:

>> Судя по всему, это должен быть параметр директивы limit_req_zone. Как он 
>> зовется
>> в вашем TODO?

> Скорее, отдельная директива, аналогично limit_req_status / 
> limit_req_log_level.

Приведу свою аргументацию, почему это должен быть именно параметр
директивы limit_req_zone.

Функция "dry-run" необходима для того, чтобы дать возможность протестировать
влияние ограничений на реальные запросы. В реальности в одном контексте будет
несколько директив limit_req, и отключать применение ограничений необходимо
будет только на части из них. 

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

Гибкости, которую может предоставить отдельная директива уровня контеста, для
этих целей явно недостаточно. Чтобы решить данную ситуацию, можно, например,
добавить параметр в директиву limit_req.

Однако, если возникает необходимость тестировать "как оно будет", то это значит,
что неправильна настройка rate всей зоны и мы будем стремиться максимально
исключать негативные последствия - т.е. будем выключать применение ограничения
везде, где используется указанная зона, либо загрублять настройку rate.

В общем случае, наиболее вероятным сценарием использования функции я вижу именно
создание дополнительной зоны  для тестирования, подключение её в нужные
контексты (возможно, параллельно ранее сконфигурированным зонам/ограничениям) и
собственно тестирование. Возможность задавать dry-run параметром limit_req для
этих целей явно избыточна, поэтому я предлагаю вариант добавления параметра в
директиву limit_req_zone. 


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Улучшение ngx_http_limit_req_module

[Pavel V.]

Здравствуйте.

Насколько сообществу интересна реализация улучшения модуля 
ngx_http_limit_req_module, а в частности
расширения синтаксиса директивы limit_req?

Предлагаемый синтаксис:

(1) limit_req zone=название [burst=число] [nodelay] [if=условие] [last];
(2) limit_req off if=условие;
(3) limit_req off;
(4) limit_req last if=условие;


Предлагаемая логика работы:

Синтаксис (1):

   Базовый синтаксис дополняется возможностью указания условия if=условие и 
параметром last.
   Если заданное условие не выполняется, то ключ зоны не вычисляется, директива 
пропускается, учет
запроса не происходит. Выполняются остальные директивы limit_req, при их 
наличии.
   Если заданное условие выполняется или условие не задано, применяются 
ограничения зоны обычным
образом. При этом вычисляется ключ зоны, если значение ключа не пустое и указан 
параметр last -
остальные директивы limit_req не выполняются.

Синтаксис (2):

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

Синтаксис (3):

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

Синтаксис (4)

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

   Отличие от синтаксиса (2): может быть в любом месте в списке директив 
limit_req, соответственно
директивы выше по списку директив должны быть обработаны корректно, в остальном
является практически точной копией синтаксиса (2) ("синтаксический сахар").

Для данного улучшения уже почти готов патч (за вычетом синтаксиса 4). Также 
можно сделать
аналогичную доработку модуля ngx_http_limit_conn_module. 

Из планируемых вещей также есть мысли по поводу добавления параметра "dry-run".

Предлагаю обсудить целесообразность/заинтересованность сообщества в подобного 
рода доработках.


Пример использования предлагаемого синтаксиса:

server {

...

limit_req_zone $binary_remote_addr zone=user:10m rate=200r/s;
limit_req_zone $binary_remote_addr zone=spider:10m rate=20r/s;

location /  {
limit_req off if=$verytrusted; #last 
applied too
limit_req zone=apiburst=2  if=$is_api_host last;
limit_req zone=spider burst=20 if=$is_spider_host$is_spider_re last nodelay;
limit_req zone=user;
}

location /static {
limit_req off;
}
...
};


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Улучшение ngx_http_limit_req_module

[Pavel V.]

Здравствуйте, Максим.

> Эта логика предполагает последовательное применение ограничений.
> Меж тем, логика работы nginx'а предполагает декларативную 
> конфигурацию, с отсутствием зависимости от порядка.  Не надо 
> тащить в nginx очередную императивную логику, хватит с нас 
> rewrite-модуля.

Понятно, переосмыслил концепцию с учетом этого замечания.
Тогда, конечно, предлагаемый мной параметр last и "условный off" в принципе
недопустимы. 

> Сделать явный отдельный параметр if - можно, но сколько-нибудь
> принципиальной разницы нет.  В то же время не факт, что мы хотим 
> тут усложнять синтаксис.

Если условия везде одинаковые, то они задаются map-ом, пусть и чуть более
громоздким конфигом, чем с параметром if. Принципиальная разница появляется
только в том, что в разные директивы limit_req в параметр if можно задать разные
условия.

В директиве access_log такой синтаксис есть и мне кажется, что это весьма
удобное решение. Хотелось бы понять, насколько оно востребованно применительно к
limit_req.

> Если хочется программировать - стоит подумать о том, чтобы 
> вытащить результаты ограничений в переменные, и дальше 
> программировать с помощью директив rewrite-модуля же.

Можно увидеть пример конфигурации, как она могла бы быть заданной
таким способом?
Например, для двух условий: $is_spider и $is_vip.
Если $is_vip - ограничений вообще нет, если $is_spider - одна зона
(ограничения), иначе вторая (другие ограничения)?

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

> Это уже записано в TODO, возможность отказаться от унаследованных 
> ограничений, безусловно, нужна.

>> Из планируемых вещей также есть мысли по поводу добавления параметра 
>> "dry-run".

> Да, сделать возможность проверки ограничений без их реального
> применения - тоже уже в TODO.

Судя по всему, это должен быть параметр директивы limit_req_zone. Как он зовется
в вашем TODO?

"Patches are welcome"? По этим двум пунктам они достаточно тривиальны.

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: $realip_remote_addr выдает айпи прокси а не клиента

[Pavel V.]

Здравствуйте, Андрей.

Вы писали 24 января 2016 г., 4:45:36:


> В конфиге прописано:

> real_ip_header X-Forwarded-For;
> real_ip_recursive on;
> set_real_ip_from 94.23.0.0/16;

>  proxy_set_header   X-Real-IP$realip_remote_addr;
>  proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;


> На бэкнде получаю в X_REAL_IP айпи прокси а не клиента:

>  [HTTP_X_REAL_IP] => 94.23.156.246
>  [HTTP_X_FORWARDED_FOR] => 176.104.49.220, 94.23.156.246
>  [REMOTE_ADDR] => 94.23.156.246

> Кто виноват и что делать?

Всё работает так, как вы указали в конфигурации.

Цитирую http://nginx.org/ru/docs/http/ngx_http_realip_module.html :

$realip_remote_addr -  хранит исходный адрес клиента (1.9.7)

В данном случае клиентом является то, что соединилось с nginx, т.е. прокси.

Вам следует использовать переменную $remote_addr:

proxy_set_header X-Real-IP $remote_addr;

Возможно также, что директива "proxy_set_header   X-Forwarded-For  " совсем 
не нужна,
чаще всего это наследие копипаста. Для получения IP реального клиента 
достаточно X-Real-IP.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: баг сафари на http/2

[Pavel Mihaduk]

Судя по спеке, заголовок действительно необязательный, так что это баг не 
сафари.

>A request or response that includes a payload body can include a 
>content-length header field. A request or response is >also malformed if the 
>value of a content-length header field does not equal the sum of theDATA 
> frame payload lengths >that form 
>the body. 

> On 20 окт. 2015 г., at 13:00, Илья Шипицин  wrote:
> 
> Добрый день!
> 
> налетели на ситуацию
> 
> 1) браузер сафари (без разницы - десктопный или мобильный)
> 2) включен http2
> 3) отправляется POST с пустым телом
> 4) запрос проксируется с nginx на http-апстрим
> 
> в результате получается, что сафари, видя, что тело пустое - не добавляет 
> Content-Length, а nginx, видя, что Content-Length отсутствует - возвращает 411
> 
> давайте с этим что-нибудь сделаем ?
> 
> стенд для воспроизведения бага: https://http2.skbkontur.ru 
> 
> 
> Илья Шипицин
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re: Проблемы с бэкэндом на http2

[Pavel Odintsov]

Приветствую!

Спасибо за ответ!

Но проблема несколько шире. Уже много фреймфорков написанных чисто на
http 2.0 (gRPC - и это только начало), которые не содержат большого
количества ненужного кода для поддержки http 1.1 просто потому что он
не нужен и смысла в нем минимум.

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

Я за унификацию :) Скорее вижу подход, где между бэкэндом и реверс
прокси бегает http2, а также во всей внутренней инфраструктуре и
силами реверс прокси это дело понижается до особо не продвинутых
внешних клиентов.

Но схему наоборот - http2 до публичного клиента и древний http 1.1 в
бэнбоне не вяжется, не нравится мне это.



2015-10-19 15:50 GMT+03:00 Maxim Dounin <mdou...@mdounin.ru>:
> Hello!
>
> On Sun, Oct 18, 2015 at 09:58:20PM +0300, Pavel Odintsov wrote:
>
>> Всем привет!
>>
>> Имеется сервер gRPC на С++, который работает только поверх
>> шифрованного HTTP2. Имеется желание его проксировать силами Nginx для
>> повышения надежности и реверс-проксирования.
>>
>> Суть в том, что Nginx должен общаться с gRPC бэкэндом только по
>> HTTP2/TLS, иначе оно не работает.
>>
>> Но Nginx не может подключиться к http2 бэкэнду вот с такой ошибкой:
>> 2015/10/18 20:54:07 [error] 2954#2954: *3 peer closed connection in
>> SSL handshake while SSL handshaking to upstream, client: 127.0.0.1,
>> server: api.fastnetmon.io, request: "POST
>> /fastmitigation.Fastnetmon/GetBanlist HTTP/2.0", upstream:
>> "https://127.0.0.1:10777/fastmitigation.Fastnetmon/GetBanlist;, host:
>> "api.fastnetmon.io:443"
>
> [...]
>
> Just for the record:
>
> Разгадка в том, что поддержки HTTP/2 в proxy - нет и не
> планируется.
>
> Основное преимущество SPDY и HTTP/2 перед HTTP - это больший
> параллелизм при меньших затратах на установление соединений (одно
> соединение, в нём много запросов одновременно). При работе с
> бекендом - с тем же успехом можно поддерживать нужное количество
> HTTP-соединений, разницы по latency - не будет, по throughput -
> обычный HTTP будет лучше, выигрыш HTTP/2 - только по ресурсам на
> уровне ядра (меньше сокетов).  И чтобы этот выигрыш получить -
> надо переписать работу с upstream'ами чуть менее, чем полностью,
> добавив поддержку мультиплексирования нескольких запросов в одном
> соединении.  Смысла тратить на это силы и время - очень мало.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблемы с бэкэндом на http2

[Pavel Mihaduk]

Я бы не стал доверять проектам, которые пишут бэкенд, поддерживающий 
http2-only. От этой идеи несет хипстерством за километр.

> On 19 окт. 2015 г., at 15:56, Pavel Odintsov <pavel.odint...@gmail.com> wrote:
> 
> Приветствую!
> 
> Спасибо за ответ!
> 
> Но проблема несколько шире. Уже много фреймфорков написанных чисто на
> http 2.0 (gRPC - и это только начало), которые не содержат большого
> количества ненужного кода для поддержки http 1.1 просто потому что он
> не нужен и смысла в нем минимум.
> 
> Отсутствие поддержки http2 со стороны бэкэнда в среде, где с клиентам
> уже можно общаться по http2 будет тормомзом прогресса, потому что мы
> не можем использовать везде http2 и исключительно из-за прихоти
> реверс-прокси должны тыщить http2.
> 
> Я за унификацию :) Скорее вижу подход, где между бэкэндом и реверс
> прокси бегает http2, а также во всей внутренней инфраструктуре и
> силами реверс прокси это дело понижается до особо не продвинутых
> внешних клиентов.
> 
> Но схему наоборот - http2 до публичного клиента и древний http 1.1 в
> бэнбоне не вяжется, не нравится мне это.
> 
> 
> 
> 2015-10-19 15:50 GMT+03:00 Maxim Dounin <mdou...@mdounin.ru>:
>> Hello!
>> 
>> On Sun, Oct 18, 2015 at 09:58:20PM +0300, Pavel Odintsov wrote:
>> 
>>> Всем привет!
>>> 
>>> Имеется сервер gRPC на С++, который работает только поверх
>>> шифрованного HTTP2. Имеется желание его проксировать силами Nginx для
>>> повышения надежности и реверс-проксирования.
>>> 
>>> Суть в том, что Nginx должен общаться с gRPC бэкэндом только по
>>> HTTP2/TLS, иначе оно не работает.
>>> 
>>> Но Nginx не может подключиться к http2 бэкэнду вот с такой ошибкой:
>>> 2015/10/18 20:54:07 [error] 2954#2954: *3 peer closed connection in
>>> SSL handshake while SSL handshaking to upstream, client: 127.0.0.1,
>>> server: api.fastnetmon.io, request: "POST
>>> /fastmitigation.Fastnetmon/GetBanlist HTTP/2.0", upstream:
>>> "https://127.0.0.1:10777/fastmitigation.Fastnetmon/GetBanlist;, host:
>>> "api.fastnetmon.io:443"
>> 
>> [...]
>> 
>> Just for the record:
>> 
>> Разгадка в том, что поддержки HTTP/2 в proxy - нет и не
>> планируется.
>> 
>> Основное преимущество SPDY и HTTP/2 перед HTTP - это больший
>> параллелизм при меньших затратах на установление соединений (одно
>> соединение, в нём много запросов одновременно). При работе с
>> бекендом - с тем же успехом можно поддерживать нужное количество
>> HTTP-соединений, разницы по latency - не будет, по throughput -
>> обычный HTTP будет лучше, выигрыш HTTP/2 - только по ресурсам на
>> уровне ядра (меньше сокетов).  И чтобы этот выигрыш получить -
>> надо переписать работу с upstream'ами чуть менее, чем полностью,
>> добавив поддержку мультиплексирования нескольких запросов в одном
>> соединении.  Смысла тратить на это силы и время - очень мало.
>> 
>> --
>> Maxim Dounin
>> http://nginx.org/
>> 
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> 
> -- 
> Sincerely yours, Pavel Odintsov
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re: Проблемы с бэкэндом на http2

[Pavel Odintsov]

Есть еще один очевидный кейс, если этот кейс не нравится. Когда бэкэнд
и фроентед разнесены километров на пары тысяч. Такой кейс есть у DDoS
защитников и крупных контентщиков с большими anycast сетями.

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

Хипстерство или нет - каждому решать самому, но если пишешь реально
быстрое приложение на С/С++ (вроде бы они еще не стали хипстерскими?)
работать с бинарным протоколом решительно приятнее, с текстовым
http/1.1.

Но к счастью решение есть и лично мне оно на первы взгляд нравится:
https://nghttp2.org - подключает все семейство http1 / spdy / http2 в
любом направлении :)

2015-10-19 16:08 GMT+03:00 Pavel Mihaduk <le...@nixkid.com>:
> Я бы не стал доверять проектам, которые пишут бэкенд, поддерживающий 
> http2-only. От этой идеи несет хипстерством за километр.
>
>> On 19 окт. 2015 г., at 15:56, Pavel Odintsov <pavel.odint...@gmail.com> 
>> wrote:
>>
>> Приветствую!
>>
>> Спасибо за ответ!
>>
>> Но проблема несколько шире. Уже много фреймфорков написанных чисто на
>> http 2.0 (gRPC - и это только начало), которые не содержат большого
>> количества ненужного кода для поддержки http 1.1 просто потому что он
>> не нужен и смысла в нем минимум.
>>
>> Отсутствие поддержки http2 со стороны бэкэнда в среде, где с клиентам
>> уже можно общаться по http2 будет тормомзом прогресса, потому что мы
>> не можем использовать везде http2 и исключительно из-за прихоти
>> реверс-прокси должны тыщить http2.
>>
>> Я за унификацию :) Скорее вижу подход, где между бэкэндом и реверс
>> прокси бегает http2, а также во всей внутренней инфраструктуре и
>> силами реверс прокси это дело понижается до особо не продвинутых
>> внешних клиентов.
>>
>> Но схему наоборот - http2 до публичного клиента и древний http 1.1 в
>> бэнбоне не вяжется, не нравится мне это.
>>
>>
>>
>> 2015-10-19 15:50 GMT+03:00 Maxim Dounin <mdou...@mdounin.ru>:
>>> Hello!
>>>
>>> On Sun, Oct 18, 2015 at 09:58:20PM +0300, Pavel Odintsov wrote:
>>>
>>>> Всем привет!
>>>>
>>>> Имеется сервер gRPC на С++, который работает только поверх
>>>> шифрованного HTTP2. Имеется желание его проксировать силами Nginx для
>>>> повышения надежности и реверс-проксирования.
>>>>
>>>> Суть в том, что Nginx должен общаться с gRPC бэкэндом только по
>>>> HTTP2/TLS, иначе оно не работает.
>>>>
>>>> Но Nginx не может подключиться к http2 бэкэнду вот с такой ошибкой:
>>>> 2015/10/18 20:54:07 [error] 2954#2954: *3 peer closed connection in
>>>> SSL handshake while SSL handshaking to upstream, client: 127.0.0.1,
>>>> server: api.fastnetmon.io, request: "POST
>>>> /fastmitigation.Fastnetmon/GetBanlist HTTP/2.0", upstream:
>>>> "https://127.0.0.1:10777/fastmitigation.Fastnetmon/GetBanlist;, host:
>>>> "api.fastnetmon.io:443"
>>>
>>> [...]
>>>
>>> Just for the record:
>>>
>>> Разгадка в том, что поддержки HTTP/2 в proxy - нет и не
>>> планируется.
>>>
>>> Основное преимущество SPDY и HTTP/2 перед HTTP - это больший
>>> параллелизм при меньших затратах на установление соединений (одно
>>> соединение, в нём много запросов одновременно). При работе с
>>> бекендом - с тем же успехом можно поддерживать нужное количество
>>> HTTP-соединений, разницы по latency - не будет, по throughput -
>>> обычный HTTP будет лучше, выигрыш HTTP/2 - только по ресурсам на
>>> уровне ядра (меньше сокетов).  И чтобы этот выигрыш получить -
>>> надо переписать работу с upstream'ами чуть менее, чем полностью,
>>> добавив поддержку мультиплексирования нескольких запросов в одном
>>> соединении.  Смысла тратить на это силы и время - очень мало.
>>>
>>> --
>>> Maxim Dounin
>>> http://nginx.org/
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>> --
>> Sincerely yours, Pavel Odintsov
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Проблемы с бэкэндом на http2

[Pavel Odintsov]

Всем привет!

Имеется сервер gRPC на С++, который работает только поверх
шифрованного HTTP2. Имеется желание его проксировать силами Nginx для
повышения надежности и реверс-проксирования.

Суть в том, что Nginx должен общаться с gRPC бэкэндом только по
HTTP2/TLS, иначе оно не работает.

Но Nginx не может подключиться к http2 бэкэнду вот с такой ошибкой:
2015/10/18 20:54:07 [error] 2954#2954: *3 peer closed connection in
SSL handshake while SSL handshaking to upstream, client: 127.0.0.1,
server: api.fastnetmon.io, request: "POST
/fastmitigation.Fastnetmon/GetBanlist HTTP/2.0", upstream:
"https://127.0.0.1:10777/fastmitigation.Fastnetmon/GetBanlist;, host:
"api.fastnetmon.io:443"

Отладочный лог следующий:
https://gist.github.com/pavel-odintsov/a63be495bc8c97e263ce

gRPC сервер ругается вот так:
E1018 20:57:43.0086738592849 security_connector.c:485]   Missing
selected ALPN property.
E1018 20:57:43.0087036812849 handshake.c:133]Peer check failed.
E1018 20:57:43.0087157642849 server_secure_chttp2.c:154] Secure
transport failed with error 2

Судя по всему, ему нужно каким-то образом явно передать ALPN что оно
HTTP2, но это сделать с Nginx - я не понимаю :(

Мой конфиг вот такой:

user  nginx;
worker_processes  1;

# warn
error_log  /var/log/nginx/error.log debug;
pid/var/run/nginx.pid;


events {
worker_connections  1024;
}


http {
include   /etc/nginx/mime.types;
default_type  application/octet-stream;

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
  '$status $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for" http
v2: $http2';

access_log  /var/log/nginx/access.log  main;

sendfileon;
#tcp_nopush on;

keepalive_timeout  65;

#gzip  on;

#include /etc/nginx/conf.d/*.conf;

server {
listen 443 ssl http2 default_server;

server_name api.fastnetmon.io;

ssl_certificate /usr/src/fastnetmon/src/server.crt;
ssl_certificate_key /usr/src/fastnetmon/src/server.key;

#root /var/www/html;
location / {
proxy_ssl_protocols TLSv1.2;
add_headerAlternate-Protocol  10777:npn-spdy/3;
proxy_pass https://127.0.0.1:10777;
proxy_set_header   Host $host;
}
}
}



-- 
Sincerely yours, Pavel Odintsov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не применятеся список разрешённых протоколов SSL.

[Pavel Mihaduk]

Наблюдал аналогичное поведение на CentOS 5.9, nginx 1.6.* - в контексте server 
директива игнорируется.
> On 1 сент. 2015 г., at 14:09, Alex Domoradov  > wrote:
> 
> А в документации указано
> 
> Контекст: http, server
> 
> У себя проверил, выставил в блоке http - ssl_protocols TLSv1.2; Без 
> изменений, sslv3 принимает
> 
> 2015-09-01 13:55 GMT+03:00 ekassir  >:
> Проблема обнаружена:
> директива ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
> работает глобально, а не для каждого отдельного сайта.
> 
> Придётся прописывать всё в общем конфиге.
> 
> Posted at Nginx Forum: 
> http://forum.nginx.org/read.php?21,261349,261355#msg-261355 
> 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org 
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org 
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: проксирование стилей

[Pavel V.]

 Причём тут локейшн москва?
 по линку http://megasait.org/moskva/ контент загружается с example.org,
 стили загружаются с megasait.org а надо с example.org
 что я делаю не так?

Вы не смотрите на конфиг целиком.
Вероятно у вас есть другие location, кроме приведенных двух.

Прочитайте документацию:

http://nginx.org/ru/docs/http/ngx_http_core_module.html#location

Обратите внимание на

Если у совпавшего префиксного location’а максимальной длины
указан модификатор “^~”, то регулярные выражения не проверяются.

Теперь еще раз вдумчиво перечитайте описание этой директивы (location).

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: nginx phpmyadmin auth_basic

[Pavel V.]

Здравствуйте, bagas.

 Добрый день.
 Подскажите пожалуйста, почему если идти по ссылке site.ru/pma/ то
 авторизация работает, а вот если идти по ссылке site.ru/pma/index.php то
 авторизации нет?

Потому что первый запрос попадает в location /pma где есть авторизация, а 
второй попадает в
location ~ ^/pma/(.*\.php)$ где таковой нет.

Используйте вложенные локейшны, это удобнее.
Либо добавьте директивы auth* во второй ваш локейшн.

Вложенные локейшны - это примерно так:

location ^~ /pma/ {
alias /usr/local/www/phpMyAdmin/;
index index.php;

auth_basic   closed site;
auth_basic_user_file /usr/local/htpasswd;

location ~ \.php$ {
fastcgi_pass unix:/tmp/rey1.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
}
}




-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: nginx phpmyadmin auth_basic

[Pavel V.]

Здравствуйте, bagas.

Вы писали 16 июля 2015 г., 17:13:04:


 Задумался, а не повлияетли такое на безопасность сервера, если несколько
 локейшенов будут содержать обработку php?

Несколько локейшнов и безопасность сервера - связаны почти никак.

 К примеру я хочу ограничить доступ к пма и админке, я создам в одном конфиге
 виртуал хсота как бы 3 точки обработки php.

С одного виртхоста можно посылать запросы на обработку в php и в разные пулы 
php-fpm на одной машине
и на разные сервера с независимыми php-fpm. Это нормально.

Безопасность определяется совсем другими вещами.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

proxy_bind в ngx_stream_proxy_module

[Pavel Mironov]

Добрый день!

А можно ожидать в обозримом будущем появления директивы proxy_bind в
ngx_stream_proxy_module, аналогичной таковой в ngx_http_proxy_module?

А то именно этой опции не хватает, чтобы окончательно уйти с haproxy на
nginx :)

Заранее спасибо!

--
Pavel Mironov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Большой POST запрос и мгновенный редирект

[Pavel V.]

Здравствуйте, Михаил.

Вы писали 31 марта 2015 г., 3:02:52:

 Здравствуйте, Viacheslav.

 Вопрос следующий: есть клиентское приложение (сайт), которое
 отсылает большие (~50MB) посты мультипартом. Хочется на некоторые
 отсылать редирект: 302 или 307 √ не имеет значения. Но сразу, а не
 зачитывая/буферезируя реквест боди на прокси. Можно?

Как должны определяться эти самые некоторые ?

 Могу ошибаться, но по протоколу http 1 ответ отправляется после
 получения всего запроса. Т.е. нельзя.

А 413 (Request Entity Too Large) когда отправляется? Тоже после получения всего 
запроса?


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Цепочка nginx proxy

[Pavel Mihaduk]

Может, хотя бы для uwsgi сделать исключение? Он как раз ожидает 
подчеркивания.

On 24 March 2015 15:12:57 Maxim Dounin wrote:
 Hello!
 
 On Tue, Mar 24, 2015 at 11:34:21AM +0300, Pavel Mihaduk wrote:
  Кстати, в связи с подчеркиваниями у меня давно вопрос: чего ради было
  делать дефолт именно таким, какой он есть? Мне в свое время это доставило
  немало головной боли с uwsgi, когда nginx выбрасывал REQUEST_METHOD :(
 
 Потому что в рамках протокола CGI (используемого, в своих
 вариациях, чуть менее, чем везде, включая переменные $http_... в
 самом nginx'е) заголовки представляются в виде переменных с
 именами HTTP_HEADER_NAME, и заголовки с подчёркиваниями - не
 отличимы от заголовков со стандартным дефисом.  Соответственно
 заголовки с подчёркиванием могут быть использованы для того, чтобы
 выдать их за какие-либо специальные заголовки (Content-Length,
 X-Real-IP, whatever).
 
 При этом в HTTP - не бывает стандартных заголовков с
 подчёркиванием, и если вдруг подчёркивание встретилось - это
 чья-то самодеятельность.
 
 Формально, по стандарту HTTP - подчёркивание использовать можно,
 это обычный символ.  Но, в свете вышеизложенного, обрабатывать
 такие заголовки и пропускать их на бекенды - плохая идея.
 
 --
 Maxim Dounin
 http://nginx.org/
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Цепочка nginx proxy

[Pavel Mihaduk]

Кстати, в связи с подчеркиваниями у меня давно вопрос: чего ради было делать 
дефолт именно таким, какой он есть? Мне в свое время это доставило немало 
головной боли с uwsgi, когда nginx выбрасывал REQUEST_METHOD :(

On 24 March 2015 01:27:25 Maxim Dounin wrote:
 Hello!
 
 On Mon, Mar 23, 2015 at 05:50:59PM -0400, MereMortals wrote:
  Добрый день!
  
  В интернете решения так и не нашел.
  
  Есть такая схема
  
  клиент -nginx_1 -nginx_2-apache
  
  На nginx_1 настрен GeoIP и в настройках прописано:
  
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $remote_addr;
  proxy_set_header X-Real-IP $my_real_ip;
  proxy_set_header GEOIP_COUNTRY_CODE $geoip_country_code;
  proxy_set_header GEOIP_COUNTRY_CODE3 $geoip_country_code3;
  proxy_set_header GEOIP_COUNTRY_NAME $geoip_country_name;
  proxy_set_header GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
  proxy_set_header GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
  proxy_set_header GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
  proxy_set_header GEOIP_CITY_COUNTRY_NAME2 $geoip_city_country_name;
  proxy_set_header GEOIP_REGION $geoip_region;
  proxy_set_header GEOIP_CITY $geoip_city;
  proxy_set_header GEOIP_POSTAL_CODE $geoip_postal_code;
  proxy_set_header GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
  proxy_set_header GEOIP_LATITUDE $geoip_latitude;
  proxy_set_header GEOIP_LONGITUDE $geoip_longitude;
  
  Но почему то до apache не доходят заголовки GEOIP_*, но доходят
  X-Forwarded-For и X-Real-IP. На вход у nginx_2 заголовки приходят,
  проверено через tcpdump, но почему то он их не проксирует. В чем может
  быть причина?
 Не надо использовать символ подчёркивания в HTTP-заголовках, от
 этого возникает множество ненужных проблем.
 
 Если всё же очень надо (e.g., подобный заголовок присылает внешний
 сервис), то есть директива underscores_in_headers, которая
 разрешает nginx'у такие заголовки проксировать дальше:
 
 http://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_heade
 rs
 
 В данном случае - правильнее будет переименовать заголовки.
 
 --
 Maxim Dounin
 http://nginx.org/
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: общий кэш для нескольких nginx

[Pavel Mihaduk]

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


Ситуация в том что есть железный балансировщик, он раскидывает трафик по 
4-6 штукам nginx, а нжинксы балансируя траффик с помощью апстрима 
перенаправляют на бэкенд сервера. На балансировщиках nginx  настроен кэш. 
Получается что на всех балансировщиках разный кеш. Допусти клиентский 
запрос попавший на балансир номер 1 кеша там не обнаружилось и запрос 
пошел на бэкенд, в то время как на балансировщике номер 2 нужный кеш в 
этот момент был, но по понятным причинам не был использоан. Вообщем если 
сделать общий кеш для всех балансировщиков nginx  можно получить хороший 
прирост производительности.


С уважением, Михаил


23 марта 2015 г., 12:56 пользователь Илья Шипицин chipits...@gmail.com[1] 
написал:


возможно, вы придете к монстроидной схеме

nginx -- squid (с поддержкой ICAP) -- бекенды

и даже после танцев с бубном вы ее настроите.

но, практика показывает, что в таких случаях надо уметь отвечать навопрос 
зачем это надо ?.после ответа на который часто оказывается, что на самом 
деле - не надо.

вы бы рассказали про вашу ситуацию в деталях ?

23 марта 2015 г., 13:54 пользователь Михаил Пульман pull...@gmail.com[2] 
написал:


 Добрый день коллеги! На фронте имеется n-ое количество nginx которые 
выступают в качестве балансировщиков. Нужно наладить единый кэш для 
всех фронтенд nginxов. Какие есть возможности в nginx для реализации этой 
задачи? С уважением, Михаил


 ___ nginx-ru mailing list nginx-
r...@nginx.org[3]
http://mailman.nginx.org/mailman/listinfo/nginx-ru[4]
nginx-ru@nginx.org[3]
http://mailman.nginx.org/mailman/listinfo/nginx-ru[4]






[1] mailto:chipits...@gmail.com
[2] mailto:pull...@gmail.com
[3] mailto:nginx-ru@nginx.org
[4] http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: общий кэш для нескольких nginx

[Pavel Mihaduk]

Я так понимаю, у вас не самый маленький проект. 
Представьте себе _взаимную_ (master-master) 
синхронизацию между несколькими серверами.




Валентин, почему Вы считаете что кеш станет узким местом? 
Разъясните если не трудно. 


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

Re: proxy pass редирект на другой сервер

[Pavel Mihaduk]

proxy_set_header Host $host;

Вы уверены, что википедия нормально работает на вашем домене? ;)

On 20 March 2015 09:08:55 voronkov wrote:
 Всем привет!
 
 Пытаюсь сделать, чтобы https://multiqa.com/testzzz делал внутренний редирект
 на https://www.wikipedia.org/
 
 Нашел рецепт редиректа на другой физический сервер:
 http://serverfault.com/questions/308238/redirecting-from-one-nginx-to-anothe
 r upstream newserver {
   server 172.16.0.1:80;  # this is new server, by IP address
 }
 server {
   listen 80;
   server_name subdomain.site.ru;
   location / {
 proxy_set_header Host $host;
 proxy_pass http://newserver;
   }
 }
 
 В результате получаю 404-ошибку.
 Подскажите в каком направлении искать, а то уже весь мозг сломал.
 Если что, - страница https://www.wikipedia.org/ на моем сервере получается
 нормально (проверял через lynx и wget)
 
 P.S.:
 На всякий случай вот мой конфиг:
 upstream newserver {
 server 91.198.174.192:80; # www.wikipedia.org by IP address
 }
 server {
 limit_conn   myzone  10;
 listen 80;
 
 server_name multiqa.com www.multiqa.com;
 rewrite ^   https://multiqa.com$request_uri? permanent;
 rewrite ^   https://www.multiqa.com$request_uri? permanent;
 rewrite ^   http://test.multiqa.com$request_uri? permanent;
 error_page 404 /404.html;
 location = /404.html {
 root /usr/share/nginx/html;
 }
 
 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root /usr/share/nginx/html;
 }
 
 location /testzzz {
 proxy_set_header Host $host;
 proxy_pass https://newserver;
 }
 
 location / {
 proxy_pass http://127.0.0.1:1081;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_redirect off;
 client_max_body_size 150m;
 client_body_buffer_size 128k;
 proxy_connect_timeout 90;
 proxy_send_timeout 90;
 proxy_read_timeout 240;
 proxy_buffer_size 128k;
 proxy_buffers 256 16k;
 proxy_busy_buffers_size 256k;
 proxy_temp_file_write_size 256k;
 expires 24h;
 }
 
 # ... and so on ...
 }
 
 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,257488,257488#msg-257488
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Некорректная работа add_after_body

[Pavel Mihaduk]

Перестать жать на бэкенде и делать это на самом nginx, кажется, единственный 
вариант.


Да, получается на nginx приходит сжатый ответ и инжект не срабатывает.
Подскажите каким образом можно произвести инжект js-скрипта в ответ, если на 
nginx со стороны сервера приложения приходит уже сжатый ответ ?


С уважением, Михаил


19 марта 2015 г., 11:41 пользователь Aleksandr Sytar sytar.a...@gmail.com[1] 
написал:






19 марта 2015 г., 11:36 пользователь Михаил Пульман pull...@gmail.com[2] 
написал:


содержимое inject.html следующего вида:
!-- test --
script type=text/javascript
код скрипта
/script
!-- test --




Соответственно содержимое в формате html и не сжато. Более глубокое 
тестирование показало что инжект происходит когда запрос приходит от 
браузеров chrome, opera и не происходит когда запрос приходит от ie или 
firefox. 
Содержимое inject.html пробовал разнообразное, начиная от html кода и 
заканчивая произвольным текстом, ситуация во всех случаях одинаковая.




curl -v -I --compressed http://урл_к_которому_мы_хотим_заинжектить_данные[3]


Если вы получите ошибку - значит сервер не умеет сжимать данные и всегда 
возвращает html к которому можно приклеить свой. Иначе, возвращаются 
сжатые данные, которые нужно предварительно распаковать.


 


С уважением, Михаил


18 марта 2015 г., 17:15 пользователь Maxim Dounin mdou...@mdounin.ru[4] 
написал:


Hello!

On Wed, Mar 18, 2015 at 04:58:28PM +0300, Михаил Пульман wrote:

[...]

 Суть в том что при любом запросе у сервера example01.ru[5], в ответ должен 
приходить ответ + Содержимое inject.html Содержимое inject.html добавляется 
к телу ответа не всегда. В чем может быть проблема?

В том, что ответ не html (http://nginx.org/r/addition_types/ru[6])или сжат.


http://nginx.org/[7]
nginx-ru@nginx.org[8]
http://mailman.nginx.org/mailman/listinfo/nginx-ru[9]



nginx-ru@nginx.org[8]
http://mailman.nginx.org/mailman/listinfo/nginx-ru[9]




nginx-ru@nginx.org[8]
http://mailman.nginx.org/mailman/listinfo/nginx-ru[9]







[1] mailto:sytar.a...@gmail.com
[2] mailto:pull...@gmail.com
[3] http://xn--__-7nfb9aidhlmdcxbjgzbc2ahahaae3ch8dikbhm5fwmwa0b
[4] mailto:mdou...@mdounin.ru
[5] http://example01.ru
[6] http://nginx.org/r/addition_types/ru
[7] http://nginx.org/
[8] mailto:nginx-ru@nginx.org
[9] http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 104 Connection reset от nginx

[Pavel Mihaduk]

Пальцем в небо: tw_recycle пробовали?

On 17 March 2015 11:01:37 Evader wrote:
 Коллеги, привет!
 
 Пытаюсь тестировать различные инстансы EC2 с nginx. Установка простейшая,
 Amazon Linux, nginx/1.6.2 + php-fpm 5.4. Встретился с проблемой, которую
 никак не могу понять как побороть. В качестве инструмента для тестирования
 – ab, weighttp, httpress, неважно, поведение идентично. Пусть есть location
 с единственным /index.php с phpinfo() внутри. nginx общается с fpm через
 unix socket.
 
 В таком режиме сервер легко держит 10К, 20 или даже 30К одновременных
 keepalive подключений. Может даже и больше, особо не проверял. Но 
проблема
 заключается в том, что при увеличении количества запросов, появляются 104
 Connection reset от самого nginx, которые фиксируются weighttp, например.
 Бывает еще Connection timed out (110), но реже. Удивительно то, что при 100К
 запросах, все работает идеально. Можно сколько угодно раз прогонять
 weighttp с 20К параллельными коннектами и общим числом запросов в 100 
тысяч
 – все будет работать. Как только число запросов увеличивается 100К –
 начинают лезть 104 reset. Эмпирическим путем я выяснил, что их момент
 появления напрямую зависит от установленного keepalive_timeout. То есть,
 если его отодвинуть в 2 раза больше, то успешно будут выполняться не 100, а
 условно 200К запросов. Если наоборот зажать до 10 секунд, все будет
 фейлиться почти сразу.
 
 При этом никаких сообщений в error логе нет. Что именно смотреть в tcpdump
 при таком поведении я не очень понимаю. somaxconn, backlog самого nginx
 задраны максимально, значения согласно ss -l применяются успешно.
 Подскажите, в какую вообще сторону копать/смотреть? Конкретных
 конфигов/sysctl не предоставляю, потому что кроме беклога, задранных
 worker_connections и установленных 4 воркерах при 8 ядрах все остальное –
 дефолтное. fpm так же довольствуется минимальными значениями в 
настройках,
 да и очевидных ошибок о достижении лимитов error логе нет.
 
 Заранее большое спасибо за идеи и помощь!
 
 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,257330,257330#msg-257330
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [security advisory] http://wiki.nginx.org/Redmine

[Pavel V.]

Здравствуйте, Дмитрий.

 вообще-то root должен смотреть в папку public, в вашем случае 
 /var/www/redmine/public/

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

Как вы и сказали, root должен указывать в public/, но в примере, который 
изначально был на странице,
он указывает не в public/, а на уровень выше. Т.е. должен, но не указывает.

При этом конфиг остается работоспособным - если try_files $uri не нашло нужный 
файл напрямую,
запрос проксируется на бэкенд и на запрос будет выдан ожидаемый результат.

Проблема возникает в тот момент, когда try_files $uri _срабатывает_ на 
специально сформированный
запрос, в результате которого возможна утечка приватных данных.

Конфиг, который был на странице до исправлений:

 server {
  server_name redmine.DOMAIN.TLD;
  root /var/www/redmine;

  location / {
  try_files $uri @ruby;
  }

  location @ruby {
  proxy_set_header  X-Real-IP  $remote_addr;
  proxy_set_header  X-Forwarded-For 
 $proxy_add_x_forwarded_for;
  proxy_set_header  Host $http_host;
  proxy_redirect off;
  proxy_read_timeout 300;
  proxy_pass http://redmine;
  }
 }

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Странности с try_files

[Pavel V.]

Здравствуйте, greenh.

Вы писали 6 декабря 2014 г., 19:21:40:

 Похоже проблема в пробельных символах
 На диске создается путь вида images/torrents%20films, а ищется 
 images/torrents films. И как с этим бороться?

Приведите ссылки в соответствие с именами файлов и каталогов на диске, не 
забывая про экранирование.

https://ru.wikipedia.org/wiki/URL#.D0.9A.D0.BE.D0.B4.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_URL



-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Странности с try_files

[Pavel V.]

Здравствуйте, greenh.

Вы писали 6 декабря 2014 г., 19:54:00:

 К сожалению изменить ссылки не возможно.  Похоже решением будет в proxy_store 
 прописать не
 $request, а urldecode от request, вот только как это сделать?

1) try_files $uri
2) proxy_store /home/site.com/img.site.com/$request_uri;

Ищете файлы по $uri, пишете файлы по $request_uri. Где логика?

В примере в документации
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store

еще есть отсылка к переменной $original_uri.

Успехов.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Странности с try_files

[Pavel V.]

Здравствуйте, greenh.

Вы писали 7 декабря 2014 г., 0:37:13:

 6 декабря 2014 г., 20:17 пользователь Pavel V. pavel2...@ngs.ru написал:
 Здравствуйте, greenh.

 Вы писали 6 декабря 2014 г., 19:54:00:

 К сожалению изменить ссылки не возможно.  Похоже решением будет в 
 proxy_store прописать не
 $request, а urldecode от request, вот только как это сделать?

 1) try_files $uri
 2) proxy_store /home/site.com/img.site.com/$request_uri;

 Ищете файлы по $uri, пишете файлы по $request_uri. Где логика?
 Спасибо, логично. Хотя, при отсутствии переменных в get запросе и редиректов 
 они будут идентичны.

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

Можно залогировать эти переменные и посмотреть:

http://nginx.org/ru/docs/http/ngx_http_log_module.html#access_log
http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_format


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Необходимо исправление в документации

[Pavel V.]

Здравствуйте, Nginx-ru.

Просьба исправить в документации 
http://nginx.org/ru/docs/http/ngx_http_core_module.html#location
абзац:

Если location задан префиксной строкой со слэшом в конце и запросы 
обрабатываются при помощи
proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass или memcached_pass, а в ответ 
на запрос с URI равным
этой строке, но без завершающего слэша, будет возвращено постоянное 
перенаправление с кодом 301 на
URI с добавленным в конец слэшом. Если такое поведение нежелательно, можно 
задать точное совпадение
URI и location, например:

видимо, необходимо убрать а в ..., а в ответ... ну и пунктуацию подправить.

Спасибо.

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Несколько expire

[Pavel V.]

Здравствуйте, Edrard.

Вы писали 16 июля 2014 г., 20:39:10:

 Здравствуйте. Нужна ваша помощь. Необходимо выставить для одной папки
 /images expire равный 30d, а для всей остальной статистики 1d

Пожалуйста, прочитайте документацию. Она написана по-русски и достаточно внятно.

http://nginx.org/ru/docs/http/ngx_http_core_module.html#location

Цитирую:

Чтобы найти location, соответствующий запросу, вначале проверяются location’ы, 
заданные префиксными
строками (префиксные location’ы). Среди них ищется location с совпадающим 
префиксом максимальной
длины и запоминается. Затем проверяются регулярные выражения, в порядке их 
следования в
конфигурационном файле.

Если у совпавшего префиксного location’а максимальной длины указан модификатор 
“^~”, то регулярные
выражения не проверяются.

У вас модификатор не указан.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Nginx возвращает 499 при проксировании после нескольких часов работы

[Pavel V.]

Здравствуйте, Andruxa.
Вы писали 1 июля 2014 г., 20:16:15:

 Виталий, спасибо за информацию! Попробуем настроить и понаблюдать. 

 Сейчас только обнаружил, что ошибся и возможно ввел заблуждение насчет
 счетчиков. 
 Посмотрел показатели не на том адаптере (взял показатели для management
 адаптера).

 Вот такие показатели на основном
   RX packets:612896756 errors:0 dropped:2060993 overruns:0 frame:0
   TX packets:631594750 errors:0 dropped:0 overruns:0 carrier:0

 Тут соотношение dropped/total значительно ниже.
 Какое соотношение можно считать допустимым?

dropped/total = 0.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: аутентификация по клиентскому сертификату SSL

[Pavel V.]

Здравствуйте, Phil.

Вы писали 21 марта 2014 г., 14:23:51:

 Собственно вопрос не новый, но вдруг что-то изменилось.
 1. Есть ли какой-то способ клиенту, который не предоставил сертификат
 вдруг его подставить и аутентифицироваться им?

Что значит вдруг? Вы про HTTP говорите?

 2. Возможно ли насильно сбросить соединение с клиентом? Это решало бы
 не только эту проблему. Грубовато, но часто действенно.

http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return код 444



-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: nginx proxy аутентификация

[Pavel V.]

Здравствуйте, komiller.

Вы писали 24 февраля 2014 г., 18:55:52:

 Здравствуйте.

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

Ознакомьтесь с 
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#ip_hash

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Авторизация

[Pavel V.]

Здравствуйте, Daniel.

Вы писали 24 января 2014 г., 1:41:19:

 2014/1/23 Pavel V. pavel2...@ngs.ru:
 Кто-нибудь может кинуть ссылку на более наглядные объяснения с более 
 человекопонятной схемой,
 как это ломается? Либо может быть кто-то разъяснит на пальцах, как 
 злоумышленник, имея одну или
 несколько пар userId + keyedhash сможет сгенерировать пару admin_userId + 
 valid_keyedhash?
 Полным перебором это ломается. Просто процессоры стали сильно быстрые
 и многоядерные. SHA1 считается слишком быстро.

Почему тогда нет проблемы если использовать HMAC-SHA1 ?

Из-за того, что считается sha1 от вычисленного в sha1,
что  дает сброс внутреннего состояния хеширующей функции?


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Не отображаются картинки после ресайзинга

[Pavel V.]

Здравствуйте, Miklucho.

Вы писали 24 января 2014 г., 14:12:49:



 Мне кажется, что проблема в том, что php сравнительно медленно ресайзит
 изображения и из-за этого срабатывают какие-то таймауты, либо в apache, либо
 в nginx.
 Не подскажет ли кто куда мне копать?

1) Смотрите в логи
2) Смотрите в ответы сервера например в firebug (в Firefox).



-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Адрес отправителя при проксировании

[Pavel V.]

Здравствуйте, misha_shar53.

Вы писали 25 января 2014 г., 11:13:29:

 Есть ли возможность установить Адрес отправителя. Если NGINX используется в
 качестве прокси сервера?

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind



-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?

[Pavel V.]

Здравствуйте, Vladimir.

 Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов.
 От них сделать каналы до серверов (с каждой впски через каждый из аплинков)
 Вы имеете в виду VPN ?

Как один из вариантов - да.
Хотя можно обойтись и прямым проксированием.

 В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал 
 выбирался нужным
 образом.
 если BGP можно реализовать стандартными спсобами linux то я рассмотрю 
 этот вариант.

можно.

 На эти же впски можно выкинуть некий статический контент...
 Для этих же впсок можно прислюнявить DNS с ненулевым TTL, чтобы исключать 
 впски из схемы в случае их
 падения..
 Я уже если честно запутался во все возможных вариантах. Можете пояснить 
 куда его прислюнявить и зачем ?

 Зачем еще DNS сервер(ы) не пониманию если честно.

Вы не внимательно читаете. Я уже написал, зачем. Попробуйте прочитать снова.


 Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ 
 (и необходимость!) этими наворотами
 заниматься.




-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?

[Pavel V.]

Здравствуйте, Васильев.

Вы писали 14 января 2014 г., 19:24:12:

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


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

Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов.
От них сделать каналы до серверов (с каждой впски через каждый из аплинков)
В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал 
выбирался нужным
образом.
На эти же впски можно выкинуть некий статический контент...
Для этих же впсок можно прислюнявить DNS с ненулевым TTL, чтобы исключать 
впски из схемы в случае их
падения..

Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и 
необходимость!) этими наворотами
заниматься.



 14.01.2014, 13:58, Vladimir Skubriev vladi...@skubriev.ru:
 14.01.2014 13:46, Артем Васильев пишет:

 При сильном желании сервить свой крутой и ценный проект на локалхосте - 
 покупается AS, ставится роутер, который может, любит, и умеет в bgp, 
 подключается 2-3 провайдера по оптике c нормальным sla. В противном случае 
 можно продолжать есть кактус с подобными вопросами и запросами, либо 
 выбрать более-менее нормальный хостинг/vps (их есть в россии, и немало, 
 даже для параноиков с особо ценными разработками)
 В вашем предложении для меня сильно много не знакомых слов. Поэтому циски, 
 bgp и провайдеры со sla идут лесом. Это слишком круто.

 В таком случае Вы за frontend nginx на vps вместо update dns via api and 
 small ttl?

 -- -- Faithfully yours, Vladimir Skubriev
 ,
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru

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


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Как в nginx получить html код запрашиваемой страницы ?

[Pavel V.]

Здравствуйте, Neutrino_9.

Вы писали 13 октября 2013 г., 0:59:33:

 А что это за модуль который умеет читать ответ от бекенда, можно пример или
 имя модуля ?

Уж прочитать официальную документацию Вы могли бы.

Я не вижу смысла для Вас в чьих либо ответах, т.к. вы не умеете (их) читать.

В Ваши успехи я больше не верю.

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: http 500

[Pavel V.]

Здравствуйте, Васильев.

Вы писали 15 сентября 2013 г., 6:12:21:

 Hello everybody!
 Попиливаю маленький статический сайтик. После сохранения файла первый его 
 запрос возвращает HTTP
 500. Второй возвращает обновлённую страницу.

  Почему так?

Надо смотреть логи. Возможно, также потребуется повысить уровень детализации 
сообщений.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: nginx и url секция в адресной строке

[Pavel V.]

Здравствуйте, bono90.

Вы писали 30 мая 2013 г., 15:02:20:

 Добрый день!
 Настроил nginx в качестве обратного прокси для доступа к сервису owa
 (exchange server).
 Когда набираю в браузере адрес домена, настроенный для использования owa,
 например: imap.domain.ru - запрос перенаправляется на
 https://imap.domain.ru/owa/auth/logon.aspx?replaceCurrent=1url=https://exchange-server.domain.local/owa/.
 Собственно вопрос как добиться того, чтобы секция URL не присутствовала в
 адресе (url= https://exchange-server.domain.local/owa/).

Перенастройте сервис так, чтобы он именовался не exchange-server.domain.local, 
а  imap.domain.ru.

Проброс сделайте так:

proxy_pass https://192.168.3.4;
proxy_set_header Host 'imap.domain.ru';




-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Доступ по ip ИЛИ через клиентский сертификат - возможно ли?

[Pavel V.]

Здравствуйте, itonohito.

Вы писали 15 мая 2013 г., 16:46:22:

 Добрый день!

 Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к
 сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip? 
 Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с
 любого ip, а кроме того - с некоторых ip доступ был для всех и без
 сертификата тоже.

Здравствуйте.

Вы можете сконфигурировать отдельный server {} на отдельном порту, разрешающий 
доступ по IP без
требования сертификата, и завернуть трафик с некоторых IP на этот порт, 
например через
iptables -t nat -I PREROUTING -s 1.2.3.4/25 -d 8.8.7.7 -p tcp --dport 443 -j 
DNAT --to-destination=8.8.7.7:444



-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Слив трафика

[Pavel V.]

Здравствуйте, gvozd.

Вы писали 14 апреля 2013 г., 10:57:41:

 Здравствуйте!
 Помогите решить проблему, происходит очень большой слив исходящего трафика,
 tcpdump'ом удалось выяснить, что nginx получает запрос:

 HTTP/1.1 302 OK
 Connection: Keep-Alive
 Location:
 http://affiliationpartner.it/tutorial/adesionecampagne.mov?COLLCC=1830002745COLLCC=3039517559;
 htmlredirect.../html


Это не HTTP-запрос, это HTTP-ответ.

 После чего происходит загрузка этого файла и накрутка трафика.

Я так понимаю, что указанный файл отдается не с вашего сервера, соответственно 
накрутки нет.
Разберитесь сами в том, как работает HTTP, либо наймите компетентного 
специалиста.
Из вами вышенаписанного проблемы не видно ни в настройках Nginx, ни в самой 
описанной ситуации.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: 500 read timeout

[Pavel V.]

Здравствуйте, nurdus.

 Не давно установил nginx и начались проблемы, знаю что из-за кривизны рук, а
 точнее отсутствие опыта.

 На сайте вызывается скрипт который может выполняться до 5 минут. Скрипт
 вызывается через cron, если вызывает через адресную строку в браузере всё
 отрабатывается нормально.

1) Вот и вызывайте его через крон, напрямую через php интерпретатор,
 а не через веб-сервера. Наши программисты переучились, переучили скрипты, 
теперь все счастливы.

2) Вы так и не сказали, что за проблемы начались. Проверьте еще раз, сколько 
выполняется ваш скрипт.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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

Re: Исключение для списка файлов

[Pavel V.]

Здравствуйте, Andrey.

Вы писали 26 февраля 2013 г., 21:59:48:

 Здравствуйте, Уважаемый(-ая, -ое) Алексей Бобок!

АБ Приветствую.
АБ Есть средней нагруженности видеосторадж (700мбит/сек)
АБ На нем есть порядка 150 mp4/flv видео, для которых нужно включить
АБ огранчение по гео.
АБ К сожалению, эти файлы можно только перечислить списком типа:
АБ /www/a.video/users/123456/u123456__.mp4
АБ /www/a.video/users/654321/u654321__.flv

АБ Какие будут рекомендации, чтобы решить эту задачу максимально дешево
АБ по ресурсам?

 Как уже было сказано, строите карту (map) своих файлов и перекидываете клиента
 по результатам.
 Для больших, редко изменяющихся списков карты - самый быстрый и дешевый 
 способ.


А нагенерировать скриптом 150 location = /file/uri/u123_555.ext {} - не лучше?
If-а, опять же, не будет.


-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

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