Re: announcing freenginx.org

[Evgeniy Berdnikov]

On Thu, Feb 15, 2024 at 10:55:15PM +0200, Gena Makhomed wrote:
> On 15.02.2024 22:06, Evgeniy Berdnikov wrote:
> 
> > Вы много чего написали, но не ответили на вопрос, сколько это будет стоить.
> > Без реального ценника все рассуждения превращаются в схоластику...
> 
> Так Вы же не мне этот вопрос задавали, а знатокам.
> 
> Не понимаю, почему Вас так сильно интересует
> ответ на вопрос, сколько это будет стоить ?
> 
> Вы собираетесь все переводить в деньги и все изменять только деньгами?

 Так я написал: без ценовой конкретики эти дискуссии становятся схоластикой.
 Нужно соизмерять свои желания со своими возможностями.
 Регистрация брендов -- занятие, доступное тем, у кого бизнес на миллионы,
 и есть серьёзная потребность этот бизнес защищать.

 Для открытого проекта намного проще десять раз поменять название, чем
 заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL
 поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим
 сделать не может, а сборщики дистрибутивов стали раздавать пакет автора,
 а не сборку Оракла. Причём там была похожая ситуация: пришли манагеры,
 привыкшие к жёсткой иерархии и принципу "начальник всегда прав",
 подключили штатных оракловских разрабов и погнали патчи, которые открыто
 не обсуждались и потому не всегда даже были понятны старым разработчикам.
 Итог закономерен.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Evgeniy Berdnikov]

On Thu, Feb 15, 2024 at 09:20:14PM +0200, Gena Makhomed wrote:
> On 15.02.2024 16:39, Evgeniy Berdnikov wrote:
> 
> > > Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то
> > > имя, которое не является ничьей торговой маркой и для защиты этого
> > > имени - зарегистрировать свою торговую марку,
> > 
> >   Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку
> >   хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия,
> >   плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать
> >   Европу и Китай?
[...]
> См. https://en.wikipedia.org/wiki/Linux_Mark_Institute
> Неужели история учит только тому, что она ничему не учит?

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

> Если бы у Максима была торговая марка freenginx - в такой ситуации
> он смог бы защитить свой проект, потому что репутационные потери
> от действия киберсквоттеров и прочих в РФ могут быть и больше
> чем 30-50 тыс.руб одноразово и ~ 25 тыс.руб раз в десять лет.

 Вы, наверное, имеете методику оценки репутационных потерь, или даже
 табличку конверсии для свободных проектов по текущему курсу.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Evgeniy Berdnikov]

On Thu, Feb 15, 2024 at 03:17:04AM +0200, Gena Makhomed wrote:
> Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то
> имя, которое не является ничьей торговой маркой и для защиты этого
> имени - зарегистрировать свою торговую марку,

 Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку
 хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия,
 плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать
 Европу и Китай?

 В РФ мы хотим регистрироваться? Насколько я понимаю, по российскому
 законодательству регистрация торговой марки (наименования, товарного знака)
 возможна лишь на юрлицо или ИП, а физлицу придётся заключить договор
 с какой-либо компанией, чтобы та оформила права на себя в интересах
 клиента. Какие тут для клиента риски -- отдельный вопрос...
 Регистрация в Роспатенте это где-то 30-50 тыс.руб, процедурно полгода-год,
 продление регистрации раз в 10 лет за ~ 25 тыс.руб (на сегодня).
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Wed, Feb 14, 2024 at 02:30:57PM +0300, Anatoliy Melnik via nginx-ru wrote:
>Все как раз получилось, дальше с этим работать было неудобно.
>К тупой записи в файл претензий не было.

 Вы не сообщили, почему "дальше с этим работать было неудобно".
 Может, поясните? Если посмотреть на озвученный список задач --

>Зачем мне это нужно:
[...]
>Регулярно требуется "нестандартная" статистика, например
>"средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки"
>"соотношение обращений по http и https ($schema) по запросам типа "q1wr"
>за час"
>"наименьшее/среднее/наибольшее время ($request_time) по запросам типа
>"sc012" за..."
>"объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в
>общем объеме трафика (сумма $body_bytes_sent всех запросов)"
>и т.д.

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

 Но из файла якобы неудобно! Чем же неудобно, почему? При чём тут вообще
 какие-то unix-сокеты, если задача в разборе последовательно идущих строк
 и каких-то элементарных вычислениях?

>Чисто техничски можно и без access-логов, будете сами реализовывать нечто
>подобное -- выберете более близкое вам решение.

 Вы не назвали альтернативные решения.

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

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

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

 Вы крутейший специалист :)) в своих собственных глазах, конечно.

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

 И что, это лишает собеседника право высказать своё мнение о правильности
 постановки задачи? Вы также не сообщили, каковы критерии "продуктивности
 пути", почему выбрана конретная реализация и т.д. Поэтому нет никаких
 оснований даже подозревать, что Вы что-то делаете правильно... :)

>Эффективность реализации весьма эфемерное понятие.
>Эффективность с точки зрения чего?
>Мы с вами эффективность считаем по совершенно разным критериям.
>Это не хорошо и не плохо. Это просто по-разному :)

 Вы не конкретизировали, по каким критериям оцениваете эффективность.

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

 Ненормально то, что один собеседник пытается аргументировать свои мысли,
 а другой всё время отвечает "Не учите меня жить! У меня другая ситуация!"
 А какая именно -- не говорит.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как лучше всего сделать защиту от denial of service при исчерпании свободного места на диске большими по объему лог-файлами nginx?

[Evgeniy Berdnikov]

On Mon, Feb 12, 2024 at 01:15:53AM +0200, Gena Makhomed wrote:
> Ротация логов делается с помощью программы logrotate, которая делает
> ротацию только по времени и никак не смотрит на количество свободного места
> на диске и на размер лог-файла.

 Насчёт размера файла утверждение неверное: в конфиге logrotate можно
 указать директиву "size", которая будет означать предельный размер
 лог-файла, по достижении которого запускается ротация. Другое дело, что
 риалтаймовского триггера на достижение предельного размера файла нет.
 А он мог бы быть в nginx-е, среди опций access_log и error_log.

> # logrotate --force /etc/logrotate.d/nginx
> 
> можно будет запускать как угодно часто, например, раз в час или даже раз в
> минуту, проверяя предварительно количество свободного места на диске или
> размер файла или по каким-то другим условиям.

 Проверять занятое место на партиции можно хоть раз в секунду и даже чаще.
 Но нет смысла чаще, чем интервал сброса файловых кэшей ядром.
 
> Это может быть полезно в случае DDoS-атак, чтобы не не было
> таких неожиданных ситуаций, что место на сервере внезапно закончилось,

 Для DoS-атак как раз и полезно разделение обязанностей между рабочим
 процессом сервиса и процессом-писателем логов. Я уже упоминал здесь
 сквидовский logfile-daemon, это один из вариантов, как можно обезопасить
 рабочий процесс от ступора. Но не самый эффективный, поскольку запись
 через пайп -- это значительное количество сисколов с обеих сторон,
 с копированием данных в ядро из писателя и обратно читателю.
 Гораздо эффективней сделать циклический буфер в разделяемой памяти,
 к которой подключаются два процесса/треда -- рабочий и писатель логов.
 Запись в такой буфер и чтение из него никаких сисколов не требует.
 Останется лишь минимизировать расходы на взаимные блокировки, которые,
 вероятно, также можно сделать без сисколов, если поискать специальные
 алгоритмы на этот счёт... В итоге получится быстрая запись и быстрое
 независимое чтение, причём если второе сдохнет или начнёт захлёбываться,
 писателя это не убьёт.

 Конечно, программирование всего этого -- немаленькая работа. 
 
 А костыли в виде логов в оперативной памяти, logrotate и питоновских
 скриптов можно, конечно, нагородить. Но в современной ситуации, я думаю,
 проще сделать триггер, который по обнаружении катастрофической нехватки
 места для логов просто отключит логгирование в nginx-e.

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

 Работоспособность web-сервиса, как правило, намного важнее логгирования.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Sun, Feb 11, 2024 at 08:32:07PM +0200, Gena Makhomed wrote:
> > Именно такая схема не с потолка упала, а появилась в результате 
> > экспериментальных проверок нескольких подходов.
> > Рассказывать почему именно так, а не иначе -- долго, скучно, с кучей 
> > подробностей... и абсолютно бесполезно :)
> > Свое видение путей решения СВОИХ задач у меня уже сформировалось, а 
> > убеждать в чем-то вас смысла не имеет.
> > Еще раз СПАСИБО.
> 
> Кто-то кого-то сейчас пытается обмануть.
> 
> Вы рассказываете, что запись логов в файлы Вам не подходит
> по каким-то очень серьезным причинам, которые Вы не можете
> озвучить, потому что это Вам скучно, неинтересно и бесполезно.

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

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

 Но по сути дела изначальный вопрос был "почему пропадают записи в syslog?"
 Причина, скорее всего, была в том, что syslogd не успевал их принимать.
 Однако прямого доказательства этому так и не было предъявлено -- в виде
 статистики возвратов EAGAIN от send() внутри nginx-a, или от мониторинга
 величины очереди на unix-сокете, или хотя бы от измерения нагрузки на
 процессор у syslogd. Хотя товарищ измерил чистую пропускную способность
 syslogd, и получил значение выше проблемного, но это возможно и не даёт
 ответа для неравномерного трафика. В итоге был переделан велосипед Y, и
 ответ на изначальный вопрос перестал интересовать. Ну, тоже бывает. :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Mon, Feb 05, 2024 at 09:56:54PM +0200, Gena Makhomed wrote:
> On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote:
> > Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас 
> > выслушать.
> 
> Создание нормального рабочего решения должно начинаться
> с внимательного чтения документации и исходников nginx.

 Насчёт чтения исходников -- выглядит примерно таким же экстремизмом,
 как требование знания ассемблера для прикладного программиста... :)

> Какую именно существующую проблему Вы пытаетесь решить
> с помощью ротации лог-файлов с интервалом в 30 секунд?

 Товарищ отвечал на этот вопрос:
 
https://mailman.nginx.org/pipermail/nginx-ru/2024-January/MD45SEEP573DPPEQYAFT26MPMUK5646B.html

