Re: Непонятна работа limit_rate

[Илья Шипицин]

вт, 6 окт. 2020 г. в 12:43, Evgeniy Berdnikov :

> On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote:
> > День добрый!
> >
> > Вы качаете файл, получаемых от прокси апстрима?
> >
> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size
> >
> > Вы упираетесь в 1Гб временного файла. когда качается быстро, он
> > вообще в темп не пишется, если файл прилетает от апстрима быстрее
> > чем забираем, то он уже пишется во временный файл. вы успеваете
> > скачать столько, сколько прилетает до начала записи во временный
> > файл + макс размер файла.
>
>  Наличие лимита на размер временного файла это что, повод обрывать закачку?
>

вы отдаете проксируемый контент по мере чтения.
статус 200 вы отдаете практически сразу.
поэтому клиент видит 200.

потом вы начинаете вычитывать ответ, и постепенно отдавать клиенту.

это регулируется (на выбор)

proxy_buffering (по умолчанию включено)
X-Accel-Buffering (можно отдать с апстрима)
proxy_max_temp_file_size (по  умолчанию 1Гб)

если вы с апстрима вычитываете на wire speed, а отдаете в узную дырочку, то
все шансы, что ответ попытается сбуферизоваться.
и это у него получится вплоть до размера 1Гб

а дальше - вы уже отдали (в сторону клиента) 200. поменять уже не можете.


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


>  Я бы предложил начать с wget -d.
>
> > 05.10.2020 20:16, Иван Мишин пишет:
> > >Забыл уточнить, что при обрыве в акцес логах все равно значится
> > >200 код, а в ерор логах пусто.
> > >
> > >пн, 5 окт. 2020 г. в 19:47, Иван Мишин  > >>:
> > >
> > >Добрый день!
> > >Есть локейшн с настроенными вот такими директивами:
> > >  limit_rate_after 15k; #150Mb
> > >  limit_rate 2048k;
> > >
> > >Пробую качать с помощью wget большой файл, и примерно через 7
> > >минут 49-55 секунд закачка обрывается ну и соответственно объем
> > >(1.1Гб) скачанных данных в зависимости от времени слегка разный.
> > >Как только убирают указанные выше две директивы, так все логично
> > >быстро качается и самое главное без обрыва , качается целиком.
> > >А проблема заключается в том что указанными директивами я лишь
> > >хотел подрезать скорость, но не понятно почему при этом файл не
> > >скачивается до конца! До 1.1Гб файлы скачиваются нормально, а
> > >больше уже нет. Хотел было грешить на таймауты какие-нибудь, но
> > >время обрыва хоть и примерно одинаковое, но все же не постоянное,
> > >поэтому идею с таймаутами отбросил.
> > >
> > >Прошу подсказать как решить проблему?
> > >
> --
>  Eugene Berdnikov
> ___
> 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: Непонятна работа limit_rate

[Илья Шипицин]

вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov :

> On Tue, Oct 06, 2020 at 03:21:14PM +0500, Илья Шипицин wrote:
> >   Наличие лимита на размер временного файла это что, повод обрывать
> >  закачку?
> >
> >вы отдаете проксируемый контент по мере чтения.
> >статус 200 вы отдаете практически сразу.
> >поэтому клиент видит 200.
> >потом вы начинаете вычитывать ответ, и постепенно отдавать клиенту.
> >это регулируется (на выбор)
> >proxy_buffering (по умолчанию включено)
> >X-Accel-Buffering (можно отдать с апстрима)
> >proxy_max_temp_file_size (по  умолчанию 1Гб)
> >если вы с апстрима вычитываете на wire speed, а отдаете в узную
> дырочку,
> >то все шансы, что ответ попытается сбуферизоваться.
> >и это у него получится вплоть до размера 1Гб
> >а дальше - вы уже отдали (в сторону клиента) 200. поменять уже не
> можете.
>
>  А с чего бы статус менять? Не влез ответ в буфер -- положили на это болт
>  (можно удалить файл из буфера, etc) и продолжаем отдавать клиенту дальше.
>
> >это дефолтные настройки. их не меняют с целью сохранения совместимости
> >(вдруг кто-то от них зависит).
> >предполагается ответственный подход. если вы несчастливы с дефолтными
> >настройками - читаете документацию, меняете на нужные.
>
>  Не знаю, как ведёт себя nginx в данной конкретной ситуации, но думаю,
>

это определенный этап, который проходит каждый крупный сервис, который
отдает файлы больше чем 1Гб :)
осознание, что дефолтные настройки не очень удачные в этом месте


>  что его авторы не столь тупы, чтобы не понимать: на апстриме всегда может
>  найтись файл, который в буфер не влезет. При любых значениях настроечных
>  параметров. Это нормальная ситуация, причём если Content-Length с апстрима
>

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

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


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


>  пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
>  в таких условиях это баг, однозначно.
> --
>  Eugene Berdnikov
> ___
> 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: Непонятна работа limit_rate

[Илья Шипицин]

вт, 6 окт. 2020 г. в 16:35, Evgeniy Berdnikov :

> On Tue, Oct 06, 2020 at 04:11:37PM +0500, Илья Шипицин wrote:
> >вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov <[1]b...@protva.ru>:
> >   найтись файл, который в буфер не влезет. При любых значениях
> >  настроечных
> >   параметров. Это нормальная ситуация, причём если Content-Length с
> >  апстрима
> >
> >с одной стороны я с вами соглашусь, что дефолтное поведение не
> выглядит
> >отличным.
> >вероятно, если файл больше нельзя сохранять в кеш, то можно просто не
> >пытаться его сохранять,
> >а обойтись тем, что сохранено, остаток дочитать, ну или подождать
> >с другой стороны, вы несчастны с дефолтным поведением - ок, меняете
> >настройку на более комфортную вам
> >и живете с ней.
> >аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему
> бы не
> >поменять ее конкретно тому,
> >кто несчастен с дефолтом
>
>  Какая настройка "более комфортная", если апстрим не контролируем?
>

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

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