> Потому что если программа, которая читает данные из unix socket`а
> отвалится - тогда произойдет переполенение буфера и nginx тогда
> заблокируется на операции записи в unix socket, и как следствие
> этого - перестанет выполнять свою основную функцию - перестанет
> отвечать на запросы клиентов по http / https протоколу.

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

 По мне так пример разумного подхода -- сквидовский logfile-daemon.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Mon, Feb 05, 2024 at 02:40:42PM +0300, Anatoliy Melnik via nginx-ru wrote:
>syslog-ng при работе с unixSocket показал довольно низкую
>производительность. (Долго с ним не разбирался. Чисто дефолтная установка
>и минимальная настройка).

 Syslog-ng производит огромное количество ненужных (на мой взгляд) сисколов
 при работе с unix-сокетами, к тому же пытается то, что отдаётся в syslog(3),
 подменить на более "правильную", по мнению автора, информацию... Например,
 выправить pid, если писатель нарисовал чужой (наверное, это такая забота о
 безопасности). Всё очень трогательно, но эта забота выливается в большие
 накладные расходы. Под большую нагрузку syslog-ng явно не заточен.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Thu, Jan 18, 2024 at 10:10:14PM +0300, Anatoliy Melnik via nginx-ru wrote:
> > Чем гадать, что "вероятнее всего", возьмите исходники nginx, вставьте
> > счётчик передач в syslog, смотрите его и сравнивайте с количеством пакетов,
> > пришедших в syslog. Так можно исключить потери в сети.
> 
> Вроде при записи в unixSocket сеть отсутствует.

 Это "внутренняя" сеть, только с address family = AF_UNIX, а не AF_INET.
 И несколько другими алгоритмами, в частности, исключены потери пакетов
 как для SOCK_STREAM, так и для SOCK_DGRAM. Что, конечно, не мешает
 приложениям дропать пакеты при переполнениях ядерных буферов, приводящим
 к ошибкам на уровне send(), как тут ведёт себя nginx -- не знаю.
 Однако попытаться увеличить всякие буферы однозначно полезно.

> В любом варианте ваш совет трудно реализовать -- моя квалификация как 
> программиста для подобной задачи не достаточна.

 Тогда шансы достичь просветления уменьшаются. :) Ну, попробуйте просто
 измерить пропускную способность syslog-ов каким-либо генератором записей,
 например, сделайте файлик с 10К уникальных сообщений, подобных nginx,
 и скармливайте его в цикле утилите logger. Посмотрите сколько запишется
 на диск и с какой скоростью, не будет ли там пропусков.

 Что касается использования памяти в сокетах, для линукса есть командочка
 "ss -m", она покажет socket memory usage. Расшифровка выдачи в man ss,
 посмотреть выдачу можно как по inet-сокетам, так и по unix-сокетам.
 Для других ОС есть другие погремушки, наверное... Квалификация тут нужна
 сисадминская, а не по части программирования, но по мне так правка кода
 nginx проще.
 
> Пока создается впечатление, что либо у меня что-то не так, либо никому не 
> приходило в голову сравнить эти данные.

 Простой вопрос: зачем писать на диск 100 тыс/с логов, что потом с ними
 предполагается делать? Ведь логи пишутся не просто так, а чтобы их потом
 как-то обрабатывать... Что именно будет нужно из из этого океана байтов?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Thu, Jan 18, 2024 at 07:13:39PM +0300, Anatoliy Melnik via nginx-ru wrote:
>Фиксировал разными средствами.
>Этот "порог" наблюдается и на rsyslog, и на syslog-ng
>Сливал с 2-х nginx в один syslog -- получилось, расхождения в статистике
>пошли с 100тыс/сек, т.е. вероятнее всего nginx теряет на этапе генерации
>сообщения, а не на этапе транспортировки или приема rsyslog-ом.

 Чем гадать, что "вероятнее всего", возьмите исходники nginx, вставьте
 счётчик передач в syslog, смотрите его и сравнивайте с количеством пакетов,
 пришедших в syslog. Так можно исключить потери в сети.

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

 Здесь тоже желательно сделать свой самописный syslog, который в простейшем
 варианте ничего не делает, лишь считает число пришедших пакетов.

 PS. Интересно также, какая на вашем стенде получается скорость записи
 в файл syslog-ом. Здесь желательно проверить, что в файле нет сообщенией
 "столько-то записей отброшено", это стандартный функционал syslog-ов.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Простой способ массового переноса http2 из listen в отдельную директиву

[Evgeniy Berdnikov]

On Thu, Dec 28, 2023 at 10:07:41AM +0200, Иван wrote:
> nginx: [warn] the "listen ... http2" directive is deprecated, use the
> "http2" directive instead in /etc/nginx/sites-enabled/...:152
> 
> 
> Надо http2 из параметра директивы listen перенести в отдельную
> 
> http2 on;
> 
> 
> У меня несколько десятков блоков server. В некоторых http2 нужен, в
> некоторых (listen 80) нет. Есть какие-нибудь идеи как конвертацию сделать
> массово?

 Это конкурс на лучший однострочник в кружке юного программиста?

 perl -i~ -pe 'if(m/listen\s+/ && s/\s+http2//) {print "http2 on;\n"}' *.conf
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

[Evgeniy Berdnikov]

On Sun, Nov 26, 2023 at 10:43:13AM +0300, Eugene Prokopiev wrote:
> и уже с proxy_ssl_server_name on наконец 200 - но с совершенно
> неожиданным http body (см. новую ветку - т.к. это уже явно не про
> репозитории)

 Навскидку: удалить Via:, X-Forwarded-For:, X-Real-IP: и прочие
 свитедельства проксирования, если они есть. Что именно отправляется,
 можно найти в debug log'е, если я правильно помню... Ну и кроме того
 могут быть засады с User-Agent:, т.к. желающие убить всех ботов
 частенько превращаются в настоящих маньяков.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кэширование репозиториев maven/pypi/npm - proxy_cache или proxy_store

[Evgeniy Berdnikov]

On Sun, Nov 26, 2023 at 09:53:54AM +0300, Eugene Prokopiev wrote:
> Requested host does not match any Subject Alternative Names (SANs) on
> TLS certificate
> [f38588ca7dc3f37ec048583198230295986084302bfd4d5c2d944911bd377a95] in
> use with this connection.
> 
> Visit 
> https://docs.fastly.com/en/guides/common-400-errors#error-421-misdirected-request
> for more information.
> * Connection #0 to host localhost left intact
> 
> И что-то я не могу подобрать комбинацию из proxy_ssl_*, чтоб
> repo.clojars.org отдал через pass_proxy что-нибудь более
> вразумительное - подскажете?

 Прочесть текст по ссылке? Там речь не про параметры ssl, однако.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Evgeniy Berdnikov]

On Mon, Mar 13, 2023 at 11:37:47AM +0300, Evgeniy Berdnikov wrote:
> On Mon, Mar 13, 2023 at 10:50:37AM +0300, Nikolay Shaplov wrote:
> > В письме от понедельник, 13 марта 2023 г. 10:46:51 MSK пользователь Maksim 
> > Kulik написал:
> > > Мне кажется, что в RFC речь идет скорее про разные блоки server {}, т.к.
> > > речь явно про several virtual hosts, а не про several server names. То 
> > > есть
> > > веб-сервер вполне корректно по RFC выбирает блок server {} по имени хоста 
> > > и
> > > используется главное имя этого блока далее в работе.
> > > Вы в своем примере имеете один виртуал хост и N имен (алиасов, если 
> > > хотите)
> > > в нем, где N может быть бесконечным в случае дефолтного хоста. Ваш сервер 
> > > и
> > > выбирает этот самый хост по имени, которое видит в заголовке.
> > Правильно. И то имя которое совпало должно попасть в переменную окружения 
> > SERVER_NAME
> > 
> > Ну даже если не читать сам текст RFC (а там по-моему предельно ясно все 
> > написано), из соображений общий логики, почему в SERVER_NAME попадает 
> > первый 
> > из алиасов, а не тот на который пришли??? В этом нет вообще никакой логики.
> 
>  +1
> 
>  И нужно отметить, что RFC про протокол взаимодействия, он не диктует как
>  писать конфиги, поэтому там ничего нет "про разные блоки server {}".
>  RFC связывает параметры запроса HTTP с параметрами CGI.

 Однако, нет, перечитав ещё несколько раз п.4.1.14 rfc3875, беру свои слова
 обратно.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Evgeniy Berdnikov]

On Mon, Mar 13, 2023 at 10:50:37AM +0300, Nikolay Shaplov wrote:
> В письме от понедельник, 13 марта 2023 г. 10:46:51 MSK пользователь Maksim 
> Kulik написал:
> > Мне кажется, что в RFC речь идет скорее про разные блоки server {}, т.к.
> > речь явно про several virtual hosts, а не про several server names. То есть
> > веб-сервер вполне корректно по RFC выбирает блок server {} по имени хоста и
> > используется главное имя этого блока далее в работе.
> > Вы в своем примере имеете один виртуал хост и N имен (алиасов, если хотите)
> > в нем, где N может быть бесконечным в случае дефолтного хоста. Ваш сервер и
> > выбирает этот самый хост по имени, которое видит в заголовке.
> Правильно. И то имя которое совпало должно попасть в переменную окружения 
> SERVER_NAME
> 
> Ну даже если не читать сам текст RFC (а там по-моему предельно ясно все 
> написано), из соображений общий логики, почему в SERVER_NAME попадает первый 
> из алиасов, а не тот на который пришли??? В этом нет вообще никакой логики.

 +1

 И нужно отметить, что RFC про протокол взаимодействия, он не диктует как
 писать конфиги, поэтому там ничего нет "про разные блоки server {}".
 RFC связывает параметры запроса HTTP с параметрами CGI.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Evgeniy Berdnikov]

On Mon, Mar 06, 2023 at 11:25:27PM +0300, Andrey Kopeyko wrote:
> Николай, к потере вашего времени привело не несоблюление RFC (требовать
> соблюдения которого в данном конкрентном случае - не очень правильно; тут
> должно быть многа букв, расскажу голосом...), а Ваше непонимание разницы
> между параметром конфига server_name и переменной запроса $http_host.
> 
> Сожалею о Вашем потерянном времени.
> 
> Приходите в офис, всё расскажу.

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

> Вот дописать в доку статью "о (вреде и) подводных камнях обработки запроса в
> дефолтном сервере" - наверное, было бы полезным.

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

 Идеально сделанный интерфейс не допускает никаких подводных камней,
 противоречий и неоднозначностей. Им просто пользуешься и "всё работает".
 То же самое должно быть и с дефолтным конфигом.
 А если камни всё-таки вылезают, нужно в первую очередь думать о том,
 как их устранить, и в последнюю -- о том, как их документировать.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Evgeniy Berdnikov]

On Mon, Mar 06, 2023 at 07:40:49PM +0100, Илья Шипицин wrote:
>а есть непустое множество тех, кто уже пользуется, и вы поменяете им
>поведение после апгрейда.

 Неужели? И как же оно поменяется?
 Поставим лучше вопрос так: что у них сломается и почему?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Evgeniy Berdnikov]

On Mon, Mar 06, 2023 at 02:22:25PM +0300, Andrey Kopeyko wrote:
> On Mon, 6 Mar 2023, Nikolay Shaplov wrote:
> > Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы
> > написано:
> > 
> > The SERVER_NAME variable MUST be set to the name of the server host
> > to which the client request is directed.
> 
> Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но
> раз вам так надо и вы понимаете что вы делаете, то пускай.

 Товарищ, наверное, хотел сказать, что составитель дефолтной конфигурации
 не заметил некоторые проблемы, с которыми могут столнуться пользователи.
 И что если вместо $server_name написать $host, то вероятность возникновения
 этих проблем будет несколько ниже. С чем трудно не согласиться.

 Как всегда, ждём, какие аргументы придумают авторы, чтобы ничего не менять. :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Evgeniy Berdnikov]

  Добрый день.
  
On Sun, Mar 05, 2023 at 06:41:17PM +0300, Nikolay Shaplov wrote:
> Разбираясь с cgi-скриптом обслуживающим многочисленные доменные имена 
> столкнулся со следующей проблемой:
> 
> В /etc/nginx/fastcgi_params написано
> 
> fastcgi_param  SERVER_NAME$server_name;
[...]
> Скрипту, тем ни менее нужно знать доменное имя которое он сейчас обслуживает, 
> и он смотрит на переменную окружения SERVER_NAME. 
> 
> А в этой переменной пусто.

 Подумайте об использовании переменной $host.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Исправления срабатываний статического анализатора.

[Evgeniy Berdnikov]

On Wed, Oct 05, 2022 at 09:24:19AM +, Korobov Vladimir via nginx-ru wrote:
> Окей, неправально выразился. 
> Я понимаю, что делает этот патч и он не делает хуже.

 Я написал, почему этот патч делает хуже, причём СИЛЬНО хуже чем было.
 И Максим Дунин высказался. Вы можете что-то возразить предметно?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Исправления срабатываний статического анализатора.

[Evgeniy Berdnikov]

On Wed, Oct 05, 2022 at 02:34:33AM +0700, Eugene Grosbein wrote:
> 05.10.2022 0:53, Evgeniy Berdnikov пишет:
> >  Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я
> >  сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою
> >  софтину полноценный обработчик сегфолта, с анализатором стека и печатью
> >  регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто.
> 
> Не нужно делать "по функционалу не хуже gdb", на это есть gdb.
> Нужно просто использовать libexecinfo или аналоги и backtrace(3) сотоварищи.

 Я пытался пользоваться backtrace(3) и сделал для себя вывод, что ценность
 распечатки стэка без возможности детального анализа памяти довольно низкая.
 Реально полезна корка или остановленный процесс, ждущий подключения gdb.

 У кого-то может быть другое мнение, конечно.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Исправления срабатываний статического анализатора.

[Evgeniy Berdnikov]

On Tue, Oct 04, 2022 at 11:33:14PM +0700, Eugene Grosbein wrote:
> 04.10.2022 20:11, Evgeniy Berdnikov пишет:
> >  При потенциальной возможности зануления указателя следует ловить и
> >  обрабатывать такое исключение. В противном случае нет смысла в проверке.
> >  Задача же не в ублажении тупых анализаторов, а в правильной работе кода.
> 
> Как пользователь разнообразного софта, могу доложить, что сегфолт очень 
> фиговая обработка исключений.
> Проверка указателя на NULL перед разадресацией в том случае, когда нельзя 
> гарантировать что он не NULL,
> практически всегда благо.

 Ну, я написал что такую ситуацию нужно ловить всегда, т.е. MUST а не SHOULD.
 
> Другой вопрос, что потом делать, если вдруг: молча восстановиться и ехать 
> дальше,
> или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но 
> что угодно лучше сырого сегфолта.

 Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я
 сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою
 софтину полноценный обработчик сегфолта, с анализатором стека и печатью
 регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто.
 Корпорации размера Оракл могут себе такое позволить, и нанять кучу
 фултайм-саппортеров на разборку трейсов, а для широкой публики нет ничего
 эффективней сборки без стрипа -> coredump -> gdb -> "bt full" и анализа
 содержимого регистров, памяти, etc.

 Конечно, если софтина mission critical, и останавливаться ей никак нельзя,
 то нужно думать об обработке сбоев. Но в большинстве случаев это можно
 решить дизайном: например, при сегфолте в рабочем процессе автоматически
 запускать новый, отмечать сбой в логе / e-mail, а корку оставлять админу
 на изучение.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Исправления срабатываний статического анализатора.

[Evgeniy Berdnikov]

On Tue, Oct 04, 2022 at 12:00:57PM +, Korobov Vladimir via nginx-ru wrote:
>После проверки исходного кода статическим анализатором (Svace
>https://www.ispras.ru/technologies/svace/) выделено несколько потенциально
>опасных мест, закрывающихся приложенным патчем.

 Тупое выбрасывание кусков кода при проверке указателя на NULL не только
 не решает проблему, но создаёт более опасную ситуацию, когда код приложения
 может работать неверно, но ничего об этом не сообщать, так что поймать баг
 станет очень трудно. Лучше сегфолт в в точно локализованном месте, чем
 глюки непонятно где и непонятно отчего.

 При потенциальной возможности зануления указателя следует ловить и
 обрабатывать такое исключение. В противном случае нет смысла в проверке.
 Задача же не в ублажении тупых анализаторов, а в правильной работе кода.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: certbot

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 02:40:21PM +0500, Илья Шипицин wrote:
>например, мы партизанским способом узнали, что можно из
>.well-known/acme-challenge редиректить по 301, и таким образом,
>сильно централизовать и упростить внедрение lets encrypt

 Зачем редиректить? Можно же проксировать .well-known/acme-challenge.
 Всё равно такой локейшн в конфиг нужно вставлять. И проксировать ведь
 безопасней, потому что при проксировании узел с certbot-ом може сделать
 вообще недоступным для соединений из интернета. А доступ к сайтам для
 передачи сертификатов дать лишь узлу с certbot-ом.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 05:38:57AM -0400, ru4ag wrote:
> увы, такая логика панели по построению конфигураций, мы рассматриваем еще
> вариант свести все ти 8 файлов из инклуда в один файл, тогда вместо 30тис
> перечитываний, будет 3,5 тис. перечитывания конкретно него. Но не уверены
> что какое-то обновление панели это все не сломает, да и все-равно остаеться
> момент что один и тот жефайл перечитыветься 3 тис раз.

 Логика панели тут побоку. Панель раскладывает конфигурацию в набор файлов.
 Вам нужно этот набор превратить в один файл. Для этого делаете свой парсер
 директив "include", возможно, применяя для этого штатные средства других
 препроцессоров, чтобы include объявить макросом.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 05:16:38AM -0400, ru4ag wrote:
> и проблема не в числе инклюдов, а в том что перечитываеться один и тот же
> файл(что идет в инклюде каждого хоста) множество раз, хотя логично было бы
> его перечитать 1 раз.

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

 Если хочется сэкономить на на сисколах open() и close(), то что мешает
 генерить общий конфиг (через m4, cpp, etc), и затем загружать его целиком?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: certbot

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 01:19:01AM +0300, Maxim Dounin wrote:
> Документация на сайте предлагает "certbot --apache" в качестве 
> основного варианта использования (например, тут: 
> https://certbot.eff.org/instructions?ws=apache=ubuntufocal), и 
> дальше уже не важно, какие ещё варианты есть: заметный процент 
> пользователей будет делать именно то, что сказали.  И получать 
> предсказуемый (точнее, непредсказуемый) результат.

 Вставлю свои 2 копейки. Certbot пытается хоть как-то помочь чайникам.
 А для чайника, как для маленького ребёнка, весь мир -- бесконечное
 нагромождение проблем. Чайнику в паре строк конфига разобраться трудно,
 спасти предыдущую конфигурацию он не додумается, работу http-сервера
 он представляет себе смутно, а уж PKI и X509 это вообще ужас...
 Смешная вроде задача "выставить в интернет свою страничку так, чтобы
 гугл и яндекс не опустили сходу в рейтинге" становится неподъёмной.

 Certbot предлагает решение, работающее для дефолтных конфигураций
 наиболее популярных дистрибутивов. Понятно, что это решение для чайников,
 но писать явно об этом нельзя, чтобы не травмировать психику детей. :)
 Главное, это не единственный вариант у certbot'a.
 
> И нет, наличие проблемы "авторы считают возможным менять конфиги" 
> в одном из вариантов использования - не означает, что в других 
> вариантах использования проблем нет.  Наличие такой проблемы 
> означает, что авторы не понимают проблему,

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

 Certbot в вариантах, не предполагающих правки конфигов, вполне себе
 работает. Можно сказать, "поставил и забыл".

 Думаю, для командны Nginx было бы неплохо вставить в дистрибутивный
 конфиг некую заготовку для "location /.well-known/acme-challenge {..}",
 и написать там комментарии как ею пользоваться. Возможно, пообщаться
 ещё с писателями certbot'a, чтобы вместе с ними сделать использование
 этой заготовки удобным и безопасным. Тогда всем новичкам станет легче.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: nginxQuic: медленный ответ от сервера.

[Evgeniy Berdnikov]

On Sat, May 28, 2022 at 12:03:19PM +0300, izor...@gmail.com wrote:
> Сервер nginx не может обработать несколько первых пакетов от клиента по не 
> известной причине.
> В одном из прошлых обсуждений с разработчиком я предоставил свои логи, но до 
> сих пор не удалось решить проблему.

 Звучит как сакраментальное "От меня пули ушли". На месте разработчиков я бы
 сказал: если не можете локализовать проблему, так предоставьте testcase.
 То есть минимальную конфигурацию, на которой проблема может быть надёжно
 воспроизведена и изучена посторонними.

> Вы писали 28 мая 2022 г., 11:15:15:
> 
> > On Sat, May 28, 2022 at 01:36:02AM +0300, izor...@gmail.com wrote:
> 
> >  Ну так изучите чем занимается сервер эти 5-7 секунд, strace/ltrace в руки,
> >  да и в том же debug логе может оказаться полезная информация.

-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: nginxQuic: медленный ответ от сервера.

[Evgeniy Berdnikov]

On Sat, May 28, 2022 at 01:36:02AM +0300, izor...@gmail.com wrote:
> Протестировал последнюю ревизию nginxQuic 5b1011b5702b.
> Проблема с долгим ответом от сервера всё ещё сохранилась.
> От клиента приходит запрос, через tcpdump видно что запрос доходит до сервера 
> nginx (в debug логе отображается событие), но
> по какой-то причине, nginx отдаёт ответ только через 5-7 секунд.

 Ну так изучите чем занимается сервер эти 5-7 секунд, strace/ltrace в руки,
 да и в том же debug логе может оказаться полезная информация.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Мусорные запросы

[Evgeniy Berdnikov]

On Wed, Apr 27, 2022 at 03:17:50AM -0400, alexander_st wrote:
> Добрый день.
> Можно ли на основе лога типа такого
> 
> 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule,
> client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host:
> "*"
...
> отправлять адреса в бан? Только сторонним парсингом лога?
> Понятно, что правилом на такие запросы (не GET, не POST) отдаю 444. Плюс
> настроены ограничения зон. Плюс стоит fail2ban.

 Вы уж определитесь, о чём хотите спросить... Если "на основе лога", то да,
 парсингом и сторонней утилитой, типа fail2ban.

 Если на лету, то сначала нужно сформулировать критерии, по которым следует
 включать блокировку, а потом для выбранных запросов сделать перенаправление
 в обработчик запроса и написать сам обработчик, делающий блокировку.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: nginx: запуск HTTP3 протокола на нескольких хостах.

[Evgeniy Berdnikov]

On Sun, Nov 21, 2021 at 02:52:38PM +0300, izor...@gmail.com wrote:
> Здравствуйте, Evgeniy.
> 
> Испробовал различные варианты - не помогло.

 1. Вы не написали что именно пробовали.
 2. Нужно не пробовать наугад, а посмотреть что посылает nginx в Host:.
 3. Вы не сделали то, что предлагалось:

> >  Следует указать то, что прописано виртуалхостом этого сайта.
> >  А что там прописано -- смотрите конфиг сервера, запускающего
> >  раундкубовские php-ки.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx: запуск HTTP3 протокола на нескольких хостах.

[Evgeniy Berdnikov]

On Sun, Nov 21, 2021 at 12:17:08AM +0300, izor...@gmail.com wrote:
> В итоге HTTP3 у меня заработало, но столкнулся со следующей проблемой - не 
> получается войти в почту через Roundcube.
> Конфигурация:
...
>   proxy_set_header Host $host;
...
> Как только убираю строки с `proxy_set_header` то начинает работать нормально.
> Что надо добавить в `proxy_set_header` чтобы сайт работал корректно?

 Следует указать то, что прописано виртуалхостом этого сайта.
 А что там прописано -- смотрите конфиг сервера, запускающего
 раундкубовские php-ки.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: CLI tools не могут разрешить хост который указан в nginx в контейнере хотя браузер корректно разрешает имя

[Evgeniy Berdnikov]

On Thu, Aug 12, 2021 at 04:28:34PM +0700, Eugene Grosbein wrote:
> 12.08.2021 16:21, Oleksandr V. Typlyns'kyi пишет:
> > чт, 12 серп. 2021, 10:57 користувач Eugene Grosbein  > > пише:
> > 
> > 
> > По-моему, нижнее подчеркивание в именах хостов (записи A или ) 
> > никто не разрешал.
> > Не надо использовать нижнее подчеркивание (можно заменить на дефис) и 
> > всё будет хорошо.
> > 
> > 
> > Так и есть, но если очень хочется, то можно через CNAME.
> > Кто его знаек как регистрация внутри устроена.
> 
> CNAME ничего не меняет в корректности подчеркивания для доменных имён,
> подчеркивание остаётся некорректным символом для этого.
> 
> Подчеркивание afair разрешено только для записей типа SRV.

 Не только SRV. Сегодня почти все почтовые хостеры используют DKIM,
 многие ещё и DMARC, оба этих механизма завязаны на использование
 доменных имён с подчёркиваниями в записях типа TXT.

 ISC BIND, например, проверяет имена хостов лишь в записях тех типов,
 где, по его мнению, имена хостов должны быть: A, , MX, NS и SOA.
 Проверки можно отключить директивой check-names.

 Но я думаю что это всё не имеет отношения к исходной проблеме.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: CLI tools не могут разрешить хост который указан в nginx в контейнере хотя браузер корректно разрешает имя

[Evgeniy Berdnikov]

On Wed, Aug 11, 2021 at 11:17:02PM -0400, budarin wrote:
> Если в браузере указать URL - https://web_app.localhost - ,браузер корректно
> разрешает имя и отображает страницу
> Если в терминале выполнить - curl https://web_app.localhost - получим
> ошибку: curl: (6) Could not resolve host: web_app.localhost

 Nginx никак не задействован в механизме разрешения имён.
 И резолверу безразлично наличие CLI или оконных интерфейсов.
 Разбирайтесь с конфигурацией контейнеров.
-- 
 Eugene Berdnikov
___
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

[Evgeniy Berdnikov]

On Tue, May 25, 2021 at 12:15:54PM +0300, Gena Makhomed wrote:
> >Но вообще если перезапуск php-бэкенда под боевой нагрузкой
> >считается нормальным рабочим действием, то браузер так или иначе
> >имеет шанс получить неполный ответ же. Пытаться в подобной
> >ситуации ещё и ошибки обрабатывать - как по мне, выглядит
> >излишним.
> 
> Это не обязательно может быть перезапуск php-бэкенда
> под боевой нагрузкой, может быть и просто временная
> деградация сети между nginx-фронтендом и бэкендом.

 Временная деградация сети приводит к ретрансмиссиям пакетов, это
 делается ядром ОС и процесс неуправляем со стороны пользователя,
 за исключением общего таймаута. А если таймаут не достигнут, то
 500-х ошибок от деградации сети не может быть. К тому же изначально
 речь шла о unix-сокетах, там совершенно иные правила игры.
-- 
 Eugene Berdnikov
___
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

[Evgeniy Berdnikov]

On Fri, May 21, 2021 at 11:03:47AM +0300, Gena Makhomed wrote:
> nginx и php-fpm у меня находятся на одном и том же хосте,
> связь между ними идет через unix domain socket по протоколу fastcgi.
...
> Речь идет о перезапуске php-fpm командой "systemctl restart php-fpm"
> Если делать "systemctl reload php-fpm" - это не всегра срабатывает,
> иногда после релоада php-fpm оказывается в нерабочем состоянии,
> поэтому использую именно "systemctl restart php-fpm" для изменения
> конфигурации php-fpm, тогда и случаются 502 ошибки с сайтами.

 В таком случае, может быть, сконфигурить 2 бэкенда, отличающиеся лишь
 сокетами (и какими-нибудь pid-файлами), описать их в одном upstream{}
 и не перезапускать php-fpm, а поднимать 2й и гасить 1й?
-- 
 Eugene Berdnikov
___
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

[Evgeniy Berdnikov]

On Fri, May 21, 2021 at 12:05:45AM +0300, Gena Makhomed wrote:
> Есть nginx, который проксирует запросы на единственный бекенд php-fpm.
> Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки.
> 
> Каким образом можно настроить nginx так, чтобы он в случае ошибки
> связи с бекендом пытался достучаться до него в течении N секунд
> (например, 30 сек), с интервалом, например, в K секунд
> (например, 0.1 сек) ?
> 
> Тогда клиент вместо сообщения про ошибку видел бы просто небольшое
> замедление ответа сервера на секунду или максимум несколько секунд,
> что гораздо лучше, чем мгновенный возврат сообщения про ошибку 5хх.

 Возврат 5xx говорит о том, что либо
 
 1. хост недоступен по сети (возможно, ребутается), по сисколу connect(2)
возвращается EHOSTUNREACH.
 2. хост доступен, но порт в этот момент не прослушивается, тогда
возвращается ECONNREFUSED,
 3. приложение возвращает 5xx и nginx форвардит этот ответ клиенту.

 Ели речь о п.2 и п.3 (перезапуск php-fpm), то это вовсе не ситуация
 "нет связи с бэкендом", которая п.1.

 Если же речь о ребуте хоста php-fpm, то либо бэкенд в локальной сети и
 оказывается недоступен по arp-у, тогда EHOSTUNREACH возвращается после
 arp-овского таймаута (обычно это 3 секунды), если бэкенд в другой
 подсети, то обычно шлюз возвращает icmp[host-unreachable] по той же
 причине, через те же 2-3 секунды.

> Может быть как-то с помощью njs или nginx-module-perl или с помощью
> ngx_http_upstream_module это можно сделать? Или тут единственно возможный
> вариант - писать патч на С для решения этой задачи?

 Ох... да просто отрубить пакетным фильтром (файрволом) этот бэкенд
 на время всех манипуляций по перезапуску php-fpm. А когда запустится,
 открыть обратно. Конечно, proxy_connect_timeout подкрутить.
 И заскриптовать всё.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как установить Rapid SSL 2018

[Evgeniy Berdnikov]

On Fri, May 14, 2021 at 07:57:31PM +0500, Илья Шипицин wrote:
>сертификат это очень контекстная тема. в момент покупки предполагается,
>что он будет единственным образом использован - настроен на веб-сервере.
>nginx входит в пятерку по распространенности. и это очень контекстно, в
>момент покупки выдать покупателю инструкцию "а использовать купленный
>сертификат лучше всего вот так (для самых популярных реализаций)"

 Не скажу насчёт "контекстности", но на nic.ru есть подробнейшие инструкции,
 в том числе для Nginx. Ткнуть в л/к ссылку на купленный сертификат и
 промотать вниз, до абзаца "Как установить SSL-сертификат".

>пт, 14 мая 2021 г. в 19:39, sf2015 :
>  Сертификат куплен на домен и поддомены. Покупался на nic.ru.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Tue, May 11, 2021 at 04:52:37AM -0400, maximkherson wrote:
> Делаю проксирование с локального хоста на google. Задача слудующая:
> 
> В браузере ввожу proxy.localhost, нажимаю enter
> Открывается google.com, но в браузере в адресной строке остаётся
> proxy.localhost (т.е. выполняется проксирование)
> ПРОБЛЕМА. У меня работает как в случае редиректа, а не проксирования, т.е.
> после пункта 1 открывается google и запись в адресной строке меняется с
> proxy.localhost на https://www.google.com.
> 
> ВОПРОС. Как сделать так, чтобы адрес оставался proxy.localhost, но
> открывался https://www.google.com ?

 Вы для какой бизнес-задачи пытаетесь изобрести такое витиеватое решение? :)

 Прежде всего следовало бы ответить на вопрос, нужно ли переписывать
 абсолютные url-ы в возвращаемых страницах на "proxy.localhost",
 и если да, то чем это делать. А если нет, то зачем такое проксирование?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тонкости работы FastCGI (phpfpm)

[Evgeniy Berdnikov]

On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote:
> Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я
> помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение.
> Или тоже помню неверно?

 Неверно. И вообще это не имеет отношения к GCI, поскольку CGI как протокол
 не содержит никаких требований к обработке статуса соединения между
 клиентом и web-сервером. CGI это интерфейс между сервером и дочерним
 процессом. А как ведёт себя сервер по отношению изменениям статусов
 пользовательских коннекций -- это особенности его реализации.

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

 Вы находили в документации по php прямо противоположное утверждение.
 Но насколько оно верно -- это вопрос, по мне так php это маргинальная
 субкультура и слепо доверять её грамотам не стоит...
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Варнинги после перехода на PHP 8

[Evgeniy Berdnikov]

On Sat, Apr 17, 2021 at 10:43:20AM -0400, Trecolom wrote:
> Можно резюмировать то, что я нарыл:
> Заголовок Content-Length от движка Nginx-су не передается.
> Никаких лишних данных движок не передает.
> Ошибка возникает только в том случае, когда протокол HTTP/1.1 и ниже.

 Я бы предложил проверить эти выводы на скрипте-однострочнике, выводящем
 "304 Not Modified" и пустое тело. Для вариантов с Content-Length и без.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тонкости работы FastCGI (phpfpm)

[Evgeniy Berdnikov]

On Fri, Apr 16, 2021 at 02:27:53PM +0700, Victor Sudakov wrote:
> Evgeniy Berdnikov wrote:
> >  В скрипте (пользовательском процессе с php) не существует 
> > connection-status.
> 
> А в https://www.php.net/manual/en/features.connection-handling.php
> написано что существует.
...
> В документации написано, что когда "remote user hits his STOP button,
> the next time your script tries to output something PHP will detect that
> the connection has been aborted and the shutdown function is called."
> 
> Из этого можно заключить, что если не пытаться что-то из скрипта
> выводить, то ABORTED никогда не наступит. Это верное утверждение?

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

 Главное на этой страничке вот что:

   The default behaviour is however for your script to be aborted when
   the remote client disconnects.
   [...]
   If you do not tell PHP to ignore a user abort and the user aborts,
   your script will terminate.

 Теоретически это реализуемо, так что предлагаю проверить утверждение на
 чистой инсталляции php со скриптом-пустышкой, уходящим в сон на 3 часа,
 и если написанное выполняется, то разбираться далее с боевыми скриптами.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Варнинги после перехода на PHP 8

[Evgeniy Berdnikov]

On Fri, Apr 16, 2021 at 03:07:54AM -0400, Trecolom wrote:
> Что я выяснил. Скрипт сайта, в ответ на запрос с заголовком
> "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не
> нулевые данные. Отсюда и варнинг.
> Скрипт делает все верно,

 Нет. При "Content-Length: 0" тело должно содержать ноль байт.
 То есть никаких данных быть не должно, скрипт работает неправильно.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тонкости работы FastCGI (phpfpm)

[Evgeniy Berdnikov]

On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote:
> А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500)
> внутри себя, и при этом nginx закрывает соединение со скриптом,
> connection-status в скрипте не перейдет в состояние ABORTED?

 В скрипте (пользовательском процессе с php) не существует connection-status.
 Статус коннекции есть в ядре, и для закрытой с одной стороны коннекции
 он будет "half closed", т.е. на стороне получателя FINa перейдёт в
 состояние CLOSE_WAIT. Смотрите диаграмму состояний TCP в RFC 793.

> Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN
> -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки
> connection-status в скрипте всё равно останется NORMAL до попытки
> вернуть клиенту какие-то данные?

 Повторю: состояние коннекции находится в ядре. Есть интерфейс общения
 процесса и ядра. Если процесс попытается написать в сокет, для которого
 другая сторона закрыла коннекцию, то ему ядро вернёт ECONNRESET.

> > Об этом, в частности, рассказывается в комментариях к 
> > описанию connection_aborted().  То есть исходная задача "скрипт 
> > ждёт ответа базы 3 часа" - в php просто так не решается.
> 
> Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если
> nginx соединение с ним закрыл. 

 Для мониторинга состояния коннекции есть poll/epoll/kqueue/etc, как уже
 писали в этом треде. Но делать такой мониторинг непросто: нужно ловить
 событие "коннекция закрыта с той стороны" и писать его обработчик,
 возможно искать способы безопасного прерывания кода, работающего 3 часа.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Варнинги после перехода на PHP 8

[Evgeniy Berdnikov]

On Thu, Apr 15, 2021 at 11:37:27AM -0400, Trecolom wrote:
> Пока не могу сообразить, как подойти к решению этой задачи. До чего
> докопался - поисковик делает запрос на сайт с заголовком If-Modified-Since
> или If-None-Match и если контент страницы не изменился, движок отдает код
> "304 Not Modified" - именно в этом случае возникает ошибка.

 Посмотрите трафик, содержимое запроса и что выдаёт в ответ сервер.
 Ответ с кодом 304 должен иметь тело нулевой длины и "Content-Length: 0".
 
 Запрос можно положить в свой скрипт, чтобы выполнять его многократно
 и таким образом локализовать проблемный участок php-ного кода.

 Содержимое трафика можно получить с помощью tcpdump/wireshark/etc,
 но когда есть подозрение на заголовки, достаточно debug log от nginx.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

[Evgeniy Berdnikov]

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:
>Замечено, что по https отдача первого байта происходит на 200мс дольше.

 Сравнение
 ltrace -S -T -tt -fp 
 с дампом трафика может прояснить ситуацию.

 По величине задержки похоже на Нагель, хотя он должен быть выключен.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не удается подменить ошибки своими страницами

[Evgeniy Berdnikov]

On Thu, Apr 01, 2021 at 04:02:20PM -0400, budarin wrote:
> коллеги, уже весь интернет перечитал - не могу решить проблему, помогите
> пожалуйста!

 debug log
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Thu, Dec 24, 2020 at 02:42:01PM -0500, pavlusha23 wrote:
> Evgeniy Berdnikov, это шутка такая или что?

 Нет, не шутка.

> Мои коллеги никуда не пишут. Они
> просто вводят свой email. Это этот форум присылает проверочное письмо с
> адреса w...@teresa.liquidhost.co. Поскольку проверочное письмо присылается с
> хрен пойми какого адреса, то оно отсекается, соответственно зарегиться здесь
> на форуме невозможно.

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

 К слову, если те коллеги такие крутые постмастеры, что у них антиспам
 круче гугла, яндекса и mail.ru, то им ничего не стоит внести на минуту
 w...@teresa.liquidhost.co в белый список и подключиться к рассылке. :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Wed, Dec 23, 2020 at 05:33:36PM -0500, pavlusha23 wrote:
> (Почините этот форум, невозможно зарегистрироваться если почта расположена
> на серверах с современными строгими антиспам настройками.)
> 
> Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться, но не
> могут. Я проверил сам, действительно невозможно. Они мне скинули логи своей
> почты тоже. У всех ситуация примерно одинакова:
> 
> 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 последних версий) на этапе
> приёмки, даже в спам не попадают. Прошу администрацию уделить этому
> внимание, вроде айтишники жеж.

 Всё с точностью до наоборот. Ваши коллеги пишут с несуществующих адресов
 (точнее, с неверифицируемых). А приёмный рилей рассылки nginx-ru, видимо,
 такие адреса отсекает. И это абсолютно правильно: зачем подписываться
 на рассылку тому, кто почту (включая эту рассылку) получать не может?

 Предложите коллегам настроить у себя почтовую систему нормально или
 сменить почтового провайдера.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Пухнет буфер кэша при нагрузке

[Evgeniy Berdnikov]

On Wed, Dec 23, 2020 at 08:34:11AM -0500, mouserok wrote:
> было 1006
> стало 1012
> эти значения есть в начальном сообщении 
> запускались до и после нагрузки

 Вы не ответили на заданные вопросы. Если нет понимания, что означают
 эти цифры, то нет и никакого смысла отвечать почему они меняются.
 Никаких проблем с nginx этот кейс не иллюстрирует.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Пухнет буфер кэша при нагрузке

[Evgeniy Berdnikov]

On Wed, Dec 23, 2020 at 07:02:32AM -0500, mouserok wrote:
> Пухнет кэш памяти если включить логирование. При нагрузке это становится
> критичным - память съедается и не высвобождается.

 Вы что конкретно имеете в виду под "буфер кэша" и "кэш памяти"?

 Покажите, где в приведённых числах что-то пухнет, а также поясните,
 почему источником проблемы считаете nginx. Он пухнет?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[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" если в хендлере есть то же самое обращение апстриму?
 Тут просто добавочное логгирование... И статус чисто внутренний, он может
 быть любой, не обязательно 421. Тогда чем этот паровоз не устраивает?


>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

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

[Evgeniy Berdnikov]

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

Re: при попытке создания папки в логах "mkcol can create a collection only"

[Evgeniy Berdnikov]

On Tue, Dec 01, 2020 at 10:01:29AM -0500, macmealan wrote:
> Подключился через файл менеджер в  kde. При попытке создать папку ошибка.
> *3 MKCOL can create a collection only, client: 10.10.1.200, server: _,
> request: "MKCOL /webdav/test/test HTTP/1.1", host: "10.10.1.108"

 Ваш файл-менеджер делает кривой запрос: урл без слэша на конце это
 не коллекция согласно стандарту, о чём сервер и сообщает.

> Файлы тоже создавать не дает ошибка
> *5 dav_ext stat failed on '/var/www/html/webdav/testfile' (2: No such file
> or directory), client: 10.10.1.200, server: _, request: "PROPFIND
> /webdav/testfile HTTP/1.1", host: "10.10.1.108"

 PROPFIND это не запрос на создание файла, а чтение атрибутов.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Tue, Oct 20, 2020 at 05:15:05AM -0400, Zalman_ wrote:
> При проверке через telnet
> 
> telnet *адрес локального IP, к которому есть доступ через HTTP* - unable to
> connect to remote host: connection refused

 Это противоречит выдаче netstat-а о том, что порт прослушивается.

> telnet *белый IP через который идет подключение из вне* - unable to connect
> to remote host: connection timed out

 Это противоречит сообщению Chrome о том, что соединение устанавливается,
 а затем закрывается сервером.

 Похоже, вопрос не имеет отношения к nginx, тут нужен обычный сисадмин
 для настройки сети.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Wed, Oct 07, 2020 at 06:10:01PM +0300, Иван Мишин wrote:
>Но вот при такой конфигурации:
>limit_rate_after 15k; #150Mb
>limit_rate 2048k;
>proxy_max_temp_file_size 6144m;  
>Поведение не понятно. При таких параметрах директив работает так -
>скачивается 150Мб и затем обрыв. Почему?

 Посмотрите логи прокси и бэкенда, посмотрите что выдаёт "wget -d".
 Для полноты можно посмотреть анализатором трафика где какая коннекция
 закрывается, обратить внимание на отметки времени, сравнить с заданными
 на всех узлах таймаутами.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[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 с
>  апстрима
> 
>с одной стороны я с вами соглашусь, что дефолтное поведение не выглядит
>отличным.
>вероятно, если файл больше нельзя сохранять в кеш, то можно просто не
>пытаться его сохранять,
>а обойтись тем, что сохранено, остаток дочитать, ну или подождать
>с другой стороны, вы несчастны с дефолтным поведением - ок, меняете
>настройку на более комфортную вам
>и живете с ней.
>аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему бы не
>поменять ее конкретно тому,
>кто несчастен с дефолтом

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

>   пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
>   в таких условиях это баг, однозначно.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[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 в данной конкретной ситуации, но думаю,
 что его авторы не столь тупы, чтобы не понимать: на апстриме всегда может
 найтись файл, который в буфер не влезет. При любых значениях настроечных
 параметров. Это нормальная ситуация, причём если Content-Length с апстрима
 пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
 в таких условиях это баг, однозначно.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[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Гб временного файла. когда качается быстро, он
> вообще в темп не пишется, если файл прилетает от апстрима быстрее
> чем забираем, то он уже пишется во временный файл. вы успеваете
> скачать столько, сколько прилетает до начала записи во временный
> файл + макс размер файла.

 Наличие лимита на размер временного файла это что, повод обрывать закачку?
 Я бы предложил начать с 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

Re: Странные 502 ответы.

[Evgeniy Berdnikov]

On Thu, Oct 01, 2020 at 09:21:07AM -0400, elc wrote:
> Вот в том и дело что на стороне сервера (промежуточном 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, отсутствуют.

 В чём вопрос-то заключается? Всё что знает о проблеме промежуточный прокси
 он написал в лог, его хоть обчитайся, дальше не сдвинешься. Выясняйте что
 происходит на upstream-е (который Origin), почему он обрывает коннекции.
 
 А то что прокси при этом выдаёт 502, так это закономерно: такой ответ и
 должен быть при обрыве коннекции upstream-ом.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Sat, Sep 26, 2020 at 04:07:10AM +0700, Eugene Grosbein wrote:
> 26.09.2020 0:45, Evgeniy Berdnikov пишет:
> 
> > On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote:
> >>>  Есть только одна нормальная политика: доставить icmp по назначению.
> >> В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP.
> > 
> >  Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать.
> 
> Да почему же невалидные. NAT ведь разный бывает, например может быть
> "клиент" с выделенной ему сеткой 100.64.0.0/24 и выделенным же одним внешним 
> IP,
> весь исходящий трафик из сетки транслируется в такой "персональный" внешний 
> IP,
> весь входящий трафик на этот IP, не являющийся ответным, транслируется 1:1
> на 100.64.0.1, что позволяет клиенту "публиковать сервисы".

 Я просил конкретный пример. Что здесь в icmp, какой ip "внешний"?
 
> Пропускать ли снаружи внутрь ICMP echo-request, которые могут быть с 
> заниженным TTL
> (traceroute probes) и хотя бы частично покажут внутренную часть сети за NAT
> между самим NAT и 100.64.0.1 ? Там может быть более одного хопа.
> Кто-то не пропускает. А пропускать ли такие же ICMP need-fragment?
> Кто-то не пропускает и ломает PMTUD.

 ICMP[frag-need] валиден лишь если он относится к открытому соединению,
 точнее, к существующей записи в контраке. Иначе icmp[frag-need] невалиден.
 
 В принципе пропускать же icmp[frag-need] можно любые, потому что ядро
 пользовательской системы точно так же должно проверять привязку icmp
 к установленному соединению, и по rfc обязано игнорировать невалидные.
 Но лучше мусор за nat не пропускать.

 Политика фильтрации может применяться только к тем типам icmp, которые
 к существованию записи в контраке не привязаны, скажем, для echo-request.
 Но не для echo-reply! Если кто-то делает иначе, в том числе тупо запрещает
 icmp внутрь, то он просто не понимает, что ломает базовые алгоримы ip.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Fri, Sep 25, 2020 at 08:37:22PM +0300, Slawa Olhovchenkov wrote:
> > теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались
> 
> побитно тогда уж!
> как он не кратный четерем может быть-то?

 Анонсированный MSS -- запросто. :)) Вписал нечётный в правило, и вуаля.
 Iptables пропустит и ядро линикса поставит. Насчёт фрюх и цисок не знаю.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote:
> >  Есть только одна нормальная политика: доставить icmp по назначению.
> 
> В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP.

 Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать.

> >  Все остальные политики ущербны, IMHO. Я лично никогда не встречал
> >  разумных "соображний безопасности", которые могли бы оправдать поломку
> >  одного из из базовых механизмов ip-стэка.
> 
> А вот некоторые считают, что пропускать ICMP внутрь NAT вообще не следует :-)

 Есть внятные аргументы кроме "хихи-хаха" и смайликов?

> >  Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать?
> 
> По количеству инсталляций стека.

 Ну и как посчитать количество инсталяций? И где эта статистика по сломанным
 инсталлированным стэкам? Мне кажется это пустой трёп, но покажите.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

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

 Спасибо.

 Хотелось бы ещё уточнить: 1/10,000 -- это после подкручивания или до?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

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

 Какое значение MSS анонсируют ваши серверы?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[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-стэка.

 Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Fri, Sep 25, 2020 at 05:49:40AM +0700, Eugene Grosbein wrote:
> 25.09.2020 0:01, Evgeniy Berdnikov пишет:
> 
> >  Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите"
> >  наверняка нет (они могут быть лишь на 2м и предпоследнем хопе).
> 
> О, сколько вам открытий чудных готовит просвященья дух!
> Даже операторы связи бывают такие, что у них MTU трассы во внешний мир меньше 
> 1500,
> я встречал, что уж говорить о корпоративных и домашних сетях.

 Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак.
 Поэтому бывает лишь на крайних хопах.

> А ещё есть особая, уличная магия в обработке входящего ICMP коробкой с NAT,
> за которой в одном или несколькими хопами (а не непосредственно на ней)
> стоит концентратор PPPoE или ещё какой туннель типа PPtP, а уже дальше 
> клиенты.

 Эта "магия" для tcp и udp ничего сложного не представляет, она уже лет 20
 работает и в линуксах, и в бсд, и в цисках. Магию не осилили зиксели и
 прочие китайцы, да, но не потому что там что-то сверхсложное. У неасиливших
 вообще всё плохо, там даже icmp[source-quench] можно встретить. :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[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

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

[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 ходит лишь по изернету, там "снаружи" ничего прилететь не может.

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

 На самом деле лишь первые 2 стратегии можно нормально реализовать
 с классическим api сокетов.

 Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по
 умолчанию и ваша голова не болит, как он там пакеты дробит и куда
 свои служебные заголоки фасует.

 Другой вопрос, насколько кривы конкретные ipv6-to-ipv4 гейты и
 шлют ли они нужные клиенту icmp.

>очень интересно в этом плане жить в мире Windows (в нем принято ставить DF
>на https),

 Чем интересно? Браузерный трафик всегда идёт внутри туннеля.
 А если туннелятор не умеет PMTUD снаружи, то какое бы DF ни было внутри,
 результат будет одинаково печальным.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Пяти секундная задержка на отправку

[Evgeniy Berdnikov]

On Thu, Sep 24, 2020 at 09:00:34AM -0400, Sergey Smirnov wrote:
> Добрый день!
> 
> Использую NGINX в качестве Load balancer.
> Столкнулся с тем, что некоторые 200 приходят с задержкой в несколько
> секунд.
> 
> Изучил логи, вижу следующее:
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED96750
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ECDFA30
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED94200, unused:
> 8
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED4B380, unused:
> 400
> 2020/09/24 12:37:58 [debug] 18718#0: timer delta: 1
> 2020/09/24 12:37:58 [debug] 18718#0: worker cycle
> 2020/09/24 12:37:58 [debug] 18718#0: epoll timer: -1
> //6 секунд задержки
> 2020/09/24 12:38:04 [debug] 18718#0: epoll: fd:9 ev:0001 d:7F344DCE31F0
> 2020/09/24 12:38:04 [debug] 18718#0: accept on 0.0.0.0:443, ready: 0
> 2020/09/24 12:38:04 [debug] 18718#0: posix_memalign: 7F344EC7F450:512
> @16
> 2020/09/24 12:38:04 [debug] 18718#0: *2331 accept: 192.168.10.86:55013
> fd:11
> 
> Прошу помощи, как это можно поправить? Что случилось?

 А где здесь видна задержка на отправку? По-моему, здесь 5-6 секунд между
 завершением предыдущего запроса и открытием коннекции (accept) для
 следующего, который может придти в любое время. Нужно посмотреть время
 поступления SYN-ов на балансировщик и сравнить с тем, что в логе.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
>Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
>ресолвится первый раз, второй и последующие - ресолвится, потом через два
>часа по новой.  

 Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем 
 nginx-то в этом провинился?
 
>Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
>(подключение).

 Каким образом это может исправить ситуацию? Изложите механизм чуда.

>А пока вынуждены таким костылем пользоваться:
> 
>  ping -4 -w 1 -c 1 -q nginx.org >> /dev/null

 Это скорее не костыль, а шаманство.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: резолвятся не все имена host-файла

[Evgeniy Berdnikov]

On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote:
> почему резолвится только часть имён? да и что за чудеса, чем upstream так 
> помогает резолвингу?

 Проверьте на стандартную ошибку: где-то имя написано с символом в кириллице
 (скорее всего в конфиге nginx), а при проверках копи-пастилась откуда-то
 без кириллицы. Обычным грепом легко это выявить, и hd помогает.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Регулярка для пробела в request uri

[Evgeniy Berdnikov]

On Wed, Sep 02, 2020 at 12:30:56AM -0400, Dmytro Lavryk wrote:
> Время от времени приходят какие-то странные УРЛы вида:
> "https://example.com/ https:/example.com/category/date/news-name/"
...
> Подскажите как правильно это обработать.

 Правильно это разобраться откуда такие урлы берутся и пофиксить клиента.

 Такие урлы могут возникать из-за того, что в каком-то документе
 (например, в письме из рассылки) ссылка создана неправильно, а браузер
 тупо обрабатывает некорректный href. Для начала посмотрите реферер.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

[Evgeniy Berdnikov]

On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:
>случилось странное, переехали на сервера по параметрам в разы большие, чем
>сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния
>на штатные параметры sysctl осталось отключение ipv6
>и swapness выставленный в 10%))
...
>меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
> 
>упорно кончается вся память через 5 минут, все 256 Гб и своп
> 
>идей практически не осталось, куда можно ещё копать?

 Вы с серверами сменили ОС, ядро и поставили nginx другой версии?
 Если да, то для начала запустите старую систему на новой железке,
 и память системе дайте столько, сколько было на старой.
 А потом двигайтесь пошагово в сторону проблемной конфигурации.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с отображением $remote_user

[Evgeniy Berdnikov]

On Thu, Aug 06, 2020 at 01:56:35PM +0300, Иван Мишин wrote:
>Всем привет. 
>Использую wget с ключами --http-user=USERNAME --http-password=PASSWORD при
>этом в nginx в переменной $remote_user пусто. Пробовал и --user=USERNAME
>--password=PASSWORD и wget  https:// [1]USERNAME:passw...@example.com, но
>во всех случаях в логах в переменной $remote_user  стоит прочерк. При этом
>с curl все работает ок. Подскажите в чем проблема?

 Вероятно, сайт не требует авторизации, а поведение wget и curl
 в этом случае слегка различаются: curl шлёпает заголовок всегда,
 а wget лишь когда это реально нужно.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не корректно работает root в nginx

[Evgeniy Berdnikov]

On Fri, Jul 31, 2020 at 02:14:17PM +0300, MihaKot wrote:
>есть конфигурация nginx
> 
>  server {
>  listen   80;
>  server_name  client.test.domain;
> 
>  charset utf-8;
> 
>  root /var/www/_test.domain/client/;
>  index  index.php index.html;
> 
>  client_max_body_size 0;
> 
>  location / {
>  #root /var/www/_test.domain/client/;
>  }
>  location /html {
>  #root /var/www/_test.domain/;
>  alias /var/www/_test.domain/html;
>  }
...
>  location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ {
>  expires 14d;
>  }
...
>При такой конфигурации скрипты работают, при
>запросе client.test.domain/html/css/style.css выдает 404 Not found
> 
>в логе nginx видно что файл
>ищет "/var/www/_test.domain/client/html/css/style.css"

 Всё правильно: срабатывает последний процитированный локейшн, а так
 как root для него не переопределён, он наследуется от блока server.

 В документации по директиве location описан алгоритм выбора конкретного
 блока: http://nginx.org/en/docs/http/ngx_http_core_module.html#location
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: tcpdump tls

[Evgeniy Berdnikov]

On Sun, Jul 26, 2020 at 08:47:40PM +0300, Slawa Olhovchenkov wrote:
> А что-как можно сделать что бы расшифровать https сессию в .pcap?

 Это 7 вёрст крюк, проще включить на сервере debug log...

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

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

Re: nginx и завышение трафика.

[Evgeniy Berdnikov]

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.

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

 Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
 аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
 и ретрансмиссий, но тогда они в дампе будут отлично видны.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx и завышение трафика.

[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

Re: location + proxy pass = 404

[Evgeniy Berdnikov]

On Wed, Jun 17, 2020 at 06:35:26AM -0400, emejibka wrote:
> В том то и дело что другие location в конфиге отсутствуют.
> Как объяснить работающий конфиг на старой версии nginx?

 Для начала получить debug log-и и сравнить.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?

[Evgeniy Berdnikov]

On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> дополнительный запрос к ресурсу.

 Если клиент умеет cache digest, то да, может отказаться заранее.
 А если нет, то к тому моменту, когда клиент сможет отклонить push,
 данные уже летят по сети и отъедают пропускную способность канала,
 это обстоятельство может навредить желанию загрузить все причандалы
 к странице побыстрее.

 Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
 профит от сложной и очень тяжёлой технологии". И push в том ряду.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx + WebDav = MS Office read only

[Evgeniy Berdnikov]

On Sat, Apr 25, 2020 at 12:36:54PM -0400, BuTbk@ wrote:
> Может что-то можно тут подправить, чтобы офис открывал файлы в режиме
> редактирования? 
> if ($request_method = PROPPATCH) { # Unsupported, allways return OK.
>   add_header  Content-Type 'text/xml';
>   return  207 ' xmlns:a="DAV:">HTTP/1.1 200
> OK';
> }

 Конечно, это можно отправить в мусорку... Но в результате выбрасывания
 заглушек из конфигов чуда не произойдёт: внутри nginx не появится код
 обработчика PROPPATCH, если его изначально не было. :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx + WebDav = MS Office read only

[Evgeniy Berdnikov]

On Sat, Apr 25, 2020 at 11:04:22AM -0400, BuTbk@ wrote:
> Нашел инструкцию(http://netlab.dhis.org/wiki/ru:software:nginx:webdav),
> чтобы виндовый клиент нормально работал с ресурсом. Все работает прекрасно,
> за исключением того, что офисные доки открываются только в режиме
> чтения(проверил, через IIS все нормально работает). Пробовал добавить
> dav_ext_methods LOCK UNLOCK; Но это ничего не изменило.
> Гугл ничего толкового не выдал. Может кто сталкивался?

 AFAIK, локов недостаточно для rw, нужна поддержка PROPPATCH, а её
 у nginx-а нет. Точнее, винде это нужно, а davfs2 нет, он работает.
 Так что проксируйте мелкомягких на IIS.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Выбор upstream server в зависимости от типа clipher

[Evgeniy Berdnikov]

On Wed, Apr 22, 2020 at 12:55:02PM +0500, Илья Шипицин wrote:
>ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov <[1]b...@protva.ru>:
> 
>  On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
>  >    но вы понимаете, что речь идет о stream-проксировании, т.е. вы
>  просто tcp
>  >    поток отправляете на тот или иной бекенд и терминация SSL будет уже
>  на
>  >    бекенде?
> 
>   Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello
>   и обработать ciphersuites ему нужно терминировать SSL.
> 
>есть технология, в haproxy называется SNI based routing, когда из
>SSL-хендшейков извлекается SNI (если он нешифрованный), и далее стрим без
>терминации роутится.
>в nginx это делается на ngx_stream_ssl_preread

 Да, не заметил, нужный модуль есть. Только функционала для выбора шифра
 не хватает. Значит, этот модуль и нужно слегка попатчить.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Выбор upstream server в зависимости от типа clipher

[Evgeniy Berdnikov]

On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
>но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто tcp
>поток отправляете на тот или иной бекенд и терминация SSL будет уже на
>бекенде?

 Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello
 и обработать ciphersuites ему нужно терминировать SSL.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx + WebSockets на C/C++

[Evgeniy Berdnikov]

On Wed, Apr 01, 2020 at 02:54:20PM +0200, Valery Kholodkov wrote:
> On 01-04-20 13:58, Evgeniy Berdnikov wrote:
> > On Wed, Apr 01, 2020 at 01:06:27PM +0200, Valery Kholodkov wrote:
> > > FastCGI использовался в прошлом для ускорения комуникации между 
> > > веб-сервером
> > > и апп-сервером.
> > 
> >   Разве? Запросы, упакованные в FastCGI, бегут по сети между серверами
> >   быстрее, чем те же запросы в виде HTTP?
> 
> См. https://en.wikipedia.org/wiki/FastCGI -> Implementation details

 Где там ответ на заданный вопрос? Я его не вижу и уверен, что его быть
 не может.

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

> > > Сейчас, когда можно с легкостью написать событийно-ориентированное
> > > приложение отвечающее по HTTP, преимущество использования FastCGI
> > > представляется сомнительным.
> > 
> >   Возможность писать простые однопоточные приложения как раз является
> >   преимуществом. К тому же запрос в FastCGI доступен приложению в
> >   уже разложенном по хедерам виде.
> 
> А как насчет кук, параметров, разбора тела, поддержки сессий? libfcgi-то
> отдает только голый запрос.

 А никак, к протоколу доставки данных это отношения не имеет.
 Любая либа будет работать с куками одинаково эффективно, как бы содержимое
 хедера Cookie ни было к ней доставлено.

> Далее, зачем в 2020 году писать многопоточное приложение с кучей блокирующих
> библиотек, если можно писать приложение с кучей неблокирующих библиотек?

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

> > > Если есть задача сделать  приложение на C++ и подключить к nginx с помощью
> > > libfcgi, то это несложно. А вот выжать из него максимум 
> > > производительности,
> > > реализовать поддерджку всех фич HTTP и поддерживать его в течении
> > > длительного времени -- это гораздо сложнее, чем на то же самом node.js.
> > 
> >   1. О каких фичах http речь?
> >   2. Где можно выжать максимум производительности, за счёт чего?
> >   3. Приведите примеры, pls, где что-то выжимается большим трудом на FastCGI
> >   и легко и просто на Node.js.
> 
> Давайте решим этот спор следующим образом: если Вам требуется некоторое
> приложение на FastCGI и C++, я готов Вам его разработать и поддерживать,
> если Вы готовы за это заплатить.

 Понятно, Вы не способны аргументировать свои утверждения, всё сводится
 к тому, что за какую-то техническую чушь хотите денег. Вопрос закрыт.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx + WebSockets на C/C++

[Evgeniy Berdnikov]

On Wed, Apr 01, 2020 at 01:06:27PM +0200, Valery Kholodkov wrote:
> FastCGI использовался в прошлом для ускорения комуникации между веб-сервером
> и апп-сервером.

 Разве? Запросы, упакованные в FastCGI, бегут по сети между серверами
 быстрее, чем те же запросы в виде HTTP?

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

 Возможность писать простые однопоточные приложения как раз является
 преимуществом. К тому же запрос в FastCGI доступен приложению в
 уже разложенном по хедерам виде.

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

 Компрессия заголовков в FastCGI, это не ошибка?

> Если есть задача сделать  приложение на C++ и подключить к nginx с помощью
> libfcgi, то это несложно. А вот выжать из него максимум производительности,
> реализовать поддерджку всех фич HTTP и поддерживать его в течении
> длительного времени -- это гораздо сложнее, чем на то же самом node.js.

 1. О каких фичах http речь?
 2. Где можно выжать максимум производительности, за счёт чего?
 3. Приведите примеры, pls, где что-то выжимается большим трудом на FastCGI
 и легко и просто на Node.js.
 Спасибо.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Таймауты proxy pass

[Evgeniy Berdnikov]

On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote:
> Добрый день.
> 
> В продолжение изучения проблемы обнаружили что в логе нжинкса
> upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
> время ответа бэка меньше 1ms:
> 
> https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0
> 
> 
> Как такое может быть?

 Ответ апстрима не обязательно помещается в один пакет, даже если у него
 установлен флаг PSH. Если бы отображалось содержимое пакетов, то можно
 было бы проверить, передан ли ответ полностью, а при наличии в дампе
 ответных ACKов -- утверждать, что ответ получен сервером.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 104: Connection reset by peer

[Evgeniy Berdnikov]

On Fri, Mar 20, 2020 at 07:17:44AM -0400, inkognito0609 wrote:
> Странно, потому что tcpdump показывает что RST отправляет именно балансер

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

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

> 11:02:29.210528 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 50630,
> win 255, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0
> 11:02:29.215540 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [R.], seq 309,
> ack 50630, win 255, options [nop,nop,TS val 4257877945 ecr 1022466631],
> length 0
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 104: Connection reset by peer

[Evgeniy Berdnikov]

On Fri, Mar 20, 2020 at 05:00:36AM -0400, inkognito0609 wrote:
> nginx работает в качестве tcp lb
> Периодически получаю 104: Connection reset by peer.
> ---
> Если причинно следственная связь в системных вызовах?
> writev() not ready (11: Resource temporarily unavailable)
> recv() failed (104: Connection reset by peer)
> или 104 ошибку получаем из-за того что не получили сообщений от сокета для
> файлового дескриптора?

 ECONNRESET означает, что по сети прилетел RST, что и написано текстом.
 Никакой связи с EAGAIN у него нет.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: HTTP/1.1 400 Bad Request при рестриме аудио потока

[Evgeniy Berdnikov]

On Mon, Mar 16, 2020 at 02:57:14PM +0300, Maxim Dounin wrote:
> В данном случае я бы скорее предположил, что 400 возвращает 
> бекенд.  В отладочном логе, это, безусловно, будет явно видно, но 

 В данном случае товарищ посылает plain http на 443-й порт, который,
 несомненно, сконфигурён как ssl, потому что curl на него ходит по https
 и без проблем забирает указанный radio-stream. A nginx при запросе
 plain http на ssl-ном порту возвращает "400 Bad Request" таким же
 plain http. Проверено на первом попавшемся под руку nginx-e.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: HTTP/1.1 400 Bad Request при рестриме аудио потока

[Evgeniy Berdnikov]

On Fri, Mar 13, 2020 at 03:42:03AM -0400, grey wrote:
> > Откуда вывод, что nginx якобы видит HEAD?
> 
> В логах nginx видно:
> 95.8.*.* - - [13/Mar/2020:10:24:59 +0300] "HEAD /radio-stream HTTP/1.1" 400
> 0 "-" "-"
> 
> При GET запросе:
> 95.8.*.* - - [13/Mar/2020:10:28:45 +0300] "GET /radio-stream HTTP/1.1" 200
> 146900 "-" "-"
> 
> Сам php-код, коим проверяю:
> 
> $ch = curl_init();
> curl_setopt($ch, CURLOPT_URL, "https://test.ru/radio-stream;);

 Достаточно. Расстрелять. :) Это не код приложения, а вызов посторонней
 программы, которая выполняет СВОЙ код (а не тот, который цитировался),
 и вообще делает обращение с СДРУГИМ url. То есть вообще всё другое,
 а результат доказывает, что nginx работает правильно.

> > И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен?
> 
> Да или я чего-то не понимаю?

 Ага. Из того, что curl работает и приводит к осмысленным записям в логе,
 следует, что plain http это совсем не то, чего ждёт nginx на этом порту.
 Подумайте над тем, что означает буква "s" в https://... :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: HTTP/1.1 400 Bad Request при рестриме аудио потока

[Evgeniy Berdnikov]

On Thu, Mar 12, 2020 at 12:54:31PM -0400, grey wrote:
> Dmytro Lavryk Wrote:
> ---
> > Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил
> > у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает
> > нормально со всеми нужными заголовками.
> 
> Да, действительно, дело в типе запроса, но понять не могу почему так
> происходит. Напишу тут код на php, я думаю программистам других языков он
> будет понятен:
> 
> $fp = fsockopen("test.ru", 443, $errno, $errstr, 30);
> $out = "GET /radio-stream HTTP/1.1\r\n";
> $out .= "Host: test.ru\r\n";
> $out .= "Connection: Close\r\n\r\n";
> fwrite($fp, $out);
> while (!feof($fp)) echo fgets($fp, 128);
> fclose($fp);
> 
> В нем я явно указываю тип запроса GET, а nginx почему говорит что к нему
> пришел HEAD

 Откуда вывод, что nginx якобы видит HEAD?

> и возвращает ответ "400 Bad Request".
> Проверил на разных версиях
> php - результат везде одинаковый, т.к. вроде как дело не в нем.

 И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: UDP Connection refused

[Evgeniy Berdnikov]

On Thu, Mar 12, 2020 at 02:32:23AM -0400, inkognito0609 wrote:
> При отправке логов через syslog (udp) проскакивают ошибки 111 Connection
> refused, что непонятно при отправке логов по udp, так как этот протокол не
> подразумевает установки соединения в принципе.

 Читайте man 7 udp. ECONNREFUSED может быть вызвана отображением
 на уровень сокетов ответов icmp[port-unreach], icmp[admin-prohib]
 на предыдущие пакеты от этого сокета, а также блокировкой исходящих udp
 локальным пакетным фильтром. Конкретика зависит от реализации
 (может отличаться для разных ОС). К nginx это отношения не имеет.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с перезапуском в centos 8

[Evgeniy Berdnikov]

On Fri, Feb 28, 2020 at 10:55:10PM -0500, windos321 wrote:
> исключено, все там было сделано правильно) я с этой проблемой вторые сутки
> воюю, конечно можно списать на усталость, но такие мелочи грех
> допускать..иначе войну не выиграть, а я надеюсь

 И что, за двое суток дёрганья всех ручек наугад не появилась идея провести
 хотя бы минимальную диагностику? Ввставить в скрипт запуска nginx команды
 по выводу состояния сети, хотя бы "networkctl -a status", дополнить
 пингом резолвера, etc.

 Я вот думаю что если два дня подряд палить из всех пушек в белый свет,
 но при этом не читать сводок с фронта, войну точно не выиграешь. :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: SSL Configuration Generator https://ssl-config.mozilla.org/

[Evgeniy Berdnikov]

On Wed, Jan 22, 2020 at 08:13:48PM +0300, Maxim Dounin wrote:
> On Wed, Jan 22, 2020 at 05:04:33AM +0200, Gena Makhomed wrote:
[...]
> > И наоборот, если в default_server задано ssl_protocols TLSv1.3;
> > то в других server`ах директива ssl_protocols TLSv1.2; не работает.
> > 
> > Это где ошибка - в документации на сайте или в коде nginx 1.17.8?
> 
> Возможность задания какой-либо директивы в контексте server - не 
> означает, что она будет применяться для всех запросов, попадающих 
> в этот блок server.  В случае виртуальных серверов - могут быть 
> нюансы.
[...]
> Подробнее можно почитать тут и по ссылкам:
> 
> https://trac.nginx.org/nginx/ticket/844
> 
> Соответственно отвечая на заданный вопрос: ошибка - в понимании 
> написанного в документации.

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

 Если в доке написано "context: server", то читатель понимает это
 буквально: для заданного server будет действовать указанная директива.
 И поскольку её задача ограничить перечень протоколов, то именно это,
 с точки зрения пользователя, и должно происходить. Потребителю
 не до того, чтобы вспоминать, что бывают name-based виртуалхосты,
 sni-based, ip-based, процессы, нити, пространства имён и прочая лабуда,
 ему не до проблем их сплетения в разных версиях. Потребитель ожидает,
 что ему дадут простой и удобный интерфейс, где все нюансы продуманы,
 а возможность ошибиться и получить не то, что ожидал -- сведена к
 минимуму. Если же интерфейс позволяет сделать бессмысленные или даже
 противоречивые комбинации параметров -- это плохой интерфейс, и его
 следует по возможности выправлять в рантайме, например, предупреждениями
 вида "извините, в этой конфигурации есть разные версии ssl_protocols
 на одном ip-шнике, это работать не будет, см. подробности в ".

 Ну и в документации капканы тоже желательно упоминать, разумеется.
 
 Вероятно, хотелось сделать интерфейс простым и универсальным, чтобы
 пользователю было легче его освоить. С одной директривой "server".
 Но если идти этим путём, то стыковку разных гаек и болтов по их профилю,
 метрикам и шагам резьбы следует прятать под капот, а потребителю выводить
 такой набор педалей и ручек, чтобы он мог решить задачу "ехать" без
 головной боли и гаданий, где же включился тормоз... IMHO.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Непонятки с binary_remote_addr

[Evgeniy Berdnikov]

On Wed, Dec 04, 2019 at 09:50:19AM +0300, CoDDoC wrote:
>В логе nginx все правильно: \xC0\xA8\x00\xC8 (мой IP 192.168.0.200)
> 
>В php:
> 
> 1. Конвертирую первый заголовок в bin, затем в hex. На выходе правильно:
>string(8) "c0a800c8"
> 2. Конвертирую второй заголовок в hex (т.к. он уже bin). На выходе:
>string(4) "c0a8"
> 
>Собственно, все. Тупняк. Ткните носом, плз, куда делась половина второго
>заголовка?

 Если конвертор думает, что у него на входе c-string (asciz), то естественно
 нулевой байт он считает концом строки. Возможно, обрезание делается на
 уровень выше, на выходе из php-шного парсера заголовка.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ошибка "upstream prematurely closed connection" - обсудим ?

[Evgeniy Berdnikov]

On Mon, Oct 14, 2019 at 11:59:44AM +0500, Илья Шипицин wrote:
>добавил отладку.
>в recv передается не ноль. из recv возвращается ноль.

 Значит процитированный фрагмент man recv и все домыслы вокруг него
 (насчёт специфики реализации в каком-то центосе) оказались мимо темы.

 Теперь самое время разобраться в обстоятельствах, при которых recv()
 возвращает ноль. Смотрите что высылает бэкенд, что прилетает по сети.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ошибка "upstream prematurely closed connection" - обсудим ?