с тех пор ситуация успела поменяться,  C10K умеют вообще, наверное, все
сервера
(для справки https://en.wikipedia.org/wiki/C10k_problem )

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

ответственное решение - настроить для себя буферизацию правильно.



>  Например, там хостинг, юзер захочет -- положит 4 гига файл, захочет --
> 15G.
>  И что, мне из-за этого отказаться от кэша вообще, хотя он в 97% уместен?
>  Хотелось бы авторов nginx-a послушать.
>


ну, я не автор. мне тоже интересно услышать эту историю.


>
> >   пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
> >   в таких условиях это баг, однозначно.
> --
>  Eugene Berdnikov
> ___
> 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: Не работает редирект на HTTPS. OpenSSL.

[Илья Шипицин]

а что-то банальное типа telnet на 443 порт ? curl, wget ?

вт, 20 окт. 2020 г. в 12:06, Zalman_ :

> imsystem Wrote:
> ---
> > Клиент, в роли браузера, должен знать о вашем центре сертификации. Вы
> > добавляли его сертификат в браузер?
> >
> > "Zalman_"  20 октября 2020 г. 08:07:44
> > написал:
> >
> > > Доброго времени суток!
> > >
> > > Нужна помощь по вопросу SSL шифрования.
> > >
> > > Объясню, что есть и что уже имеется.
> > >
> > > Основная задача – поднять RocketChat на локальном сервере и
> > обеспечить
> > > шифрование при доступе к локальному серверу из вне.
> > >
> > > Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на сервере.
> > В
> > > качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в
> > качестве СУБД
> > > использую MongoDB - db version v4.0.20. Использование Nginx и
> > MongoDB
> > > описано в мануале по установке RocketChat.
> > > Все это удалось сделать и все хорошо работает. То есть Nginx +
> > MongoDB +
> > > RocketChat хорошо работают как в локальной сети, так и из вне (с
> > помощью
> > > проброса портов). Однако не удается подключить SSL – сертификат. Так
> > как
> > > сервер поднимался локально (доступ из вне и локально осуществляется
> > через
> > > IP-адрес сервера и порт) и отсутствует какой-то домен, то получение
> > > SSL-сертификата от Let’S Encrypt является проблематичным, поэтому
> > выбрал
> > > самоподписанный SSL-сертификат на основе OpenSSL.
> > > Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал.
> > Конфиги
> > > nginx.conf, а также конфиг в папке
> > > /etc/nginx/sites-available/rocketchat.conf настроил, однако по
> > каким-то
> > > причинам доступ к чату есть через HTTP, но нет через HTTPS.
> > >
> > > С этой темой сижу уже достаточно долго. Пробовал много способов и
> > много
> > > различных конфигов, но все равно не работает.
> > > Причем пробовал как с отключенным UFW, так и с включенным (разрешал
> > > подключение по портам 80, 443, *нужный мне порт*). Также в iptables
> > тоже
> > > разрешил 3 предыдущих порта, но эффекта ноль.
> > >
> > > А вот тут я приведу конфиги.
> > > /etc/nginx/nginx.conf
> > > user www-data;
> > > worker_processes auto;
> > > pid /run/nginx.pid;
> > > include /etc/nginx/modules-enabled/*.conf;
> > >
> > > events {
> > >worker_connections 768;
> > ># multi_accept on;
> > > }
> > >
> > > http {
> > >##
> > ># Basic Settings
> > >##
> > >#sendfile on;
> > >tcp_nopush on;
> > >tcp_nodelay on;
> > >keepalive_timeout 65;
> > >types_hash_max_size 2048;
> > ># server_tokens off;
> > >
> > ># server_names_hash_bucket_size 64;
> > ># server_name_in_redirect off;
> > >
> > >include /etc/nginx/mime.types;
> > >default_type application/octet-stream;
> > >
> > >##
> > ># SSL Settings
> > >##
> > >##
> > ># Logging Settings
> > >##
> > >
> > >access_log /var/log/nginx/access.log;
> > >error_log /var/log/nginx/error.log;
> > >
> > >##
> > ># Gzip Settings
> > >##
> > >
> > >gzip on;
> > >
> > ># gzip_vary on;
> > ># gzip_proxied any;
> > ># gzip_comp_level 6;
> > ># gzip_buffers 16 8k;
> > ># gzip_http_version 1.1;
> > ># gzip_types text/plain text/css application/json
> > > application/javascript text/xml application/xml applicatio$
> > >
> > >##
> > ># Virtual Host Configs
> > >##
> > >
> > >include /etc/nginx/conf.d/*.conf;
> > >include /etc/nginx/sites-enabled/*.conf;
> > > }
> > >
> > > #mail {
> > > #   # See sample authentication script at:
> > > #   # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
> > > #
> > > #   # auth_http localhost/auth.php;
> > > #   # pop3_capabilities "TOP" "USER";
> > > #   # imap_capabilities "IMAP4rev1" "UIDPLUS";
> > > #
> > > #   server {
> > > #   listen localhost:110;
> > > #   protocol   pop3;
> > > #   proxy  on;
> > > #   }
> > > #
> > > #   server {
> > > #   listen localhost:143;
> > > #   protocol   imap;
> > > #   proxy  on;
> > > #   }
> > > #}
> > >
> > > /etc/nginx/sites-available/default.conf
> > >
> > > upstream backend {
> > >   server 127.0.0.1;
> > > }
> > >
> > > #HTTP
> > > server {
> > >#Делаю конфиг согласно
> > > https://techlist.top/translation-nginx-to-https/
> > >listen 80;
> > >server_name *IP локального сервера*;
> > >return 301 https://$server_name$request_uri;
> > > }
> > >
> > > #HTTPS
> > > server {
> > >#Порт, который будет слушать Nginx для SSL
> > >listen 443 ssl http2;
> > >
> > >#Имя сайта
> > >server_name *IP локального сервера*;
> > >
> > >#Корневая директория и индексный файл (ничего не 

Re: Не работает редирект на HTTPS. OpenSSL.

[Илья Шипицин]

есть немного сбивающая с толку команда

iptables-save

выводит (и только) список правил фаирвола на любых линуксовых вариантах
netfilter-а

вт, 20 окт. 2020 г. в 12:53, Dmytro Lavryk :

> Получается nginx слушает, но кто-то режет соединение. Возможно таки
> фаервол, возможно еще-то-то. Не настолько силен в Бубунте, чтобы подсказать
> что может и как диагностировать :(
>
>
>  Увімкнуто вт, 20 жовт. 2020 10:50:00 +0300 *Zalman_
> >* написав 
>
> Dmytro Lavryk Wrote:
> ---
> > netstat -an | grep 443
> >
> > думаю ответ "пусто"
> >  Увімкнуто вт, 20 жовт. 2020 10:43:28 +0300 Zalman_
> >  написав 
>
> tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,289759,289769#msg-289769
>
> ___
> 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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

пт, 9 окт. 2020 г. в 15:28, Vladislav V. Prodan :

>
>
> пт, 25 сент. 2020 г. в 19:53, Илья Шипицин :
>
>>
>>
>> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :
>>
>>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>>> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>>> >  собирать?
>>> >
>>> >по нашей оценке 1 пользователь на 10 тысяч пользователей
>>> сталкивается с
>>> >поломанным MTU
>>>
>>>  Какое значение MSS анонсируют ваши серверы?
>>>
>>
>> 1416
>>
>
> Здравствуйте.
> И как вы на сервере (с nginx) это изменили?
>

iptables


>
> ___
> 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: нормализация uri

[Илья Шипицин]

вт, 18 авг. 2020 г. в 13:16, Gena Makhomed :

> On 17.08.2020 17:58, Maxim Dounin wrote:
>
> > HTTP response splitting предоставляет атакующему контроль над
> > ответом, и XSS - одно из прямых и наиболее очевидных следствий.
>
> >> И почему nginx не может закодировать "\n" or "\r" перед тем,
> >> как применять $uri для построения проксированого запроса?
> >> Это выглядит как не закрытая security vulnerability в nginx.
>
> > Ничего не мешает, равно как и, скажем, заменить в отправляемом
> > перенаправлении A на B.  Тут и в остальных подобныых директивах
> > (return, add_header, proxy_set_header, proxy_pass) nginx ожидает
> > корректно закодированне значения.
>
> Если эти ожидания не оправдались - nginx ведь может понять,
> что ему не предоставили корректно закодированные значения.
>
> И в таком случае - он может ведь вернуть 500 ошибку вместо
> того, чтобы предоставлять атакующему возможность сделать XSS.
>
> Например, проведите голосование среди пользователей nginx+,
> какую реакцию nginx+ они предпочитают - 500 ошибку или XSS?
> Я почти уверен, что никто не захочет, чтобы у них была XSS.
>

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

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

но вы правы, есть WAF-ы, naxsi, например. если оператор реверс прокси
принимает решение, он, конечно, может себе втащить WAF-чик


>
> Просканировать строку на предмет наличия в ней символов
> "\n" или "\r" окажет влияне на производительность
> на уровне статистической погрешности, около нуля.
>
> Почему нет? Ведь тогда nginx станет неуязвим к атаке
> вида HTTP response splitting - разве это того не стоит?
>
> Наверное нет смысла делать в nginx отдельную директиву
> HTTP_response_splitting_security_vulnerability on/off;
>

поменять поведение по умолчанию и сломать кому-то сценарии, так себе
удовольствие



>
> > В случае директивы rewrite дополнительно гарантируется, что
> > переменные $1..$9, полученные из раскодированного URI запроса с
> > помощью регулярного выражения в первом параметре, будут
> > рассматриваться как раскодированные.
>
> Может быть имеет смысл для каждой переменной в nginx добавить
> поле статуса, показывающее, является ли эта переменная
> корректно закодированной или корректно раскодированной?
>
> Тогда nginx смог бы сам на лету превращать раскодированные
> переменные в закодированные, например, при использовании их
> в тех директивах, где необходимо корректно закодированное
> значение переменной.
>
>  Насколько высока вероятность того, что патч, реализующий
>  дополнительную функциональность merge_slashes redirect;
>  или normalize_uri on; будет принят в основную ветку nginx?
> >>
> >>> Задача не кажется типичной. Если очень хочется решать её силами
> >>> nginx'а - я бы рекомендовал начать с инкапсуляции нужных
> >>> перенаправленый в отдельных include-файлах, и/или решений на
> >>> скриптовых языках, или же отдельного модуля для нормализации.
> >>
> >> Что написать в include-файлах вместо
> >>
> >>  if ($request_uri ~ "^[^?]*?//") {
> >>  rewrite "^" $scheme://$host$uri permanent;
> >>  }
> >>
> >>  if ($http_host ~ "\.$") {
> >>  rewrite "^" $scheme://$host$uri permanent;
> >>  }
> >>
> >> чтобы не было XSS ?
> >
> > rewrite ^(.*) $scheme://$host$1 permanent;
>
> Спасибо. Получился такой конфиг:
>
> if ($request_uri ~ "^[^?]*?//") { rewrite ^(.*) $scheme://$host$1
> permanent; }
> if ($http_host ~ "\.$") { rewrite ^(.*) $scheme://$host$1 permanent; }
>
> Похоже, что это максимум из того, что можно выжать из nginx
> в его современном виде и эту ситуацию уже никак улучшить нельзя?
>
> Например, путем создания в nginx директивы normalize_uri со значением
> по умолчанию on. Тогда все работало бы так как надо прямо из коробки.
>
> Задача является более, чем типичной, вот например, такая проблема:
> http://mailman.nginx.org/pipermail/nginx-ru/2014-April/053860.html
> Здесь бы тоже normalize_uri on; было бы решением проблемы.
>
> Случаев, когда normalize_uri on; будет создавать проблемы
> при включенном merge_slashes on; не обнаружено ни одного.
>
> --
> Best regards,
>   Gena
>
> ___
> 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: статический контент и NodeJS Express

[Илья Шипицин]

вт, 29 сент. 2020 г. в 12:11, Cyril Zlachevsky :

> спасибо за помощь, все заработало как надо, с небольшими изменениями -
> в строке конфига nginx
> root  root /var/www/path/to/static;
> не нужно указывать в конце static, иначе nginx будет добавлять static
> два раза в запрос и не находить запрашиваемый файл:
> 2020/09/29 09:21:30 [error] 1530#1530: *179 open()
>
> "home/user/src/nodejs-app/public/static/static/paintings/ekGLnI-1601359891434.jpg"
> failed (2: No such file or directory), client: 127.0.0.1, server: ,
> request: "GET /static/paintings/ekGLnI-1601359891434.jpg HTTP/1.1",
> host: "127.0.0.1:8080", referrer:
> "http://127.0.0.1:8080/admin/paintings/16;
>
> В итоге рабочий конфиг у меня получился такой:
> server {
> listen 8080;
> location / {
> proxy_pass http://127.0.0.1:3000;
> }
>
> location /static/ {
> root /home/user/src/nodejs-app/public/;
> }
> }
>
> Осталось как-то проверить, будут ли отклоняться запросы PUT и
> POST-запросы к каталогу public/static, не содержащие кук авторизации -
> эта проверка есть на бек-энде, но я не уверен, сработает ли она в
> текущей связке с nginx.
>


curl -X POST ...
curl -X PUT ...


>
>
> вт, 29 сент. 2020 г. в 08:44, fox :
> >
> > Как уже писали выше, например, так:
> > server {
> > location / {
> > proxy_pass http://127.0.0.1:3000;
> > }
> >
> > location /public/static/ {
> > root /var/www/path/to/static;
> > }
> > }
> >
> > 29.09.2020 12:14, Cyril Zlachevsky пишет:
> > > В middleware NextJS каталог public прописан как protected:
> > > protected generatePublicRoutes(): Route[] {
> > >
> > > Авторизация требуется только на загрузку файлов в данный каталог через
> > > запросы PUT и POST и реализована в Express.
> > > И насколько я представляю задачу, нужно, чтобы nginx знал об Express и
> > > динамический контент отдавал ему (на порт 3000 например), а работу со
> > > статикой брал на себя.
> > > Как этот функционал реализовать?
> > >
> > > пн, 28 сент. 2020 г. в 21:07, Alexey Galygin :
> > >>
> > >> Express действительно любит кэшировать состояния (правда это больше
> касается шаблонов — он их компилирует и больше не проверяет, но слышать про
> файлы такое удивительно, возможно используемое раздающее middleware
> придерживается другой политики)
> > >>
> > >
> > >> обычная практика в таких случаях:
> > >>
> > >> выделение «датахранилки» — папки, которую через настроенный location
> раздаёт nginx напрямую
> > >> с кэшами (заголовки и настройки добавить по вкусу)
> > >> https://nginx.org/ru/docs/beginners_guide.html#static
> > >>
> > >> вся статика складывается туда, и нет смысла грузить backend
> непрофильными запросами вообще — nginx отстреляется лучше всего
> > >>
> > >> если каким-то файлам требуется авторизация, можно сделать
> дополнительный internal location и с backend после проверки кидать туда
> (через x-accel-redirect —
> https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/)
> > >> и nginx опять таки отдаст статику напрямую и быстрее любой backend
> логики
> > >>
> > >> более того, можно сделать, чтобы правильна работала отдача частичного
> контента (bytes range) и эффективная раздача с диска
> > >>
> > >> всё что не попадает под пути хранилки проксировать на Express
> > >>
> > >> On 28 Sep 2020, at 20:08, Cyril Zlachevsky <
> cyril.zlachev...@gmail.com> wrote:
> > >>
> > >> Есть приложение на NodeJS, которое прекрасно работает в
> > >> developer-режиме. В качестве http-сервера используется ExpressJS.
> > >> В production-режиме появляется проблема - http GET запросы возвращают
> > >> 404-ю ошибку для всех новых файлов, загруженных после старта
> приложения
> > >> в каталог public.
> > >>
> > >> Пример: если до старта файл public/static/old.jpg существовал, GET
> > >> запрос вернет его с кодом 200.
> > >> Если мы загрузили через nodejs-приложение файл public/static/new.jpg
> > >> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение,
> > >> GET на public/static/new.jpg будет возвращать 200.
> > >>
> > >> Гугление проблемы привело к пониманию, что это не ошибка, а
> особенность
> > >> Express-сервера и для production рекомендуется использовать связку
> > >> nginx+express. Как мне настроить работу этой связки, я не вполне
> > >> представляю, поэтому прошу помощи здесь.
> ___
> 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: Почему пустой if ломает работу try files?

[Илья Шипицин]

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

по сути просто диалекты языка

вт, 29 сент. 2020 г. в 22:41, Alexey Galygin :

> иногда трудно обойтись без дополнительной логики,
> которую ради такой мелочи отдавать на backend грустно
>
> и речь про улучшение поведения исключительно с обратной совместимостью
>
> если совсем никак, то можно добавить условно extended if — eif
>
>
> > On 29 Sep 2020, at 19:47, fox  wrote:
> >
> > 1) может, потому что конфиг - это не язык программирования?
> >
> > 2) изменение поведения сломает тысячи существующих систем.
> >
> >
> > 29.09.2020 23:31, Alexey Galygin пишет:
> >> присоединяюсь к вопросу:
> >>
> >> почему бы не сделать if нормальным? чтобы без артефактов… и немного
> мощнее
> >>
> >> нам вот тоже приходится делать по несколько map, чтобы логику чуть
> более сложную построить…
> >> и это ужас
> >>
> >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov  wrote:
> >>>
> >>>
>  On 29 Sep 2020, at 17:12, Ilya Evseev 
> wrote:
> 
>  Имеется nginx 1.19.2 со следующей настройкой:
> 
>   server {
>   location / {
>   if ($http_user_agent ~ "TestAgent") { }
>   try_files $uri $uri/ /index.html;
>   }
>   }
> 
>  Почему попадание в if меняет логику работы последующего try_files?
> >>>
> >>> https://wiki.nginx.org/IfIsEvil
> >>>
> >>> --
> >>> Sergey Kandaurov
> >>>
> >>> ___
> >>> 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Почему пустой if ломает работу try files?

[Илья Шипицин]

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

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

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

ср, 30 сент. 2020 г. в 10:44, Alexey Galygin :

> да, примеры были из habr, но и там к статье были претензии к map-решению
> + я специально усложнил пример регулярными выражениями
>
> поэтому указанный map это не эквивалент
>
> во вторых плохо читаемый хак и издевательство над линейной логикой
> зачем такие костыли, если можно доделать нормальный if?
>
>
>
> On 30 Sep 2020, at 05:14, fox  wrote:
>
> Троллишь?
>
> map "$http_user_agent:$method:$uri" $block {
>"HackYou:POST:/admin/some/url"  "1";
> }
>
> if ($block) {
>return 403;
> }
>
>
> 30.09.2020 02:24, Alexey Galygin пишет:
>
> не вкусовщина
> часто очень не хватает простейших and/&& и or/||
>
> вот чтобы такое не писать:
>
> if($http_user_agent~ "HackYou"){ set$block"A"; } if($method= "POST") {
> set$block"${block}B"; } if($uri~ “^/admin/some/url") {
> set$block"${block}C"; } if($block= "ABC") { return403; }
>
> vs условно:
>
> if/eif ($http_user_agent~ “HackYou” && $method= “POST” && $uri~
> “^/admin/some/url”) {
> return403;
> }
>
>
> On 29 Sep 2020, at 21:49, Илья Шипицин  <mailto:chipits...@gmail.com >> wrote:
>
> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в
> определенном синтаксисе.
> сейчас вы точно так же выражаете свою мысль через map-ы.
>
> по сути просто диалекты языка
>
> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin  <mailto:m...@me.com >>:
>
>иногда трудно обойтись без дополнительной логики,
>которую ради такой мелочи отдавать на backend грустно
>
>и речь про улучшение поведения исключительно с обратной совместимостью
>
>если совсем никак, то можно добавить условно extended if — eif
>
>
> On 29 Sep 2020, at 19:47, fox 
><mailto:red-f...@ya.ru >> wrote:
>
>
> 1) может, потому что конфиг - это не язык программирования?
>
> 2) изменение поведения сломает тысячи существующих систем.
>
>
> 29.09.2020 23:31, Alexey Galygin пишет:
>
> присоединяюсь к вопросу:
>
> почему бы не сделать if нормальным? чтобы без артефактов… и
>
>немного мощнее
>
>
> нам вот тоже приходится делать по несколько map, чтобы логику
>
>чуть более сложную построить…
>
> и это ужас
>
> On 29 Sep 2020, at 19:29, Sergey Kandaurov 
><mailto:pluk...@nginx.com >> wrote:
>
>
>
> On 29 Sep 2020, at 17:12, Ilya Evseev
>
>mailto:nginx-fo...@forum.nginx.org
> >>
>wrote:
>
>
> Имеется nginx 1.19.2 со следующей настройкой:
>
>   server {
>   location / {
>   if ($http_user_agent ~ "TestAgent") { }
>   try_files $uri $uri/ /index.html;
>   }
>   }
>
> Почему попадание в if меняет логику работы последующего
>
>try_files?
>
>
> https://wiki.nginx.org/IfIsEvil
>
> --
> Sergey Kandaurov
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org >
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org >
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org >
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org <mailto:nginx-ru@nginx.org >
>http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto: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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov :

> On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote:
> >есть распространенное ожидание, что якобы ICMP Frag needed может
> как-то
> >помочь.
> >на самом деле - скорее нет.
> >допустим, у вас на участке сети мелкий MTU. в этом случае вы
> действительно
> >увидите ICMP Frag required.
>
>  Ч.Т.Д.
>
> >если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric,
> >whatever), то ICMP Frag required придет не вам, а туда, где
> терминируется
> >туннель.
> >благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию,
> >которая идет снаружи туннеля ?
>
>
>  PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может.
>


я примерно тыщу раз сталкивался с ситуацией

"у нас не устанавливается SSL от браузера" --> "запускаем трейсроут" --> в
транзите вижу узел с днс именем, содержащим pppoe.
примерно в 100% случаях снижение MTU на клиенте или аналогичная манипуляция
на сервере чинили

при этом ни у меня, ни у клиента icmp не блокировано. просто сигнализация
идет, вероятно, с pppoe узлами в транзите.


>
>  А обработка сигналов это задача тунеллятора. У него может быть несколько
>  стратегий:
>
>  1. ставить df=0 и не париться, шлюзы сами всю работу сделают;
>  2. ставить df=1, ловить icmp[frag-need] и дробить-собирать пакеты самому;
>  3. ставить df=1, ловить icmp и ретранслировать его на нижний уровень.
>
>  На самом деле лишь первые 2 стратегии можно нормально реализовать
>  с классическим api сокетов.
>
>  Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по
>  умолчанию и ваша голова не болит, как он там пакеты дробит и куда
>  свои служебные заголоки фасует.
>


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



>
>  Другой вопрос, насколько кривы конкретные ipv6-to-ipv4 гейты и
>  шлют ли они нужные клиенту icmp.
>
> >очень интересно в этом плане жить в мире Windows (в нем принято
> ставить DF
> >на https),
>
>  Чем интересно? Браузерный трафик всегда идёт внутри туннеля.
>

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

и фейсбук выставляет MSS=1410. что-то в этом есть :) кажется, я понимаю,
зачем.


>  А если туннелятор не умеет PMTUD снаружи, то какое бы DF ни было внутри,
>  результат будет одинаково печальным.
>

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


> --
>  Eugene Berdnikov
> ___
> 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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :

> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
> >  собирать?
> >
> >по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается
> с
> >поломанным MTU
>
>  Какое значение MSS анонсируют ваши серверы?
>

1416


> --
>  Eugene Berdnikov
> ___
> 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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

пт, 25 сент. 2020 г. в 22:25, Slawa Olhovchenkov :

> On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote:
>
> > >> >   Насчёт "самая распостранённая" -- статистика есть? Как её
> вообще
> > >> >  собирать?
> > >> >
> > >> >по нашей оценке 1 пользователь на 10 тысяч пользователей
> > >> сталкивается с
> > >> >поломанным MTU
> > >>
> > >>  Какое значение MSS анонсируют ваши серверы?
> > >>
> > >
> > > 1416
> > >
> > >
> >
> > мы итерационно подошли к этой цифре.
> > я попросил техподдержку эскалировать на меня кейсы, когда они
> подкручивали
> > MTU на клиенте.
> >
> > и на очередном клиенты мы по одному байту крутили
>
> а чего по байту-то?
>

делением пополам, конечно.

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

за первую мы снизились до 1456 кажется. и потом был еще один клиент, мы
упали до 1416

теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались



> ___
> 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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

пт, 25 сент. 2020 г. в 21:52, Илья Шипицин :

>
>
> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :
>
>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>> >  собирать?
>> >
>> >по нашей оценке 1 пользователь на 10 тысяч пользователей
>> сталкивается с
>> >поломанным MTU
>>
>>  Какое значение MSS анонсируют ваши серверы?
>>
>
> 1416
>
>

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

и на очередном клиенты мы по одному байту крутили
ну и получилось очень близко к фейсбуку (у них 1410)


> --
>>  Eugene Berdnikov
>> ___
>> 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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

пт, 25 сент. 2020 г. в 21:34, Evgeniy Berdnikov :

> On Fri, Sep 25, 2020 at 08:49:08PM +0700, Eugene Grosbein wrote:
> > 25.09.2020 11:32, Evgeniy Berdnikov wrote:
> > >  Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может.
> Никак.
> >
> > Да.
> >
> > >  Поэтому бывает лишь на крайних хопах.
> >
> > Нет. Это утверждение никак не связано с предыдущим и из него не вытекает,
> > слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по
> PPPoE,
> > а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ
> другой сети.
>
>  Из "технически возможно" не следует "разумно и оправдано". Нужно иногда
>  включать здравый смысл. PPPoE сделано для подключения для подключения
>  множества клиентов к одному хабу, главная его цель -- авторизация клиента.
>  Никто в здравом рассудке ТАК подключать аплинки на магистральном
>  маршрутизаторе не будет.
>
> > Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со
> входящим "снаружи"
> > ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки)
> IP-пакет,
> > изначально отправленного "изнутри"? Подсказка: существуют как минимум
> две разные
> > политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И
> она же
> > самая распространенная.
>
>  Есть только одна нормальная политика: доставить icmp по назначению.
>  Все остальные политики ущербны, IMHO. Я лично никогда не встречал
>  разумных "соображний безопасности", которые могли бы оправдать поломку
>  одного из из базовых механизмов ip-стэка.
>
>  Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать?
>

по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается с
поломанным MTU


> --
>  Eugene Berdnikov
> ___
> 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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

пт, 25 сент. 2020 г. в 22:00, Evgeniy Berdnikov :

> On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote:
> > Какое значение MSS анонсируют ваши серверы?
> >
> >  1416
> >
> >
> >мы итерационно подошли к этой цифре.
> >я попросил техподдержку эскалировать на меня кейсы, когда они
> подкручивали
> >MTU на клиенте.
> >и на очередном клиенты мы по одному байту крутили
> >ну и получилось очень близко к фейсбуку (у них 1410)
>
>  Спасибо.
>
>  Хотелось бы ещё уточнить: 1/10,000 -- это после подкручивания или до?
>

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

после подкручивания практически в ноль упало. было одно обращение, когда
крутили MTU до 1300.
мы решили больше не трогать MSS

потому что это уменьшает объем полезной нагрузки per packet


> --
>  Eugene Berdnikov
> ___
> 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: Странные 502 ответы.

[Илья Шипицин]

Тогда смотрите core dumped на том nginx, который так отвечает

On Thu, Oct 1, 2020, 6:21 PM elc  wrote:

> Там тоже nginx.
> Если быть точным, то nginx/1.17.3 и на Edge_proxy и на промежуточном proxy.
> Что на стороне Origin server сказать не могу, но в рамках данного вопроса
> это не имеет значения.
> Вот в том и дело что на стороне сервера (промежуточном proxy) ничего не
> падает, worker-ы работают стабильно, не убиваются.
> По ресурсам CPU idle 80+% на всех серверах.
>
> На промежуточных proxy в error.log есть записи "upstream prematurely closed
> connection while reading response header from upstream" и "upstream timed
> out (110: Connection timed out) while reading response header from
> upstream"
> , это получается при запросах proxy_промежуточные <-> Origin server, но
> сейчас вопрос не про них.
>
> Других записей в error.log на промежуточном proxy нет. В access.log на
> промежуточном proxy также запросы, которые на edge_proxy 502, отсутствуют.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,289619,289627#msg-289627
>
> ___
> 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: Странные 502 ответы.

[Илья Шипицин]

"while reading response header from upstream"


что-то упало на стороне сервера, формирующего ответ. что там за софт ?

ср, 30 сент. 2020 г. в 20:25, elc :

> Опишу немного для общего понимания схему:
>
> Клиенты обращаются на несколько прокси серверов, которые проксирую запросы
> на другие (промежуточные) прокси и промежуточные прокси уже проксируют
> запрос на сервера оригинации.
> Client <-> Edge_proxy <-> proxy_промежуточные <-> Origin server
>
>
>
> Периодически возникают проблемы с 502-ми ответами в логе с одного из
> upstream серверов.
> При этом на запрос к апстриму, где в логе 502, есть записи в error.log вида
>
>
> 2020/09/29 07:28:09 [error] 13038#13038: *4641196828 upstream prematurely
> closed connection while reading response header from upstream, client:
> ,
> server: , request: "GET  HTTP/1.1", upstream:
> "http:///", host: ""
> или
> 2020/09/29 07:54:54 [error] 40174#40174: *3165979465 upstream prematurely
> closed connection while reading response header from upstream, client:
> ,
> server: , request: "GET  HTTP/1.1", upstream:
> "http:///", host: ""
>
> Сам лог запроса:
> IP  [30/Sep/2020:10:12:57 +] "GET  HTTP/1.1" 200 MISS
> "UPSTREAM1, UPSTREAM2" 75539 "-" "User_agent" "0.079" "-"
> "TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256" "21/7498183988" 75945 "0, 75539" "-,
> 0.076" "0.000, 0.076" "502, 200" RU 3dca4fc6a9c7cf10a8448faa0 443
>
> Где  "0.000, 0.076" - request_time
> "502, 200" - соотв коды ответов для Upstream1, Upstream2.
>
> При этом через секунду или даже меньше, запросы с этого промежуточного
> прокси-сервера приходят с 200-м кодом.
> + очень смущает то, что время ответа 0.000. Значит никакие таймауты не
> превышались.
>
> Проблем с сетью между серверами нет, MTR показывает 0% потерь на дистанции
> 1час+.
> Ресурсов на серверах хватает.
>
> Помогите, пожалуйста, понять в чем проблема.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,289619,289619#msg-289619
>
> ___
> 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: статический контент и NodeJS Express

[Илья Шипицин]

Лучшим источником информации было бы описание со стороны Express. Вы у них
эту рекомендацию нашли? Поделитесь ссылкой?

On Mon, Sep 28, 2020, 10:08 PM Cyril Zlachevsky 
wrote:

> Есть приложение на NodeJS, которое прекрасно работает в
> developer-режиме. В качестве http-сервера используется ExpressJS.
> В production-режиме появляется проблема - http GET запросы возвращают
> 404-ю ошибку для всех новых файлов, загруженных после старта приложения
> в каталог public.
>
> Пример: если до старта файл public/static/old.jpg существовал, GET
> запрос вернет его с кодом 200.
> Если мы загрузили через nodejs-приложение файл public/static/new.jpg
> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение,
> GET на public/static/new.jpg будет возвращать 200.
>
> Гугление проблемы привело к пониманию, что это не ошибка, а особенность
> Express-сервера и для production рекомендуется использовать связку
> nginx+express. Как мне настроить работу этой связки, я не вполне
> представляю, поэтому прошу помощи здесь.
> ___
> 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: статический контент и NodeJS Express

[Илья Шипицин]

вт, 29 сент. 2020 г. в 10:14, Cyril Zlachevsky :

> В middleware NextJS каталог public прописан как protected:
> protected generatePublicRoutes(): Route[] {
>
> Авторизация требуется только на загрузку файлов в данный каталог через
> запросы PUT и POST и реализована в Express.
> И насколько я представляю задачу, нужно, чтобы nginx знал об Express и
> динамический контент отдавал ему (на порт 3000 например), а работу со
> статикой брал на себя.
> Как этот функционал реализовать?
>

при помощи try_files


>
> пн, 28 сент. 2020 г. в 21:07, Alexey Galygin :
> >
> > Express действительно любит кэшировать состояния (правда это больше
> касается шаблонов — он их компилирует и больше не проверяет, но слышать про
> файлы такое удивительно, возможно используемое раздающее middleware
> придерживается другой политики)
> >
>
> > обычная практика в таких случаях:
> >
> > выделение «датахранилки» — папки, которую через настроенный location
> раздаёт nginx напрямую
> > с кэшами (заголовки и настройки добавить по вкусу)
> > https://nginx.org/ru/docs/beginners_guide.html#static
> >
> > вся статика складывается туда, и нет смысла грузить backend
> непрофильными запросами вообще — nginx отстреляется лучше всего
> >
> > если каким-то файлам требуется авторизация, можно сделать дополнительный
> internal location и с backend после проверки кидать туда (через
> x-accel-redirect —
> https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/)
> > и nginx опять таки отдаст статику напрямую и быстрее любой backend логики
> >
> > более того, можно сделать, чтобы правильна работала отдача частичного
> контента (bytes range) и эффективная раздача с диска
> >
> > всё что не попадает под пути хранилки проксировать на Express
> >
> > On 28 Sep 2020, at 20:08, Cyril Zlachevsky 
> wrote:
> >
> > Есть приложение на NodeJS, которое прекрасно работает в
> > developer-режиме. В качестве http-сервера используется ExpressJS.
> > В production-режиме появляется проблема - http GET запросы возвращают
> > 404-ю ошибку для всех новых файлов, загруженных после старта приложения
> > в каталог public.
> >
> > Пример: если до старта файл public/static/old.jpg существовал, GET
> > запрос вернет его с кодом 200.
> > Если мы загрузили через nodejs-приложение файл public/static/new.jpg
> > GET-запрос будет возвращать ошибку 404. Если перезапустить приложение,
> > GET на public/static/new.jpg будет возвращать 200.
> >
> > Гугление проблемы привело к пониманию, что это не ошибка, а особенность
> > Express-сервера и для production рекомендуется использовать связку
> > nginx+express. Как мне настроить работу этой связки, я не вполне
> > представляю, поэтому прошу помощи здесь.
> ___
> 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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

чт, 24 сент. 2020 г. в 18:27, Maxim Dounin :

> Hello!
>
> On Thu, Sep 24, 2020 at 02:03:37PM +0300, Sergey Budnevitch wrote:
>
> > > Продемонстрированная проблема ровно одна: пакетный менеджер не
> > > может получить
> > > http://nginx.org/packages/debian/dists/buster/InRelease с
> > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения.
> > >
> > >
> > > Первый запрос дождался таймаута (непонятно почему).
> > > Второй запрос выполнился мгновенно.
> > > https://pastebin.com/dWbffATH
> >
> > Смотрите:
> > a) вы продемонстрировали проблему с первым подключением к nginx.org
> > b) вы утверждаете что бывает проблема с резолвером, когда используется
> ipv6
> > c) вы используете  Hurricane Electric tunnel brocker для ipv6
> >
> > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или
> на какие-то проблемы в he.
> >
> > nginx.org доступен по ipv6 c нескольких точек с которых я мог
> проверить, и судя по логам подключаются
> > по ipv6 к nginx.org как обычно.
>
> Насколько я вижу, соединение нормально устанавливается, запрос
> отправляется, а ответ не приходит и ждёт таймаута.  После чего на
> некоторое время всё исправляется.
>
> Если используется тоннель, то это выглядит и пахнет как
> классическая проблема с MTU, которая лечится за счёт PMTU black
> hole detection.
>
> Я со своей стороны давно разочаровался в идее работоспособности
> PMTU discovery в современном интернете, и жить с тоннелями без
> правки MSS никому не рекомендую.
>
> Но с нашей стороны явно имеет смысл проверить, что ICMP
> fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей
> ответственности ходят нормально и не зафильтрованы.  С учётом
> того, что пинги не ходят - у меня вот лично в этом сомнения.
>


есть распространенное ожидание, что якобы ICMP Frag needed может как-то
помочь.
на самом деле - скорее нет.


допустим, у вас на участке сети мелкий MTU. в этом случае вы действительно
увидите ICMP Frag required.
если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric,
whatever), то ICMP Frag required придет не вам, а туда, где терминируется
туннель.
благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию,
которая идет снаружи туннеля ?


что действительно работает, это манипуляции (в разумных пределах) с MSS,
например --clamp-mss-to-pmtu
очень интересно в этом плане жить в мире Windows (в нем принято ставить DF
на https), и очень забавно наблюдать
за MSS, например, от фейсбука (и прочих игроков такого масштаба)


>
> --
> Maxim Dounin
> http://mdounin.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: Проблемы со связностью по ipv6 сайта nginx.org

[Илья Шипицин]

чт, 24 сент. 2020 г. в 22:02, Evgeniy Berdnikov :

> On Thu, Sep 24, 2020 at 09:18:40PM +0500, Илья Шипицин wrote:
> >чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov :
> >
> >   PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не
> может.
> >
> >я примерно тыщу раз сталкивался с ситуацией
> >"у нас не устанавливается SSL от браузера" --> "запускаем трейсроут"
> --> в
> >транзите вижу узел с днс именем, содержащим pppoe.
> >примерно в 100% случаях снижение MTU на клиенте или аналогичная
> >манипуляция на сервере чинили
> >при этом ни у меня, ни у клиента icmp не блокировано. просто
> сигнализация
> >идет, вероятно, с pppoe узлами в транзите.
>
>  Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите"
>  наверняка нет (они могут быть лишь на 2м и предпоследнем хопе).
>  "Снаружи" на pppoe icmp никогда не прилетают, хотя бы потому, что
>  pppoe это не ip и вследствие этого он по интернету в принципе ходить
>  не может.
>

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


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



>
>  Здесь же наверняка причина в том, что терминирующий pppoе шлюз не
>  посылает клиенту icmp на пакет с максимальным для изернета mtu,
>  хотя приделать к нему pppoe-шные хедеры тоже не может: места нет.
>  Таких кривых шлюзов немало, с этим я согласен.
>
> >   Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по
> >   умолчанию и ваша голова не болит, как он там пакеты дробит и куда
> >   свои служебные заголоки фасует.
> >
> >это ровно такая же ситуация, про которую я говорил. если вы являетесь
> той
> >точкой, которая терминирует OpenVPN - вы видите
> >icmp dest unreach и обрабатываете. если OpenVPN  где-то в транзите,
> леший
> >знает, как смаршрутизируется icmp dest unreach
>
>  Никакой магии: icmp посылается на src_ip исходного пакета, и если пакет
>  был от openvpn, то icmp придёт обратно к узлу-отправителю с openvpn.
>  Тут всё детерминировано и однозначно. А тип icmp будет "frag-need".
> --
>  Eugene Berdnikov
> ___
> 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

500-ки, которых не пишется в error.log

[Илья Шипицин]

привет,

столкнулись с ситуацией, 500 пишется в access.log, при этом upstream_addr
пустой, в error.log пусто.

поиск по коду показывает несколько мест примерно вот таких (выделили
память, она не выделилась, финализировали с 500-кой)

http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_core_module.c#l1012

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

в подобных местах, когда фейлится palloc, может стоит в error.log добавить
ошибку ? или это по каким-то причинам невозможно ?

Илья Шипицин
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: SSL для IE 8

[Илья Шипицин]

ср, 22 июл. 2020 г. в 18:07, fox :

> Не знаю, чья ошибка: моя или сервера:
>
> $ openssl s_client -cipher DES-CBC3-SHA -tls1 -connect ogtrk.ru:443


https://www.ssllabs.com/ssltest/analyze.html?d=ogtrk.ru

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



>
> CONNECTED(0005)
> 140423953981888:error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no
> ciphers available:../ssl/statem/statem_clnt.c:3786:No ciphers enabled
> for max supported SSL/TLS version
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 7 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1
> Cipher: 
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1595423155
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> ---
>
>
> 22.07.2020 19:47, grey пишет:
> > С первоначальным сайтом, о котором шла речь в первом посте дело
> затянулось,
> > вот адрес другого ogtrk.ru , где можно увидеть точно такую же проблему.
> > Напомню, сайт не открывается в IE8 на WinXP SP3 со всеми установленными
> > обновлениями, хотя шифр DES-CBC3-SHA в конфиге присутствует.
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288801#msg-288801
> >
> > ___
> > 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: Відповідь: ssl redirect

[Илья Шипицин]

Сертификат наследуется с уровня выше

On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk  wrote:

> Ну так нет же тут сертификата. Пропишите для monitor.domains в конфиге.
>
>  Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
> >* написав 
>
> Всем привет.
> Почему то не коректно работает редирект
>
> server {
> listen 443 ssl;
> server_name monitor.domain;
> # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently 
> response.
> return 301 https://monitor.other-domain$request_uri;
> }
>
>
> редирект не проходит.
> он подставляет сертификат от другого домена, который на этом хосте
> крутится.
> вследствии чего браузер стопорит редирект.
>
> Причем тоже самое но на другом сервере работает нормально.
>
>
> --
> P.S. Сохраняйте переписку в теле письма.
> ___
> Best regards, Konstantin @MihaKot@ Aksarin.
> Phone: +7 921 74 66 818
> Skype: mihakot
> E-mail: miha...@gmail.com
> ___
> 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: Відповідь: ssl redirect

[Илья Шипицин]

Вероятно, дело в положении сервера. Или фазе луны. Попробуйте повернуть
сервер на 90%

On Thu, Aug 6, 2020, 10:30 PM MihaKot  wrote:

> Тогда почему на другом сервере точно такая же конфигурация работает.
>
> чт, 6 авг. 2020 г. в 20:17, Илья Шипицин :
>
>> Сертификат наследуется с уровня выше
>>
>> On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk  wrote:
>>
>>> Ну так нет же тут сертификата. Пропишите для monitor.domains в конфиге.
>>>
>>>  Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
>>> >* написав 
>>>
>>> Всем привет.
>>> Почему то не коректно работает редирект
>>>
>>> server {
>>> listen 443 ssl;
>>> server_name monitor.domain;
>>> # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently 
>>> response.
>>> return 301 https://monitor.other-domain$request_uri;
>>> }
>>>
>>>
>>> редирект не проходит.
>>> он подставляет сертификат от другого домена, который на этом хосте
>>> крутится.
>>> вследствии чего браузер стопорит редирект.
>>>
>>> Причем тоже самое но на другом сервере работает нормально.
>>>
>>>
>>> --
>>> P.S. Сохраняйте переписку в теле письма.
>>> ___
>>> Best regards, Konstantin @MihaKot@ Aksarin.
>>> Phone: +7 921 74 66 818
>>> Skype: mihakot
>>> E-mail: miha...@gmail.com
>>> ___
>>> 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
>
>
>
> --
> P.S. Сохраняйте переписку в теле письма.
> ___
> Best regards, Konstantin @MihaKot@ Aksarin.
> Phone: +7 921 74 66 818
> Skype: mihakot
> E-mail: miha...@gmail.com
> ___
> 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: Проксирование с кэшем из CDN

[Илья Шипицин]

вот такая штука поможет ?

https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock

ср, 5 авг. 2020 г. в 11:39, Raice :

> Да, работает! Но получается, пока он файл не скачает, он будет просто
> проксировать на CDN все. Т.е. если одновременно клиенты начнут качать, то в
> итоге мы все равно получим N скачиваний с CDN, а клиенты все начинают
> качать
> одновременно практически.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288966,288973#msg-288973
>
> ___
> 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 MISS

[Илья Шипицин]

а содержимое файла /720p_02815.ts может меняться ?

если контент уникален, может включить proxy store ?

пн, 10 авг. 2020 г. в 18:04, Slawa Olhovchenkov :

> On Mon, Aug 10, 2020 at 03:40:58PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > > >
> > > > > Есть файл, не меняется, заголовков про expire не имеет.
> > > > >
> > > > > Response: {'status': 200, 'headers': {'content-length': '615700',
> 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified':
> 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag':
> '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> > > > >  'tx00451618a-005f306158-a6edb7b-default', 'date':
> 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason':
> 'OK'}
> > > > >
> > > > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET
> /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]"GET
> /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]"GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300] "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]"GET
> /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > > > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > > >
> > > > > какие причины могут быть для возникновения MISS?
> > > > >
> > > > > зона не заполнена даже наполовину.
> > > > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2
> max_size=6000g inactive=10d use_temp_path=off;
> > > >
> > > > Если выше показаны заголовки ответа бэкенда, то я в первую очередь
> > > > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы
> > > > причины для возникновения HIT?
> > > >
> > > > В отсутствии явно заданных заголовков Cache-Control / Expire /
> > > > X-Accel-Expire - единственная возможная причина кэширования это
> > > > директива proxy_cache_valid, если она в конфиге есть - то
> > > > вероятнее всего отвечает на оба вопроса.
> > >
> > > proxy_cache_valid  200  5d;
> >
> > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за
> > времена приведены в логах, но $request_time там точно нет, а если
>
> $request_time $connection $upstream_cache_status $upstream_connect_time
> $upstream_response_time $upstream_bytes_received
>
> > запросы общаются с бэкендом одновременно и proxy_cache_lock не
>
> да не вопрос.
>
> > используется - то и MISS'ов может быть одновременно много, при
> > этом завершаться запросы могут в заметно разное время.
>
> не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть
> в 21:01:47. апстрим отдался почти мгновенно.
> теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.
>
> 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.106 78233513 MISS 0.000 0.016 616206
> 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.409 71530389 HIT - - -
> 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.106 78883331 HIT - - -
> 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]"GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.045 78875231 MISS 0.000 0.043 616196
> 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.973 78738732 HIT - - -
> 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]"GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.000 73778063 HIT - - -
> 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300] "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.001 73446584 HIT - - -
> 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.331 77746051 HIT - - -
> 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.444 78915833 HIT - - -
> 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]"GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.318 78021062 HIT - 

Re: аккуратное выведение бекенда на стримах

[Илья Шипицин]

вт, 4 авг. 2020 г. в 19:24, Gena Makhomed :

> On 04.08.2020 17:04, Илья Шипицин wrote:
>
> >> А что мешает просто убрать сервер из конфига и сделать reload?
> >> Ранее усановленные соединения доработают, новые будут
> >> устанавливаться только к бэкендам из новой конфигурации.
>
> > пожалуй, что можно и так.
> > мы так раньше делали, и поскольку мы не контролировали сколько у нас
> > worker-ов (а на каждый релоад запускается новый набор), то время от
> времени
> > ловили out of memory.
>
> если добавить в конфиг директиву worker_shutdown_timeout 60s;
> - разве это не поможет избавиться от ошибок out of memory ?
> и/или делать релоад nginx не чаще чем раз в минуту.
>

позволит. только установленные подключения порвутся


>
> --
> Best regards,
>   Gena
>
> ___
> 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: Відповідь: ssl redirect

[Илья Шипицин]

если сертификат не указать (вообще никакой), то nginx не запустится

ср, 12 авг. 2020 г. в 20:40, fox :

> Сертификат-то от домена monitor.domain есть?
>
> Сдаётся мне, что на втором сервере этот сертификат есть.
>
>
> 07.08.2020 00:57, Илья Шипицин пишет:
> > Вероятно, дело в положении сервера. Или фазе луны. Попробуйте повернуть
> > сервер на 90%
> >
> > On Thu, Aug 6, 2020, 10:30 PM MihaKot  > <mailto:miha...@gmail.com>> wrote:
> >
> > Тогда почему на другом сервере точно такая же конфигурация работает.
> >
> > чт, 6 авг. 2020 г. в 20:17, Илья Шипицин  > <mailto:chipits...@gmail.com>>:
> >
> > Сертификат наследуется с уровня выше
> >
> > On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk  > <mailto:r...@dl.sm.ua>> wrote:
> >
> > __
> > Ну так нет же тут сертификата. Пропишите для monitor.domains
> > в конфиге.
> >
> >  Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
> > mailto:miha...@gmail.com>>* написав 
> >
> > Всем привет.
> > Почему то не коректно работает редирект
> >
> > server {
> > listen 443 ssl;
> > server_name monitor.domain;
> > # Redirect all HTTP requests to HTTPS with a 301 Moved
> > Permanently response.
> > return 301 https://monitor.other-domain$request_uri;
> > }
> >
> >
> > редирект не проходит.
> > он подставляет сертификат от другого домена, который на
> > этом хосте крутится.
> > вследствии чего браузер стопорит редирект.
> >
> > Причем тоже самое но на другом сервере работает
> нормально.
> >
> >
> > --
> > P.S. Сохраняйте переписку в теле письма.
> > ___
> > Best regards, Konstantin @MihaKot@ Aksarin.
> > Phone: +7 921 74 66 818
> > Skype: mihakot
> > E-mail: miha...@gmail.com <mailto:miha...@gmail.com>
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> > --
> > P.S. Сохраняйте переписку в теле письма.
> > ___
> > Best regards, Konstantin @MihaKot@ Aksarin.
> > Phone: +7 921 74 66 818
> > Skype: mihakot
> > E-mail: miha...@gmail.com <mailto:miha...@gmail.com>
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org <mailto: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

аккуратное выведение бекенда на стримах

[Илья Шипицин]

привет!

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

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

можно что-то такое на SYN-ах намутить ? на уровне идеи вроде норм. по
реализации ?


Илья Шипицин
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: аккуратное выведение бекенда на стримах

[Илья Шипицин]

вт, 4 авг. 2020 г. в 17:30, Maxim Dounin :

> Hello!
>
> On Tue, Aug 04, 2020 at 05:14:45PM +0500, Илья Шипицин wrote:
>
> > вижу такую штуку. есть проксирование на стримах на 5 серверов. я хочу
> > вывести из эксплуатации 1-й. чтобы запросы доработали.
> >
> > я каким-то образом делаю шаманство и говорю "если это SYN, то его надо
> на 4
> > сервера, а если это установленное с 1-м, ок, кидаем пакетики на 1-й".
> потом
> > когда горшочек перестает варить, я физически выключаю 1-й.
> >
> > можно что-то такое на SYN-ах намутить ? на уровне идеи вроде норм. по
> > реализации ?
>
> А что мешает просто убрать сервер из конфига и сделать reload?
> Ранее усановленные соединения доработают, новые будут
> устанавливаться только к бэкендам из новой конфигурации.
>


пожалуй, что можно и так.
мы так раньше делали, и поскольку мы не контролировали сколько у нас
worker-ов (а на каждый релоад запускается новый набор), то время от времени
ловили out of memory.


>
> --
> Maxim Dounin
> http://mdounin.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: SSL для IE 8

[Илья Шипицин]

чт, 9 июл. 2020 г. в 18:38, grey :

> Привет всем!
>
> Возникла задача сделать, чтобы сайт открывался в Windows XP на IE 8. На
> сайте
>
> https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.10.3=1.0.1e=yes=old
> выбрал - создать конфиг под старые браузеры, получил набор шифров:
>
> ssl_ciphers
>
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
>
> Если верить интернету, то для работы сайта в IE 8 необходим последний в
> списке "DES-CBC3-SHA", но почему сайт не открывается. Нашел в инете патч
> для
> IE 8, который добавляет 256 битное шифрование для этого старого браузера и
> он помог, но это не вариант.
>

256-битное шифрование это SHA2 ?
дело в том, что до WinXP SP2 поддерживался только SHA1
начиная с SP2 поддерживается SHA2

сертификат сейчас вы можете выпустить только SHA2



>
> Подскажите, что не хватает в конфиге, чтобы сайт открывался в этом
> браузере?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288640#msg-288640
>
> ___
> 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: SSL для IE 8

[Илья Шипицин]

вы сайт уже в интернет выставили ? дайте адрес ?


пт, 10 июл. 2020 г. в 14:23, grey :

> Уже пробовал SSL Labs. Результат 1 ошибка для IE 8 / XP   No FS 1   No SNI
> 2   Server sent fatal alert: handshake_failure, остальные все тесты
> проходят.
>
>
> Тот же яндекс без проблем открывается на этой старой ОС. Неужели дело в
> бесплатном сертификате? Нашел пару сайтов с этим же сертификатом - тоже не
> открываются. Хотя на сайте Let’s Encrypt написано, что все должно работать:
>
> Known Compatible
> Internet Explorer on Windows XP SP3 and higher
>
> Не могу понять причину. Подскажите, как хоть вычислить кто виноват?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288654#msg-288654
>
> ___
> 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: SSL для IE 8

[Илья Шипицин]

"не доступен еще", но скоро планируется? дадите адрес, когда будет доступен
?

пт, 10 июл. 2020 г. в 16:59, grey :

> Нет, сайт в интернете не доступен еще. Но например, вот аналогичный сайт с
> такой же проблемой https://helloworld.letsencrypt.org/ от самого издателя
> сертификата.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288656#msg-288656
>
> ___
> 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: SSL для IE 8

[Илья Шипицин]

у приведенного примера не включен шифр DES-CBC3-SHA
у вас он включен ? попробуйте его добавить

пт, 10 июл. 2020 г. в 16:59, grey :

> Нет, сайт в интернете не доступен еще. Но например, вот аналогичный сайт с
> такой же проблемой https://helloworld.letsencrypt.org/ от самого издателя
> сертификата.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288656#msg-288656
>
> ___
> 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

уязвимость в реверс-проксировании

[Илья Шипицин]

привет!

конкретики, к сожалению, почти нет
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV28

если у кого-то есть конкретика, поделитесь, плиз ?

Илья Шипицин
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ssl_protocols

[Илья Шипицин]

сб, 4 июл. 2020 г. в 22:54, Gena Makhomed :

> On 29.06.2020 17:07, Maxim Dounin wrote:
>
>  > Соответственно для включения TLSv1.3 по умолчанию надо решить две
>  > проблемы:
>


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


>  >
>  > 1. Сделать решение, которое бы позволило реализовать ту же
>  > семантику "отазаться общаться, не предъявляя сертификата" в
>  > условиях наличия TLSv1.3.
>  >
>  > 2. Придумать решение для существующих конфигураций с "ssl_ciphers
>  > aNULL; return 444;".
>
> Эти две проблемы выглядят как в принципе не решаемые
> в условиях наличия включенного протокола TLSv1.3.
>
>
> >>> в TLSv1.3 не настраиваются шифры
> >>
> >> И если быть уж совсем точным, шифры в TLSv1.3 настраиваются.
> >> Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема
> >> только в том, что вот разработчики nginx не могут договориться
> >> с разработчиками OpenSSL о том, как эти шифры необходимо настраивать.
> >>
> >> В том же Apache можно без проблем настроить шифры для TLSv1.3:
> >> https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
> >>
> >> Если никак не получается договориться с разработчиками OpenSSL,
> >> может быть имеет сделать смысл форк OpenSSL иил написать с нуля
> >> свою собственную библиотеку? Ведь когда-то так и nginx появился,
> >> когда стало понятно, что apache не подходит для некоторых задач.
> >>
> >> Или пойти по пути Apache, сделав возможность раздельной настройки
> >> шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества
> >> времени уже стало понятно, что разработчики OpenSSL свою точку зрения
> >> по этому вопросу менять не собираются и в OpenSSL все будет так же.
> >
> > В тикете тут:
> >
> > https://trac.nginx.org/nginx/ticket/1529
> >
> > и связанных тикетах - достаточно подробно расписано, что
> > настраивается, что не настраивается (в BoringSSL, например, для
> > TLSv1.3 не настраивается вообще ничего), и что именно я думаю по
> > этому поводу.  Не вижу смысла тут повторяться.
>
> Два года назад Вы написали:
>
> https://trac.nginx.org/nginx/ticket/1529#comment:1
>
> "I don't think that nginx should add support for this interface
> before the long-term approach is clear".
>
> https://trac.nginx.org/nginx/ticket/1529#comment:4
>
> For now, solution to configure ciphers as implemented
> in OpenSSL 1.1.1-dev looks highly inconsistent, and it is not clear
> what they are going to do next. Once there will be a clear
> and consistent long-term approach available, we'll consider
> what to do with this.
>
> Теперь, по прошествии двух лет - long-term approach is clear.
>
> В OpenSSL ничего не изменится, хотя бы потому,
> что поддержка нового интерфейса уже встроена в httpd Apache.
>
> --
> Best regards,
>   Gena
>
> ___
> 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: SSL для IE 8

[Илья Шипицин]

очень правдоподобную картинку по client handshake дает SSL Labs
попробуйте?

чт, 9 июл. 2020 г. в 19:40, grey :

> Да, вроде бы SHA-2 - это 256 бит. У меня WinXP SP3 со всем обновлениями.
> Официально IE 8 поддерживает только 128 битное шифрование. Вот я и пытаюсь
> запустить на нем сайт. Перепробовал уже несколько вариантов из интернета с
> разными наборами шифров - не открывается сайт в этом браузере.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288644#msg-288644
>
> ___
> 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: location + proxy pass = 404

[Илья Шипицин]

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


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


ср, 17 июн. 2020 г. в 15:35, emejibka :

> В том то и дело что другие location в конфиге отсутствуют.
> Как объяснить работающий конфиг на старой версии nginx?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288370,288372#msg-288372
>
> ___
> 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: location + proxy pass = 404

[Илья Шипицин]

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

ср, 17 июн. 2020 г. в 15:43, Сергей Тургузов :

> Ещё вариант, можно через rewrite придти к нужному url.
> Но голый конфиг вида server { listen; location /asd/ { proxy_pass; } }
> работать не будет, у вас нет условия для ‘/‘, т.е. запросы неподходящие под
> заданный location будут выдавать ошибку.
>
> > 17 июня 2020 г., в 13:35, emejibka 
> написал(а):
> >
> > В том то и дело что другие location в конфиге отсутствуют.
> > Как объяснить работающий конфиг на старой версии nginx?
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288370,288372#msg-288372
> >
> > ___
> > 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: location + proxy pass = 404

[Илья Шипицин]

ср, 17 июн. 2020 г. в 21:53, emejibka :

> Странно, запустил nginx версии 1.12 в докере с "рабочим" конфигом,
> результат
> тот же - 404.
>
> У нас следующая задача - необходимо спрятать за nginx с десяток других веб
> сервисов, nginx будет работать только как реверс-прокси. DNS использовать
>

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

если у вас адреса фиксированные - вы вполне можете работать на  IP адресах.


> нельзя, nginx будет использоваться внутри локальной сети, dns может быть
> недоступен, да и адреса серверов могут быть разные.
> Т.е. надо поднять сервер по-умолчанию (без виртуальных серверов), где
> каждая
> "виртуальная папка" (location) будет проксировать запросы на другой
> веб-сервер. Пример
> /a => http://10.86.11.80/
> /b => http://some_server
> /c => http://other_server/some_folder/api
> и т.д.
>

куча location-ов и куча правил проксирования. как обычно


>
> Пока писал это понял что nginx`у будет необходимо заменить все ссылки в
> ответе, что вряд ли возможно или всё таки можно это сделать?
>
> Ещё раз посмотрел "рабочий" конфиг, вы были правы, я нашёл location / в
> котором был такой же proxy_pass поэтому всё работало.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288370,288381#msg-288381
>
> ___
> 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: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)

[Илья Шипицин]

чт, 25 июн. 2020 г. в 19:59, Gena Makhomed :

> On 25.06.2020 17:23, Maxim Dounin wrote:
>
> >>> в этом месте вы думаете, что воркер сам себе проставил такой лимит на
> >>> количество файлов.
> >>
> >>> посмотрите в /proc//limits , действительно ли там значения,
> которые вы
> >>> ожидаете или нет
> >>> у нас было, что systemd применял свои лимиты поверх
> >>
> >> # cat /proc/205/cmdline
> >> nginx: worker process
> >>
> >> # grep "Max open files" /proc/205/limits
> >> Max open files  262144   262144   files
> >
> > А у master-процесса что?
>
> # cat /proc/182/cmdline
> nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
>
> # grep "Max open files" /proc/182/limits
> Max open files   1024 262144   files
>
> С помощью директив конфига nginx, насколько я понимаю,
> 1024 нельзя увеличить до какого-нибудь большего значения.
>
> с помощью systemctl edit nginx сделал
>
> /etc/systemd/system/nginx.service.d/override.conf
>
> [Service]
> LimitNOFILE=infinity
>
> так что теперь, после перезапуска у мастера такие параметры:
>
> # cat /proc/690/cmdline
> nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
>
> # grep "Max open files" /proc/690/limits
> Max open files  262144   262144   files
>
> И nginx теперь нормально запускается даже при worker_processes 128;
>
> Спасибо!
>
> > Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает,
> > что количество одновременно отправляемых файловых дескрипторов
> > превышает лимит на количество дескрипторов в отправляющем
> > процессе, в данном случае - в мастере, ибо никто больше файловые
> > дескрипторы с помощью sendmsg() не шлёт.
>
> > Ну и отвечая на исходный вопрос про "насколько критична эта
> > ошибка": приведённая ошибка как минимум означает, что система
> > общения между мастером и рабочими процессами больше не работает.
> > То есть отвечать на запросы nginx будет, а скажем reload сделать -
> > уже нормально не сможет.  То есть приблизительно как и со всеми
> > ошибками уровня alert: "что-то развалилось и непредсказуемо
> > глючит, сделайте что-нибудь".
>
> Если я правильно понял Ваш ответ - nginx шлет файловые дескрипторы
> из мастера в воркеры только в процессе старта и в процессе релоада,
> то есть, эта ошибка
>

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


интересно посмотреть, что у вас в /proc//fd , это файлы открытые
мастером



>
> sendmsg() failed (109: Too many references: cannot splice)
>
> не должна повториться в дальнейшем, в процессе работы nginx
> под большой нагрузкой, если в процессе запуска и релоада
> подобных ошибок не было.
>
> P.S.
>
> На том сервере процессор AMD EPYC 7502P 32-Core Processor
> так что 32 worker-процесса nginx вполне должно быть достаточно,
> по количеству физических ядер и без правки LimitNOFILE для мастера.
>
> Но при настройке worker_processes auto; глюки есть уже сейчас,
> потому что в auto считаются виртуальные а не физические ядра.
>
> Со стороны nginx этот глюк никак нельзя обойти/устранить,
> чтобы все работало при настройке worker_processes auto;
> без ручной правки LimitNOFILE через systemctl edit nginx
> на сервере с процессором AMD EPYC 7502P 32-Core Processor?
>
> --
> Best regards,
>   Gena
>
> ___
> 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: Как обработать редирект и проксировать результат приложению?

[Илья Шипицин]

это не во всех случаях можно сделать корректно.

например, 301 по RFC можно отвечать только на GET. а если сервер ответил
301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или
GET ?
вот именно этот выбор и доносится до клиента, когда 301 транслируется один
в один.

теоретически, вы можете накостылить обработчик 301-ошибки, назначить его на
локейшен, и в локейшене сделать proxy_pass
но это очень скользкая дорожка

пт, 26 июн. 2020 г. в 17:41, Александр Карабанов :

> Здравствуйте.
>
> Приложению запрещено самостоятельно открывать соединения с внешним миром.
> Приложение отправляет запрос на proxykipalive.lan, а Nginx проксирует этот
> запрос на целевой хост (это сделано, чтобы переиспользовать соединение за
> счёт keepalive и не открывать новое соединение на каждый запрос от
> приложения).
> Возникла ситуация, когда целевой хост стал отвечать 301 редиректом,
> естественно приложение, получив вместо ожидаемого контента, 301 редирект
> сломалось.
> Есть ли способ заставить Nginx обработать редирект самостоятельно и отдать
> приложению готовый контент?
> --
> С уважением,
> Александр Карабанов
> ___
> 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: Как обработать редирект и проксировать результат приложению?

[Илья Шипицин]

я примерно такое имел в виду.

а вот расскажите, как будет работать, если на POST запрос будет 301, вы в
@handle_redirect отправите тоже POST ?

пн, 29 июн. 2020 г. в 12:03, Александр Карабанов :

> Вот такое решение нашёл:
>
> https://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx
>
> server {
> ...
>
> location / {
> proxy_pass http://backend;
> # You may need to uncomment the following line if your redirects are 
> relative, e.g. /foo/bar#proxy_redirect / /;
> proxy_intercept_errors on;
> error_page 301 302 307 = @handle_redirect;
> }
>
> location @handle_redirect {
> set $saved_redirect_location '$upstream_http_location';
> proxy_pass $saved_redirect_location;
> }}
>
>
> пт, 26 июн. 2020 г. в 15:57, Илья Шипицин :
>
>> это не во всех случаях можно сделать корректно.
>>
>> например, 301 по RFC можно отвечать только на GET. а если сервер ответил
>> 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или
>> GET ?
>> вот именно этот выбор и доносится до клиента, когда 301 транслируется
>> один в один.
>>
>> теоретически, вы можете накостылить обработчик 301-ошибки, назначить его
>> на локейшен, и в локейшене сделать proxy_pass
>> но это очень скользкая дорожка
>>
>> пт, 26 июн. 2020 г. в 17:41, Александр Карабанов <
>> zend.karaba...@gmail.com>:
>>
>>> Здравствуйте.
>>>
>>> Приложению запрещено самостоятельно открывать соединения с внешним
>>> миром. Приложение отправляет запрос на proxykipalive.lan, а Nginx
>>> проксирует этот запрос на целевой хост (это сделано, чтобы переиспользовать
>>> соединение за счёт keepalive и не открывать новое соединение на каждый
>>> запрос от приложения).
>>> Возникла ситуация, когда целевой хост стал отвечать 301 редиректом,
>>> естественно приложение, получив вместо ожидаемого контента, 301 редирект
>>> сломалось.
>>> Есть ли способ заставить Nginx обработать редирект самостоятельно и
>>> отдать приложению готовый контент?
>>> --
>>> С уважением,
>>> Александр Карабанов
>>> ___
>>> 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: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)

[Илья Шипицин]

чт, 25 июн. 2020 г. в 16:34, Gena Makhomed :

> Здравствуйте, All!
>
> CentOS 8.2, nginx 1.19.0 из официального репозитория.
>
> Когда запускаю nginx внутри systemd-nspawn контейнера -
> в error.log видно большое количество сообщений про ошибку:
>
> [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
>
> Подозреваю, что nginx в контейнере не хватает каких-то лимитов,
> только не понятно каких именно.
>
> При worker_processes 64; ошибка появляется в логах,
> при worker_processes 32; ошибки в логах больше нет.
>
> Каким образом можно сделать так, чтобы nginx работал в контейнере
> systemd-nspawn без ошибок с директивой worker_processes 64; в конфиге?
>
> Насколько критична эта ошибка, и может ли она появиться в логах
> при worker_processes 32; в случае высокой нагрузки на nginx?
>
> Процессор на этом сервере: AMD EPYC 7502P 32-Core Processor
> 32 физических ядра, 64 виртуальных ядра (Simultaneous MultiThreading).
>
> Конфиг:
>
> /etc/systemd/nspawn/1.nspawn
>
> [Exec]
> ResolvConf=copy-host
> LimitNOFILE=infinity
> LimitNICE=40
>
> [Network]
> Bridge=venet0
>
> /etc/nginx/nginx.conf
>
> worker_processes 64;
> worker_priority -10;
> worker_rlimit_core 512M;
> worker_rlimit_nofile 262144;
>

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

посмотрите в /proc//limits , действительно ли там значения, которые вы
ожидаете или нет
у нас было, что systemd применял свои лимиты поверх



> worker_shutdown_timeout 60s;
> working_directory /var/log/nginx;
>
> error_log /var/log/nginx/error.log warn;
>
> events {
>  worker_connections  262144;
>  use epoll;
> }
>
> http {
>  # ...
> }
>
> --
> Best regards,
>   Gena
>
> ___
> 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: access log и параметр flush

[Илья Шипицин]

Сброс происходит в двух случаях, или при заполнении буфера или раз в
какое-то время.

Буфер фиксированного размера

On Wed, Jun 10, 2020, 8:13 PM grey  wrote:

> Это я видел в русской доке:
>
> Если задан размер буфера с помощью параметра buffer или указан параметр
> gzip
> (1.3.10, 1.2.7), то запись будет буферизованной.
>
> "Если задан", а он не задан, то по логике сброс должен происходить в 5
> минут
> согласно параметру flush=5m. Получается, на сайте не совсем правильное
> описание.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288325,288326#msg-288326
>
> ___
> 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: json log и "экранирование" неопределенных переменных

[Илья Шипицин]

через map можете назначить свою переменную и логировать уже ее.

а что за переменные ? просто, там есть, например, upstream_response_time,
он может быть числом (если ответил один бекенд), прочерком (если не ответил
ни один), и комбинацией чисел и прочерков через запятую (если несколько
бекендов зафейлили, а последний ответил)

пт, 24 июл. 2020 г. в 16:14, Slawa Olhovchenkov :

> Внезапно выяснилось что если пишем в json формате (ну ок,
> экранирование json), то отсутсвующе числовые значения все ломают.
> они идут как "-". может в этом случае их выводить как null?
> ___
> 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: json log и "экранирование" неопределенных переменных

[Илья Шипицин]

пт, 24 июл. 2020 г. в 16:20, Slawa Olhovchenkov :

> On Fri, Jul 24, 2020 at 04:17:11PM +0500, Илья Шипицин wrote:
>
> > через map можете назначить свою переменную и логировать уже ее.
>
> ну вот для upstream_response_time так прокатит ли?
>

прокатит


> и не правильней ли все же при экранировании json это делать на уровне
> mod_log?
>

у этой переменной список возможных значений

float
-
-, float, float

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


>
> > а что за переменные ? просто, там есть, например, upstream_response_time,
> > он может быть числом (если ответил один бекенд), прочерком (если не
> ответил
> > ни один), и комбинацией чисел и прочерков через запятую (если несколько
> > бекендов зафейлили, а последний ответил)
>
> вообще да, именно он.
>
> > пт, 24 июл. 2020 г. в 16:14, Slawa Olhovchenkov :
> >
> > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > они идут как "-". может в этом случае их выводить как null?
> > > ___
> > > 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: Как правильно склеить www на без www?

[Илья Шипицин]

попробуйте другой линукс ?

чт, 23 июл. 2020 г. в 13:43, akoval :

> В DNS прописаны сервера, то-есть ip по домену определяет.
> Может это особенности ubuntu-сервера?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288770,288812#msg-288812
>
> ___
> 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: Как рассчитать ssl buffer size

[Илья Шипицин]

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

пт, 17 июл. 2020 г. в 17:41, bagas :

> Понимание для чего нужно есть.
> Слышал для улучшения отзывчивости сайта нужно уменьшать, но вот как
> вычислить?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288743,288744#msg-288744
>
> ___
> 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 add_header

[Илья Шипицин]

Наследуются. Но если на уровне server есть add_header, то все директивы
уровня выше игнорятся

On Fri, Jul 17, 2020, 2:38 PM nkatsy  wrote:

> Добрый день.
>
> В секции http есть есть следующие директивы:
>
> --
> add_header X-Frame-Options 'SAMEORIGIN';
> add_header X-XSS-Protection "1; mode=block";
> add_header X-Content-Type-Options nosniff;
> --
>
> Которые почему-то не наследуются для https-версии сайта.
> Для http - работает.
> Если эти директивы добавить в https секцию.
> Все работает.
> В чем может быть проблема?
> --
>
> Спасибо.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288741,288741#msg-288741
>
> ___
> 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 add_header

[Илья Шипицин]

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

On Sat, Jul 18, 2020, 1:23 AM nkatsy  wrote:

> Хм, неожиданно.  Но так и есть.
> В server был другой add_header.
> Не логичнее ли было бы наследовать, с http, то что не оговоренно в server?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288741,288751#msg-288751
>
> ___
> 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: json log и "экранирование" неопределенных переменных

[Илья Шипицин]

вс, 26 июл. 2020 г. в 22:05, Slawa Olhovchenkov :

> On Sun, Jul 26, 2020 at 09:52:35PM +0500, Илья Шипицин wrote:
>
> > > https://stackoverflow.com/questions/21120999/representing-null-in-json
> > >
> > > в предположении что значение числовое.
> > >
> >
> > а как правильно ескейпить "0.001, - , 0.002"
>

первый бекенд вернул 503
второй сбросил tcp
третий вернул 200

и у меня proxy_next_upstream http_503


>
> да, хороший вопрос
> только почему у нас два ответа?
>
> но я думаю что если одно число -- то как число
> если ничего -- не было обращений к апстирму -- null
> иначе строка в кавычках.
> ___
> 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: json log и "экранирование" неопределенных переменных

[Илья Шипицин]

вс, 26 июл. 2020 г. в 21:43, Slawa Olhovchenkov :

> On Sun, Jul 26, 2020 at 07:29:04PM +0300, Валентин Бартенев wrote:
>
> > On Sunday, 26 July 2020 19:15:20 MSK Slawa Olhovchenkov wrote:
> > > On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:
> > >
> > > >
> > > > > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov 
> wrote:
> > > > >
> > > > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > > > они идут как "-". может в этом случае их выводить как null?
> > > >
> > > > Такая подстановка используется в эскейпинге по умолчанию,
> > > > если значение переменной не найдено.  В других форматах
> > > > эскейпинга значение не выводится, подробнее здесь:
> > > > http://nginx.org/r/log_format/ru
> > >
> > > ну по спецификации json отстувиие должно кодироваться как null, не?
> >
> > Это где такое написано?
>
> https://stackoverflow.com/questions/21120999/representing-null-in-json
>
> в предположении что значение числовое.
>

а как правильно ескейпить "0.001, - , 0.002"


>
> в любом случае варианта выводить ничего нет -- для чисел будет не
> валидный json, а все числа пихать в виде строк в "" -- как-то тоже
> кажется неправильным.
> ___
> 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: tcpdump tls

[Илья Шипицин]

у chrome есть net-internals

https://support.google.com/chrome/a/answer/6271171?hl=en

пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov :

> On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:
>
> > 27.07.2020 0:47, Slawa Olhovchenkov пишет:
> >
> > > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> > >
> > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > > типа
> > >
> > > 
> > > Server's response
> > >
> > > Full response:
> > > 0 Missing status code HTTP/1.1
> > > =
> > >
> > >
> > > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > > именно пришло.
> >
> > В случае сеансовых ключей RSA можно попробовать в Wireshark:
> > меню Редактирование/Параметры (Edit/Preference),
> > дальше Protocols/TLS и там есть место вставить серверный ключ.
>
> И брать его из браузера? Как?
>
> > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> > дампить сессионные ключи, чтобы потом можно было их использовать в
> Wireshark,
> > в (Pre)-Master-Secret log filename.
>
> Отлично, меня это устроит, какие ключевые слова гуглить?
> ___
> 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: tcpdump tls

[Илья Шипицин]

Если хочется именно pcap, посмотрите, тут на форуме был вопрос про слив
ключей шифрования в ФСБ. Можно подгрузить библиотеку, которая сохранит
ключи в файл

On Sun, Jul 26, 2020, 10:47 PM Slawa Olhovchenkov  wrote:

> А что-как можно сделать что бы расшифровать https сессию в .pcap?
>
> Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> типа
>
> 
> Server's response
>
> Full response:
> 0 Missing status code HTTP/1.1
> =
>
>
> и я хочу своими глазами увидеть что конкретно ему отправилось и что
> именно пришло.
> ___
> 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: tcpdump tls

[Илья Шипицин]

Возможно проще fiddler на стороне браузера

On Sun, Jul 26, 2020, 10:47 PM Slawa Olhovchenkov  wrote:

> А что-как можно сделать что бы расшифровать https сессию в .pcap?
>
> Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> типа
>
> 
> Server's response
>
> Full response:
> 0 Missing status code HTTP/1.1
> =
>
>
> и я хочу своими глазами увидеть что конкретно ему отправилось и что
> именно пришло.
> ___
> 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: tcpdump tls

[Илья Шипицин]

пн, 27 июл. 2020 г. в 12:44, Eugene Grosbein :

> 27.07.2020 0:47, Slawa Olhovchenkov пишет:
>
> > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> >
> > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > типа
> >
> > 
> > Server's response
> >
> > Full response:
> > 0 Missing status code HTTP/1.1
> > =
> >
> >
> > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > именно пришло.
>
> В случае сеансовых ключей RSA можно попробовать в Wireshark:
> меню Редактирование/Параметры (Edit/Preference),
> дальше Protocols/TLS и там есть место вставить серверный ключ.
>


тут, вероятно, стоит сделать оговорку про FPS (forward perfect secrecy).
давным-давно, когда зрители фильмов про чебурашку еще были детьми, шифры
были такие,
что имея закрытый ключ сервера можно было декодировать SSL сессию.

потом пришли безопасники, сказали "непорядок" и ввели FPS шифры (сейчас
почти все такие, если вы специально
не ограничите, и то, не факт, что современный браузер будет с таким
работать).


поэтому нужны сессионные ключи. которые можно стырить из браузера или из
nginx (через специальную библиотеку)


>
> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> дампить сессионные ключи, чтобы потом можно было их использовать в
> Wireshark,
> в (Pre)-Master-Secret log filename.
>
>
>
> ___
> 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 и завышение трафика.

[Илья Шипицин]

а научите, как $bytes_sent  должен биться с SSL ?

чт, 23 июл. 2020 г. в 21:35, Evgeniy Berdnikov :

> On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> > это все понятно и очевидно, но два раза -- это два раза.
> > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > закрывать не должны.
>
>  Можно запустить tcpdump и посмотреть, сколько отдаётся клиенту.
>  Эта утилита прямо номера байт с начала коннекции покажет.
>  В нормальной сети можно ещё накинуть ещё 2-5% на ретрасмиссии.
>  Плюс есть счётчики интерфейсов (там будет больше на L2-заголовки,
>  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
>  адресовать претензии к nginx или к канальному оборудованию.
> --
>  Eugene Berdnikov
> ___
> 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 и завышение трафика.

[Илья Шипицин]

чт, 23 июл. 2020 г. в 22:39, Slawa Olhovchenkov :

>
> On Thu, Jul 23, 2020 at 08:33:25PM +0300, Evgeniy Berdnikov wrote:
>
> > On Thu, Jul 23, 2020 at 07:54:09PM +0300, Slawa Olhovchenkov wrote:
> > > On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
> > ...
> > > >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> > > >  адресовать претензии к nginx или к канальному оборудованию.
> > >
> > > я не понимаю к чему это все, я уже сказал -- канальное оборудование
> > > (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> > > чем по учету bytes_sent.
> >
> >  Чтобы понять, какая из двух линеек крива, следует приложить третью.
>
> Что непонятно в следующем утверждении: счетчики l2 от операционной
> системы и свича совпадают? Это канает как две дополнительных линейки?
>
> >  А чтобы не путаться в лесу, лучше всего изучить отдельную сосну.
> >
> >  Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
> >  аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
> >  и ретрансмиссий, но тогда они в дампе будут отлично видны.
>
> Откуда я для одной конекции возьму аппартные счетчики?
>
> Каким образом 50% заголовков и ретрансмиссий дадут вдвое меньше
> трафика на апапртаных счетчиках?
>

а подзапросы используются ?

конфиг это proxy_pass или что-то хитрее ?


> ___
> 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 и завышение трафика.

[Илья Шипицин]

чт, 23 июл. 2020 г. в 21:54, Slawa Olhovchenkov :

> On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
>
> > On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> > > это все понятно и очевидно, но два раза -- это два раза.
> > > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > > закрывать не должны.
> >
> >  Можно запустить tcpdump и посмотреть, сколько отдаётся клиенту.
> >  Эта утилита прямо номера байт с начала коннекции покажет.
> >  В нормальной сети можно ещё накинуть ещё 2-5% на ретрасмиссии.
> >  Плюс есть счётчики интерфейсов (там будет больше на L2-заголовки,
> >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> >  адресовать претензии к nginx или к канальному оборудованию.
>
> я не понимаю к чему это все, я уже сказал -- канальное оборудование
> (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> чем по учету bytes_sent.
>
> PS: а что, ssl как-то хитро bytes_sent искажает?
>

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

обычно, за счет SSL добавляется оверхеда (который непонятно как посчитать)



> ___
> 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: странное поведение Chrome на http2

[Илья Шипицин]

нельзя сказать, чтобы с вебсокетами или http2 всё было прямо печально.
обе годные технологии с какими-то небольшими изъянами проектирования, не
более

ср, 2 дек. 2020 г. в 09:37, Aln Kapa :

> Понял.
> А ещё вопрос, вот сейчас http3 ждём там все также печально?
>
> вт, 1 дек. 2020 г., 21:48 Maxim Dounin :
>
>> Hello!
>>
>> On Tue, Dec 01, 2020 at 08:26:57PM +0300, Aln Kapa wrote:
>>
>> > От это поворот!
>> > без tls и на каждый коннект  отдельное соединение.
>>
>> Про "без tls" - это уж как сконфигурите.  А то, что соединение
>> это, ВНЕЗАПНО, соединение - ну да, так уж получилось.
>>
>> > А sse  работает так же?
>>
>> Если под SSE вы имеете в виду Server-Sent Events, то они работают
>> в рамках стриминга HTTP-ответа с Content-Type "text/event-stream",
>> и могут работать как по HTTP/1.x, так и по HTTP/2.
>>
>> --
>> Maxim Dounin
>> http://mdounin.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, если сервер из upstream недоступен.

[Илья Шипицин]

я сталкивался с несколькими вариантами

1) платный nginx (там есть отложенный ресолв)
2) haproxy
3) проксировать не на апстрим, а на бекенд напрямую, тогда можно через
переменную ресолвить динамически
4) спрятать ресолв в consul templates

вт, 8 дек. 2020 г. в 13:19, fbulkin :

> Приветствую.
>
> Как запустить nginx. при условии, если часть серверов в upstream
> недоступны?
>
> upstream upstream-agw {
> ip_hash;
> server i18s-a-agw1:8080 max_fails=0;
> server i18s-a-agw3:8080 max_fails=0;
> }
>
>  i18s-a-agw1:8080 - доступен!
>  i18s-a-agw3:8080 - На момент запуска не резолвится
>
> error:
> nginx[29440]: nginx: [emerg] host not found in upstream "i18s-a-agw3:8080"
> in
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,290166,290166#msg-290166
>
> ___
> 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: странное поведение Chrome на http2

[Илья Шипицин]

вспомнил. мы проводили исследование на то, пользуются ли клиенты SNI.
в принципе, на вайлдкардовых сертах, как оказалось, можно работать и без
SNI.
некоторые случаи мы идентифицировали, это клиенты с определенными билдами
КриптоПро (как-то оно афектит даже RSA криптографию)

я к чему. в приведенном ниже условии, кажется, придется легитимизировать
пустой $ssl_server_name

но даже с учетом этого хак выглядит несложным. мы затестим.

if ($ssl_server_name != "example.com") {
return 421;
}

вт, 1 дек. 2020 г. в 18:43, Maxim Dounin :

> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin :
> >
> > > Hello!
> > >
> > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> > >
> > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > > > >
> > > > > > привет!
> > > > > >
> > > > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > > > домены разные, каждый со своей бизнес логикой.
> > > > > >
> > > > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP
> один,
> > > то я
> > > > > > буду весь трафик гонять через одно tcp подключение". все бы
> ничего,
> > > но
> > > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > > > подключение до конкретного сайта, а вообще все, которые он
> умудрился
> > > > > > связать с этим tcp подключением.
> > > > > >
> > > > > > частный пример - сайт, который иногда формирует очень длинные
> URL, не
> > > > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> > > такой
> > > > > > ситуации Chrome рвет всё до этого IP адреса.
> > > > > >
> > > > > > как-то не по христиански чтоли.
> > > > > >
> > > > > > подумалось, что аналогичных хостингов высокой плотности в
> рассылке
> > > может
> > > > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > > > >
> > > > > Это называется connection reuse, правила прописаны тут:
> > > > >
> > > > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > > > >
> > > > > В частности:
> > > > >
> > > > >For "https" resources, connection reuse additionally depends on
> > > > >having a certificate that is valid for the host in the URI.  The
> > > > >certificate presented by the server MUST satisfy any checks
> that the
> > > > >client would perform when forming a new TLS connection for the
> host
> > > > >in the URI.
> > > > >
> > > > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > > > серверов).
> > > > >
> > > > > Ну либо руками возвращать 421 по необходимости, проверяя
> > > $ssl_server_name.
> > > > >
> > > >
> > > > в исходниках это вот так
> > > >
> > > > if ((size_t) len > h2scf->max_field_size) {
> > > > ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> > > >   "client exceeded http2_max_field_size limit");
> > > >
> > > > return ngx_http_v2_connection_error(h2c,
> > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > > > }
> > > >
> > > >
> > > > как можно в этом месте вернуть "по необходимости" 421 ?
> > >
> > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> > > соединением невозможна.  Возвращать 421 надо заранее, до того, как
> > > придёт кривой запрос.
> > >
> > >
> > пардон. я не понимаю, что вы предлагаете.
> > можете привести пример, как сделать ?
>
> Если добавить что-нибудь вроде:
>
> if ($ssl_server_name != "example.com") {
> return 421;
> }
>
> во все релевантные блоки server{}, это предотвратит reuse
> соединений, кроме первых запросов.  Соответственно соединения
> будут отдельными, и при необходимости закрыть соединение - будет
> закрываться только соединение с одним сервером, а не со всеми
> серверами на данном IP.
>
> Ну и обращаю внимание на озвученный выше и проигнорированный
> вариант разных сертификатов.  Он позволяет контроллировать
> поведение на стороне браузера и соответственно более эффективен,
> т.к. нет проблемы первых запросов.
>
> --
> Maxim Dounin
> http://mdounin.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

странное поведение Chrome на http2

[Илья Шипицин]

привет!

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

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

частный пример - сайт, который иногда формирует очень длинные URL, не
помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой
ситуации Chrome рвет всё до этого IP адреса.

как-то не по христиански чтоли.

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

Илья Шипицин
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: странное поведение Chrome на http2

[Илья Шипицин]

вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :

> Hello!
>
> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>
> > привет!
> >
> > может кто сталкивался, и знает, что с этим можно сделать.
> > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > домены разные, каждый со своей бизнес логикой.
> >
> > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один, то я
> > буду весь трафик гонять через одно tcp подключение". все бы ничего, но
> > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > подключение до конкретного сайта, а вообще все, которые он умудрился
> > связать с этим tcp подключением.
> >
> > частный пример - сайт, который иногда формирует очень длинные URL, не
> > помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой
> > ситуации Chrome рвет всё до этого IP адреса.
> >
> > как-то не по христиански чтоли.
> >
> > подумалось, что аналогичных хостингов высокой плотности в рассылке может
> > быть достаточное количество. не первый же  я с таким столкнулся?
>
> Это называется connection reuse, правила прописаны тут:
>
> https://tools.ietf.org/html/rfc7540#section-9.1.1
>
> В частности:
>
>For "https" resources, connection reuse additionally depends on
>having a certificate that is valid for the host in the URI.  The
>certificate presented by the server MUST satisfy any checks that the
>client would perform when forming a new TLS connection for the host
>in the URI.
>
> То есть если хочется, чтобы соединения не reuse'ались, можно
> сконфигурировать разные сертификаты для разных серверов (или групп
> серверов).
>
> Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.
>

в исходниках это вот так

if ((size_t) len > h2scf->max_field_size) {
ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
  "client exceeded http2_max_field_size limit");

return ngx_http_v2_connection_error(h2c,
NGX_HTTP_V2_ENHANCE_YOUR_CALM);
}


как можно в этом месте вернуть "по необходимости" 421 ?



>
> --
> Maxim Dounin
> http://mdounin.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: странное поведение Chrome на http2

[Илья Шипицин]

вт, 1 дек. 2020 г. в 18:13, Maxim Dounin :

> Hello!
>
> On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :
> >
> > > Hello!
> > >
> > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > >
> > > > привет!
> > > >
> > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > домены разные, каждый со своей бизнес логикой.
> > > >
> > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один,
> то я
> > > > буду весь трафик гонять через одно tcp подключение". все бы ничего,
> но
> > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > подключение до конкретного сайта, а вообще все, которые он умудрился
> > > > связать с этим tcp подключением.
> > > >
> > > > частный пример - сайт, который иногда формирует очень длинные URL, не
> > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> такой
> > > > ситуации Chrome рвет всё до этого IP адреса.
> > > >
> > > > как-то не по христиански чтоли.
> > > >
> > > > подумалось, что аналогичных хостингов высокой плотности в рассылке
> может
> > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > >
> > > Это называется connection reuse, правила прописаны тут:
> > >
> > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > >
> > > В частности:
> > >
> > >For "https" resources, connection reuse additionally depends on
> > >having a certificate that is valid for the host in the URI.  The
> > >certificate presented by the server MUST satisfy any checks that the
> > >client would perform when forming a new TLS connection for the host
> > >in the URI.
> > >
> > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > серверов).
> > >
> > > Ну либо руками возвращать 421 по необходимости, проверяя
> $ssl_server_name.
> > >
> >
> > в исходниках это вот так
> >
> > if ((size_t) len > h2scf->max_field_size) {
> > ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> >   "client exceeded http2_max_field_size limit");
> >
> > return ngx_http_v2_connection_error(h2c,
> > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > }
> >
> >
> > как можно в этом месте вернуть "по необходимости" 421 ?
>
> Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> соединением невозможна.  Возвращать 421 надо заранее, до того, как
> придёт кривой запрос.
>
>
пардон. я не понимаю, что вы предлагаете.
можете привести пример, как сделать ?



> --
> Maxim Dounin
> http://mdounin.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: странное поведение Chrome на http2

[Илья Шипицин]

вт, 1 дек. 2020 г. в 18:43, Maxim Dounin :

> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin :
> >
> > > Hello!
> > >
> > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> > >
> > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > > > >
> > > > > > привет!
> > > > > >
> > > > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > > > домены разные, каждый со своей бизнес логикой.
> > > > > >
> > > > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP
> один,
> > > то я
> > > > > > буду весь трафик гонять через одно tcp подключение". все бы
> ничего,
> > > но
> > > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > > > подключение до конкретного сайта, а вообще все, которые он
> умудрился
> > > > > > связать с этим tcp подключением.
> > > > > >
> > > > > > частный пример - сайт, который иногда формирует очень длинные
> URL, не
> > > > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> > > такой
> > > > > > ситуации Chrome рвет всё до этого IP адреса.
> > > > > >
> > > > > > как-то не по христиански чтоли.
> > > > > >
> > > > > > подумалось, что аналогичных хостингов высокой плотности в
> рассылке
> > > может
> > > > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > > > >
> > > > > Это называется connection reuse, правила прописаны тут:
> > > > >
> > > > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > > > >
> > > > > В частности:
> > > > >
> > > > >For "https" resources, connection reuse additionally depends on
> > > > >having a certificate that is valid for the host in the URI.  The
> > > > >certificate presented by the server MUST satisfy any checks
> that the
> > > > >client would perform when forming a new TLS connection for the
> host
> > > > >in the URI.
> > > > >
> > > > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > > > серверов).
> > > > >
> > > > > Ну либо руками возвращать 421 по необходимости, проверяя
> > > $ssl_server_name.
> > > > >
> > > >
> > > > в исходниках это вот так
> > > >
> > > > if ((size_t) len > h2scf->max_field_size) {
> > > > ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> > > >   "client exceeded http2_max_field_size limit");
> > > >
> > > > return ngx_http_v2_connection_error(h2c,
> > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > > > }
> > > >
> > > >
> > > > как можно в этом месте вернуть "по необходимости" 421 ?
> > >
> > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> > > соединением невозможна.  Возвращать 421 надо заранее, до того, как
> > > придёт кривой запрос.
> > >
> > >
> > пардон. я не понимаю, что вы предлагаете.
> > можете привести пример, как сделать ?
>
> Если добавить что-нибудь вроде:
>
> if ($ssl_server_name != "example.com") {
> return 421;
> }
>

идею понял, протестируем


>
> во все релевантные блоки server{}, это предотвратит reuse
> соединений, кроме первых запросов.  Соответственно соединения
> будут отдельными, и при необходимости закрыть соединение - будет
> закрываться только соединение с одним сервером, а не со всеми
> серверами на данном IP.
>
> Ну и обращаю внимание на озвученный выше и проигнорированный
> вариант разных сертификатов.  Он позволяет контроллировать
> поведение на стороне браузера и соответственно более эффективен,
> т.к. нет проблемы первых запросов.
>

если это вайлдкард, где я возьму разных сертификатов



вообще, я расчитывал на

1) более адекватное поведение хрома (хотя о чем это я)
2) более адекватное поведение nginx с учетом пункта "1", например, вместо
фатального для браузера GO AWAY, отвечать 421



>
> --
> Maxim Dounin
> http://mdounin.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: странное поведение Chrome на http2

[Илья Шипицин]

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


это лишь гипотеза. но тем не менее

вт, 1 дек. 2020 г. в 20:53, Aln Kapa :

> А вот такое поведение? В какой-то момент chrome перестает что либо
> получать по websocket, если открыть несколько вкладок на разные сайты с
> одним ip.
>
> вт, 1 дек. 2020 г., 2:11 Maxim Dounin :
>
>> Hello!
>>
>> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>>
>> > привет!
>> >
>> > может кто сталкивался, и знает, что с этим можно сделать.
>> > ситуация - хостинг высокой плотности, на одном IP много доменов.
>> > домены разные, каждый со своей бизнес логикой.
>> >
>> > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один, то я
>> > буду весь трафик гонять через одно tcp подключение". все бы ничего, но
>> > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
>> > подключение до конкретного сайта, а вообще все, которые он умудрился
>> > связать с этим tcp подключением.
>> >
>> > частный пример - сайт, который иногда формирует очень длинные URL, не
>> > помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой
>> > ситуации Chrome рвет всё до этого IP адреса.
>> >
>> > как-то не по христиански чтоли.
>> >
>> > подумалось, что аналогичных хостингов высокой плотности в рассылке может
>> > быть достаточное количество. не первый же  я с таким столкнулся?
>>
>> Это называется connection reuse, правила прописаны тут:
>>
>> https://tools.ietf.org/html/rfc7540#section-9.1.1
>>
>> В частности:
>>
>>For "https" resources, connection reuse additionally depends on
>>having a certificate that is valid for the host in the URI.  The
>>certificate presented by the server MUST satisfy any checks that the
>>client would perform when forming a new TLS connection for the host
>>in the URI.
>>
>> То есть если хочется, чтобы соединения не reuse'ались, можно
>> сконфигурировать разные сертификаты для разных серверов (или групп
>> серверов).
>>
>> Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.
>>
>> --
>> Maxim Dounin
>> http://mdounin.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 -t" ?

[Илья Шипицин]

ср, 23 дек. 2020 г. в 13:54, Dmitry Morozovsky :

> On Wed, 23 Dec 2020, Илья Шипицин wrote:
>
> > привет!
> >
> > беру чистый centos, ставлю nginx из стокового репозитория.
> > в /var/cache/nginx - пусто. ожидаемо
> >
> > делаю "nginx -t", и уже не пусто. а вот это не очень ожидаемо было.
> >
> > почему так ?
>
>
> ожидаемо: чтоб проверить, что прав хватает.
>
> доплогику засовывать, чтобы удалять пустые? а если параллельно nginx уже
> бегает, просто ничего туда ещё не написал?
>

мы ловим "access denied" на уже запущенном и работающем воркере в момент,
когда запускаем "nginx -t"

ну и как бы не очень ожидаемо, что тестирование конфигурации это еще
создание временных папок



>
> >
> >
> > [root@centos system]# cd /var/cache/nginx/
> > [root@centos nginx]# ls
> > [root@centos nginx]# nginx -t
> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > nginx: configuration file /etc/nginx/nginx.conf test is successful
> > [root@centos nginx]# ls
> > client_temp  fastcgi_temp  proxy_temp  scgi_temp  uwsgi_temp
> > [root@centos nginx]#
> >
> >
> >
> > Илья Шипицин
> >
>
> --
> Sincerely,
> D.Marck[DM5020, MCK-RIPE, DM3-RIPN]
> [ FreeBSD committer:ma...@freebsd.org
> ]
> ---
> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woo...@woozle.net
> ***
> ---
> ___
> 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 -t" ?

[Илья Шипицин]

отбой. наши "access denied"  вызваны сугубо нашими локальными приколами

On Wed, Dec 23, 2020, 2:55 PM Илья Шипицин  wrote:

>
>
> ср, 23 дек. 2020 г. в 13:54, Dmitry Morozovsky :
>
>> On Wed, 23 Dec 2020, Илья Шипицин wrote:
>>
>> > привет!
>> >
>> > беру чистый centos, ставлю nginx из стокового репозитория.
>> > в /var/cache/nginx - пусто. ожидаемо
>> >
>> > делаю "nginx -t", и уже не пусто. а вот это не очень ожидаемо было.
>> >
>> > почему так ?
>>
>>
>> ожидаемо: чтоб проверить, что прав хватает.
>>
>> доплогику засовывать, чтобы удалять пустые? а если параллельно nginx уже
>> бегает, просто ничего туда ещё не написал?
>>
>
> мы ловим "access denied" на уже запущенном и работающем воркере в момент,
> когда запускаем "nginx -t"
>
> ну и как бы не очень ожидаемо, что тестирование конфигурации это еще
> создание временных папок
>
>
>
>>
>> >
>> >
>> > [root@centos system]# cd /var/cache/nginx/
>> > [root@centos nginx]# ls
>> > [root@centos nginx]# nginx -t
>> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
>> > nginx: configuration file /etc/nginx/nginx.conf test is successful
>> > [root@centos nginx]# ls
>> > client_temp  fastcgi_temp  proxy_temp  scgi_temp  uwsgi_temp
>> > [root@centos nginx]#
>> >
>> >
>> >
>> > Илья Шипицин
>> >
>>
>> --
>> Sincerely,
>> D.Marck[DM5020, MCK-RIPE,
>> DM3-RIPN]
>> [ FreeBSD committer:ma...@freebsd.org
>> ]
>>
>> ---
>> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woo...@woozle.net
>> ***
>>
>> ---
>> ___
>> 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

режим dry run для "return 421"

[Илья Шипицин]

привет!

рассматриваем вариант

if ($some_condition != $host) { return 421; }

вопрос - как можно по дешевому в этом месте сделать "логирование вместо
return" ?

Илья Шипицин
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: режим dry run для "return 421"

[Илья Шипицин]

грубо - сделать все то же самое, что было бы без "return 421" +
залогировать попытку вернуть.
классический dry run

error_page 421  = @handler_421;

location / {
   if ($some_condition != $host) { return 421; }

   proxy_pass http://upstream;

   access_log /var/log/my.log;
}

location @handler_421 {
   proxy_pass http://upstream;

   access_log /var/log/my.log;
   access_log /var/log/additional.log special_format;
}



On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov  wrote:

> On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
> >привет!
> >рассматриваем вариант
> >if ($some_condition != $host) { return 421; }
> >вопрос - как можно по дешевому в этом месте сделать "логирование
> вместо
> >return" ?
>
>  return 302 
>  ?
>
>  Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
>  Логгирование это не ответ, а этап обработки запроса.
> --
>  Eugene Berdnikov
> ___
> 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: режим dry run для "return 421"

[Илья Шипицин]

вт, 22 дек. 2020 г. в 19:58, Evgeniy Berdnikov :

> On Tue, Dec 22, 2020 at 06:17:13PM +0500, Илья Шипицин wrote:
> >грубо - сделать все то же самое, что было бы без "return 421" +
> >залогировать попытку вернуть.
> >классический dry run
> >error_page 421  = @handler_421;
> >location / {
> >   if ($some_condition != $host) { return 421; }
> >   proxy_pass http://upstream;
> >   access_log /var/log/my.log;
> >}
> >location @handler_421 {
> >   proxy_pass http://upstream;
> >   access_log /var/log/my.log;
> >   access_log /var/log/additional.log special_format;
> >}
>
>  Какой же он "dry" если в хендлере есть то же самое обращение апстриму?
>

изначально у меня вот так

location / {
  proxy_pass http://upstream;
}

я хочу добавить if ($some_condition != $host) { return 421; } в режиме, в
котором поведение не поменяется, но я убеждусь, что конструкция будет
срабатывать ровно тогда, когда я имею в виду



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


с POST-ами есть вопросы. ну и вообще конструкция громоздкая.


>
>
> >    On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov <[3]b...@protva.ru>
> wrote:
> >
> >  On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
> >  >привет!
> >  >рассматриваем вариант
> >  >if ($some_condition != $host) { return 421; }
> >  >вопрос - как можно по дешевому в этом месте сделать
> "логирование
> >  вместо
> >  >return" ?
> >
> >   return 302 
> >   ?
> >
> >   Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
> >   Логгирование это не ответ, а этап обработки запроса.
> >  --
> >   Eugene Berdnikov
> >  ___
> >  nginx-ru mailing list
> >  [4]nginx-ru@nginx.org
> >  [5]http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> > References
> >
> >Visible links
> >1. http://upstream/
> >2. http://upstream/
> >3. mailto:b...@protva.ru
> >4. mailto:nginx-ru@nginx.org
> >5. http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> --
>  Eugene Berdnikov
> ___
> 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: режим dry run для "return 421"

[Илья Шипицин]

Да, так и сделаю. Спасибо

On Tue, Dec 22, 2020, 11:22 PM Oleg A. Mamontov  wrote:

> On Tue, Dec 22, 2020 at 06:17:13PM +0500, Илья Шипицин wrote:
> >грубо - сделать все то же самое, что было бы без "return 421" +
> залогировать
> >попытку вернуть.
> >классический dry run
>
> Возможно, вам подойдет дополнительный access_log по условию:
> ---
> map $host $condition {
>  default 1;
>  some_condition  0;
> }
> ...
> location / {
>proxy_pass http://upstream;
>
>access_log /var/log/my.log;
>access_log /var/log/conditional.log if=$condition;
> }
> ---
>
> >error_page 421  = @handler_421;
> >
> >location / {
> >   if ($some_condition != $host) { return 421; }
> >
> >   proxy_pass http://upstream;
> >
> >   access_log /var/log/my.log;
> >}
> >
> >location @handler_421 {
> >   proxy_pass http://upstream;
> >
> >   access_log /var/log/my.log;
> >   access_log /var/log/additional.log special_format;
> >}
> >
> >
> >
> >On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov  wrote:
> >
> >On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
> >>привет!
> >>рассматриваем вариант
> >>if ($some_condition != $host) { return 421; }
> >>вопрос - как можно по дешевому в этом месте сделать "логирование
> >вместо
> >>return" ?
> >
> > return 302 
> > ?
> >
> > Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
> > Логгирование это не ответ, а этап обработки запроса.
> >--
> > Eugene Berdnikov
> >___
> >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
>
>
> --
> Cheers,
> Oleg A. Mamontov
>
> mailto: o...@mamontov.net
>
> skype:  lonerr11
> cell:   +7 (903) 798-1352
> ___
> 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 -t" ?

[Илья Шипицин]

привет!

беру чистый centos, ставлю nginx из стокового репозитория.
в /var/cache/nginx - пусто. ожидаемо

делаю "nginx -t", и уже не пусто. а вот это не очень ожидаемо было.

почему так ?


[root@centos system]# cd /var/cache/nginx/
[root@centos nginx]# ls
[root@centos nginx]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@centos nginx]# ls
client_temp  fastcgi_temp  proxy_temp  scgi_temp  uwsgi_temp
[root@centos nginx]#



Илья Шипицин
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Почините этот форум, невозможно зарегистрироваться...

[Илья Шипицин]

это не показатель.


крупные почтовики не делают smtp callback. они могут себе позволить мэшн
лёрнинг на письмах.

пт, 25 дек. 2020 г. в 03:35, Nikolay Grebnev :

> Не выдержал, поискал форум и зарегистрировался.
> Мне на гмейл письмо дошло без каких-либо проблем.
> Если не придираться к странному w...@teresa.liquidhost.co то все работает.
>
> Delivered-To: niko.lay.greb...@gmail.com
> ARC-Authentication-Results: i=1; mx.google.com;
>dkim=pass header.i=@teresa.liquidhost.co header.s=x
> header.b=V8nVUu6W;
>spf=pass (google.com: domain of w...@teresa.liquidhost.co
> designates 69.46.5.194 as permitted sender)
> smtp.mailfrom=w...@teresa.liquidhost.co
> Return-Path: 
> Received: from teresa.liquidhost.co (teresa.liquidhost.co. [69.46.5.194])
> by mx.google.com with ESMTPS id
> q82si25308046ybb.349.2020.12.24.14.31.25
> for 
> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
> Thu, 24 Dec 2020 14:31:25 -0800 (PST)
> Received-SPF: pass (google.com: domain of w...@teresa.liquidhost.co
> designates 69.46.5.194 as permitted sender) client-ip=69.46.5.194;
> Authentication-Results: mx.google.com;
>dkim=pass header.i=@teresa.liquidhost.co header.s=x
> header.b=V8nVUu6W;
>spf=pass (google.com: domain of w...@teresa.liquidhost.co
> designates 69.46.5.194 as permitted sender)
> smtp.mailfrom=w...@teresa.liquidhost.co
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=teresa.liquidhost.co; s=x; h=Date:Sender:From:Message-ID:
> Content-Transfer-Encoding:Content-Type:Subject:To:Reply-To:Cc:MIME-Version:
> Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
> Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
>
> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
> bh=KeAYON1uPKfiT7gBMq7vXqaYrWBWGyAb2NJ8aa5aPzw=;
> b=V8nVUu6Wn4UqMKG6xM179lDFj
>
> UtcRpp+KjdvejCTI52iyXkMVWEWJHMhInKX13xY3AZCGoxvceSKwUn0SGKn2nWp4o4sM0zpnt/VLW
> ZCRdk4aXbEFtL0/dDI1k3UyhMXlbd4ibxyv00VOXEGKnk21MCmU50L1ocy0IMjlEjlqM8=;
> Received: from www by teresa.liquidhost.co with local (Exim 4.91
> (FreeBSD)) (envelope-from ) id
> 1ksZ8n-000O5o-9U for niko.lay.greb...@gmail.com; Thu, 24 Dec 2020
> 17:31:25 -0500
> To: niko.lay.greb...@gmail.com
> Subject: Please verify your account
> X-PHP-Originating-Script: 1001:email_functions.php
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> X-Mailer: Phorum5
> Message-ID: <202012241731.68503279075...@forum.nginx.org>
> X-Phorum: df1b22e43d937f289ea4a05cca76e7e8fbad5c3b
> From: Nginx Forum 
> Sender: World Wide Web Owner 
> Date: Thu, 24 Dec 2020 17:31:25 -0500
>
> On Fri, Dec 25, 2020 at 1:27 AM Alexey  wrote:
> >
> > 24.12.2020 1:33, pavlusha23 пишет:
> > > (Почините этот форум, невозможно зарегистрироваться если почта
> расположена
> > > на серверах с современными строгими антиспам настройками.)
> > >
> > > Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться,
> но не
> > > могут. Я проверил сам, действительно невозможно. Они мне скинули логи
> своей
> > > почты тоже. У всех ситуация примерно одинакова:
> > >
> > > sender verify fail for : all relevant MX
> records
> > > point to non-existent hosts or (invalidly) to IP addresses.
> > > F= rejected RCPT : Sender
> verify
> > > failed
> > >
> > > Т.е. этот форум для служебной рассылки использует какой-то левый
> > > несуществующий адрес отправителя w...@teresa.liquidhost.co то ли DNS
> неверно
> > > настроен, и естественно такие письма сразу отсекаются почтовыми
> серверами
> > > (по крайней мере всеми на базе ispmanager последних версий) на этапе
> > > приёмки, даже в спам не попадают. Прошу администрацию уделить этому
> > > внимание, вроде айтишники жеж.
> > >
> > > У меня старый аккаунт тут, поэтому пишу по просьбе трудящихся. Всем
> спасибо
> > > и с наступающим рождеством!
> >
> >
> >
> > тут кажется уже неоднократно отвечали сотрудники нгинкса, что форум
> > сделан сторонними людьми как прокладка между почтофой рассылкой и вебом.
> > и кажется его (форума) владельцам он надоел, там то сертификат скисает
> > на несколько недель, то вот подтверждения шлет непойми с каких адресов..
> >
> >
> > почему нгинс не уберет из ДНСа forum. при таком подходе, не понятно. Но
> > совет был, не пользоваться, а ходить туда и пользоваться почтовой
> > рассылкой.
> >
> >
> > ниже не единственный ответ по проблеме с форумом
> >
> >
> > 27.02.2020 15:09, Maxim Dounin пишет:
> > Hello!
> >
> > On Thu, Feb 27, 2020 at 12:08:42AM +0300, Dmitry Ivanov wrote:
> >
> > > Здравствуйте, Aleksandr.
> > >
> > >> @Dmitry - форум это просто веб-морда к почтовой рассылке - можно
> > >> подписаться на странице -
> > >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > > Я  в  рассылке  и  читаю. А с форума тяну RSS
> > Форум - поддерживается не нами, его держит Jim Ohlstein.
> > Соответственно писать о проблемах форума в русскую рассылку -
> > приблизительно полностью бесполезно.
> >
> > 

Re: upstream priority

[Илья Шипицин]

можно проксировать на самого себя каскадом.
на каждом каскаде 2 бекенда

пт, 6 нояб. 2020 г. в 22:40, Nikita Koshikov :

> Доброго всем времени суток
>
> Подскажите как можно сделать что-то максимально подобное для выбора
> backend сервера по приоритету, в идеале нужно что-то
>
>   upstream backend {
> server [::1]:81 priority=1;
> server [::1]:82 priority=2;
> server [::1]:83 priority=3;
> server [::1]:84 priority=4;
> server [::1]:85 priority=5;
>   }
> т.е. пока жив хоть один с более высоким приоритетом - слать запросы на
> него ?
>
> Из того что пробовал
>   upstream backend {
> server [::1]:81 weight=1;
> server [::1]:83 backup;
>   }
> Так работает - однако не поддерживает 2+ бекенда
>
> Из самого близкого что удалось сделать - через hash со статичным ключом
>   upstream backend {
> hash 'http_balance';
> server [::1]:81 weight=1 fail_timeout=60;
> server [::1]:82 weight=2 fail_timeout=60;
> server [::1]:83 weight=3 fail_timeout=60;
>   }
> Проблема только что веса не всегда работают, - в данной конфигурации
> выбирается server:82, хотя у 83 более высокий weight. Полная цепочка
> при отказах - 82->83->81
> Учитывается ли вес в такой конфигурации ?
> С более высокими весами начинает работать как нужно 83->82->81
>   upstream backend {
> hash 'http_balance';
> server [::1]:81 weight=1 fail_timeout=60;
> server [::1]:82 weight=10 fail_timeout=60;
> server [::1]:83 weight=100 fail_timeout=60;
>   }
> Хотелось бы понимать это совпадение или веса принимаются в расчет при
> выборе hash-а?
> ___
> 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: upstream priority

[Илья Шипицин]

все верно, первый бекенд - с максимальным весом, бекапом - следующий
(который устроен аналогично)

но я бы не играл с error_page, это запутано получается. что именно
редиректить на error_page, 502 ? 504 ? собственные 502 или проксированные ?
в общем, сложно это.

пт, 6 нояб. 2020 г. в 23:17, Nikita Koshikov :

> Спасибо,
> Имеется ввиду два бекенда один из который с backup ?
>
>   upstream c1 {
> server [::1]:81 ;
> server [::1]:82 backup;
>   }
>
>   upstream c2 {
> server [::1]:83 ;
> server [::1]:84 backup;
>   }
>
> server {
>   location {
> proxy_pass http://c1
> error_page @c2
>   }
> }
> Или что-то другое ?
>
> On Fri, Nov 6, 2020 at 9:52 AM Илья Шипицин  wrote:
> >
> > можно проксировать на самого себя каскадом.
> > на каждом каскаде 2 бекенда
> >
> > пт, 6 нояб. 2020 г. в 22:40, Nikita Koshikov :
> >>
> >> Доброго всем времени суток
> >>
> >> Подскажите как можно сделать что-то максимально подобное для выбора
> >> backend сервера по приоритету, в идеале нужно что-то
> >>
> >>   upstream backend {
> >> server [::1]:81 priority=1;
> >> server [::1]:82 priority=2;
> >> server [::1]:83 priority=3;
> >> server [::1]:84 priority=4;
> >> server [::1]:85 priority=5;
> >>   }
> >> т.е. пока жив хоть один с более высоким приоритетом - слать запросы на
> него ?
> >>
> >> Из того что пробовал
> >>   upstream backend {
> >> server [::1]:81 weight=1;
> >> server [::1]:83 backup;
> >>   }
> >> Так работает - однако не поддерживает 2+ бекенда
> >>
> >> Из самого близкого что удалось сделать - через hash со статичным ключом
> >>   upstream backend {
> >> hash 'http_balance';
> >> server [::1]:81 weight=1 fail_timeout=60;
> >> server [::1]:82 weight=2 fail_timeout=60;
> >> server [::1]:83 weight=3 fail_timeout=60;
> >>   }
> >> Проблема только что веса не всегда работают, - в данной конфигурации
> >> выбирается server:82, хотя у 83 более высокий weight. Полная цепочка
> >> при отказах - 82->83->81
> >> Учитывается ли вес в такой конфигурации ?
> >> С более высокими весами начинает работать как нужно 83->82->81
> >>   upstream backend {
> >> hash 'http_balance';
> >> server [::1]:81 weight=1 fail_timeout=60;
> >> server [::1]:82 weight=10 fail_timeout=60;
> >> server [::1]:83 weight=100 fail_timeout=60;
> >>   }
> >> Хотелось бы понимать это совпадение или веса принимаются в расчет при
> >> выборе hash-а?
> >> ___
> >> 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

пакеты для ARM64

[Илья Шипицин]

привет!


http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml:
[Errno 14] HTTP Error 404 - Not Found
Trying other mirror.

(ну и файлов реально нет)

не было спроса на arm64 ?


Илья
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: пакеты для ARM64

[Илья Шипицин]

Ага, я нашёл src.rpm, хотел посмотреть на опции компиляции. Вроде ничего
особенного. Intrinsic-и поддерживаются?

On Thu, Dec 31, 2020, 2:34 PM Konstantin Pavlov  wrote:

> Здравствуйте,
>
> 30.12.2020 19:30, Илья Шипицин wrote:
> > привет!
> >
> >
> > http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml
> > <http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml
> >:
> > [Errno 14] HTTP Error 404 - Not Found
> > Trying other mirror.
> >
> > (ну и файлов реально нет)
> >
> > не было спроса на arm64 ?
>
> Да, не было запросов конкретно на CentOS 7 aarch64 и мы их вообще не
> собирали.
>
> К тому же, в CentOS 7 это не официально поддерживаемая архитектура - их
> собирает AltArch SIG.
> Для RHEL 7 похоже в AWS EC2 Red Hat тоже arm64 AMI не выкладывают (в
> отличие от RHEL 8) -- так что перспективы добавления этой ОС/архитектуры
> в наши сборки довольно туманны.
>
> --
> Konstantin Pavlov
> https://www.nginx.com/
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

сертификат на forum.nginx.org

[Илья Шипицин]

привет,

https://www.ssllabs.com/ssltest/analyze.html?d=forum.nginx.org=69.46.5.194

недействительный.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Клиентские SSL-сертификаты + ngx_http_auth_basic_module

[Илья Шипицин]

пт, 1 янв. 2021 г. в 22:47, Vladislav Shabanov :

> Добрый день!
>
> Хочу посоветоваться.
> Есть сервер, где зона «для сотрудников» закрыта двумя слоями авторизации:
> auth_basic
> + проверка на уровне приложения, с куками, сессиями и прочим.
>
> Отказываться от auth_basic не хочется:
>
>- В коде приложения запросто могут быть ошибки. Забыли, например,
>завернуть какую-нибудь функцию приложения в декоратор и получили дырку в
>защите.
>- Сессионную куку могут угнать. XSS, «мутные» плагины для браузеров и
>т. д.
>- Есть «интимная» статика, которую проверять через auth_request не
>хочется, т.к. замедляет.
>
> Проблема в том, что большинство браузеров неудобно работают с basic_auth:
> Сафари под iPhone спрашивает пароль каждые несколько часов и даже не
> заморачивается, чтобы его запомнить. FireFox после рестарта показывает
> модальный диалог со вводом пароля в одном из окон и блокирует все остальные
> окна с тем же сайтом. Неудобно, короче.
>
> Настроил клиентские сертификаты. Есть сотни мануалов, ничего интересного.
> Но вот раздача сертификатов сотрудникам и установка их в браузеры – дело
> муторное. У каждого браузера свои тараканы, сложно объяснить сотруднику по
> телефону, как поставить сертификат в его браузер и т. д. А если сертификат
> устареет или придётся его отозвать, совсем беда.
>
> Поэтому решил сделать вот какую логику:
>
>- Если браузер предъявил сертификат, то *auth_basic* не требуем.
>- Если не предъявил, то пусть вводит логин+пароль через *auth_basic*.
>- Проверка доступа на уровне приложения никуда не девается, работаем
>по старому.
>
>
тут есть подводные камни как минимум с сафари.
браузер предъявил или браузер не предъявил на транспортном уровне работает
таким образом

1) в серверном SSL Hello выставляется флаг "хочу сертификат"
(вы можете намекнуть клиенту, на каких именно УЦ вы хотели бы видеть
сертификат, либо "*ssl_verify_client* optional_no_ca;", если вы готовы
принимать сертификат любого УЦ)

2) нормальный браузер реагирует так, если он видит, что у него нет
клиентских сертификатов на требуемом УЦ, он не пытается спросить у
пользователя, и отправляет запрос без сертификата

3) сафари будет требовать пользователя сертификат в любом случае

далее на стороне nginx можно настроить обработчик 496 ошибки, мы с таким
игрались, туда попадет трафик без клиентских сертов (и там вы сможете
реализовать нужную вам логику)




> Я не нашёл способа, как настроить конфиг nginx, чтобы эту логику
> реализовать. Конструкции с
>
> if $ssl_client_verify == "SUCCESS" {}
>
> несовместимы с auth_basic.
>


error_page 496 .


>
> Пока придумал только одно: отпатчил *ngx_http_auth_basic_module.c*,
> сделал в нём директиву
>
> *auth_basic_skip_if_client_cert**on/off*
>
> по которой проверка пароля выключается, если предъявлен валидный
> клиентский сертификат.
>
> Вопросы:
>
>1. Может быть, кто-то решал аналогичную задачу? Чтоб и два слоя защиты
>для страховки и удобство в повседневной работе?
>
>
кроме описанной вами трудностей с доставкой и установкой клиентских сертов
еще есть неприятное поведение сафари


>
>1. Существует ли решение без патча ngx_http_auth_basic_module.c?
>2. Интересен ли кому-нибудь этот патч? Может, на моём велосипеде ещё
>кто-нибудь хочет покататься? :)
>
>
как-то сейчас oauth более в тренде


>
> С уважением,
> Владислав
>
>
>
> ___
> 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: странное поведение Chrome на http2

[Илья Шипицин]

для истории - хром и сафари пытаются переиспользовать конекшин
если отдавать 421, то хром переподключается (как и ожидается), а сафари
превращается в тыкву.

вт, 1 дек. 2020 г. в 18:43, Maxim Dounin :

> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin :
> >
> > > Hello!
> > >
> > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> > >
> > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > > > >
> > > > > > привет!
> > > > > >
> > > > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > > > домены разные, каждый со своей бизнес логикой.
> > > > > >
> > > > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP
> один,
> > > то я
> > > > > > буду весь трафик гонять через одно tcp подключение". все бы
> ничего,
> > > но
> > > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > > > подключение до конкретного сайта, а вообще все, которые он
> умудрился
> > > > > > связать с этим tcp подключением.
> > > > > >
> > > > > > частный пример - сайт, который иногда формирует очень длинные
> URL, не
> > > > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> > > такой
> > > > > > ситуации Chrome рвет всё до этого IP адреса.
> > > > > >
> > > > > > как-то не по христиански чтоли.
> > > > > >
> > > > > > подумалось, что аналогичных хостингов высокой плотности в
> рассылке
> > > может
> > > > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > > > >
> > > > > Это называется connection reuse, правила прописаны тут:
> > > > >
> > > > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > > > >
> > > > > В частности:
> > > > >
> > > > >For "https" resources, connection reuse additionally depends on
> > > > >having a certificate that is valid for the host in the URI.  The
> > > > >certificate presented by the server MUST satisfy any checks
> that the
> > > > >client would perform when forming a new TLS connection for the
> host
> > > > >in the URI.
> > > > >
> > > > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > > > серверов).
> > > > >
> > > > > Ну либо руками возвращать 421 по необходимости, проверяя
> > > $ssl_server_name.
> > > > >
> > > >
> > > > в исходниках это вот так
> > > >
> > > > if ((size_t) len > h2scf->max_field_size) {
> > > > ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> > > >   "client exceeded http2_max_field_size limit");
> > > >
> > > > return ngx_http_v2_connection_error(h2c,
> > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > > > }
> > > >
> > > >
> > > > как можно в этом месте вернуть "по необходимости" 421 ?
> > >
> > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> > > соединением невозможна.  Возвращать 421 надо заранее, до того, как
> > > придёт кривой запрос.
> > >
> > >
> > пардон. я не понимаю, что вы предлагаете.
> > можете привести пример, как сделать ?
>
> Если добавить что-нибудь вроде:
>
> if ($ssl_server_name != "example.com") {
> return 421;
> }
>
> во все релевантные блоки server{}, это предотвратит reuse
> соединений, кроме первых запросов.  Соответственно соединения
> будут отдельными, и при необходимости закрыть соединение - будет
> закрываться только соединение с одним сервером, а не со всеми
> серверами на данном IP.
>
> Ну и обращаю внимание на озвученный выше и проигнорированный
> вариант разных сертификатов.  Он позволяет контроллировать
> поведение на стороне браузера и соответственно более эффективен,
> т.к. нет проблемы первых запросов.
>
> --
> Maxim Dounin
> http://mdounin.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: sandboxing

[Илья Шипицин]

На примере nginx, раз уж про него речь.

Штука выглядит прикольной, но не могу придумать, когда она полезна и в чём

On Wed, May 12, 2021, 10:12 PM Maxim Konovalov  wrote:

> Привет.
>
> On 12.05.2021 19:54, Илья Шипицин wrote:
> > какие преимущества и в каких сценариях может дать такая настройка?
> >
> Илья, вы спрашиваете про sandboxing как технологию вообще или
> применительно к nginx/systemd?
>
> --
> Maxim Konovalov
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проксирование в nginx / открыть другой сайт не меняя текущий адрес

[Илья Шипицин]

 если вы хотите проксировать на google, то это сайт, выставляющий HSTS
заголовок (http strict),
в вашем варианте вы отдадите эти заголовки на 80-м нешифрованном порту.
браузер скорее всего сделает редирект.



вт, 11 мая 2021 г. в 13:52, maximkherson :

> Делаю проксирование с локального хоста на google. Задача слудующая:
>
> В браузере ввожу proxy.localhost, нажимаю enter
> Открывается google.com, но в браузере в адресной строке остаётся
> proxy.localhost (т.е. выполняется проксирование)
> ПРОБЛЕМА. У меня работает как в случае редиректа, а не проксирования, т.е.
> после пункта 1 открывается google и запись в адресной строке меняется с
> proxy.localhost на https://www.google.com.
>
> ВОПРОС. Как сделать так, чтобы адрес оставался proxy.localhost, но
> открывался https://www.google.com ?
>
> Помогите пожалуйста, перепробовал множество вариантов, откатил до более
> менее рабочего, вот мой актуальный код:
>
> server {
> <-->listen *:80;
> <-->server_name proxy.localhost;
> <-->location / {
> <--><-->proxy_pass https://google.com/;
> <-->}
> }
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,291478,291478#msg-291478
>
> ___
> 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: sandboxing

[Илья Шипицин]

а как предполагается, это должно работать ?

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

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

ср, 12 мая 2021 г. в 17:43, :

> Здравствуйте.
> SystemD поддерживает возможность запуска сервисов в режиме песочницы. В
> параметрах есть опция RemoveIPC -
> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RemoveIPC=
> Приложение nginx использует IPC вызовы? Можно ли фильтровать эти события,
> а так же системные вызовы @ipc -
> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=
> Набор фильтров @ipc фильруется такие системные вызовы:
> ```
> # SysV IPC, POSIX Message Queues or other IPC
> ipc
> memfd_create
> mq_getsetattr
> mq_notify
> mq_open
> mq_timedreceive
> mq_timedreceive_time64
> mq_timedsend
> mq_timedsend_time64
> mq_unlink
> msgctl
> msgget
> msgrcv
> msgsnd
> pipe
> pipe2
> process_vm_readv
> process_vm_writev
> semctl
> semget
> semop
> semtimedop
> semtimedop_time64
> shmat
> shmctl
> shmdt
> shmget
> ```
> В коде nginx используются эти вызовы?
> Тут -
> https://github.com/nginx/nginx/blob/master/src/event/ngx_event_pipe.c#L119
> вроде используется вызов pipe. Или это разные вещи?
>
> nginx.service:
> ```
> AmbientCapabilities=CAP_NET_BIND_SERVICE
> AmbientCapabilities=CAP_SYS_RESOURCE
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> CapabilityBoundingSet=CAP_SYS_RESOURCE
> LockPersonality=true
> MemoryDenyWriteExecute=true
> NoNewPrivileges=true
> PrivateDevices=true
> PrivateMounts=true
> PrivateTmp=true
> ProcSubset=pid
> ProtectClock=true
> ProtectControlGroups=true
> ProtectHome=true
> ProtectHostname=true
> ProtectKernelLogs=true
> ProtectKernelModules=true
> ProtectKernelTunables=true
> ProtectProc=invisible
> ProtectSystem=strict
> RemoveIPC=true
> RestrictAddressFamilies=AF_UNIX
> RestrictAddressFamilies=AF_INET
> RestrictAddressFamilies=AF_INET6
> RestrictNamespaces=true
> RestrictRealtime=true
> RestrictSUIDSGID=true
> SystemCallArchitectures=native
> SystemCallFilter=~@cpu-emulation @debug @keyring @ipc @mount @obsolete
> @privileged @setuid
> UMask=0027
> ```
>
>
> --
> С уважением,
>  Izorkin  mailto:izor...@gmail.com
>
> ___
> 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: sandboxing

[Илья Шипицин]

какие преимущества и в каких сценариях может дать такая настройка?

ср, 12 мая 2021 г. в 21:44, :

> Здравствуйте, Илья.
>
> Если nginx использует эти вызовы, то в конфигурацию сервиса добавить
> строки, которые разрешают эти вызовы:
> ```
> SystemCallFilter=pipe
> SystemCallFilter=pipe2
> ```
>
> Хотелось немного повысить безопасность службы и изолировать от других
> сервисов, запущенных в системе. С большинство параметров
> изоляции nginx работает нормально, а вот с системными вызовами уже сложнее
> маленько разобраться.
>
> Вы писали 12 мая 2021 г., 18:39:33:
>
>
> а как предполагается, это должно работать ?
>
> типа, программа использует эти вызовы, а мы такие бац, и запретили.
> и что должно произойти ? всё сломается ?
>
> какая модель угроз ? есть какие-нибудь примеры ?
>
>
>
>
> *-- С уважением,  Izorkin  *
> mailto:izor...@gmail.com 
> ___
> 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: Configuring nginx to retry a single upstream server

[Илья Шипицин]

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

1) можно, и пожалуй, нужно указывать max_fails=0 (чтобы не держать бекенд в
грейлисте, а максимально пытаться отправлять на него запросы)

2) можно продублировать бекенд несколько раз, как будто у вас несколько
серверов, это позволяет улучшить ситуацию, когда деградировала сеть между
балансером и бекендом, тогда timeout while connecting будет переотправлен
на якобы следующий бекенд

пт, 21 мая 2021 г. в 02:05, Gena Makhomed :

> Здравствуйте, All!
>
> Есть nginx, который проксирует запросы на единственный бекенд php-fpm.
> Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки.
>
> Каким образом можно настроить nginx так, чтобы он в случае ошибки
> связи с бекендом пытался достучаться до него в течении N секунд
> (например, 30 сек), с интервалом, например, в K секунд
> (например, 0.1 сек) ?
>
> Тогда клиент вместо сообщения про ошибку видел бы просто небольшое
> замедление ответа сервера на секунду или максимум несколько секунд,
> что гораздо лучше, чем мгновенный возврат сообщения про ошибку 5хх.
>
> Может быть как-то с помощью njs или nginx-module-perl или с помощью
> ngx_http_upstream_module это можно сделать? Или тут единственно
> возможный вариант - писать патч на С для решения этой задачи?
>
> --
> Best regards,
>   Gena
>
> ___
> 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: Как установить Rapid SSL 2018

[Илья Шипицин]

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

по крайней мере я такие рекомендации припоминаю.

пт, 14 мая 2021 г. в 18:22, Andrey Kopeyko :

> sf2015 писал 2021-05-14 09:38:
> > Для домена test.ru и всех поддоменов приобретен сеттификат Rapid SSL
> > 2018
>
> Если ваш сертификат допустимо ставить на несколько серверов одновременно
> (ищите в договоре "server licences" или аналогичные слова), то можете
> просто размножить ключ+серт по нужному кол-ву железок\виртуалок. С
> соответствующими рисками для безопасности.
>
> Если такое вам не разрешено, то
> * или раскладывайте ключ+серт на свой страх и риск
> * или докупайте опцию "server licences"
> * или докупайте нужное кол-во сертификатов для уникальных ключей
>
> > Имеется:
> >  сам сертификат test_ru.crt
> >  промежуточный intermediate_pem_geotrust_rapidssl_wildcard_1.crt
> >  промежуточный intermediate_pem_geotrust_rapidssl_wildcard_2.crt
> >  приватный ключ key.txt
> >  корневой сертификат root_pem_geotrust_rapidssl_wildcard_1.crt
> >  сертификат test.ru.ca-bundle
> >
> > Nginx установлен на Ubuntu 20 с IP 192.168.0.43.
> >
> > общая задача такая. Есть некий вебсервис (https:// t1.test.ru), который
> > крутится на серваке в локалке с адресом 192.168.0.230.
> >
> > Сейчас При вводе адреса https://t1.test.ru клиент проваливается
> > на192.168.0.230.
> > Нужна схема с проксированием так, чтобы При вводе адреса
> > https://t1.test.ru
> > клиент проваливается на192.168.0.43, а затем перенаправлялся на
> > 192.168.0.230
> >
> > В перспективе будут еще https://t2.test.ru, которые пойдут на
> > 192.168.0.232
> > и т.п.
> >
> >
> > -
> > 1. Подскажите какие как быть с сертификатами. Какие из приведённых выше
> > прописать в файле конфигурации.
> >
> >
> >
> >
> > server {
> > #listen 80;
> >listen 443 ssl default_server;
> >listen [::]:443 ssl default_server;
> >   ssl on;
> > ssl_certificate /etc/ssl/test.ru/dcli.ru.ca-bundle;
> > #ssl_certificate_key /etc/ssl/test.ru/key.txt;
> > #ssl_session_timeout 5m;
> > #ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> > #ssl_dhparam /etc/ssl/certs/dhparam.pem;
> > #ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
> > #ssl_prefer_server_ciphers on;
> > #ssl_session_cache shared:SSL:10m;
> >
> >
> > server_name t1.test.ru;
> > access_log /var/log/nginx/access.log;
> > error_log /var/log/nginx/error.log;
> >
> > location / {
> > proxy_pass https://192.168.0.230;
> > }
> > }
> >
> > Posted at Nginx Forum:
> > https://forum.nginx.org/read.php?21,291518,291518#msg-291518
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Best regards,
> Andrey A. Kopeyko 
> ___
> 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: Как установить Rapid SSL 2018

[Илья Шипицин]

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




пт, 14 мая 2021 г. в 19:39, sf2015 :

> Сертификат куплен на домен и поддомены. Покупался на nic.ru.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,291518,291523#msg-291523
>
> ___
> 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_header

[Илья Шипицин]

вт, 25 мая 2021 г. в 18:42, Gena Makhomed :

> On 25.05.2021 15:01, Maxim Dounin wrote:
>
> > Возможно, когда-нибудь добавится концепция "явно унаследовать
> > список с предыдущего уровня и дать возможность дополнить его",
> > что-нибудь вроде
> >
> >  add_header inherit;
> >  add_header Foo bar;
> >
> > Что по сути аналогично использованию include-файла, но чуть проще
> > синтаксически.  Но это, скажем так, очень абстрактная идея,
> > реализация которой под очень большим вопросом.
>
> Кроме add_header аналогичные проблемы и с директивой proxy_set_header
>
> Может быть имеет смысл сделать новую директиву join с помощью которой
> и регулировать объединение или отмену обединения для других директив?
>
> Syntax: join  on|off;
> Context: http, server, location, if in location
>
> По умолчанию:
>
> join add_header off;
>
> join proxy_set_header off;
>
> Например, на уровне http объединение может быть включено, а на уровне
> какого-то конкретного location - явно выключено, при необходимости.
>
> Кроме директивы add_header было бы удобно иметь директиву set_header,
> которая не добавляет новый заголовок, а переопределяет, если заголовок
> с таким именем уже был определен ранее, в режиме join add_header on;
>


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


>
> --
> Best regards,
>   Gena
>
> ___
> 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: How to write $upstream_trailer_{name} into access.log

[Илья Шипицин]

Из документации как это понять

On Mon, May 24, 2021, 6:19 AM Maxim Dounin  wrote:

> Hello!
>
> On Sun, May 23, 2021 at 01:00:18AM +0300, Gena Makhomed wrote:
>
> > Здравствуйте, All!
> >
> > Использую nginx/1.19.10 из официального репозитория nginx.org
> >
> > На бэкенде в секции http прописал такие директивы:
> >
> > add_trailer X-Response-Time $upstream_response_time always;
> > add_trailer X-Cache-Status $upstream_cache_status always;
> >
> > На фронтенде в секции http прописал proxy_http_version 1.1;
> > Также на фронтенде в директиву log_format добавил переменные:
> >
> > $upstream_trailer_x_response_time $upstream_trailer_x_cache_status
> >
> > Ожидается что в лог будут записаны полученные значения этих переменных,
> > но вместо них в лог пишутся символы - - обозначающие пустые значения.
> >
> > Почему так происходит? Это ошибка в nginx или я что-то делаю не так?
>
> Чтение трейлеров от бэкендов сейчас поддерживается только для
> gRPC-бэкендов.  Если хочется, чтобы работало и для HTTP/1.1 с
> chunked - присылайте патчи.
>
> --
> Maxim Dounin
> http://mdounin.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: Route by request method

[Илья Шипицин]

можно на limit_except разрешить только GET. остальное попадет в запрет и
навешать на него кастомную страницу ошибки

вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :

> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
> >
> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
> >>обработку запроса в другой location. Обратите внимание - trailing slash
> >>в proxy_pass в данном случае имеет значение.
> >>---
> >>location / {
> >> if ($request_method != 'GET') {
> >> rewrite ^/(.*) /proxy/$1 last;
> >> }
> >> root /data;
> >>}
> >>location /proxy/ {
> >> internal;
> >> proxy_pass http://127.0.0.1:8080/;
> >>}
> >
> >Возможно переход в именованный location с помощью директив
> >"error_page 418 = @location; return 418;" будет лучше
> >с точки зрения читабельности, чем rewrite директивы,
> >делающие конфиг nginx похожим на конфиг sendmail?
>
> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
> с error_page лучше для решения поставленной задачи.
>
> Что вижу: нецелевое использование директивы / фиктивного статуса,
> появление лишней строки в конфиге и необходимость включать
> recursive_error_pages при использовании реальной обработки последующих
> ошибок проксирования.
>
> Но согласен - так делать тоже можно, TMTOWTDI
>
> >location / {
> >if ($request_method != 'GET') {
> >error_page 418 = @proxy;
> >return 418;
> >}
> >root /data;
> >}
> >location @proxy {
> >proxy_pass http://127.0.0.1:8080;
> >}
> >
> >По-сути вот этот набор из двух директив:
> >"error_page 418 = @location; return 418;"
> >означает простое действие "goto @location;"
> >
> >--
> >Best regards,
> > Gena
> >
> >___
> >nginx-ru mailing list
> >nginx-ru@nginx.org
> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Cheers,
> Oleg A. Mamontov
>
> mailto: o...@mamontov.net
>
> skype:  lonerr11
> cell:   +7 (903) 798-1352
> ___
> 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 - Microsoft Remote Desktop Gateway

[Илья Шипицин]

В ms rpc есть нарушения http, для апача есть поддержка. Для nginx только
стрим. На http будет разваливаться

On Wed, Feb 10, 2021, 10:53 AM KDI  wrote:

> Как правильно проксировать 443 порт на сервер шлюзов удаленого рабочего
> стола
>
> Вот мой конфиг%
>
> root@nginx:/etc/nginx/sites-available# cat rds.domain.su
> server {
> if ($allowed_country = no) {
> return 404;
> }
> listen 443 ssl;
> server_name  rds.domain.su;
> ssl_certificate /etc/nginx/ssl/domain.crt;
> ssl_certificate_key /etc/nginx/ssl/domain.rsa;
> location / {
> proxy_pass https://rds.domain.su:443;
> proxy_ssl_verify off;
> 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_set_header X-Forwarded-Host $server_name;
> proxy_set_header X-Forwarded-Proto https;
> proxy_request_buffering off;
> access_log /var/log/nginx/rds.access.log;
> error_log /var/log/nginx/rds.error.log;
> }
> }
>
> веб страница открывается ошибок нету а если подключаюсь через приложение
> mstsc выдается ошибка
>
> 2021/02/10 08:42:00 [error] 18427#18427: *400577 upstream prematurely
> closed
> connection while reading response header from upstream, client:
>
> что делаю не так ?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,290710,290710#msg-290710
>
> ___
> 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 - Microsoft Remote Desktop Gateway

[Илья Шипицин]

(тут была бы уместна отправка на вики в раздел best practices, если такое
есть, перенаправьте, плиз)

пример с терминацией SSL --> TCP

upstream rd-gateway {
server x.x.x.x:80 ;
server y.y.y.y:80 ;
server z.z.z.z:80 ;
hash $remote_addr consistent;
}

server {
listen 443 ssl;
proxy_pass rd-gateway;

ssl_certificate  /etc/ssl/fullchain.pem;
ssl_certificate_key  /etc/ssl/privkey.pem;

ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA;

ssl_session_cache shared:SSL_stream:60m;
ssl_session_timeout   4h;
ssl_handshake_timeout 30s;
}

ср, 10 февр. 2021 г. в 12:39, KDI :

> Как правильно сделать стрим ?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,290710,290712#msg-290712
>
> ___
> 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 - Microsoft Remote Desktop Gateway

[Илья Шипицин]

Не-не-не, это не rdp, а rdp gateway. Чуть другое. У гейтвея транспорт SSL в
отличии от rdp. Терминировать SSL можно по настроению. Мы терминируем

On Wed, Feb 10, 2021, 4:58 PM Maxim Konovalov  wrote:

> On 10.02.2021 10:57, Илья Шипицин wrote:
> > (тут была бы уместна отправка на вики в раздел best practices, если
> > такое есть, перенаправьте, плиз)
> >
> Эта часть есть, например, тут:
>
>
> https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/#example
>
> И даже без плюсо-специфичных фишек.
>
> > пример с терминацией SSL --> TCP
> >
> Кажется, для проксирования rdp терминировать ssl как раз не надо.
>
> --
> Maxim Konovalov
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: пакеты для ARM64

[Илья Шипицин]

Я смотрел в src.rpm для rhel8, никакой специфики не увидел, собрал сам.

Поигрался с версией gcc, 9-я даёт грубо 10% к производительности.

Спасибо за пакеты))

On Wed, Feb 10, 2021, 4:50 PM Konstantin Pavlov  wrote:

> Добрый день,
>
> 31.12.2020 12:34, Konstantin Pavlov wrote:
> > Да, не было запросов конкретно на CentOS 7 aarch64 и мы их вообще не
> > собирали.
> >
> > К тому же, в CentOS 7 это не официально поддерживаемая архитектура - их
> > собирает AltArch SIG.
> > Для RHEL 7 похоже в AWS EC2 Red Hat тоже arm64 AMI не выкладывают (в
> > отличие от RHEL 8) -- так что перспективы добавления этой ОС/архитектуры
> > в наши сборки довольно туманны.
>
> Туман рассеялся и теперь пакеты mainline/stable для RHEL/CentOS 7 на
> aarch64 доступны в репозиториях на nginx.org.
>
> --
> Konstantin Pavlov
> https://www.nginx.com/
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: запись ответа от сервиса в лог файл nginx

[Илья Шипицин]

proxy_store ?

чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov :

> Добрый день.
> Подскажите что можно сделать в ситуации когда требуется писать в файл тело
> ответа сервиса, попробовал вариант с обработкой в body_filter_by_lua, но
> при больших телах ответа воркер блокируется и потребляет 100% CPU
> Какие еще варианты реализовать задачу на уровне nginx возможны?
> ___
> 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