[Evgeniy Berdnikov]

On Sun, Oct 13, 2019 at 02:18:30PM +0500, Илья Шипицин wrote:
>в одном месте - не завершается:
>http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369
>собственно, recv в некоторых случаях может выдавать 0 и это не всегда
>ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с
>какими-нибудь сетевыми штуками бекпортированными в ядро 3.10)
>man recv
>...
>"The value 0 may also be returned if the requested number of bytes to
>receive from a stream socket was 0."

 Насколько я разбираюсь в английском, "requested number of bytes" -- это
 значение аргумента len, т.е. ситуация, когда в recv() передают длину
 буфера равную нулю, т.е. из сокета запрашивается чтение нуля байт.
 Nginx действительно так делает?

>собственно, в этом месте меняем текст. и, чудо, после этого залогированные
>"upstream prematurely closed connection" идеально кореллируют с реальными
>обрывами.

 Что на что меняем? diff покажите.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx http_x_forwarded_for blocking ip

[Evgeniy Berdnikov]

On Thu, Sep 26, 2019 at 06:06:54AM -0400, classic85 wrote:
> всем привет
> 
> подкажите плиз
> нужно блокировать ip по заголовку: 
> http_x_forward_for":«10.13.2.14, 10.99.111.25:13555 
> нужно блокировать только если эти два ip вместе приходят 
> пробовал разные способы. все равно проходит
> 
> пример
> 
> if ($http_x_forward_for ~ " ?10\.13\.2\.14*") {
>   return 403;

 А такой заголовок вообще есть? Бывает X-Forwarded-For.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru