From mdounin на mdounin.ru Mon Apr 1 12:54:52 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 1 Apr 2019 15:54:52 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: References: Message-ID: <20190401125452.GQ1877@mdounin.ru> Hello! On Sun, Mar 31, 2019 at 09:10:15PM +0300, sergio wrote: > Вот тут > https://nginx.org/en/docs/http/ngx_http_ssl_module.html > написано: > > For the OCSP stapling to work, the certificate of the server certificate > issuer should be known. If the ssl_certificate file does not contain > intermediate certificates, the certificate of the server certificate > issuer should be present in the ssl_trusted_certificate file. > > For a resolution of the OCSP responder hostname, the resolver directive > should also be specified. > > И ещё: > > For verification to work, the certificate of the server certificate > issuer, the root certificate, and all intermediate certificates should > be configured as trusted using the ssl_trusted_certificate directive. > > По-этому я взял и сделал всё ровно наоборот: не стал указывать ни > resolver ни ssl_trusted_certificate. Включил только лишь: > ssl_stapling on; > ssl_stapling_verify on; > И мои сертификаты не содержат цепочки доверия, только лишь сам сертификат. > > 1. Почему ocsp работает и это не отражено в документации? > (я вижу OCSP Response Data в openssl s_client -connect hostname:443 > -tls1_2 -tlsextdebug -status) Если issuer'а нет ни в цепочке сертификатов в ssl_certificate, ни в доверенных сертификатах ssl_trusted_certificate (либо ssl_client_certificate, см. описания соответствующих директив), то OCSP stapling будет работать только при явном задании OCSP-ответа с помощью директивы ssl_stapling_file. Если же директива ssl_stapling_file не используется, и issuer certificate найти не получилось - на старте nginx ругнётся в лог на уровне warn словами "issuer certificate not found" и отключит stapling. > 2. Как вычисляются значения resolver и ssl_trusted_certificate, когда > они не указаны? Никак, с точностью до того, что если соответствующие директивы таки указаны на предыдущих уровнях - то будут, естветственно, использоватся значения, заданные на предыдущих уровнях. В случае, если resolver не указан, и при этом включён OCSP stapling - nginx будет пытаться использовать IP-адреса OCSP-сервера, полученные при старте, при каждом обращении к OCSP-серверу ругаясь в логи про "no resolver defined to resolve ..." на уровне warn. -- Maxim Dounin http://mdounin.ru/ From sergio на outerface.net Mon Apr 1 13:29:34 2019 From: sergio на outerface.net (sergio) Date: Mon, 1 Apr 2019 16:29:34 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <20190401125452.GQ1877@mdounin.ru> References: <20190401125452.GQ1877@mdounin.ru> Message-ID: <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> On 01/04/2019 15:54, Maxim Dounin wrote: > Если issuer'а нет ни в цепочке сертификатов в ssl_certificate Прошу прощения, нагло наврал. issuer есть в ssl_certificate, мне его туда незаметно подсовывают оказывается. > В случае, если resolver не указан, и при этом включён OCSP > stapling - nginx будет пытаться использовать IP-адреса > OCSP-сервера, полученные при старте, > при каждом обращении к OCSP-серверу ругаясь в логи про "no > resolver defined to resolve ..." на уровне warn. Проверил всё ещё раз. "no resolver defined to resolve" в логах нет. (Сами логи есть.) -- sergio. From mdounin на mdounin.ru Mon Apr 1 14:44:21 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 1 Apr 2019 17:44:21 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> References: <20190401125452.GQ1877@mdounin.ru> <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> Message-ID: <20190401144421.GR1877@mdounin.ru> Hello! On Mon, Apr 01, 2019 at 04:29:34PM +0300, sergio wrote: > On 01/04/2019 15:54, Maxim Dounin wrote: > > > В случае, если resolver не указан, и при этом включён OCSP > > stapling - nginx будет пытаться использовать IP-адреса > > OCSP-сервера, полученные при старте, > > при каждом обращении к OCSP-серверу ругаясь в логи про "no > > resolver defined to resolve ..." на уровне warn. > > Проверил всё ещё раз. "no resolver defined to resolve" в логах нет. > (Сами логи есть.) Ну тут вариантов множество - либо resolver таки defined, либо обращений к OCSP-серверу нет, либо логов нужного уровня нет, либо вы неправильно в них смотрите. -- Maxim Dounin http://mdounin.ru/ From sergio на outerface.net Mon Apr 1 15:15:41 2019 From: sergio на outerface.net (sergio) Date: Mon, 1 Apr 2019 18:15:41 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <20190401144421.GR1877@mdounin.ru> References: <20190401125452.GQ1877@mdounin.ru> <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> <20190401144421.GR1877@mdounin.ru> Message-ID: <7a92467b-bb54-3171-58a1-583431bf2650@outerface.net> On 01/04/2019 17:44, Maxim Dounin wrote: > либо обращений к OCSP-серверу нет обращения есть, я их вижу в query.log бинда, при старте энджинкса > либо resolver таки defined вне зависимости от того, закомментирована ли строчка "resolver localhost;" в conf.d/ssl.conf или нет > либо логов нужного уровня нет, либо вы неправильно в них смотрите логи есть, смотрю их правильно Судя про тому, что при отсутствии resolver используется localhost а не IP OCSP, видимо есть какая-то умолчательная логика? -- sergio. From mdounin на mdounin.ru Mon Apr 1 16:22:05 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 1 Apr 2019 19:22:05 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <7a92467b-bb54-3171-58a1-583431bf2650@outerface.net> References: <20190401125452.GQ1877@mdounin.ru> <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> <20190401144421.GR1877@mdounin.ru> <7a92467b-bb54-3171-58a1-583431bf2650@outerface.net> Message-ID: <20190401162205.GS1877@mdounin.ru> Hello! On Mon, Apr 01, 2019 at 06:15:41PM +0300, sergio wrote: > On 01/04/2019 17:44, Maxim Dounin wrote: > > > либо обращений к OCSP-серверу нет > > обращения есть, я их вижу в query.log бинда, при старте энджинкса В query.log бинда невозможно увидеть обращения к OCSP-серверу. Максимум, что там можно увидеть - это резолвинг имени OCSP-сервера. На старте, как я уже писал, делается резолвинг имени с использованием системного резолвера. В процессе работы - при обращениях к OCSP-серверу резолвинг его имени делается с использованием DNS-сервера, заданного директивой resolver. > > либо resolver таки defined > > вне зависимости от того, закомментирована ли строчка > "resolver localhost;" в conf.d/ssl.conf или нет > > > > либо логов нужного уровня нет, либо вы неправильно в них смотрите > > логи есть, смотрю их правильно Давайте пойдём простым путём. Покажите вывод "nginx -V", "nginx -T" и debug log с обращением к OCSP-серверу. Подробнее о том, как получить debug log, тут: http://nginx.org/en/docs/debugging_log.html Отмечу на всякий случай, что обращение к OCSP-серверу в норме происходит в момент первого SSL handshake'а с расширением status_request, то есть при первом соединении через openssl s_client -connect :443 -status | grep OCSP и OCSP-ответа в этом соединении не будет. Если OCSP-ответ есть - значит, соединение не первое, и соответственно обращение к OCSP-серверу было раньше. > Судя про тому, что при отсутствии resolver используется localhost а не > IP OCSP, видимо есть какая-то умолчательная логика? Нет. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Apr 3 12:08:04 2019 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Wed, 03 Apr 2019 08:08:04 -0400 Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCIGxvY2F0aW9uINC40LvQuCDRjyDRh9GC0L4t?= =?UTF-8?B?0YLQviDQtNC10LvQsNGOINC90LUg0YLQsNC6Pw==?= Message-ID: <26c69f12b4ef62f4acd1e51f78dc6d68.NginxMailingListRussian@forum.nginx.org> Выдержки из конфига: location = /robots.txt { add_header X-uri "robots"; allow all; } location = "/someuri" { add_header X-uri "someuri"; try_files $uri =403; } Проверяем: # curl -v https://mydomain.com/robots.txt < HTTP/2 200 < server: nginx < date: Wed, 03 Apr 2019 12:03:41 GMT < content-type: text/plain; charset=utf-8 < content-length: 444 < last-modified: Sun, 10 Mar 2019 12:35:47 GMT < vary: Accept-Encoding < etag: "5c8504a3-1bc" < x-uri: robots < accept-ranges: bytes # curl -v https://lekos.com.ua/someuri < HTTP/2 404 < server: nginx < date: Wed, 03 Apr 2019 12:05:30 GMT < content-type: text/html; charset=utf-8 < content-length: 162 < Что я делаю не так??? Вообще это все как тест, проблема была в том, что не уходит в именованый локейшин location = "/someuri" { try_files $uri @back; } Для чистоты эксперимента и НЕ пересечения с другими локейшенами /someuri так и есть в конфиге. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283594,283594#msg-283594 From nginx-forum на forum.nginx.org Wed Apr 3 12:22:46 2019 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Wed, 03 Apr 2019 08:22:46 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBsb2NhdGlvbiDQuNC70Lgg0Y8g0Yc=?= =?UTF-8?B?0YLQvi3RgtC+INC00LXQu9Cw0Y4g0L3QtSDRgtCw0Lo/?= In-Reply-To: <26c69f12b4ef62f4acd1e51f78dc6d68.NginxMailingListRussian@forum.nginx.org> References: <26c69f12b4ef62f4acd1e51f78dc6d68.NginxMailingListRussian@forum.nginx.org> Message-ID: Dmytro Lavryk Wrote: ------------------------------------------------------- > Выдержки из конфига: Сам сразу и разобрался. Вдруг кому пригодится: Выше по конфигу были прописаны error_page на статические файлы, которых (файлов) не было. Потому все ошибки в итоге выдавались как 404 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283594,283595#msg-283595 From kpoxa на kpoxa.net Thu Apr 4 09:42:24 2019 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 4 Apr 2019 12:42:24 +0300 Subject: nginx-1.15.10 In-Reply-To: <20190326142559.GG1877@mdounin.ru> References: <20190326142559.GG1877@mdounin.ru> Message-ID: Добрый день. В документации не нашел про > *) Добавление: диапазоны портов в директиве listen Можно пример использования? вт, 26 мар. 2019 г. в 17:26, Maxim Dounin : > Изменения в nginx 1.15.10 > 26.03.2019 > > *) Изменение: теперь при использовании имени хоста в директиве listen > nginx создаёт listen-сокеты для всех адресов, соответствующих этому > имени (ранее использовался только первый адрес). > > *) Добавление: диапазоны портов в директиве listen. > > *) Добавление: возможность загрузки SSL-сертификатов и секретных ключей > из переменных. > > *) Изменение: переменная $ssl_server_name могла быть пустой при > использовании OpenSSL 1.1.1. > > *) Исправление: nginx/Windows не собирался с Visual Studio 2015 и > новее; > ошибка появилась в 1.15.9. > > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim на nginx.com Thu Apr 4 09:45:56 2019 From: maxim на nginx.com (Maxim Konovalov) Date: Thu, 4 Apr 2019 12:45:56 +0300 Subject: nginx-1.15.10 In-Reply-To: References: <20190326142559.GG1877@mdounin.ru> Message-ID: On 04/04/2019 12:42, kpoxa wrote: > Добрый день. > > В документации не нашел про >>   *) Добавление: диапазоны портов в директиве listen > Можно пример использования? > http://nginx.org/en/docs/stream/ngx_stream_core_module.html#listen -- Maxim Konovalov From kpoxa на kpoxa.net Thu Apr 4 10:47:34 2019 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 4 Apr 2019 13:47:34 +0300 Subject: nginx-1.15.10 In-Reply-To: References: <20190326142559.GG1877@mdounin.ru> Message-ID: Добрый день. Здорово, работает. При задании 10 000 портов ругается, несмотря на выставление большого числа открытых файлов #sysctl fs.file-max fs.file-max = 999999 nginx.conf ... worker_rlimit_nofile 1000000; … http{ server{ listen 10000-11010; } } error.log 2019/04/04 13:36:00 [emerg] 1243#1243: socket() 0.0.0.0:11016 failed (24: Too many open files) -- Рустам чт, 4 апр. 2019 г. в 12:45, Maxim Konovalov : > On 04/04/2019 12:42, kpoxa wrote: > > Добрый день. > > > > В документации не нашел про > >> *) Добавление: диапазоны портов в директиве listen > > Можно пример использования? > > > http://nginx.org/en/docs/stream/ngx_stream_core_module.html#listen > > -- > Maxim Konovalov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpoxa на kpoxa.net Thu Apr 4 10:55:17 2019 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 4 Apr 2019 13:55:17 +0300 Subject: proxy_bind ipv6 Message-ID: Добрый день. При использовании proxy_bind 2a04:40:1000:8::3; Получаю ошибку 500 со следующим текстом в логе: 2019/04/04 13:50:37 [crit] 1780#1780: *1 bind(2a04:40:1000:8::3) failed (97: Address family not supported by protocol) while connecting to upstream, client: 18.5.7.10, server: localhost , request: "GET / HTTP/1.1", upstream: "https://server:443/", host: " 178.218.213.241:443" В proxy_bind не поддерживается ipv6 ? -- Рустам -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Thu Apr 4 12:19:04 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 4 Apr 2019 17:19:04 +0500 Subject: nginx-1.15.10 In-Reply-To: References: <20190326142559.GG1877@mdounin.ru> Message-ID: worker_rlimit_nofile - это для воркеров порты биндит мастер предлагаю такой вариант (если у вас линукс) зайдите в /proc/ - посмотрите limits, что там ? попасть туда может из кучи разных мест, например, из systemd чт, 4 апр. 2019 г. в 15:47, kpoxa : > Добрый день. > > Здорово, работает. > > При задании 10 000 портов ругается, несмотря на выставление большого числа > открытых файлов > > #sysctl fs.file-max > fs.file-max = 999999 > > nginx.conf > ... > worker_rlimit_nofile 1000000; > … > http{ > server{ > listen 10000-11010; > } > } > > error.log > 2019/04/04 13:36:00 [emerg] 1243#1243: socket() 0.0.0.0:11016 failed (24: > Too many open files) > > -- > Рустам > > > > чт, 4 апр. 2019 г. в 12:45, Maxim Konovalov : > >> On 04/04/2019 12:42, kpoxa wrote: >> > Добрый день. >> > >> > В документации не нашел про >> >> *) Добавление: диапазоны портов в директиве listen >> > Можно пример использования? >> > >> http://nginx.org/en/docs/stream/ngx_stream_core_module.html#listen >> >> -- >> Maxim Konovalov >> > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Thu Apr 4 12:33:44 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 4 Apr 2019 15:33:44 +0300 Subject: proxy_bind ipv6 In-Reply-To: References: Message-ID: <5A31CE05-0178-4F52-9A01-A8C8A504FFE6@nginx.com> > On 4 Apr 2019, at 13:55, kpoxa wrote: > > Добрый день. > > При использовании > > proxy_bind 2a04:40:1000:8::3; > > Получаю ошибку 500 со следующим текстом в логе: > > 2019/04/04 13:50:37 [crit] 1780#1780: *1 bind(2a04:40:1000:8::3) failed (97: Address family not supported by protocol) while connecting to upstream, client: 18.5.7.10, server: localhost > , request: "GET / HTTP/1.1", upstream: "https://server:443/", host: "178.218.213.241:443" > > В proxy_bind не поддерживается ipv6 ? > Такая ошибка будет, если имя server порезолвилось в адрес, отличный от ipv6. -- Sergey Kandaurov From mdounin на mdounin.ru Thu Apr 4 12:40:50 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 4 Apr 2019 15:40:50 +0300 Subject: proxy_bind ipv6 In-Reply-To: References: Message-ID: <20190404124050.GB1877@mdounin.ru> Hello! On Thu, Apr 04, 2019 at 01:55:17PM +0300, kpoxa wrote: > Добрый день. > > При использовании > > proxy_bind 2a04:40:1000:8::3; > > Получаю ошибку 500 со следующим текстом в логе: > > 2019/04/04 13:50:37 [crit] 1780#1780: *1 bind(2a04:40:1000:8::3) failed > (97: Address family not supported by protocol) while connecting to > upstream, client: 18.5.7.10, server: localhost > , request: "GET / HTTP/1.1", upstream: "https://server:443/", host: " > 178.218.213.241:443" > > В proxy_bind не поддерживается ipv6 ? Поддерживается. Но если вы пытаетесь идти на IPv4-бэкенд, то счастья не будет. Ну отдельно отмечу, что если бы вы не отредактировали 'upstream: "https://server:443/"' в приведённой строке лога - проблема была бы очевидна. Не надо так. -- Maxim Dounin http://mdounin.ru/ From kpoxa на kpoxa.net Thu Apr 4 13:10:53 2019 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 4 Apr 2019 16:10:53 +0300 Subject: proxy_bind ipv6 In-Reply-To: <20190404124050.GB1877@mdounin.ru> References: <20190404124050.GB1877@mdounin.ru> Message-ID: Добрый день. Действительно там ipv4 адрес, в значении upstream, ошибку понял. Можно ли как-то резолверу сказать, что надо работать только с ipv6 ? У доменов, которые используются, есть и то у другое, а резолвер выдаёт только ipv4. чт, 4 апр. 2019 г. в 15:41, Maxim Dounin : > Hello! > > On Thu, Apr 04, 2019 at 01:55:17PM +0300, kpoxa wrote: > > > Добрый день. > > > > При использовании > > > > proxy_bind 2a04:40:1000:8::3; > > > > Получаю ошибку 500 со следующим текстом в логе: > > > > 2019/04/04 13:50:37 [crit] 1780#1780: *1 bind(2a04:40:1000:8::3) failed > > (97: Address family not supported by protocol) while connecting to > > upstream, client: 18.5.7.10, server: localhost > > , request: "GET / HTTP/1.1", upstream: "https://server:443/", host: " > > 178.218.213.241:443" > > > > В proxy_bind не поддерживается ipv6 ? > > Поддерживается. Но если вы пытаетесь идти на IPv4-бэкенд, то > счастья не будет. > > Ну отдельно отмечу, что если бы вы не отредактировали 'upstream: > "https://server:443/"' в приведённой строке лога - проблема была > бы очевидна. Не надо так. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Thu Apr 4 14:27:20 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 4 Apr 2019 17:27:20 +0300 Subject: proxy_bind ipv6 In-Reply-To: References: <20190404124050.GB1877@mdounin.ru> Message-ID: <20190404142720.GE1877@mdounin.ru> Hello! On Thu, Apr 04, 2019 at 04:10:53PM +0300, kpoxa wrote: > Действительно там ipv4 адрес, в значении upstream, ошибку понял. > Можно ли как-то резолверу сказать, что надо работать только с ipv6 ? > У доменов, которые используются, есть и то у другое, а резолвер выдаёт > только ipv4. Нет, сейчас resolver умеет возвращать либо IPv4 + IPv6 (что в случае proxy_pass с переменными означает преимущественное использование IPv4, так как IPv4-адрес будет возвращён первым), либо только IPv4 ("resolver ... ipv6=off"). Соответственно если хочется использовать именно IPv6, то на текущий единственное решение - использовать имена, которые резолвятся только в IPv6 (ну или фильтровать где-то на DNS-сервере). -- Maxim Dounin http://mdounin.ru/ From identw на gmail.com Thu Apr 4 17:36:33 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Thu, 4 Apr 2019 22:36:33 +0500 Subject: =?UTF-8?B?0JrQvtC70LjRh9C10YHRgtCy0L4g0LrQu9C40LXQvdGB0YLQutC40YUg0L7RiNC4?= =?UTF-8?B?0LHQvtC6INCy0YvRgNC+0YHQu9C+INC/0L7RgdC70LUg0L7QsdC90L7QstC7?= =?UTF-8?B?0LXQvdC40Y8g0LTQviDQvdC+0LLQvtC5IG5naW54KDEuMTQuMikgYyDQvdC+?= =?UTF-8?B?0LLRi9C8IG9wZW5zc2wgKDEuMC4yZyk=?= Message-ID: Добрый день. ОС: Ubuntu 16.04 Nginx версия с которой проблемы: nginx version: nginx/1.14.2 built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) built with OpenSSL 1.0.2g  1 Mar 2016 TLS SNI support enabled Обновились до последней стабильной сборки nginx. Количество ошибок 4xx значительно повышается: А именно 499 в два раза, 400 в 20 раз, 408 в 14 раз, в целом всего 4xx ошибок становится в 3-4 раза больше. Раннее мы работали на nginx 1.12.1 собственной сборки с openssl 1.0.1u, когда-то я собирали эту версию по тем же причинам (сборка nginx 1.12.1 из репозитория себя вела точно также - куча ошибок). Поэтому сейчас снова пришлось собрать уже новую версию nginx (1.14.2) но со старым openssl 1.0.1u. Привожу скрин для наглядности: http://joxi.net/n2YQdVZSbozM02.jpg Здесь статистка по ошибкам из двух одинаковых серверов за 30 минутный интервал времени. Где lb21 имеет nginx 1.14.2 + openssl 1.0.1u, а lb21-2 nginx 1.14.2 + openssl 1.0.2g Вот так выглядет процесс отката до nginx 1.14.2 + openssl 1.0.1u c точки зрения количества ошибок: http://joxi.net/EA4RKZXHowQDQm.jpg (здесь каждый столбик это количество за минуту). Конфигурации одинаковые, количество трафика одинаковое. Пробовал менять местами версии nginx между этими серверами, сразу видно как начинает расти количество ошибок на том сервере где используется nginx 1.14.2 + openssl 1.0.2g. Тенденция роста количества 499, 400, 408 ошибок видна моментально после обновления версии. Пробовал разные версии openssl (ветки 1.0.2, 1.1.1). Все что выше 1.0.1u дает такой результат.  Пробовал отключать/включать http2 никак не влияет. Конфиугация ssl в nginx стоит по умолчанию (то есть только указаны диррективы ssl_certificate, ssl_certificate_key). Вроде все уже давно юзают и http2 и новую ssl и не жалуются, а я каждые два года собираю nginx со старой ssl и не понимаю в чем может быть дело =(. Может у кого-то похожие проблемы? -- Kind regards Dmitry Sergeev From mdounin на mdounin.ru Fri Apr 5 15:36:45 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 5 Apr 2019 18:36:45 +0300 Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INC60LvQuNC10L3RgdGC0LrQuNGFINC+?= =?UTF-8?B?0YjQuNCx0L7QuiDQstGL0YDQvtGB0LvQviDQv9C+0YHQu9C1INC+0LHQvdC+?= =?UTF-8?B?0LLQu9C10L3QuNGPINC00L4g0L3QvtCy0L7QuSBuZ2lueCgxLjE0LjIpIGMg?= =?UTF-8?B?0L3QvtCy0YvQvCBvcGVuc3NsICgxLjAuMmcp?= In-Reply-To: References: Message-ID: <20190405153645.GJ1877@mdounin.ru> Hello! On Thu, Apr 04, 2019 at 10:36:33PM +0500, Dmitry Sergeev wrote: > Добрый день. > ОС: Ubuntu 16.04 > > Nginx версия с которой проблемы: > nginx version: nginx/1.14.2 > built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) > built with OpenSSL 1.0.2g  1 Mar 2016 > TLS SNI support enabled > > Обновились до последней стабильной сборки nginx. Количество ошибок 4xx > значительно повышается: А именно 499 в два раза, 400 в 20 раз, 408 в 14 > раз, в целом всего 4xx ошибок становится в 3-4 раза больше. > > Раннее мы работали на nginx 1.12.1 собственной сборки с openssl 1.0.1u, > когда-то я собирали эту версию по тем же причинам (сборка nginx 1.12.1 > из репозитория себя вела точно также - куча ошибок). > > Поэтому сейчас снова пришлось собрать уже новую версию nginx (1.14.2) но > со старым openssl 1.0.1u. > > Привожу скрин для наглядности: http://joxi.net/n2YQdVZSbozM02.jpg > Здесь статистка по ошибкам из двух одинаковых серверов за 30 минутный > интервал времени. > Где lb21 имеет nginx 1.14.2 + openssl 1.0.1u, а lb21-2 nginx 1.14.2 + > openssl 1.0.2g > > Вот так выглядет процесс отката до nginx 1.14.2 + openssl 1.0.1u c точки > зрения количества ошибок: http://joxi.net/EA4RKZXHowQDQm.jpg (здесь > каждый столбик это количество за минуту). Количество ошибок на уровне HTTP - может быть нерелевантно происходящему, и, скажем, означать, что больше проблемных клиентов теперь могут пройти через SSL handshake. Ну и смотреть надо не на абсолютные цифры, а на проценты от трафика. Если речь про доли процента - наблюдаемое изменение может быть следствием того, что проблемы возникают у каких-либо малораспространённых клинтов, и совершенно не факт, что на это надо обращать внимание. Например, из OpenSSL 1.0.2 могли убрать какие-то workaround'ы для ошибочного поведения, или же из-за изменения списка шифров теперь используются другие шифры, которые, наоборот, вызывают проблемы в этих клиентах. Если же хочется таки разобраться - то имеет смысл смотреть подробную информацию по ошибкам, в частности - что при этом пишет nginx в логи (если есть подробности - они скорее всего на уровне info), и что известно про этих клиентов - User-Agent, используемые протоколы, шифры и так далее. > Конфигурации одинаковые, количество трафика одинаковое. Пробовал менять > местами версии nginx между этими серверами, сразу видно как начинает > расти количество ошибок на том сервере где используется nginx 1.14.2 + > openssl 1.0.2g. Тенденция роста количества 499, 400, 408 ошибок видна > моментально после обновления версии. > > Пробовал разные версии openssl (ветки 1.0.2, 1.1.1). Все что выше 1.0.1u > дает такой результат.  Пробовал отключать/включать http2 никак не влияет. В первую очередь - в OpenSSL 1.0.1 нет ALPN, то есть HTTP/2 в современных браузерах работать не будет. Если в конфиге включён HTTP/2 - переход на OpenSSL 1.0.2 будет сильным изменением поведения в любом случае. Так что имеет смысл HTTP/2 выключить и сравнивать строго без HTTP/2. Важно при этом выключить везде, потому как http2 - это опция сокета, и если она останется в любом из блоков server, то HTTP/2 продолжит работать. > Конфиугация ssl в nginx стоит по умолчанию (то есть только указаны > диррективы ssl_certificate, ssl_certificate_key). Если вдруг используются множественные сертификаты в одном блоке server - переход с OpenSSL 1.0.1 на 1.0.2 потребует изменения цепочек в ssl_certificate, т.к. в случае OpenSSL 1.0.1 цепочка только одна и общаяя для всех сертификатов, а в случае 1.0.2 - у каждого сертификата своя. В остальном я каких-либо особенных проблем с OpenSSL 1.0.2 не помню, в целом хорошая ветка. -- Maxim Dounin http://mdounin.ru/ From swood на fotofor.biz Sat Apr 6 09:54:41 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sat, 6 Apr 2019 10:54:41 +0100 Subject: =?UTF-8?B?0KHRgtCw0YLQuNGH0LXRgdC60LDRjyDRgdCx0L7RgNC60LAgbmdpbngg0YEgR0Q=?= Message-ID: Здравствуйте. Подскажите, пожалуйста, почему nginx в данном случае никак не может собраться статически с libgd: ---------- cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd ---------- ---------------------------------------- checking for GD library in /opt/local/ /opt/local/lib/libgd.a(gd.o): In function `lsqrt': /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' collect2: error: ld returned 1 exit status ---------- Сам libgd собран в /opt/local с флагом static. К сожалению, мне действительно нужна статическая сборка. Остается страдать и все же так не делать или есть способ что-то тут сделать? -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor на sysoev.ru Sat Apr 6 10:06:07 2019 From: igor на sysoev.ru (Igor Sysoev) Date: Sat, 6 Apr 2019 13:06:07 +0300 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: References: Message-ID: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > Здравствуйте. > > Подскажите, пожалуйста, почему nginx в данном случае никак не может собраться статически с libgd: > > ---------- > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd > ---------- > > ---------------------------------------- > checking for GD library in /opt/local/ > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > collect2: error: ld returned 1 exit status > ---------- > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне действительно нужна статическая сборка. Остается страдать и все же так не делать или есть способ что-то тут сделать? Нужно добавить "-lm" в --with-ld-opt -- Igor Sysoev http://nginx.com From swood на fotofor.biz Sat Apr 6 11:07:44 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sat, 6 Apr 2019 12:07:44 +0100 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> Message-ID: Добавил и не помогло. сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > Здравствуйте. > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может > собраться статически с libgd: > > > > ---------- > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib > -lgd > > ---------- > > > > ---------------------------------------- > > checking for GD library in /opt/local/ > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > collect2: error: ld returned 1 exit status > > ---------- > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне > действительно нужна статическая сборка. Остается страдать и все же так не > делать или есть способ что-то тут сделать? > > Нужно добавить "-lm" в --with-ld-opt > > > -- > Igor Sysoev > http://nginx.com > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor на sysoev.ru Sat Apr 6 11:14:07 2019 From: igor на sysoev.ru (Igor Sysoev) Date: Sat, 6 Apr 2019 14:14:07 +0300 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> Message-ID: А что в autoconf.err ? -- Igor Sysoev http://nginx.com > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: > > Добавил и не помогло. > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > Здравствуйте. > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может собраться статически с libgd: > > > > ---------- > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd > > ---------- > > > > ---------------------------------------- > > checking for GD library in /opt/local/ > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > collect2: error: ld returned 1 exit status > > ---------- > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне действительно нужна статическая сборка. Остается страдать и все же так не делать или есть способ что-то тут сделать? > > Нужно добавить "-lm" в --with-ld-opt > > > -- > Igor Sysoev > http://nginx.com > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Best regards, > Anton Kiryushkin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From swood на fotofor.biz Sat Apr 6 11:57:40 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sat, 6 Apr 2019 12:57:40 +0100 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> Message-ID: Ситуация очень напоминает предыдущую: cc -static -static-libgcc -lm -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib -lgd ---------- ---------------------------------------- checking for GD library in /opt/local/ /opt/local/lib/libgd.a(gd.o): In function `lsqrt': /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' collect2: error: ld returned 1 exit status ---------- Версия nginx 1.15.10. gcc version 4.8.2. сб, 6 апр. 2019 г. в 12:14, Igor Sysoev : > А что в autoconf.err ? > > -- > Igor Sysoev > http://nginx.com > > > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: > > > > Добавил и не помогло. > > > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > > > Здравствуйте. > > > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может > собраться статически с libgd: > > > > > > ---------- > > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib > -lgd > > > ---------- > > > > > > ---------------------------------------- > > > checking for GD library in /opt/local/ > > > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > > collect2: error: ld returned 1 exit status > > > ---------- > > > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне > действительно нужна статическая сборка. Остается страдать и все же так не > делать или есть способ что-то тут сделать? > > > > Нужно добавить "-lm" в --with-ld-opt > > > > > > -- > > Igor Sysoev > > http://nginx.com > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > -- > > Best regards, > > Anton Kiryushkin > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From swood на fotofor.biz Sat Apr 6 12:21:06 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sat, 6 Apr 2019 13:21:06 +0100 Subject: nginx: [emerg] getpwnam("www-data") failed Message-ID: При обновлении на 1.15.10 поймал такую картину. В конфиге полжизни было написано: user www-data; Пользователь есть, группа есть. Все ищется по /etc/passwd и /etc/group. Что поменялось в nginx? -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dado на korolev-net.ru Sat Apr 6 16:37:33 2019 From: dado на korolev-net.ru (Evgenii Davidov) Date: Sat, 6 Apr 2019 19:37:33 +0300 Subject: https cpu load Message-ID: <20190406163733.GY9051@korolev-net.ru> добрый день переключили сайт на https, когда меньше тысячи соединией работает, когда уже тысяч 5 то загрузка cpu у nginx 100% 8 ядер 2.53GHz worker_processes 8 ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; подскажите пожалуйста: есть какие-то наблюдения какое нужно железо чтобы обслуживать скажем 10000 соединений? или надо распараллеливать на несколько серверов? спасибо -- Evgenii V Davidov From chipitsine на gmail.com Sat Apr 6 18:11:19 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 6 Apr 2019 23:11:19 +0500 Subject: https cpu load In-Reply-To: <20190406163733.GY9051@korolev-net.ru> References: <20190406163733.GY9051@korolev-net.ru> Message-ID: привет. предлагаю начать с http://nginx.org/ru/docs/ngx_google_perftools_module.html позволяет увидеть, действительно ли дело в https насчет https (если окажется, что дело в нем), есть пространство для оптимизации - установить ECDSA сертификат (если еще не установили), это может в 4 раза снизить нагрузку. также можно поменять порядок шифрсьютов, например, GCM и chacha могут в разы меньше тратить процессора. 10000 установленных соединений или 10000 новых соединений в секунду ? сб, 6 апр. 2019 г. в 21:37, Evgenii Davidov : > > добрый день > > переключили сайт на https, когда меньше тысячи соединией работает, когда > уже тысяч 5 то загрузка cpu у nginx 100% > > 8 ядер 2.53GHz > > worker_processes 8 > > ssl_session_cache shared:SSL:10m; > ssl_session_timeout 10m; > > подскажите пожалуйста: есть какие-то наблюдения какое нужно железо чтобы > обслуживать скажем 10000 соединений? > или надо распараллеливать на несколько серверов? > > спасибо > > -- > Evgenii V Davidov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From igor на sysoev.ru Sat Apr 6 18:22:09 2019 From: igor на sysoev.ru (Igor Sysoev) Date: Sat, 6 Apr 2019 21:22:09 +0300 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> Message-ID: <797CFF3B-9E2B-49F1-B729-0D399562D6DA@sysoev.ru> А статическая libm.a есть? Можно попробовать поставить -lm до -static: --with-ld-opt="-lm -static ... -- Igor Sysoev http://nginx.com > On 6 Apr 2019, at 14:57, Anton Kiryushkin wrote: > > Ситуация очень напоминает предыдущую: > > cc -static -static-libgcc -lm -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib -lgd > ---------- > > ---------------------------------------- > checking for GD library in /opt/local/ > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > collect2: error: ld returned 1 exit status > ---------- > > Версия nginx 1.15.10. gcc version 4.8.2. > > сб, 6 апр. 2019 г. в 12:14, Igor Sysoev : > А что в autoconf.err ? > > -- > Igor Sysoev > http://nginx.com > > > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: > > > > Добавил и не помогло. > > > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > > > Здравствуйте. > > > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может собраться статически с libgd: > > > > > > ---------- > > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd > > > ---------- > > > > > > ---------------------------------------- > > > checking for GD library in /opt/local/ > > > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > > collect2: error: ld returned 1 exit status > > > ---------- > > > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне действительно нужна статическая сборка. Остается страдать и все же так не делать или есть способ что-то тут сделать? > > > > Нужно добавить "-lm" в --with-ld-opt > > > > > > -- > > Igor Sysoev > > http://nginx.com > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > -- > > Best regards, > > Anton Kiryushkin > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Best regards, > Anton Kiryushkin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From dado на korolev-net.ru Sat Apr 6 18:40:15 2019 From: dado на korolev-net.ru (Evgenii Davidov) Date: Sat, 6 Apr 2019 21:40:15 +0300 Subject: https cpu load In-Reply-To: References: <20190406163733.GY9051@korolev-net.ru> Message-ID: <20190406184015.GA77204@korolev-net.ru> Здравствуйте, On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > 10000 установленных соединений или 10000 новых соединений в секунду ? спасибо, установленных) > > сб, 6 апр. 2019 г. в 21:37, Evgenii Davidov : > > > > > добрый день > > > > переключили сайт на https, когда меньше тысячи соединией работает, когда > > уже тысяч 5 то загрузка cpu у nginx 100% > > > > 8 ядер 2.53GHz > > > > worker_processes 8 > > > > ssl_session_cache shared:SSL:10m; > > ssl_session_timeout 10m; > > > > подскажите пожалуйста: есть какие-то наблюдения какое нужно железо чтобы > > обслуживать скажем 10000 соединений? > > или надо распараллеливать на несколько серверов? > > > > спасибо > > > > -- > > Evgenii V Davidov > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Evgenii V Davidov From chipitsine на gmail.com Sat Apr 6 19:14:51 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 7 Apr 2019 00:14:51 +0500 Subject: https cpu load In-Reply-To: <20190406184015.GA77204@korolev-net.ru> References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> Message-ID: сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > Здравствуйте, > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > 10000 установленных соединений или 10000 новых соединений в секунду ? > > спасибо, установленных) > 200000 установленных на 1 сервер обрабатываем > > > > > сб, 6 апр. 2019 г. в 21:37, Evgenii Davidov : > > > > > > > > добрый день > > > > > > переключили сайт на https, когда меньше тысячи соединией работает, > когда > > > уже тысяч 5 то загрузка cpu у nginx 100% > > > > > > 8 ядер 2.53GHz > > > > > > worker_processes 8 > > > > > > ssl_session_cache shared:SSL:10m; > > > ssl_session_timeout 10m; > > > > > > подскажите пожалуйста: есть какие-то наблюдения какое нужно железо > чтобы > > > обслуживать скажем 10000 соединений? > > > или надо распараллеливать на несколько серверов? > > > > > > спасибо > > > > > > -- > > > Evgenii V Davidov > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > Evgenii V Davidov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Sat Apr 6 20:17:27 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sat, 6 Apr 2019 23:17:27 +0300 Subject: https cpu load In-Reply-To: References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> Message-ID: <20190406201727.GZ2161@zxy.spb.ru> On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > Здравствуйте, > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > 10000 установленных соединений или 10000 новых соединений в секунду ? > > > > спасибо, установленных) > > > > > 200000 установленных на 1 сервер обрабатываем какая разница сколько их, если скажем они все простаивают? имеет значение количество передаваемого трафика по этим соединениям (в гигабитах/с) и количество устанавливаемых соединений в секунду (когда считаются вся ассиметричная математика). From swood на fotofor.biz Sun Apr 7 11:34:54 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sun, 7 Apr 2019 12:34:54 +0100 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: <797CFF3B-9E2B-49F1-B729-0D399562D6DA@sysoev.ru> References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> <797CFF3B-9E2B-49F1-B729-0D399562D6DA@sysoev.ru> Message-ID: Да, конечно, есть: # find /usr -type f -name 'libm.a' /usr/lib/x86_64-linux-gnu/libm.a Да, я попробовал поставить -lm перед -static, это мне тоже не помогло. К слову, libgd тоже там есть: # find /usr -type f -name 'libgd.a' /usr/lib/x86_64-linux-gnu/libgd.a Подскажите, пожалуйста, где эти тесты лежат в исходнике, поправлю локально, как обычно это делаю с php. сб, 6 апр. 2019 г. в 19:22, Igor Sysoev : > А статическая libm.a есть? > Можно попробовать поставить -lm до -static: > > --with-ld-opt="-lm -static ... > > -- > Igor Sysoev > http://nginx.com > > > On 6 Apr 2019, at 14:57, Anton Kiryushkin wrote: > > > > Ситуация очень напоминает предыдущую: > > > > cc -static -static-libgcc -lm -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm > -L/usr/pkg/lib -lgd > > ---------- > > > > ---------------------------------------- > > checking for GD library in /opt/local/ > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > collect2: error: ld returned 1 exit status > > ---------- > > > > Версия nginx 1.15.10. gcc version 4.8.2. > > > > сб, 6 апр. 2019 г. в 12:14, Igor Sysoev : > > А что в autoconf.err ? > > > > -- > > Igor Sysoev > > http://nginx.com > > > > > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: > > > > > > Добавил и не помогло. > > > > > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > > > > > Здравствуйте. > > > > > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может > собраться статически с libgd: > > > > > > > > ---------- > > > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib > -lgd > > > > ---------- > > > > > > > > ---------------------------------------- > > > > checking for GD library in /opt/local/ > > > > > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > > > collect2: error: ld returned 1 exit status > > > > ---------- > > > > > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне > действительно нужна статическая сборка. Остается страдать и все же так не > делать или есть способ что-то тут сделать? > > > > > > Нужно добавить "-lm" в --with-ld-opt > > > > > > > > > -- > > > Igor Sysoev > > > http://nginx.com > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > -- > > > Best regards, > > > Anton Kiryushkin > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > -- > > Best regards, > > Anton Kiryushkin > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From identw на gmail.com Sun Apr 7 12:45:23 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Sun, 7 Apr 2019 15:45:23 +0300 Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INC60LvQuNC10L3RgdGC0LrQuNGFINC+?= =?UTF-8?B?0YjQuNCx0L7QuiDQstGL0YDQvtGB0LvQviDQv9C+0YHQu9C1INC+0LHQvdC+?= =?UTF-8?B?0LLQu9C10L3QuNGPINC00L4g0L3QvtCy0L7QuSBuZ2lueCgxLjE0LjIpIGMg?= =?UTF-8?B?0L3QvtCy0YvQvCBvcGVuc3NsICgxLjAuMmcp?= In-Reply-To: <20190405153645.GJ1877@mdounin.ru> References: <20190405153645.GJ1877@mdounin.ru> Message-ID: <9436898b-907d-8a9f-e5f7-5e5d6db7261c@gmail.com> > Количество ошибок на уровне HTTP - может быть нерелевантно > происходящему, и, скажем, означать, что больше проблемных клиентов > теперь могут пройти через SSL handshake. > > Ну и смотреть надо не на абсолютные цифры, а на проценты от > трафика. Если речь про доли процента - наблюдаемое изменение > может быть следствием того, что проблемы возникают у каких-либо > малораспространённых клинтов, и совершенно не факт, что на это > надо обращать внимание. Например, из OpenSSL 1.0.2 могли убрать > какие-то workaround'ы для ошибочного поведения, или же из-за > изменения списка шифров теперь используются другие шифры, которые, > наоборот, вызывают проблемы в этих клиентах. Ну не знаю, количество ошибок, которое возросло в 3-4 раза, как по мне стоит того, чтобы обратить внимание. Доля трафика конечно небольшая, я думаю примерно в пределах одного процента, а точнее: 0.24% запросов это ошибки (499,408,400). Но обычно эта доля составляет 0.05%, что и расстраивает. Надо конечно это считать не по количеству запросов, а по количеству пользователей, которых это затрагивает, но все же. > Если же хочется таки разобраться - то имеет смысл смотреть > подробную информацию по ошибкам, в частности - что при этом пишет > nginx в логи (если есть подробности - они скорее всего на уровне > info), и что известно про этих клиентов - User-Agent, используемые > протоколы, шифры и так далее. Да, спасибо. Буду исследовать дальше. > В первую очередь - в OpenSSL 1.0.1 нет ALPN, то есть HTTP/2 в > современных браузерах работать не будет. Если в конфиге включён > HTTP/2 - переход на OpenSSL 1.0.2 будет сильным изменением > поведения в любом случае. Так что имеет смысл HTTP/2 выключить и > сравнивать строго без HTTP/2. Важно при этом выключить везде, > потому как http2 - это опция сокета, и если она останется в любом > из блоков server, то HTTP/2 продолжит работать. Тестил как с http2 так и без него, результат один и тот же. Про то что отключать его нужно во всех блоках server знаю, после выключения непосредственно проверял вручную, выключился ли он действительно. > Если вдруг используются множественные сертификаты в одном блоке > server - переход с OpenSSL 1.0.1 на 1.0.2 потребует изменения > цепочек в ssl_certificate, т.к. в случае OpenSSL 1.0.1 цепочка > только одна и общаяя для всех сертификатов, а в случае 1.0.2 - у > каждого сертификата своя. Я к сожалению не очень разбираюсь в этом, я использую wildcard сертификаты от letsencrypt. То что сгенирировал certbot то и даю nginx. Как писал раннее, тестил версии openssl: 1.0.1u, 1.0.2g, 1.1.1b. Данная проблема воспроизводится успешно на 1.0.2g и 1.1.1b. Спасибо за наводки, понял, что проблема скорее всего на клиентской стороне с поддержкой алгоритмов ssl или еще какие-то, буду исследовать дальше. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Sun Apr 7 13:14:18 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 7 Apr 2019 18:14:18 +0500 Subject: https cpu load In-Reply-To: <20190406201727.GZ2161@zxy.spb.ru> References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> Message-ID: On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > Здравствуйте, > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > 10000 установленных соединений или 10000 новых соединений в секунду ? > > > > > > спасибо, установленных) > > > > > > > > > 200000 установленных на 1 сервер обрабатываем > > какая разница сколько их, если скажем они все простаивают? > > имеет значение количество передаваемого трафика по этим соединениям (в > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > считаются вся ассиметричная математика). > Я предполагаю, что на больших объёмах действует закон больших чисел, и количество установленных соединений вытекает из того, что вы написали. Вообще, я с вами согласен, моё предложение посмотреть профайлер было как раз про это. _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Sun Apr 7 13:15:56 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 7 Apr 2019 18:15:56 +0500 Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INC60LvQuNC10L3RgdGC0LrQuNGFINC+?= =?UTF-8?B?0YjQuNCx0L7QuiDQstGL0YDQvtGB0LvQviDQv9C+0YHQu9C1INC+0LHQvdC+?= =?UTF-8?B?0LLQu9C10L3QuNGPINC00L4g0L3QvtCy0L7QuSBuZ2lueCgxLjE0LjIpIGMg?= =?UTF-8?B?0L3QvtCy0YvQvCBvcGVuc3NsICgxLjAuMmcp?= In-Reply-To: <9436898b-907d-8a9f-e5f7-5e5d6db7261c@gmail.com> References: <20190405153645.GJ1877@mdounin.ru> <9436898b-907d-8a9f-e5f7-5e5d6db7261c@gmail.com> Message-ID: On Sun, Apr 7, 2019, 5:45 PM Dmitry Sergeev wrote: > Количество ошибок на уровне HTTP - может быть нерелевантно > происходящему, и, скажем, означать, что больше проблемных клиентов > теперь могут пройти через SSL handshake. > > Ну и смотреть надо не на абсолютные цифры, а на проценты от > трафика. Если речь про доли процента - наблюдаемое изменение > может быть следствием того, что проблемы возникают у каких-либо > малораспространённых клинтов, и совершенно не факт, что на это > надо обращать внимание. Например, из OpenSSL 1.0.2 могли убрать > какие-то workaround'ы для ошибочного поведения, или же из-за > изменения списка шифров теперь используются другие шифры, которые, > наоборот, вызывают проблемы в этих клиентах. > > Ну не знаю, количество ошибок, которое возросло в 3-4 раза, как по мне > стоит того, чтобы обратить внимание. Доля трафика конечно небольшая, я > думаю примерно в пределах одного процента, а точнее: 0.24% запросов это > ошибки (499,408,400). Но обычно эта доля составляет 0.05%, что и > А каких-нибудь мобильных клиентов на okhttp старых версий (у них очень плохо с http2) нет? расстраивает. Надо конечно это считать не по количеству запросов, а по > количеству пользователей, которых это затрагивает, но все же. > > Если же хочется таки разобраться - то имеет смысл смотреть > подробную информацию по ошибкам, в частности - что при этом пишет > nginx в логи (если есть подробности - они скорее всего на уровне > info), и что известно про этих клиентов - User-Agent, используемые > протоколы, шифры и так далее. > > Да, спасибо. Буду исследовать дальше. > > В первую очередь - в OpenSSL 1.0.1 нет ALPN, то есть HTTP/2 в > современных браузерах работать не будет. Если в конфиге включён > HTTP/2 - переход на OpenSSL 1.0.2 будет сильным изменением > поведения в любом случае. Так что имеет смысл HTTP/2 выключить и > сравнивать строго без HTTP/2. Важно при этом выключить везде, > потому как http2 - это опция сокета, и если она останется в любом > из блоков server, то HTTP/2 продолжит работать. > > Тестил как с http2 так и без него, результат один и тот же. Про то что > отключать его нужно во всех блоках server знаю, после выключения > непосредственно проверял вручную, выключился ли он действительно. > > Если вдруг используются множественные сертификаты в одном блоке > server - переход с OpenSSL 1.0.1 на 1.0.2 потребует изменения > цепочек в ssl_certificate, т.к. в случае OpenSSL 1.0.1 цепочка > только одна и общаяя для всех сертификатов, а в случае 1.0.2 - у > каждого сертификата своя. > > Я к сожалению не очень разбираюсь в этом, я использую wildcard сертификаты > от letsencrypt. То что сгенирировал certbot то и даю nginx. Как писал > раннее, тестил версии openssl: 1.0.1u, 1.0.2g, 1.1.1b. Данная проблема > воспроизводится успешно на 1.0.2g и 1.1.1b. > > Спасибо за наводки, понял, что проблема скорее всего на клиентской стороне > с поддержкой алгоритмов ssl или еще какие-то, буду исследовать дальше. > > > -- > > Kind regards > Dmitry Sergeev > Tel: +7 (951) 129-75-72 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From annulen на yandex.ru Sun Apr 7 15:13:07 2019 From: annulen на yandex.ru (Konstantin Tokarev) Date: Sun, 07 Apr 2019 18:13:07 +0300 Subject: https cpu load In-Reply-To: References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> Message-ID: <20750221554649987@sas1-063d61d846d8.qloud-c.yandex.net> 07.04.2019, 16:14, "Илья Шипицин" : > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: >> On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: >> >>> сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : >>> >>> > Здравствуйте, >>> > >>> > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: >>> > >>> > > 10000 установленных соединений или 10000 новых соединений в секунду ? >>> > >>> > спасибо, установленных) >>> > >>> >>> >>> 200000 установленных на 1 сервер обрабатываем >> >> какая разница сколько их, если скажем они все простаивают? >> >> имеет значение количество передаваемого трафика по этим соединениям (в >> гигабитах/с) и количество устанавливаемых соединений в секунду (когда >> считаются вся ассиметричная математика). > > Я предполагаю, что на больших объёмах действует закон больших чисел, и количество установленных соединений вытекает из того, что вы написали. При разном характере нагрузки среднее время жизни соединения может быть очень разным --  Regards, Konstantin From slw на zxy.spb.ru Sun Apr 7 15:50:58 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sun, 7 Apr 2019 18:50:58 +0300 Subject: https cpu load In-Reply-To: References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> Message-ID: <20190407155058.GA2161@zxy.spb.ru> On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > > > Здравствуйте, > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > 10000 установленных соединений или 10000 новых соединений в секунду ? > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > 200000 установленных на 1 сервер обрабатываем > > > > какая разница сколько их, если скажем они все простаивают? > > > > имеет значение количество передаваемого трафика по этим соединениям (в > > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > > считаются вся ассиметричная математика). > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, и > количество установленных соединений вытекает из того, что вы написали. прежде чем ссылаться на закон больших чисел надо убедиться что в обоих случаях происодит один и тот же эксперимент. > Вообще, я с вами согласен, моё предложение посмотреть профайлер было как > раз про это. нет никакого смысла смотреть профайлер в данный момент. From chipitsine на gmail.com Sun Apr 7 17:02:22 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 7 Apr 2019 22:02:22 +0500 Subject: https cpu load In-Reply-To: <20190407155058.GA2161@zxy.spb.ru> References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> <20190407155058.GA2161@zxy.spb.ru> Message-ID: вс, 7 апр. 2019 г. в 20:51, Slawa Olhovchenkov : > On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > > > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > > > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > > > > > Здравствуйте, > > > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > > > 10000 установленных соединений или 10000 новых соединений в > секунду ? > > > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > > > > > 200000 установленных на 1 сервер обрабатываем > > > > > > какая разница сколько их, если скажем они все простаивают? > > > > > > имеет значение количество передаваемого трафика по этим соединениям (в > > > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > > > считаются вся ассиметричная математика). > > > > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, и > > количество установленных соединений вытекает из того, что вы написали. > > прежде чем ссылаться на закон больших чисел надо убедиться что в обоих > случаях происодит один и тот же эксперимент. > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было как > > раз про это. > > нет никакого смысла смотреть профайлер в данный момент. > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть профайлер. какие еще есть варианты ? gperftools хорош для этой задачи. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Apr 7 17:16:28 2019 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Sun, 07 Apr 2019 13:16:28 -0400 Subject: =?UTF-8?B?0J7Qs9GA0LDQvdC40YfQtdC90LjQtSDQtNC+0YHRgtGD0L/QsCDQuiDQv9Cw0L8=?= =?UTF-8?B?0LrQtSDQv9C+IElQ?= Message-ID: <3e0b639bd741c5c5fa3373bfdbced20e.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Необходимо ограничить доступ к файлам папки /orders-files (в ней содержатся файлы с расширением doc) по ip, делаю так: location ^~ /orders-files/ { allow 123.45.678.90; deny all; client_max_body_size 32M; access_log off; break; } location ~* ^.+\.(css|js|svg|jpg|jpeg|gif|png|ico|zip|rar|doc|xls|pdf|exe|wav|bmp|rtf)$ { client_max_body_size 128M; access_log off; expires 7d; break; } Такое впечатление, что нижний location мешает. Не могли бы помочь разобраться... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283658,283658#msg-283658 From slw на zxy.spb.ru Sun Apr 7 18:00:00 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sun, 7 Apr 2019 21:00:00 +0300 Subject: https cpu load In-Reply-To: References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> <20190407155058.GA2161@zxy.spb.ru> Message-ID: <20190407180000.GB2161@zxy.spb.ru> On Sun, Apr 07, 2019 at 10:02:22PM +0500, Илья Шипицин wrote: > вс, 7 апр. 2019 г. в 20:51, Slawa Olhovchenkov : > > > On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > > > > > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov wrote: > > > > > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov : > > > > > > > > > > > Здравствуйте, > > > > > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > > > > > 10000 установленных соединений или 10000 новых соединений в > > секунду ? > > > > > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > > > > > > > > > 200000 установленных на 1 сервер обрабатываем > > > > > > > > какая разница сколько их, если скажем они все простаивают? > > > > > > > > имеет значение количество передаваемого трафика по этим соединениям (в > > > > гигабитах/с) и количество устанавливаемых соединений в секунду (когда > > > > считаются вся ассиметричная математика). > > > > > > > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, и > > > количество установленных соединений вытекает из того, что вы написали. > > > > прежде чем ссылаться на закон больших чисел надо убедиться что в обоих > > случаях происодит один и тот же эксперимент. > > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. и при этом не сообщая ничего о своем (референсном в данном случае) профиле нагрузке? оригинально > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было как > > > раз про это. > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > профайлер. какие еще есть варианты ? очевидно он расходуется на https, это бесполезное знание. интересоваться профалингом следует тоьлко если производительность не соответсвет ожидаемой, а это пока не известно. > gperftools хорош для этой задачи. не имеет значениею From chipitsine на gmail.com Sun Apr 7 18:12:50 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 7 Apr 2019 23:12:50 +0500 Subject: https cpu load In-Reply-To: <20190407180000.GB2161@zxy.spb.ru> References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> <20190407155058.GA2161@zxy.spb.ru> <20190407180000.GB2161@zxy.spb.ru> Message-ID: вс, 7 апр. 2019 г. в 23:00, Slawa Olhovchenkov : > On Sun, Apr 07, 2019 at 10:02:22PM +0500, Илья Шипицин wrote: > > > вс, 7 апр. 2019 г. в 20:51, Slawa Olhovchenkov : > > > > > On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote: > > > > > > > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov > wrote: > > > > > > > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote: > > > > > > > > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov >: > > > > > > > > > > > > > Здравствуйте, > > > > > > > > > > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет: > > > > > > > > > > > > > > > 10000 установленных соединений или 10000 новых соединений в > > > секунду ? > > > > > > > > > > > > > > спасибо, установленных) > > > > > > > > > > > > > > > > > > > > > > > > > 200000 установленных на 1 сервер обрабатываем > > > > > > > > > > какая разница сколько их, если скажем они все простаивают? > > > > > > > > > > имеет значение количество передаваемого трафика по этим > соединениям (в > > > > > гигабитах/с) и количество устанавливаемых соединений в секунду > (когда > > > > > считаются вся ассиметричная математика). > > > > > > > > > > > > > Я предполагаю, что на больших объёмах действует закон больших чисел, > и > > > > количество установленных соединений вытекает из того, что вы > написали. > > > > > > прежде чем ссылаться на закон больших чисел надо убедиться что в обоих > > > случаях происодит один и тот же эксперимент. > > > > > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. > > и при этом не сообщая ничего о своем (референсном в данном случае) > профиле нагрузке? оригинально > это некое предположение, что "среднее хорошо написанное веб-приложение для браузера" работает примерно одинаково. > > > > > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было > как > > > > раз про это. > > > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > > профайлер. какие еще есть варианты ? > > очевидно он расходуется на https, это бесполезное знание. > неочевидно. например, у нас 70% cpu это компрессия. опять же, https это как минимум два вида нагрузки - ассиметричные хендшейки и симметричное шифрование. сколько каждого из них, весьма интересно. из интересных моментов, каким-то странным образом при сборке портов freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной оптимизацией. по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику (которая в случае включенной ассемблерной оптимизации умножилась на ноль). еще из интересных моментов, был странный опыт с подменой ответа (какой-то баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении тимсити) привела к всплеску cpu. увидели это тоже по gperftools сколько раз использовал gperftools, еще не было повода пожалеть. > интересоваться профалингом следует тоьлко если производительность не > соответсвет ожидаемой, а это пока не известно. > > > gperftools хорош для этой задачи. > > не имеет значениею > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Sun Apr 7 18:22:37 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sun, 7 Apr 2019 21:22:37 +0300 Subject: https cpu load In-Reply-To: References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> <20190407155058.GA2161@zxy.spb.ru> <20190407180000.GB2161@zxy.spb.ru> Message-ID: <20190407182237.GC2161@zxy.spb.ru> On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote: > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это. > > > > и при этом не сообщая ничего о своем (референсном в данном случае) > > профиле нагрузке? оригинально > > > > это некое предположение, что "среднее хорошо написанное веб-приложение для > браузера" работает примерно одинаково. я не заметил, там говорилось что нгинкс колокейтится с приложением? он не статику раздает, не проксей работает? > > > > > > > > > > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было > > как > > > > > раз про это. > > > > > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > > > > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > > > профайлер. какие еще есть варианты ? > > > > очевидно он расходуется на https, это бесполезное знание. > > > > > неочевидно. > например, у нас 70% cpu это компрессия. > > опять же, https это как минимум два вида нагрузки - ассиметричные хендшейки > и симметричное шифрование. сколько каждого из них, весьма интересно. это бесполезное знание, пока мы не узнали что на это расходуется больше ожидаемого. если у нас большая частота новых соединений то будет пик в ассиметричных хендшейках и что дальше? так и должно быть. и смотреть надо на это для начала, а не профайлинг запускать. да и вообще, поинтересоваться что за процессор и все такое. > из интересных моментов, каким-то странным образом при сборке портов > freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной > оптимизацией. это надо было постараться, да. даже дважды (т.е. что бы для начала системный не устроил) > по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику > (которая в случае включенной ассемблерной оптимизации умножилась на ноль). > > еще из интересных моментов, был странный опыт с подменой ответа (какой-то > баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении > тимсити) привела к всплеску cpu. увидели это тоже по gperftools это проявлялось тоьлко на https? > сколько раз использовал gperftools, еще не было повода пожалеть. ни разу не использовал и не жалею. предпочитаю pcstat, но тогда когда имеет смысл. From swood на fotofor.biz Sun Apr 7 19:16:47 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Sun, 7 Apr 2019 20:16:47 +0100 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> <797CFF3B-9E2B-49F1-B729-0D399562D6DA@sysoev.ru> Message-ID: Я взял код из лога и попробовал его собрать ровно так, как написано. Строка моего configure следующая: ./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --add-module=/usr/src/naxsi/naxsi_src --with-debug --with-http_v2_module --with-cc-opt="-static -static-libgcc" --with-ld-opt="-static -lm" --with-cpu-opt=generic --with-openssl=./openssl-1.0.2r --with-stream --with-stream_ssl_module --user=www-data --with-http_image_filter_module Что-то тут уже устаревшее, но это не очень важно. Выпадает ошибка: checking for GD library ... not found checking for GD library in /usr/local/ ... not found checking for GD library in /usr/pkg/ ... not found checking for GD library in /opt/local/ ... not found Окей. Берем код автотеста: #include #include #include int main(void) { gdImagePtr img = gdImageCreateFromGifPtr(1, NULL); (void) img; return 0; } Собираем: cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib -lgd (строчка из того же лога). Не собирается. Однако, если подвинуть -lm в конец: cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd -lm Все соберется. Вопрос, как передвинуть на уровне сборки? вс, 7 апр. 2019 г. в 12:34, Anton Kiryushkin : > Да, конечно, есть: > > # find /usr -type f -name 'libm.a' > /usr/lib/x86_64-linux-gnu/libm.a > > Да, я попробовал поставить -lm перед -static, это мне тоже не помогло. > К слову, libgd тоже там есть: > # find /usr -type f -name 'libgd.a' > /usr/lib/x86_64-linux-gnu/libgd.a > > Подскажите, пожалуйста, где эти тесты лежат в исходнике, поправлю > локально, как обычно это делаю с php. > > сб, 6 апр. 2019 г. в 19:22, Igor Sysoev : > >> А статическая libm.a есть? >> Можно попробовать поставить -lm до -static: >> >> --with-ld-opt="-lm -static ... >> >> -- >> Igor Sysoev >> http://nginx.com >> >> > On 6 Apr 2019, at 14:57, Anton Kiryushkin wrote: >> > >> > Ситуация очень напоминает предыдущую: >> > >> > cc -static -static-libgcc -lm -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I >> /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm >> -L/usr/pkg/lib -lgd >> > ---------- >> > >> > ---------------------------------------- >> > checking for GD library in /opt/local/ >> > >> > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': >> > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' >> > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': >> > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' >> > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' >> > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' >> > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' >> > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': >> > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' >> > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' >> > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': >> > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' >> > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' >> > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' >> > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' >> > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': >> > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' >> > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' >> > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': >> > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' >> > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' >> > collect2: error: ld returned 1 exit status >> > ---------- >> > >> > Версия nginx 1.15.10. gcc version 4.8.2. >> > >> > сб, 6 апр. 2019 г. в 12:14, Igor Sysoev : >> > А что в autoconf.err ? >> > >> > -- >> > Igor Sysoev >> > http://nginx.com >> > >> > > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: >> > > >> > > Добавил и не помогло. >> > > >> > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : >> > > > On 6 Apr 2019, at 12:54, Anton Kiryushkin >> wrote: >> > > > >> > > > Здравствуйте. >> > > > >> > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может >> собраться статически с libgd: >> > > > >> > > > ---------- >> > > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I >> /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib >> -lgd >> > > > ---------- >> > > > >> > > > ---------------------------------------- >> > > > checking for GD library in /opt/local/ >> > > > >> > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': >> > > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' >> > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': >> > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' >> > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' >> > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' >> > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' >> > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': >> > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' >> > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' >> > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': >> > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' >> > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' >> > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' >> > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' >> > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': >> > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' >> > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' >> > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': >> > > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' >> > > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' >> > > > collect2: error: ld returned 1 exit status >> > > > ---------- >> > > > >> > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне >> действительно нужна статическая сборка. Остается страдать и все же так не >> делать или есть способ что-то тут сделать? >> > > >> > > Нужно добавить "-lm" в --with-ld-opt >> > > >> > > >> > > -- >> > > Igor Sysoev >> > > http://nginx.com >> > > _______________________________________________ >> > > nginx-ru mailing list >> > > nginx-ru на nginx.org >> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > >> > > >> > > -- >> > > Best regards, >> > > Anton Kiryushkin >> > > >> > > _______________________________________________ >> > > nginx-ru mailing list >> > > nginx-ru на nginx.org >> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru на nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > >> > >> > -- >> > Best regards, >> > Anton Kiryushkin >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru на nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Best regards, > Anton Kiryushkin > > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor на sysoev.ru Sun Apr 7 19:41:22 2019 From: igor на sysoev.ru (Igor Sysoev) Date: Sun, 7 Apr 2019 22:41:22 +0300 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> <797CFF3B-9E2B-49F1-B729-0D399562D6DA@sysoev.ru> Message-ID: <615D41B2-5FE0-4E06-A371-1AE460456B93@sysoev.ru> > On 7 Apr 2019, at 22:16, Anton Kiryushkin wrote: > > Я взял код из лога и попробовал его собрать ровно так, как написано. > Строка моего configure следующая: > ./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --add-module=/usr/src/naxsi/naxsi_src --with-debug --with-http_v2_module --with-cc-opt="-static -static-libgcc" --with-ld-opt="-static -lm" --with-cpu-opt=generic --with-openssl=./openssl-1.0.2r --with-stream --with-stream_ssl_module --user=www-data --with-http_image_filter_module > > Что-то тут уже устаревшее, но это не очень важно. > Выпадает ошибка: > checking for GD library ... not found > checking for GD library in /usr/local/ ... not found > checking for GD library in /usr/pkg/ ... not found > checking for GD library in /opt/local/ ... not found > > Окей. Берем код автотеста: > > #include > #include > #include > > int main(void) { > gdImagePtr img = gdImageCreateFromGifPtr(1, NULL); > (void) img; > return 0; > } > > Собираем: > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib -lgd (строчка из того же лога). > Не собирается. > Однако, если подвинуть -lm в конец: > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd -lm > > Все соберется. > > Вопрос, как передвинуть на уровне сборки? Штатно не двигается. Можно добавить в auto/lib/libgd/conf: - ngx_feature_libs="-L/usr/pkg/lib -lgd" + ngx_feature_libs="-L/usr/pkg/lib -lgd -lm" В динамической libgd.so зависимость от libm.so записана, а в статической такой возможности нет. -- Igor Sysoev http://nginx.com From chipitsine на gmail.com Sun Apr 7 20:02:53 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 8 Apr 2019 01:02:53 +0500 Subject: https cpu load In-Reply-To: <20190407182237.GC2161@zxy.spb.ru> References: <20190406163733.GY9051@korolev-net.ru> <20190406184015.GA77204@korolev-net.ru> <20190406201727.GZ2161@zxy.spb.ru> <20190407155058.GA2161@zxy.spb.ru> <20190407180000.GB2161@zxy.spb.ru> <20190407182237.GC2161@zxy.spb.ru> Message-ID: вс, 7 апр. 2019 г. в 23:22, Slawa Olhovchenkov : > On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote: > > > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает > это. > > > > > > и при этом не сообщая ничего о своем (референсном в данном случае) > > > профиле нагрузке? оригинально > > > > > > > это некое предположение, что "среднее хорошо написанное веб-приложение > для > > браузера" работает примерно одинаково. > > я не заметил, там говорилось что нгинкс колокейтится с приложением? > он не статику раздает, не проксей работает? > > > > > > > > > > > > > > > > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер > было > > > как > > > > > > раз про это. > > > > > > > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > > > > > > > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > > > > профайлер. какие еще есть варианты ? > > > > > > очевидно он расходуется на https, это бесполезное знание. > > > > > > > > > неочевидно. > > например, у нас 70% cpu это компрессия. > > > > опять же, https это как минимум два вида нагрузки - ассиметричные > хендшейки > > и симметричное шифрование. сколько каждого из них, весьма интересно. > > это бесполезное знание, пока мы не узнали что на это расходуется > больше ожидаемого. если у нас большая частота новых соединений то > будет пик в ассиметричных хендшейках и что дальше? так и должно быть. > информация о том, что пик в хендшейках - полезна. допустим, у нас не используется http2 - значит надо его включить допустим, можно увеличить keepalive_requests допустим, можно поревьювить кеш SSL сессий (хотя, по приведенному конфигу - с ним все хорошо) допустим, можно поменять порядок шифрстютов (у GCM хендшейки дешевле) допустим, можно перейти на ECDSA (увеличение производительности от x4 на Xeon до x16 на Celeron) > и смотреть надо на это для начала, а не профайлинг запускать. > без профайлинга непонятно, действительно ли ssl в топе. > > да и вообще, поинтересоваться что за процессор и все такое. > > > из интересных моментов, каким-то странным образом при сборке портов > > freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной > > оптимизацией. > > это надо было постараться, да. > даже дважды (т.е. что бы для начала системный не устроил) > на freebsd до недавнего времени в base system поставлвлся openssl-1.0.1, постарались мы ровно один раз, когда "убрали" галочку с ассемблерной оптимизации > > > по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику > > (которая в случае включенной ассемблерной оптимизации умножилась на > ноль). > > > > еще из интересных моментов, был странный опыт с подменой ответа (какой-то > > баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении > > тимсити) привела к всплеску cpu. увидели это тоже по gperftools > > это проявлялось тоьлко на https? > это пример того, как при помощи профайлера найти узкое место. проявлялось это, понятно, в единственной ситуации, вышел новый релиз teamcity, и несколько десятков агентов пошли скачивать инсталяторы. и это пошло сквозь регурярку > > > сколько раз использовал gperftools, еще не было повода пожалеть. > > ни разу не использовал и не жалею. > предпочитаю pcstat, но тогда когда имеет смысл. > вариантов профилирования миллион. неплохой обзор, например, тут http://openresty.org/slides/nginx-conf-2018/#1 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Apr 8 00:48:30 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 8 Apr 2019 03:48:30 +0300 Subject: nginx: [emerg] getpwnam("www-data") failed In-Reply-To: References: Message-ID: <20190408004830.GK1877@mdounin.ru> Hello! On Sat, Apr 06, 2019 at 01:21:06PM +0100, Anton Kiryushkin wrote: > При обновлении на 1.15.10 поймал такую картину. В конфиге полжизни было > написано: > user www-data; > > Пользователь есть, группа есть. Все ищется по /etc/passwd и /etc/group. Что > поменялось в nginx? Ничего. Последнее изменение в соответствующей функции - стилистическое - датируется 2015 годом, nginx 1.9.6, 7ac57369036c. Последнее смысловое изменение - о том, чтобы сообщения об ошибках были более детерминированы - было в 2007 году, nginx 0.6.3, eb232400e829. Сообщение как бы говорит о том, что библиотечный вызов getpwnam() с параметром "www-data" вернул ошибку. Если далее в скобках не указано подробностей про собственно ошибку - это должно случаться тогда и только тогда, когда такого пользователя нет. Если это не соответствует реальности - стоит искать причины в системе. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Apr 8 01:44:06 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 8 Apr 2019 04:44:06 +0300 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjRh9C10YHQutCw0Y8g0YHQsdC+0YDQutCwIG5naW54INGB?= =?UTF-8?B?IEdE?= In-Reply-To: <615D41B2-5FE0-4E06-A371-1AE460456B93@sysoev.ru> References: <34BD5A0B-818B-4E25-B987-0DA476BB72DC@sysoev.ru> <797CFF3B-9E2B-49F1-B729-0D399562D6DA@sysoev.ru> <615D41B2-5FE0-4E06-A371-1AE460456B93@sysoev.ru> Message-ID: <20190408014406.GL1877@mdounin.ru> Hello! On Sun, Apr 07, 2019 at 10:41:22PM +0300, Igor Sysoev wrote: > > On 7 Apr 2019, at 22:16, Anton Kiryushkin wrote: > > > > Я взял код из лога и попробовал его собрать ровно так, как написано. > > Строка моего configure следующая: > > ./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --add-module=/usr/src/naxsi/naxsi_src --with-debug --with-http_v2_module --with-cc-opt="-static -static-libgcc" --with-ld-opt="-static -lm" --with-cpu-opt=generic --with-openssl=./openssl-1.0.2r --with-stream --with-stream_ssl_module --user=www-data --with-http_image_filter_module > > > > Что-то тут уже устаревшее, но это не очень важно. > > Выпадает ошибка: > > checking for GD library ... not found > > checking for GD library in /usr/local/ ... not found > > checking for GD library in /usr/pkg/ ... not found > > checking for GD library in /opt/local/ ... not found > > > > Окей. Берем код автотеста: > > > > #include > > #include > > #include > > > > int main(void) { > > gdImagePtr img = gdImageCreateFromGifPtr(1, NULL); > > (void) img; > > return 0; > > } > > > > Собираем: > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib -lgd (строчка из того же лога). > > Не собирается. > > Однако, если подвинуть -lm в конец: > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd -lm > > > > Все соберется. > > > > Вопрос, как передвинуть на уровне сборки? > > Штатно не двигается. > Можно добавить в auto/lib/libgd/conf: > > - ngx_feature_libs="-L/usr/pkg/lib -lgd" > + ngx_feature_libs="-L/usr/pkg/lib -lgd -lm" > > В динамической libgd.so зависимость от libm.so записана, > а в статической такой возможности нет. Штатно аналогичный результат можно, если очень хочется, получить так: ./configure --with-http_image_filter_module \ --with-ld-opt="-L/usr/pkg/lib -static -lgd -lm" Хотя вот лично я бы - не рекомендовал, особенно под Linux'ом. Там warning'и при статической линковке - не просто так, и игнорирование их ведёт к вопросам "у меня всё сломалось, что вы поменяли в nginx'е" вполне очевидным образом. Тем более, что у современного GD зависимостей - устанешь перечислять, -lm - это только верхушка айсберга. Скажем, чтобы собраться статически со штатным пакетом GD на FreeBSD мне потребовалась какая-то такая простыня: ./auto/configure --with-http_image_filter_module \ --with-ld-opt="-L/usr/local/lib -static -lgd -lm \ -lpng -lm -lz -lfontconfig -lfreetype -ljpeg \ -ltiff -lwebp -lexpat -lbz2" -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Apr 8 02:10:02 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 8 Apr 2019 05:10:02 +0300 Subject: nginx: [emerg] getpwnam("www-data") failed In-Reply-To: <20190408004830.GK1877@mdounin.ru> References: <20190408004830.GK1877@mdounin.ru> Message-ID: <20190408021002.GM1877@mdounin.ru> Hello! On Mon, Apr 08, 2019 at 03:48:30AM +0300, Maxim Dounin wrote: > On Sat, Apr 06, 2019 at 01:21:06PM +0100, Anton Kiryushkin wrote: > > > При обновлении на 1.15.10 поймал такую картину. В конфиге полжизни было > > написано: > > user www-data; > > > > Пользователь есть, группа есть. Все ищется по /etc/passwd и /etc/group. Что > > поменялось в nginx? > > Ничего. Последнее изменение в соответствующей функции - > стилистическое - датируется 2015 годом, nginx 1.9.6, 7ac57369036c. > Последнее смысловое изменение - о том, чтобы сообщения об ошибках > были более детерминированы - было в 2007 году, nginx 0.6.3, > eb232400e829. > > Сообщение как бы говорит о том, что библиотечный вызов > getpwnam() с параметром "www-data" вернул ошибку. Если далее в > скобках не указано подробностей про собственно ошибку - это должно > случаться тогда и только тогда, когда такого пользователя нет. > Если это не соответствует реальности - стоит искать причины в > системе. Соседний тред наводит на мысли о том, что nginx собран на Linux'е статически. В этом случае линковщик выдаёт большую простыню warning'ов, в том числе - про getpwnam(): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Если это требование нарушено - чудеса ожидаемы. На практике это означает, что статически собранное приложение можно использовать только на той же машине и необходимо пересобирать при любых обновлениях системы. Ну или просто не надо ничего собирать статически. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Apr 8 16:03:48 2019 From: nginx-forum на forum.nginx.org (RuslanValitov) Date: Mon, 08 Apr 2019 12:03:48 -0400 Subject: =?UTF-8?B?Tmdpbngg0Lgg0YDQtdCz0YPQu9GP0YDQvdGL0LUg0LLRi9GA0LDQttC10L3QuNGP?= Message-ID: <50562a067e1cdde99bf63bd3198f4f46.NginxMailingListRussian@forum.nginx.org> Добрый день. Пишу conf файл для своего сайта. Задача сделать Location который удовлетворяет следующим путям: site.ru/catalog/ site.ru/catalog/?id=3 site.ru/catalog/1/ site.ru/catalog/1/?id=3 при этом необходимо получить значение $1 если оно есть. Использую регулярное выражение: location ~* catalog/(\w+) -- site.ru/catalog/1/ -работает site.ru/catalog/1/?id=3 -работает site.ru/catalog/ - 404 -- очевидно что nginx ждет что после catalog/ должен быть некий (\w+), поэтому (site.ru/catalog/) не попадает вы выше созданный Location Подскажите как изменить регулярное выражение что бы учитывался вариант (site.ru/catalog/) ? Не хочу плодить отдельный локейшен =catalog/ Заранее премного благодарен. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283671,283671#msg-283671 From pluknet на nginx.com Mon Apr 8 16:18:07 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Mon, 8 Apr 2019 19:18:07 +0300 Subject: =?UTF-8?B?UmU6IE5naW54INC4INGA0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <50562a067e1cdde99bf63bd3198f4f46.NginxMailingListRussian@forum.nginx.org> References: <50562a067e1cdde99bf63bd3198f4f46.NginxMailingListRussian@forum.nginx.org> Message-ID: > On 8 Apr 2019, at 19:03, RuslanValitov wrote: > > Добрый день. Пишу conf файл для своего сайта. > Задача сделать Location который удовлетворяет следующим путям: > site.ru/catalog/ > site.ru/catalog/?id=3 > site.ru/catalog/1/ > site.ru/catalog/1/?id=3 > при этом необходимо получить значение $1 если оно есть. > > Использую регулярное выражение: > location ~* catalog/(\w+) > -- > site.ru/catalog/1/ -работает > site.ru/catalog/1/?id=3 -работает > site.ru/catalog/ - 404 > -- > > Подскажите как изменить регулярное выражение что бы учитывался вариант > (site.ru/catalog/) ? Используйте квантификатор "?": location ~* catalog/(\w+)? https://www.pcre.org/original/doc/html/pcrepattern.html#SEC17 -- Sergey Kandaurov From nginx-forum на forum.nginx.org Mon Apr 8 16:52:24 2019 From: nginx-forum на forum.nginx.org (RuslanValitov) Date: Mon, 08 Apr 2019 12:52:24 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC4INGA0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: References: Message-ID: <75dac5c4533ab475fa53955e4055b14e.NginxMailingListRussian@forum.nginx.org> Огромное спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283671,283674#msg-283674 From ngnx8810773a83 на avksrv.org Mon Apr 8 21:03:05 2019 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Tue, 9 Apr 2019 00:03:05 +0300 Subject: =?UTF-8?B?UmU6IE5naW54INC4INGA0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: References: <50562a067e1cdde99bf63bd3198f4f46.NginxMailingListRussian@forum.nginx.org> Message-ID: <9b2e50d0-25de-01f8-b073-4eeac37e270c@avksrv.org> 08.04.2019 19:18, Sergey Kandaurov пишет: >> On 8 Apr 2019, at 19:03, RuslanValitov wrote: >> >> Добрый день. Пишу conf файл для своего сайта. >> Задача сделать Location который удовлетворяет следующим путям: >> site.ru/catalog/ >> site.ru/catalog/?id=3 >> site.ru/catalog/1/ >> site.ru/catalog/1/?id=3 >> при этом необходимо получить значение $1 если оно есть. >> >> Использую регулярное выражение: >> location ~* catalog/(\w+) >> -- >> site.ru/catalog/1/ -работает >> site.ru/catalog/1/?id=3 -работает >> site.ru/catalog/ - 404 >> -- >> >> Подскажите как изменить регулярное выражение что бы учитывался вариант >> (site.ru/catalog/) ? > Используйте квантификатор "?": > location ~* catalog/(\w+)? > > https://www.pcre.org/original/doc/html/pcrepattern.html#SEC17 > и "?id=3" не часть uri и в проверку  регулярного выражения в location не попадает вообще... и в приведенное выражение Вы поймаете еще и /Tratata/My/Super/TheCaTaLog/TheRE/AreMoRe/letters и в $1 будет TheRE Но, возможно, оно Вам так и нужно., ну или location ~ "^/catalog/(?:(?\d+)/)?$" номер после id будет в $catalogid наличие параметра id можно посмотреть в $arg_id внутри локешна. Ну так.. :) /Алексей From nginx на kinetiksoft.com Tue Apr 9 07:06:33 2019 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Tue, 9 Apr 2019 10:06:33 +0300 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0Log0L8=?= =?UTF-8?B?0LDQv9C60LUg0L/QviBJUA==?= In-Reply-To: <3e0b639bd741c5c5fa3373bfdbced20e.NginxMailingListRussian@forum.nginx.org> References: <3e0b639bd741c5c5fa3373bfdbced20e.NginxMailingListRussian@forum.nginx.org> Message-ID: <2f5df175-4f1e-3aa4-34ad-f24067d87a0d@kinetiksoft.com> Здравствуйте! А зачем break в этих локейшенах? Сходу ответа на Ваш вопрос у меня нет, но попробуйте сначала точно выяснить куда приходит запрос: для каждого локейшена отдельный лог файл и\или return 444 по очереди в каждый локейшен.  Как точно узнаете, если всё еще будет не понятно, давайте целый вывод nginx -T . С уважением, Иван. 07.04.2019 20:16, Vvedensky пишет: > Здравствуйте. > Необходимо ограничить доступ к файлам папки /orders-files (в ней содержатся > файлы с расширением doc) по ip, делаю так: > location ^~ /orders-files/ { > allow 123.45.678.90; > deny all; > client_max_body_size 32M; > access_log off; > break; > } > location ~* > ^.+\.(css|js|svg|jpg|jpeg|gif|png|ico|zip|rar|doc|xls|pdf|exe|wav|bmp|rtf)$ > { > client_max_body_size 128M; > access_log off; > expires 7d; > break; > } > > Такое впечатление, что нижний location мешает. Не могли бы помочь > разобраться... > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283658,283658#msg-283658 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine на gmail.com Tue Apr 9 08:59:29 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 9 Apr 2019 13:59:29 +0500 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0Log0L8=?= =?UTF-8?B?0LDQv9C60LUg0L/QviBJUA==?= In-Reply-To: <3e0b639bd741c5c5fa3373bfdbced20e.NginxMailingListRussian@forum.nginx.org> References: <3e0b639bd741c5c5fa3373bfdbced20e.NginxMailingListRussian@forum.nginx.org> Message-ID: а локейшен "/" тоже есть ? вс, 7 апр. 2019 г. в 22:16, Vvedensky : > Здравствуйте. > Необходимо ограничить доступ к файлам папки /orders-files (в ней содержатся > файлы с расширением doc) по ip, делаю так: > location ^~ /orders-files/ { > allow 123.45.678.90; > deny all; > client_max_body_size 32M; > access_log off; > break; > } > location ~* > ^.+\.(css|js|svg|jpg|jpeg|gif|png|ico|zip|rar|doc|xls|pdf|exe|wav|bmp|rtf)$ > { > client_max_body_size 128M; > access_log off; > expires 7d; > break; > } > > Такое впечатление, что нижний location мешает. Не могли бы помочь > разобраться... > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,283658,283658#msg-283658 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Apr 9 13:14:32 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 9 Apr 2019 16:14:32 +0300 Subject: nginx-1.15.11 Message-ID: <20190409131432.GR1877@mdounin.ru> Изменения в nginx 1.15.11 09.04.2019 *) Исправление: в директиве ssl_stapling_file на Windows. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Apr 9 16:48:02 2019 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Tue, 09 Apr 2019 12:48:02 -0400 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0Log0L8=?= =?UTF-8?B?0LDQv9C60LUg0L/QviBJUA==?= In-Reply-To: <2f5df175-4f1e-3aa4-34ad-f24067d87a0d@kinetiksoft.com> References: <2f5df175-4f1e-3aa4-34ad-f24067d87a0d@kinetiksoft.com> Message-ID: <6d1a30556b79db9a2d773fa28ff4ddb5.NginxMailingListRussian@forum.nginx.org> Удалось разобраться: проблема была в другом месте. Но за рекомендации спасибо. Использование отдельных лог-файлов очень может быть полезным для отладки, сам бы не додумался. Про break - считал, что встретив этот оператор nginx прерывает дальнейшую работу (т.е. не пойдёт проверять следующий location). Это не так? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283658,283696#msg-283696 From nginx-forum на forum.nginx.org Tue Apr 9 16:48:55 2019 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Tue, 09 Apr 2019 12:48:55 -0400 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0Log0L8=?= =?UTF-8?B?0LDQv9C60LUg0L/QviBJUA==?= In-Reply-To: References: Message-ID: <3783a7dfdee79d6588cf7a4b128fb438.NginxMailingListRussian@forum.nginx.org> Да есть. Спасибо, нашёл ошибку, она была в другом месте. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283658,283697#msg-283697 From chipitsine на gmail.com Tue Apr 9 20:31:12 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 10 Apr 2019 01:31:12 +0500 Subject: =?UTF-8?B?dW5kZXJzY29yZXNfaW5faGVhZGVycyAtINCx0LDQsyDQsiDQtNC+0LrRg9C80LU=?= =?UTF-8?B?0L3RgtCw0YbQuNC4ID8=?= Message-ID: привет! допустим, у нас своеобразное приложение. с подчеркиванием в хедерах (не спрашивайте, у меня нет идей, чем заправлялись разработчики) читаем https://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers ок. директиву надо писать в дефолт сервере. пишем log_format underscore '$http_header_underscore\t$status'; server { listen 80; server_name localhost; access_log /var/log/nginx/test.log underscore; location / { proxy_pass http://127.0.0.1:81; } } server { listen 80 default_server; server_name _; underscores_in_headers on; location / { return 404; } } server { listen 81; server_name localhost; location / { return 418; } } можете проверить (я проверял на 1.15.11 без доп модулей) - не работает. зато, если добавить в соответствующий сервер - работает. баг ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From podnimator на gmail.com Wed Apr 10 05:53:57 2019 From: podnimator на gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40Lkg0KHRgtC10L/QsNC90LXQvdC60L4=?=) Date: Wed, 10 Apr 2019 08:53:57 +0300 Subject: =?UTF-8?B?0JrQsNC6INC60LXRiNC40YDQvtCy0LDRgtGMINCy0LjQtNC10L4g0YEg0YHQvtGF?= =?UTF-8?B?0YDQsNC90LXQvdC40LXQvCDRhNGD0L3QutGG0LjQvtC90LDQu9GM0L3QvtGB?= =?UTF-8?B?0YLQuCDQvNC+0LTRg9C70Y8gbmd4X2h0dHBfbXA0X21vZHVsZT8=?= Message-ID: Здравствуйте, В данный момент раздаем видео (ngx_http_mp4_module) с файлового сервера (35TB) и начали упираться в дисковую производительность. Хочу настроить кеширование популярных видеофайлов с помощью Nginx. Пробовал с proxy_store, но как контролировать объем кеша, ведь нет вытеснения по LRU? Пробовал Slice, но как контролировать скорость отдачи фрагмента без limit_rate? Есть опасения, что на сервере c каналом 10-20 Gbps будет высокая нагрузка из за накладных расходов во время работы Slice. Кто нибудь знает, как работают кеширующие видео серверы в CDN? location ~* \.mp4$ { mp4; mp4_buffer_size 3m; mp4_max_buffer_size 15m; limit_rate 128k; limit_rate_after 3m; root /var/www/cache; try_files $uri @storage; } location @storage { max_ranges 0; proxy_set_header If-Range ""; proxy_set_header Range ""; proxy_hide_header accept-ranges; proxy_pass http://files.com; proxy_store on; proxy_store_access user:rw group:rw all:r; proxy_temp_path /var/www/tmp/; root /var/www/cache; } ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на kinetiksoft.com Wed Apr 10 07:56:09 2019 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Wed, 10 Apr 2019 10:56:09 +0300 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0Log0L8=?= =?UTF-8?B?0LDQv9C60LUg0L/QviBJUA==?= In-Reply-To: <6d1a30556b79db9a2d773fa28ff4ddb5.NginxMailingListRussian@forum.nginx.org> References: <2f5df175-4f1e-3aa4-34ad-f24067d87a0d@kinetiksoft.com> <6d1a30556b79db9a2d773fa28ff4ddb5.NginxMailingListRussian@forum.nginx.org> Message-ID: Нет, не так. break и location существуют совершенно параллельно друг другу. break (https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#break) только про директивы модуля rewrite. А логика выбора location описывается полностью тут https://nginx.org/ru/docs/http/ngx_http_core_module.html#location, и про break там ничего. 09.04.2019 19:48, Vvedensky пишет: > читал, что встретив этот оператор > nginx прерывает дальнейшую работу (т.е. не пойдёт проверять следующий > location). Это не так? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283658,283696#msg-283696 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From pluknet на nginx.com Wed Apr 10 11:24:58 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 10 Apr 2019 14:24:58 +0300 Subject: =?UTF-8?B?UmU6IHVuZGVyc2NvcmVzX2luX2hlYWRlcnMgLSDQsdCw0LMg0LIg0LTQvtC60YM=?= =?UTF-8?B?0LzQtdC90YLQsNGG0LjQuCA/?= In-Reply-To: References: Message-ID: <1F976508-4B4D-4511-84BD-BE1243ECC218@nginx.com> > On 9 Apr 2019, at 23:31, Илья Шипицин wrote: > > привет! > > допустим, у нас своеобразное приложение. с подчеркиванием в хедерах (не спрашивайте, у меня нет идей, чем заправлялись разработчики) > > читаем > > https://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers > > ок. директиву надо писать в дефолт сервере. > пишем > > log_format underscore '$http_header_underscore\t$status'; > > server { > listen 80; > server_name localhost; > > access_log /var/log/nginx/test.log underscore; > > location / { > proxy_pass http://127.0.0.1:81; > } > > } > > server { > listen 80 default_server; > server_name _; > > underscores_in_headers on; > > location / { return 404; } > } > > server { > listen 81; > server_name localhost; > > location / { return 418; } > > } > > > > можете проверить (я проверял на 1.15.11 без доп модулей) - не работает. > зато, если добавить в соответствующий сервер - работает. > > баг ? Нет, изменение поведения: hg.nginx.org/nginx/rev/c4d3310574e0 Видимо, забыли поправить документацию. -- Sergey Kandaurov From sergio на outerface.net Thu Apr 11 00:55:31 2019 From: sergio на outerface.net (sergio) Date: Thu, 11 Apr 2019 03:55:31 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <20190401162205.GS1877@mdounin.ru> References: <20190401125452.GQ1877@mdounin.ru> <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> <20190401144421.GR1877@mdounin.ru> <7a92467b-bb54-3171-58a1-583431bf2650@outerface.net> <20190401162205.GS1877@mdounin.ru> Message-ID: <7f5f0c7b-80e8-b873-dcd4-7e6d71ccefbb@outerface.net> On 01/04/2019 19:22, Maxim Dounin wrote: > Давайте пойдём простым путём. Не похож он на простой. > Покажите вывод "nginx -V" # nginx -V nginx version: nginx/1.14.1 built with OpenSSL 1.1.0f 25 May 2017 (running with OpenSSL 1.1.0j 20 Nov 2018) TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-jqo7Nx/nginx-1.14.1=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_gzip_static_module --without-http_browser_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_conn_module --without-http_memcached_module --without-http_referer_module --without-http_split_clients_module --without-http_userid_module --add-dynamic-module=/build/nginx-jqo7Nx/nginx-1.14.1/debian/modules/http-echo > "nginx -T" Тут очень много всего, куча серверов, 909 строк, и не всё я могу показать. Давайте так: # nginx -T | grep "resol\|stapl" nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful ssl_stapling on; ssl_stapling_verify on; #resolver localhost; > и debug log с обращением к OCSP-серверу У меня дебиан, nginx-debug нету. Я просто взял и заменил warn на debug в error_log на уровне http и на уровне server'а один терминал: tail query.log другой терминал: tcpdump на обращение к ocsp ещё терминал: tail error.log (две штуки) делаю /etc/init.d/nginx restart в query.log вижу резолвинг oscp сервера, на двух остальных тихо делаю echo | openssl s_client -connect target:443 -status | grep -A20 'OCSP response' ... OCSP response: no response sent вижу обращение и ответ на tcpdump'е (Content-Type: application/ocsp-response) вижу кучу невнятных записей в error.log со словами [debug], ни слова про ocsp: [debug] 30320#30320: *1 SSL certificate status callback [debug] 30320#30320: *1 SSL_do_handshake: -1 [debug] 30320#30320: *1 SSL_get_error: 2 [debug] 30320#30320: *1 epoll add event: fd:55 op:1 ev:80002001 [debug] 30320#30320: *1 event timer add: 55: 60000:4031539074 [debug] 30320#30320: *1 reusable connection: 0 [debug] 30320#30320: *1 SSL handshake handler: 0 [debug] 30320#30320: *1 SSL_do_handshake: 1 [debug] 30320#30320: *1 SSL: TLSv1.2, cipher: "ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD" [debug] 30320#30320: *1 reusable connection: 1 [debug] 30320#30320: *1 http wait request handler [debug] 30320#30320: *1 malloc: 000056367BE9E750:1024 [debug] 30320#30320: *1 SSL_read: -1 [debug] 30320#30320: *1 SSL_get_error: 2 [debug] 30320#30320: *1 free: 000056367BE9E750 [debug] 30320#30320: *1 http wait request handler [debug] 30320#30320: *1 malloc: 000056367BE9E750:1024 [debug] 30320#30320: *1 SSL_read: 1 [debug] 30320#30320: *1 SSL_read: 0 [debug] 30320#30320: *1 SSL_get_error: 6 [debug] 30320#30320: *1 peer shutdown SSL cleanly [debug] 30320#30320: *1 reusable connection: 0 [debug] 30320#30320: *1 posix_memalign: 000056367BE21560:4096 @16 [debug] 30320#30320: *1 http process request line [info] 30320#30320: *1 client prematurely closed connection while reading client request line, client: , server: [debug] 30320#30320: *1 http finalize request: 400, "?" a:1, c:1 [debug] 30320#30320: *1 http terminate request count:1 [debug] 30320#30320: *1 http terminate cleanup count:1 blk:0 [debug] 30320#30320: *1 http request count:1 blk:0 [debug] 30320#30320: *1 http close request [debug] 30320#30320: *1 http log handler [debug] 30320#30320: *1 free: 000056367BE21560, unused: 590 [debug] 30320#30320: *1 close http connection: 55 [debug] 30320#30320: *1 SSL_shutdown: 1 [debug] 30320#30320: *1 event timer del: 55: 4031539074 [debug] 30320#30320: *1 reusable connection: 0 [debug] 30320#30320: *1 free: 000056367BE9E750 [debug] 30320#30320: *1 free: 000056367BE7D4F0, unused: 24 делаю echo | openssl s_client -connect target:443 -status | grep -A20 'OCSP response' ... OCSP response: DONE ====================================== OCSP Response Data: в tcpdump'е в этот момент тишина, в error log пачка абсолютно таких же записей как и в первый раз один в один -- sergio. From mdounin на mdounin.ru Thu Apr 11 19:56:20 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 11 Apr 2019 22:56:20 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <7f5f0c7b-80e8-b873-dcd4-7e6d71ccefbb@outerface.net> References: <20190401125452.GQ1877@mdounin.ru> <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> <20190401144421.GR1877@mdounin.ru> <7a92467b-bb54-3171-58a1-583431bf2650@outerface.net> <20190401162205.GS1877@mdounin.ru> <7f5f0c7b-80e8-b873-dcd4-7e6d71ccefbb@outerface.net> Message-ID: <20190411195620.GF1877@mdounin.ru> Hello! On Thu, Apr 11, 2019 at 03:55:31AM +0300, sergio via nginx-ru wrote: > On 01/04/2019 19:22, Maxim Dounin wrote: > > > Давайте пойдём простым путём. > > Не похож он на простой. Он простой в том смысле, что результат не зависит от ваших оценочных суждений, а проверяем. [...] > > "nginx -T" > > Тут очень много всего, куча серверов, 909 строк, и не всё я могу > показать. Давайте так: > > # nginx -T | grep "resol\|stapl" > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok > nginx: configuration file /etc/nginx/nginx.conf test is successful > ssl_stapling on; > ssl_stapling_verify on; > #resolver localhost; Нет, так не работает. Если не хотите чего-то показывать - воспроизведите проблему в песочнице и давайте полный конфиг из неё. Впрочем, я уже вижу проблему и без этого. Как и предполагалось ранее - логов нужного уровня нет: > > и debug log с обращением к OCSP-серверу > > У меня дебиан, nginx-debug нету. Я просто взял и заменил warn на debug > в error_log на уровне http и на уровне server'а Директиву error_log следует указывать на глобальном уровне. Именно туда попадают сообщения, которые генерируются инфраструктурным кодом, не привязанным к конкретному соединению и/или модулю. Поскольку на глобальном уровне error_log у вас, судя по всему, не задан вообще, то используется error log, заданный при сборке - /var/log/nginx/error.log - с уровнем логгирования error. Но этого недостаточно, чтобы увидеть сообщения уровня warn, а тем более - debug. В результат в логе видно, что был вызыван certificate status callback: > вижу кучу невнятных записей в error.log со словами [debug], ни слова про > ocsp: > > [debug] 30320#30320: *1 SSL certificate status callback > [debug] 30320#30320: *1 SSL_do_handshake: -1 > [debug] 30320#30320: *1 SSL_get_error: 2 > [debug] 30320#30320: *1 epoll add event: fd:55 op:1 ev:80002001 > [debug] 30320#30320: *1 event timer add: 55: 60000:4031539074 но не видно всего того, что начинает происходить после этого callback'а уже без привязки к конкретному соединению. Должно быть как-то так: ... 2019/04/11 22:37:56 [debug] 52632#100124: *1 SSL certificate status callback 2019/04/11 22:37:56 [debug] 52632#100124: posix_memalign: 29056000:2048 @16 2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp request 2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp request length 96, escape 3 2019/04/11 22:37:56 [warn] 52632#100124: no resolver defined to resolve ocsp.cacert.org while requesting certificate status, responder: ocsp.cacert.org, certificate: "/path/to/crt" 2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp connect 2019/04/11 22:37:56 [debug] 52632#100124: stream socket 9 2019/04/11 22:37:56 [debug] 52632#100124: connect to 213.154.225.237:80, fd:9 #2 2019/04/11 22:37:56 [debug] 52632#100124: kevent set event: 9: ft:-1 fl:0025 2019/04/11 22:37:56 [debug] 52632#100124: kevent set event: 9: ft:-2 fl:0025 2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp connect peer done 2019/04/11 22:37:56 [debug] 52632#100124: event timer add: 9: 60000:351011347 2019/04/11 22:37:56 [debug] 52632#100124: event timer add: 9: 60000:351011347 2019/04/11 22:37:56 [debug] 52632#100124: *1 SSL_do_handshake: 1 2019/04/11 22:37:56 [debug] 52632#100124: *1 SSL: TLSv1.2, cipher: "ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD" ... -- Maxim Dounin http://mdounin.ru/ From sergio на outerface.net Thu Apr 11 21:02:39 2019 From: sergio на outerface.net (sergio) Date: Fri, 12 Apr 2019 00:02:39 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <20190411195620.GF1877@mdounin.ru> References: <20190401125452.GQ1877@mdounin.ru> <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> <20190401144421.GR1877@mdounin.ru> <7a92467b-bb54-3171-58a1-583431bf2650@outerface.net> <20190401162205.GS1877@mdounin.ru> <7f5f0c7b-80e8-b873-dcd4-7e6d71ccefbb@outerface.net> <20190411195620.GF1877@mdounin.ru> Message-ID: <7186872b-9c89-f0d3-aca0-60903625608d@outerface.net> On 11/04/2019 22:56, Maxim Dounin wrote: Я подписан, не надо меня в cc включать. > Директиву error_log следует указывать на глобальном уровне. Ага! > при каждом обращении к OCSP-серверу ругаясь в логи про "no resolver > defined to resolve ..." на уровне warn. Действительно, ругается, всё встало на свои места, спасибо! > В случае, если resolver не указан, и при этом включён OCSP stapling > - nginx будет пытаться использовать IP-адреса OCSP-сервера, полученные > при старте Полученные от кого? -- sergio. From mdounin на mdounin.ru Fri Apr 12 13:34:52 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 12 Apr 2019 16:34:52 +0300 Subject: ssl_stapling without ssl_trusted_certificate In-Reply-To: <7186872b-9c89-f0d3-aca0-60903625608d@outerface.net> References: <20190401125452.GQ1877@mdounin.ru> <1cd30198-8939-42d6-ac2c-b192108a6bb8@outerface.net> <20190401144421.GR1877@mdounin.ru> <7a92467b-bb54-3171-58a1-583431bf2650@outerface.net> <20190401162205.GS1877@mdounin.ru> <7f5f0c7b-80e8-b873-dcd4-7e6d71ccefbb@outerface.net> <20190411195620.GF1877@mdounin.ru> <7186872b-9c89-f0d3-aca0-60903625608d@outerface.net> Message-ID: <20190412133452.GG1877@mdounin.ru> Hello! On Fri, Apr 12, 2019 at 12:02:39AM +0300, sergio via nginx-ru wrote: > On 11/04/2019 22:56, Maxim Dounin wrote: > > Я подписан, не надо меня в cc включать. У вас в DMARC policy написано "p=quarantine", в результате Mailman в ваших письмах переписывает адрес отправителя на "sergio via nginx-ru " и добавляет Cc. Соответственно при ответе на такое письмо - также случается Cc. Подробнее тут: https://wikitech.wikimedia.org/wiki/Mailman#DMARC_Compatibility Что с этим можно сделать, кроме как запретить постинг людям с подобными DMARC-политиками - я, честно говоря, не знаю. Вы, со своей стороны, можете убрать DMARC-политику, дуло исчезнет. > > Директиву error_log следует указывать на глобальном уровне. > > Ага! > > > при каждом обращении к OCSP-серверу ругаясь в логи про "no resolver > > defined to resolve ..." на уровне warn. > > Действительно, ругается, всё встало на свои места, спасибо! > > > В случае, если resolver не указан, и при этом включён OCSP stapling > > - nginx будет пытаться использовать IP-адреса OCSP-сервера, полученные > > при старте > > Полученные от кого? От системы, при помощи функции getaddrinfo() (или gethostbyname(), если getaddrinfo() нет). Обычно это выливается в использование конфигурации в /etc/nsswitch.conf, а далее /etc/hosts и системного DNS-резолвера, с конфигурацией в /etc/resolv.conf, но бывают и другие реализации - всё зависит от конкретной операционной системы. -- Maxim Dounin http://mdounin.ru/ From vladget на gmail.com Fri Apr 12 13:40:29 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Fri, 12 Apr 2019 16:40:29 +0300 Subject: =?UTF-8?B?UmU6IHVuZGVyc2NvcmVzX2luX2hlYWRlcnMgLSDQsdCw0LMg0LIg0LTQvtC60YM=?= =?UTF-8?B?0LzQtdC90YLQsNGG0LjQuCA/?= In-Reply-To: <1F976508-4B4D-4511-84BD-BE1243ECC218@nginx.com> References: <1F976508-4B4D-4511-84BD-BE1243ECC218@nginx.com> Message-ID: Не понимаю в чем баг, underscores_in_headers работает в контексте server где она описана. On Wed, Apr 10, 2019 at 2:25 PM Sergey Kandaurov wrote: > > > On 9 Apr 2019, at 23:31, Илья Шипицин wrote: > > > > привет! > > > > допустим, у нас своеобразное приложение. с подчеркиванием в хедерах (не > спрашивайте, у меня нет идей, чем заправлялись разработчики) > > > > читаем > > > > > https://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers > > > > ок. директиву надо писать в дефолт сервере. > > пишем > > > > log_format underscore '$http_header_underscore\t$status'; > > > > server { > > listen 80; > > server_name localhost; > > > > access_log /var/log/nginx/test.log underscore; > > > > location / { > > proxy_pass http://127.0.0.1:81; > > } > > > > } > > > > server { > > listen 80 default_server; > > server_name _; > > > > underscores_in_headers on; > > > > location / { return 404; } > > } > > > > server { > > listen 81; > > server_name localhost; > > > > location / { return 418; } > > > > } > > > > > > > > можете проверить (я проверял на 1.15.11 без доп модулей) - не работает. > > зато, если добавить в соответствующий сервер - работает. > > > > баг ? > > Нет, изменение поведения: hg.nginx.org/nginx/rev/c4d3310574e0 > Видимо, забыли поправить документацию. > > -- > Sergey Kandaurov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Apr 12 13:47:31 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 12 Apr 2019 18:47:31 +0500 Subject: =?UTF-8?B?UmU6IHVuZGVyc2NvcmVzX2luX2hlYWRlcnMgLSDQsdCw0LMg0LIg0LTQvtC60YM=?= =?UTF-8?B?0LzQtdC90YLQsNGG0LjQuCA/?= In-Reply-To: References: <1F976508-4B4D-4511-84BD-BE1243ECC218@nginx.com> Message-ID: "Если директива указана на уровне server , её значение используется только в том случае, если сервер является сервером по умолчанию. Указанное значение распространяется на все виртуальные серверы, слушающие на том же адресе и порту." документация. не поправили пт, 12 апр. 2019 г. в 18:40, Vladimir Getmanshchuk : > Не понимаю в чем баг, underscores_in_headers работает в контексте server > где она описана. > > On Wed, Apr 10, 2019 at 2:25 PM Sergey Kandaurov > wrote: > >> >> > On 9 Apr 2019, at 23:31, Илья Шипицин wrote: >> > >> > привет! >> > >> > допустим, у нас своеобразное приложение. с подчеркиванием в хедерах (не >> спрашивайте, у меня нет идей, чем заправлялись разработчики) >> > >> > читаем >> > >> > >> https://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers >> > >> > ок. директиву надо писать в дефолт сервере. >> > пишем >> > >> > log_format underscore '$http_header_underscore\t$status'; >> > >> > server { >> > listen 80; >> > server_name localhost; >> > >> > access_log /var/log/nginx/test.log underscore; >> > >> > location / { >> > proxy_pass http://127.0.0.1:81; >> > } >> > >> > } >> > >> > server { >> > listen 80 default_server; >> > server_name _; >> > >> > underscores_in_headers on; >> > >> > location / { return 404; } >> > } >> > >> > server { >> > listen 81; >> > server_name localhost; >> > >> > location / { return 418; } >> > >> > } >> > >> > >> > >> > можете проверить (я проверял на 1.15.11 без доп модулей) - не работает. >> > зато, если добавить в соответствующий сервер - работает. >> > >> > баг ? >> >> Нет, изменение поведения: hg.nginx.org/nginx/rev/c4d3310574e0 >> Видимо, забыли поправить документацию. >> >> -- >> Sergey Kandaurov >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Yours sincerely, > Vladimir Getmanshchuk > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vladget на gmail.com Sat Apr 13 05:54:04 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Sat, 13 Apr 2019 08:54:04 +0300 Subject: =?UTF-8?B?UmU6IHVuZGVyc2NvcmVzX2luX2hlYWRlcnMgLSDQsdCw0LMg0LIg0LTQvtC60YM=?= =?UTF-8?B?0LzQtdC90YLQsNGG0LjQuCA/?= In-Reply-To: References: <1F976508-4B4D-4511-84BD-BE1243ECC218@nginx.com> Message-ID: Все, теперь понял о чем вы. Действительно неправильная формулировка. пт, 12 квіт. 2019 о 16:47 Илья Шипицин пише: > "Если директива указана на уровне server > , её > значение используется только в том случае, если сервер является сервером по > умолчанию. Указанное значение распространяется на все виртуальные серверы, > слушающие на том же адресе и порту." > > документация. не поправили > > пт, 12 апр. 2019 г. в 18:40, Vladimir Getmanshchuk : > >> Не понимаю в чем баг, underscores_in_headers работает в контексте server >> где она описана. >> >> On Wed, Apr 10, 2019 at 2:25 PM Sergey Kandaurov >> wrote: >> >>> >>> > On 9 Apr 2019, at 23:31, Илья Шипицин wrote: >>> > >>> > привет! >>> > >>> > допустим, у нас своеобразное приложение. с подчеркиванием в хедерах >>> (не спрашивайте, у меня нет идей, чем заправлялись разработчики) >>> > >>> > читаем >>> > >>> > >>> https://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers >>> > >>> > ок. директиву надо писать в дефолт сервере. >>> > пишем >>> > >>> > log_format underscore '$http_header_underscore\t$status'; >>> > >>> > server { >>> > listen 80; >>> > server_name localhost; >>> > >>> > access_log /var/log/nginx/test.log underscore; >>> > >>> > location / { >>> > proxy_pass http://127.0.0.1:81; >>> > } >>> > >>> > } >>> > >>> > server { >>> > listen 80 default_server; >>> > server_name _; >>> > >>> > underscores_in_headers on; >>> > >>> > location / { return 404; } >>> > } >>> > >>> > server { >>> > listen 81; >>> > server_name localhost; >>> > >>> > location / { return 418; } >>> > >>> > } >>> > >>> > >>> > >>> > можете проверить (я проверял на 1.15.11 без доп модулей) - не работает. >>> > зато, если добавить в соответствующий сервер - работает. >>> > >>> > баг ? >>> >>> Нет, изменение поведения: hg.nginx.org/nginx/rev/c4d3310574e0 >>> Видимо, забыли поправить документацию. >>> >>> -- >>> Sergey Kandaurov >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> -- >> Yours sincerely, >> Vladimir Getmanshchuk >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Apr 13 12:49:18 2019 From: nginx-forum на forum.nginx.org (gegavat) Date: Sat, 13 Apr 2019 08:49:18 -0400 Subject: =?UTF-8?B?0JrQvtC90YTQuNCzINCf0YDQvtC60YHQuA==?= Message-ID: <8b33a4fd978681ee58268458ce0a0925.NginxMailingListRussian@forum.nginx.org> Приветствую! Уважамые знатоки, помогите с конфигом. Есть поддомен proxy.mysite.com Нужно сделать так, чтобы по ссылке proxy.mysite.com?url=http://somesite.com подгружался контент с указанной в GET-параметре страницы. В общем чтобы содержимое другого сайта грузилось именно с моего домена. Как может выглядить конфиг nginx для этой реализации? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283768,283768#msg-283768 From simplebox66 на gmail.com Tue Apr 16 09:26:15 2019 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Tue, 16 Apr 2019 12:26:15 +0300 Subject: =?UTF-8?B?0KHQu9C+0LbQvdGL0Lkg0LrQtdGIIFBPU1Qg0LfQsNC/0YDQvtGB0L7Qsg==?= Message-ID: Добрый день, помогите пожалуйста со следующей проблемой: Есть такой конфиг: server { server_name www.example.ru; proxy_cache_methods POST; proxy_cache_key $remote_addr$request_uri proxy_cache_valid 200 302 5m; expires 5m; location /1test { proxy_pass http://ololo; proxy_cache_methods GET; proxy_cache_key $server_name$request_uri proxy_cache_valid 200 302 1h; expires 1h; } location /2test { proxy_pass http://ololo; } location /3test { proxy_pass http://ololo; proxy_cache_methods GET; proxy_cache_key $server_name$request_uri proxy_cache_valid 200 302 3d; expires 3d; } } Суть конфига в том что при обращении на /*test/* POST запросом должно должен сработать кеш по ключу $remote_addr$request_uri у которого срок годности 5m При get запросе на /1test/* должен сработать кеш по ключу $server_name$request_uri сроком на 1h При get запросе на /2test/* кеша быть не должно При get запросе на /3test/* должен сработать кеш по ключу $server_name$request_uri сроком на 3d Но в моем случае это так не работает. И я понимаю почему, потому что происходит переопределение директив. Подскажите как решить мне эту задачу? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Apr 16 09:53:26 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 16 Apr 2019 14:53:26 +0500 Subject: =?UTF-8?B?0LTQu9C40L3QvdGL0LUg0LfQsNCz0L7Qu9C+0LLQutC4INCyIG1zaWUxMSAvIGh0?= =?UTF-8?B?dHAy?= Message-ID: привет, столкнулись с ситуацией, когда msie11 пытается отправлять очень длинную куку в логах видим 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded http2_max_field_size limit while processing HTTP/2 connection, client: 46.17.202.13, server: X.X.X.X:443 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state connection error 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send GOAWAY frame: last sid 17, error 11 собственно, вопрос. на уровне "error" ни одного сообщения. (у нас был включен error, соответственно, мы ничего не видели). есть предложение поднять уровень "http2 state connection error" до "error" Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Tue Apr 16 12:09:26 2019 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Tue, 16 Apr 2019 15:09:26 +0300 Subject: =?UTF-8?B?UmU6INCh0LvQvtC20L3Ri9C5INC60LXRiCBQT1NUINC30LDQv9GA0L7RgdC+0LI=?= In-Reply-To: References: Message-ID: <6c9271a5e3c7b3628f4238d59c7f514d@kopeyko.ru> Иван Мишин писал 2019-04-16 12:26: > Добрый день, помогите пожалуйста со > следующей проблемой: Добрый день, Иван! > Есть такой конфиг: ... > Но в моем случае это так не работает. Потому что вы * не задали "proxy_cache_path" - прокси пока некуда кешировать * не включили само кеширование директивой proxy_cache -- Best regards, Andrey A. Kopeyko From chmind на yandex.ru Tue Apr 16 13:10:57 2019 From: chmind на yandex.ru (chmind на yandex.ru) Date: Tue, 16 Apr 2019 16:10:57 +0300 Subject: alias 301 redirect Message-ID: <0CBD0D16-3D45-43F5-B704-48ECF82A9BB9@yandex.ru> Добрый день. Есть такая конфигурация: location ~ /folder/images/ { alias /var/www/domain.com/folder/src/images/ ; } при запросе domain.com/folder/images/test.png Я почему-то получаю 301 редирект на domain.com/folder/images/test.png/ Судя по логам запрос попадает именно в этот локейшен и больше никуда. Подскажите пожалуйста в чем может быть проблема ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Apr 16 14:23:47 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2019 17:23:47 +0300 Subject: =?UTF-8?B?UmU6INC00LvQuNC90L3Ri9C1INC30LDQs9C+0LvQvtCy0LrQuCDQsiBtc2llMTEg?= =?UTF-8?B?LyBodHRwMg==?= In-Reply-To: References: Message-ID: <20190416142347.GQ1877@mdounin.ru> Hello! On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote: > привет, > > столкнулись с ситуацией, когда msie11 пытается отправлять очень длинную куку > > в логах видим > > 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded > http2_max_field_size limit while processing HTTP/2 connection, client: > 46.17.202.13, server: X.X.X.X:443 > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state connection > error > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send GOAWAY > frame: last sid 17, error 11 > > > собственно, вопрос. на уровне "error" ни одного сообщения. > (у нас был включен error, соответственно, мы ничего не видели). > есть предложение поднять уровень "http2 state connection error" до "error" Ошибки, которые вызываются некорректными действиями клиента, как то попытки прислать некорректные или слишком длинные заголовки - стандартно логгируются именно на уровне info. На уровне error логгируются те проблемы, решение которых - на серверной стороне. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Apr 16 14:37:12 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2019 17:37:12 +0300 Subject: alias 301 redirect In-Reply-To: <0CBD0D16-3D45-43F5-B704-48ECF82A9BB9@yandex.ru> References: <0CBD0D16-3D45-43F5-B704-48ECF82A9BB9@yandex.ru> Message-ID: <20190416143712.GS1877@mdounin.ru> Hello! On Tue, Apr 16, 2019 at 04:10:57PM +0300, chmind на yandex.ru wrote: > Добрый день. > > Есть такая конфигурация: > > location ~ /folder/images/ { > alias /var/www/domain.com/folder/src/images/ ; > } > > при запросе domain.com/folder/images/test.png > > Я почему-то получаю 301 редирект на domain.com/folder/images/test.png/ > > Судя по логам запрос попадает именно в этот локейшен и больше никуда. > > Подскажите пожалуйста в чем может быть проблема ? При использовании директивы alias в location, заданном регулярным выражением, директива alias определяет полный путь к запрашиваемому ресурсу. Соответственно у вас для любого запроса - путь в файловой системе указывает на каталог, и из-за этого на любой запрос возвращается перенаправление. Если вы на самом деле хотели написать префиксный location для запросов в /folder/images/ - уберите "~". -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Apr 16 15:10:17 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2019 18:10:17 +0300 Subject: nginx-1.15.12 Message-ID: <20190416151016.GV1877@mdounin.ru> Изменения в nginx 1.15.12 16.04.2019 *) Исправление: в рабочем процессе мог произойти segmentation fault, если в директивах ssl_certificate или ssl_certificate_key использовались переменные и был включён OCSP stapling. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Tue Apr 16 15:14:12 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 16 Apr 2019 20:14:12 +0500 Subject: =?UTF-8?B?UmU6INC00LvQuNC90L3Ri9C1INC30LDQs9C+0LvQvtCy0LrQuCDQsiBtc2llMTEg?= =?UTF-8?B?LyBodHRwMg==?= In-Reply-To: <20190416142347.GQ1877@mdounin.ru> References: <20190416142347.GQ1877@mdounin.ru> Message-ID: вт, 16 апр. 2019 г. в 19:23, Maxim Dounin : > Hello! > > On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote: > > > привет, > > > > столкнулись с ситуацией, когда msie11 пытается отправлять очень длинную > куку > > > > в логах видим > > > > 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded > > http2_max_field_size limit while processing HTTP/2 connection, client: > > 46.17.202.13, server: X.X.X.X:443 > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state > connection > > error > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send GOAWAY > > frame: last sid 17, error 11 > > > > > > собственно, вопрос. на уровне "error" ни одного сообщения. > > (у нас был включен error, соответственно, мы ничего не видели). > > есть предложение поднять уровень "http2 state connection error" до > "error" > > Ошибки, которые вызываются некорректными действиями клиента, как > то попытки прислать некорректные или слишком длинные заголовки - > стандартно логгируются именно на уровне info. На уровне error > логгируются те проблемы, решение которых - на серверной стороне. > а клиенту кто-то сказал, что 6 килобайт в хедере это некорректно ? в RFC такое ? > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Apr 16 15:33:36 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2019 18:33:36 +0300 Subject: =?UTF-8?B?UmU6INC00LvQuNC90L3Ri9C1INC30LDQs9C+0LvQvtCy0LrQuCDQsiBtc2llMTEg?= =?UTF-8?B?LyBodHRwMg==?= In-Reply-To: References: <20190416142347.GQ1877@mdounin.ru> Message-ID: <20190416153336.GX1877@mdounin.ru> Hello! On Tue, Apr 16, 2019 at 08:14:12PM +0500, Илья Шипицин wrote: > вт, 16 апр. 2019 г. в 19:23, Maxim Dounin : > > > Hello! > > > > On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote: > > > > > привет, > > > > > > столкнулись с ситуацией, когда msie11 пытается отправлять очень длинную > > куку > > > > > > в логах видим > > > > > > 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded > > > http2_max_field_size limit while processing HTTP/2 connection, client: > > > 46.17.202.13, server: X.X.X.X:443 > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state > > connection > > > error > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send GOAWAY > > > frame: last sid 17, error 11 > > > > > > > > > собственно, вопрос. на уровне "error" ни одного сообщения. > > > (у нас был включен error, соответственно, мы ничего не видели). > > > есть предложение поднять уровень "http2 state connection error" до > > "error" > > > > Ошибки, которые вызываются некорректными действиями клиента, как > > то попытки прислать некорректные или слишком длинные заголовки - > > стандартно логгируются именно на уровне info. На уровне error > > логгируются те проблемы, решение которых - на серверной стороне. > > > > а клиенту кто-то сказал, что 6 килобайт в хедере это некорректно ? > в RFC такое ? Это не важно. Если ошибка может быть вызвана действиями клиента - используется уровень info. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Apr 16 15:39:48 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 16 Apr 2019 20:39:48 +0500 Subject: =?UTF-8?B?UmU6INC00LvQuNC90L3Ri9C1INC30LDQs9C+0LvQvtCy0LrQuCDQsiBtc2llMTEg?= =?UTF-8?B?LyBodHRwMg==?= In-Reply-To: <20190416153336.GX1877@mdounin.ru> References: <20190416142347.GQ1877@mdounin.ru> <20190416153336.GX1877@mdounin.ru> Message-ID: я вижу упоминание SETTINGS_MAX_HEADER_LIST_SIZE в grpc. в http2 клиенту это передается ? вт, 16 апр. 2019 г. в 20:33, Maxim Dounin : > Hello! > > On Tue, Apr 16, 2019 at 08:14:12PM +0500, Илья Шипицин wrote: > > > вт, 16 апр. 2019 г. в 19:23, Maxim Dounin : > > > > > Hello! > > > > > > On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote: > > > > > > > привет, > > > > > > > > столкнулись с ситуацией, когда msie11 пытается отправлять очень > длинную > > > куку > > > > > > > > в логах видим > > > > > > > > 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded > > > > http2_max_field_size limit while processing HTTP/2 connection, > client: > > > > 46.17.202.13, server: X.X.X.X:443 > > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state > > > connection > > > > error > > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send > GOAWAY > > > > frame: last sid 17, error 11 > > > > > > > > > > > > собственно, вопрос. на уровне "error" ни одного сообщения. > > > > (у нас был включен error, соответственно, мы ничего не видели). > > > > есть предложение поднять уровень "http2 state connection error" до > > > "error" > > > > > > Ошибки, которые вызываются некорректными действиями клиента, как > > > то попытки прислать некорректные или слишком длинные заголовки - > > > стандартно логгируются именно на уровне info. На уровне error > > > логгируются те проблемы, решение которых - на серверной стороне. > > > > > > > а клиенту кто-то сказал, что 6 килобайт в хедере это некорректно ? > > в RFC такое ? > > Это не важно. > > Если ошибка может быть вызвана действиями клиента - используется > уровень info. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Apr 16 16:07:14 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2019 19:07:14 +0300 Subject: =?UTF-8?B?UmU6INC00LvQuNC90L3Ri9C1INC30LDQs9C+0LvQvtCy0LrQuCDQsiBtc2llMTEg?= =?UTF-8?B?LyBodHRwMg==?= In-Reply-To: References: <20190416142347.GQ1877@mdounin.ru> <20190416153336.GX1877@mdounin.ru> Message-ID: <20190416160714.GY1877@mdounin.ru> Hello! On Tue, Apr 16, 2019 at 08:39:48PM +0500, Илья Шипицин wrote: > я вижу упоминание SETTINGS_MAX_HEADER_LIST_SIZE в grpc. > в http2 клиенту это передается ? SETTINGS_MAX_HEADER_LIST_SIZE - это ограничение на суммарный размер заголовков, в то время как http2_max_field_size - ограничение на одно поле. И нет, не передаётся. Если бы передавалось - для честных клиентов ситуация могла бы стать только хуже: если бы вдруг клиент решил, что что раз сказали нельзя - то и нельзя, и не стал бы отправлять такой запрос - на сервере о проблеме бы вообще никогда не узнали. (Каждый раз, когда я смотрю на HTTP/2, мне становится грустно.) > > вт, 16 апр. 2019 г. в 20:33, Maxim Dounin : > > > Hello! > > > > On Tue, Apr 16, 2019 at 08:14:12PM +0500, Илья Шипицин wrote: > > > > > вт, 16 апр. 2019 г. в 19:23, Maxim Dounin : > > > > > > > Hello! > > > > > > > > On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote: > > > > > > > > > привет, > > > > > > > > > > столкнулись с ситуацией, когда msie11 пытается отправлять очень > > длинную > > > > куку > > > > > > > > > > в логах видим > > > > > > > > > > 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded > > > > > http2_max_field_size limit while processing HTTP/2 connection, > > client: > > > > > 46.17.202.13, server: X.X.X.X:443 > > > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state > > > > connection > > > > > error > > > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send > > GOAWAY > > > > > frame: last sid 17, error 11 > > > > > > > > > > > > > > > собственно, вопрос. на уровне "error" ни одного сообщения. > > > > > (у нас был включен error, соответственно, мы ничего не видели). > > > > > есть предложение поднять уровень "http2 state connection error" до > > > > "error" > > > > > > > > Ошибки, которые вызываются некорректными действиями клиента, как > > > > то попытки прислать некорректные или слишком длинные заголовки - > > > > стандартно логгируются именно на уровне info. На уровне error > > > > логгируются те проблемы, решение которых - на серверной стороне. > > > > > > > > > > а клиенту кто-то сказал, что 6 килобайт в хедере это некорректно ? > > > в RFC такое ? > > > > Это не важно. > > > > Если ошибка может быть вызвана действиями клиента - используется > > уровень info. > > > > -- > > Maxim Dounin > > http://mdounin.ru/ > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://mdounin.ru/ From simplebox66 на gmail.com Wed Apr 17 08:52:47 2019 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 17 Apr 2019 11:52:47 +0300 Subject: =?UTF-8?B?UmU6INCh0LvQvtC20L3Ri9C5INC60LXRiCBQT1NUINC30LDQv9GA0L7RgdC+0LI=?= In-Reply-To: <6c9271a5e3c7b3628f4238d59c7f514d@kopeyko.ru> References: <6c9271a5e3c7b3628f4238d59c7f514d@kopeyko.ru> Message-ID: > > * не задали "proxy_cache_path" - прокси пока некуда кешировать > * не включили само кеширование директивой proxy_cache Это задано на уровне http. Мой вопрос не в том что кеширование не работает, а в том что оно работает не так как надо, не так как планировал. вт, 16 апр. 2019 г. в 15:09, Andrey Kopeyko : > Иван Мишин писал 2019-04-16 12:26: > > Добрый день, помогите пожалуйста со > > следующей проблемой: > > Добрый день, Иван! > > > Есть такой конфиг: > ... > > Но в моем случае это так не работает. > > Потому что вы > * не задали "proxy_cache_path" - прокси пока некуда кешировать > * не включили само кеширование директивой proxy_cache > > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chmind на yandex.ru Wed Apr 17 08:58:59 2019 From: chmind на yandex.ru (chmind на yandex.ru) Date: Wed, 17 Apr 2019 11:58:59 +0300 Subject: alias 301 redirect In-Reply-To: <20190416143712.GS1877@mdounin.ru> References: <0CBD0D16-3D45-43F5-B704-48ECF82A9BB9@yandex.ru> <20190416143712.GS1877@mdounin.ru> Message-ID: <4774CB2E-1341-4B7E-B94B-E6E0DE0BCA88@yandex.ru> Спасибо. > On 16 Apr 2019, at 17:37, Maxim Dounin wrote: > > Hello! > > On Tue, Apr 16, 2019 at 04:10:57PM +0300, chmind на yandex.ru wrote: > >> Добрый день. >> >> Есть такая конфигурация: >> >> location ~ /folder/images/ { >> alias /var/www/domain.com/folder/src/images/ ; >> } >> >> при запросе domain.com/folder/images/test.png >> >> Я почему-то получаю 301 редирект на domain.com/folder/images/test.png/ >> >> Судя по логам запрос попадает именно в этот локейшен и больше никуда. >> >> Подскажите пожалуйста в чем может быть проблема ? > > При использовании директивы alias в location, заданном регулярным > выражением, директива alias определяет полный путь к > запрашиваемому ресурсу. Соответственно у вас для любого запроса - > путь в файловой системе указывает на каталог, и из-за этого на > любой запрос возвращается перенаправление. > > Если вы на самом деле хотели написать префиксный location > для запросов в /folder/images/ - уберите "~". > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From andrey на kopeyko.ru Wed Apr 17 11:14:44 2019 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 17 Apr 2019 14:14:44 +0300 (MSK) Subject: =?UTF-8?B?UmU6INCh0LvQvtC20L3Ri9C5INC60LXRiCBQT1NUINC30LDQv9GA0L7RgdC+0LI=?= In-Reply-To: References: <6c9271a5e3c7b3628f4238d59c7f514d@kopeyko.ru> Message-ID: On Wed, 17 Apr 2019, Иван Мишин wrote: >> * не задали "proxy_cache_path" - прокси пока некуда кешировать >> * не включили само кеширование директивой proxy_cache > > Это задано на уровне http. > Мой вопрос не в том что кеширование не работает, а в том что оно работает > не так как надо, не так как планировал. Тогда надо включать debug_connection, делать запрос, и читать error.log > вт, 16 апр. 2019 г. в 15:09, Andrey Kopeyko : > >> Иван Мишин писал 2019-04-16 12:26: >>> Добрый день, помогите пожалуйста со >>> следующей проблемой: >> >> Добрый день, Иван! >> >>> Есть такой конфиг: >> ... >>> Но в моем случае это так не работает. >> >> Потому что вы >> * не задали "proxy_cache_path" - прокси пока некуда кешировать >> * не включили само кеширование директивой proxy_cache >> >> >> -- >> Best regards, >> Andrey A. Kopeyko >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Andrey A. Kopeyko From fe на hamilton.rinet.ru Wed Apr 17 19:42:37 2019 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Wed, 17 Apr 2019 22:42:37 +0300 Subject: =?UTF-8?B?0J/QvtC70YPRh9C40YLRjCDQutC70Y7RhyBsaW1pdF9yYXRlINCyINC70L7Qs9C1?= =?UTF-8?B?IHJhdGVfbGltaXQt0LA=?= Message-ID: Привет! Возникла задача rate_limit-итить обращения к api при помощи Nginx-а и таким образом защититься от DDOS-а. Авторизация к api идет через jwt, в ключе есть логин пользователя. Поэтому я уже заказал demo nginx plus, планирую воспользоваться функционалом jwt и rate limit-ить по логину, примерно так: > auth_jwt_claim_set $login info login; > limit_req_zone $login zone=one:10m rate=1r/s; а дальше хочется получить список нехороших логинов, через которые нас пытаются досить. Прочитал доку https://www.nginx.com/blog/rate-limiting-nginx/ -- там написано что я получу адрес клиента, request и хостнейм в слуяае превышения лимита. И это здорово. А можно как-то получить значение ключа (в моем случае это логин пользователя), который привысил rate limit? Пока есть гипотеза логгировать логин в access.log и потом коррелировать access.log и error.log, но выглядит немного странно. И вдруг можно получить результат сильно проще. -- Fedor Dikarev From oleg на mamontov.net Thu Apr 18 08:16:43 2019 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Thu, 18 Apr 2019 11:16:43 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0LrQu9GO0YcgbGltaXRfcmF0ZSDQsiDQu9C+?= =?UTF-8?B?0LPQtSByYXRlX2xpbWl0LdCw?= In-Reply-To: References: Message-ID: <20190418081643.pvhymuj4yhe43uxu@xenon.mamontov.net> On Wed, Apr 17, 2019 at 10:42:37PM +0300, Fedor Dikarev wrote: >Привет! > >Возникла задача rate_limit-итить обращения к api при помощи Nginx-а и >таким образом защититься от DDOS-а. >Авторизация к api идет через jwt, в ключе есть логин пользователя. >Поэтому я уже заказал demo nginx plus, планирую воспользоваться >функционалом jwt и rate limit-ить по логину, примерно так: >>auth_jwt_claim_set $login info login; >> limit_req_zone $login zone=one:10m rate=1r/s; > >а дальше хочется получить список нехороших логинов, через которые нас >пытаются досить. >Прочитал доку https://www.nginx.com/blog/rate-limiting-nginx/ -- там >написано что я получу адрес клиента, request и хостнейм в слуяае >превышения лимита. И это здорово. >А можно как-то получить значение ключа (в моем случае это логин >пользователя), который привысил rate limit? > >Пока есть гипотеза логгировать логин в access.log и потом >коррелировать access.log и error.log, но выглядит немного странно. И >вдруг можно получить результат сильно проще. Перехватить 503 с помощью error_page и обработать в специальном location с кастомизированным log_format ? -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From fe на hamilton.rinet.ru Thu Apr 18 11:53:28 2019 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Thu, 18 Apr 2019 14:53:28 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0LrQu9GO0YcgbGltaXRfcmF0ZSDQsiDQu9C+?= =?UTF-8?B?0LPQtSByYXRlX2xpbWl0LdCw?= In-Reply-To: <20190418081643.pvhymuj4yhe43uxu@xenon.mamontov.net> References: <20190418081643.pvhymuj4yhe43uxu@xenon.mamontov.net> Message-ID: <3ea2a35e-3a01-fe1d-53c5-5537481e4ac5@hamilton.rinet.ru> 18.04.2019 11:16, Oleg A. Mamontov пишет: > On Wed, Apr 17, 2019 at 10:42:37PM +0300, Fedor Dikarev wrote: >> Привет! >> >> Возникла задача rate_limit-итить обращения к api при помощи Nginx-а и >> таким образом защититься от DDOS-а. >> Авторизация к api идет через jwt, в ключе есть логин пользователя. >> Поэтому я уже заказал demo nginx plus, планирую воспользоваться >> функционалом jwt и rate limit-ить по логину, примерно так: >>> auth_jwt_claim_set $login info login; >>> limit_req_zone $login zone=one:10m rate=1r/s; >> >> а дальше хочется получить список нехороших логинов, через которые нас >> пытаются досить. >> Прочитал доку https://www.nginx.com/blog/rate-limiting-nginx/ -- там >> написано что я получу адрес клиента, request и хостнейм в слуяае >> превышения лимита. И это здорово. >> А можно как-то получить значение ключа (в моем случае это логин >> пользователя), который привысил rate limit? >> >> Пока есть гипотеза логгировать логин в access.log и потом >> коррелировать access.log и error.log, но выглядит немного странно. И >> вдруг можно получить результат сильно проще. > > Перехватить 503 с помощью error_page и обработать в специальном location > с кастомизированным log_format ? Привет, Олег! Спасибо за совет: да, все просто и логично, я почему-то не подумал в эту сторону. Сегодня-завтра попробуем поднять этот вариант на QA, понагружаем немного и отпишусь о результатах. -- Fedor Dikarev From chipitsine на gmail.com Thu Apr 18 11:59:10 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 18 Apr 2019 16:59:10 +0500 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0LrQu9GO0YcgbGltaXRfcmF0ZSDQsiDQu9C+?= =?UTF-8?B?0LPQtSByYXRlX2xpbWl0LdCw?= In-Reply-To: <3ea2a35e-3a01-fe1d-53c5-5537481e4ac5@hamilton.rinet.ru> References: <20190418081643.pvhymuj4yhe43uxu@xenon.mamontov.net> <3ea2a35e-3a01-fe1d-53c5-5537481e4ac5@hamilton.rinet.ru> Message-ID: при такой маршрутизации запросов возможно потребуется включить *log*_ *subrequest* чт, 18 апр. 2019 г. в 16:53, Fedor Dikarev : > 18.04.2019 11:16, Oleg A. Mamontov пишет: > > On Wed, Apr 17, 2019 at 10:42:37PM +0300, Fedor Dikarev wrote: > >> Привет! > >> > >> Возникла задача rate_limit-итить обращения к api при помощи Nginx-а и > >> таким образом защититься от DDOS-а. > >> Авторизация к api идет через jwt, в ключе есть логин пользователя. > >> Поэтому я уже заказал demo nginx plus, планирую воспользоваться > >> функционалом jwt и rate limit-ить по логину, примерно так: > >>> auth_jwt_claim_set $login info login; > >>> limit_req_zone $login zone=one:10m rate=1r/s; > >> > >> а дальше хочется получить список нехороших логинов, через которые нас > >> пытаются досить. > >> Прочитал доку https://www.nginx.com/blog/rate-limiting-nginx/ -- там > >> написано что я получу адрес клиента, request и хостнейм в слуяае > >> превышения лимита. И это здорово. > >> А можно как-то получить значение ключа (в моем случае это логин > >> пользователя), который привысил rate limit? > >> > >> Пока есть гипотеза логгировать логин в access.log и потом > >> коррелировать access.log и error.log, но выглядит немного странно. И > >> вдруг можно получить результат сильно проще. > > > > Перехватить 503 с помощью error_page и обработать в специальном location > > с кастомизированным log_format ? > > Привет, Олег! > > Спасибо за совет: да, все просто и логично, я почему-то не подумал в эту > сторону. Сегодня-завтра попробуем поднять этот вариант на QA, > понагружаем немного и отпишусь о результатах. > -- > Fedor Dikarev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From oleg на mamontov.net Thu Apr 18 13:23:44 2019 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Thu, 18 Apr 2019 16:23:44 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0LrQu9GO0YcgbGltaXRfcmF0ZSDQsiDQu9C+?= =?UTF-8?B?0LPQtSByYXRlX2xpbWl0LdCw?= In-Reply-To: References: <20190418081643.pvhymuj4yhe43uxu@xenon.mamontov.net> <3ea2a35e-3a01-fe1d-53c5-5537481e4ac5@hamilton.rinet.ru> Message-ID: <20190418132344.5iihcoidxxmo3cio@xenon.mamontov.net> On Thu, Apr 18, 2019 at 04:59:10PM +0500, Илья Шипицин wrote: >при такой маршрутизации запросов возможно потребуется включить *log*_ >*subrequest* Да нет, не потребуется. >чт, 18 апр. 2019 г. в 16:53, Fedor Dikarev : > >> 18.04.2019 11:16, Oleg A. Mamontov пишет: >> > On Wed, Apr 17, 2019 at 10:42:37PM +0300, Fedor Dikarev wrote: >> >> Привет! >> >> >> >> Возникла задача rate_limit-итить обращения к api при помощи Nginx-а и >> >> таким образом защититься от DDOS-а. >> >> Авторизация к api идет через jwt, в ключе есть логин пользователя. >> >> Поэтому я уже заказал demo nginx plus, планирую воспользоваться >> >> функционалом jwt и rate limit-ить по логину, примерно так: >> >>> auth_jwt_claim_set $login info login; >> >>> limit_req_zone $login zone=one:10m rate=1r/s; >> >> >> >> а дальше хочется получить список нехороших логинов, через которые нас >> >> пытаются досить. >> >> Прочитал доку https://www.nginx.com/blog/rate-limiting-nginx/ -- там >> >> написано что я получу адрес клиента, request и хостнейм в слуяае >> >> превышения лимита. И это здорово. >> >> А можно как-то получить значение ключа (в моем случае это логин >> >> пользователя), который привысил rate limit? >> >> >> >> Пока есть гипотеза логгировать логин в access.log и потом >> >> коррелировать access.log и error.log, но выглядит немного странно. И >> >> вдруг можно получить результат сильно проще. >> > >> > Перехватить 503 с помощью error_page и обработать в специальном location >> > с кастомизированным log_format ? >> >> Привет, Олег! >> >> Спасибо за совет: да, все просто и логично, я почему-то не подумал в эту >> сторону. Сегодня-завтра попробуем поднять этот вариант на QA, >> понагружаем немного и отпишусь о результатах. >> -- >> Fedor Dikarev -- Cheers, Oleg A. Mamontov From nginx-forum на forum.nginx.org Sat Apr 20 08:16:21 2019 From: nginx-forum на forum.nginx.org (RuslanValitov) Date: Sat, 20 Apr 2019 04:16:21 -0400 Subject: =?UTF-8?B?0J/QvtC00LrQu9GO0YfQtdC90LjQtSDQuiBSZWRpcyDRh9C10YDQtdC3IG5naW54?= Message-ID: <1745892d3663ec5c0382093b2a7df2ac.NginxMailingListRussian@forum.nginx.org> Добрый день уважаемые. Имеется: 1. Nginx + lua 2. redis 5.0 3. Внешнее приложение с redis клиентом Задача: подключить внешнее приложение к redis. Доступ на прямую по external_ip:6001 внешнему приложения давать не хочу, остается открыть соединение клиента с redis через nginx c предварительной аутентификацией. Как я это представляю: 1. Клиент запрашивает соединение на site.com/connect_to_redis 2. nginx по средствам lua проверяет логин и пароль и если все ОК, то происходит внутренний редирект с локейшена /connect_to_redis на local_ip:6001 3. nginx держит (не разрывает) соединение. Поправьте меня если я не верно представляю схему работы. Быть может кто предложит иную схему? Пока не представляю: 1. Как при попытке соединения внешнего клиента redis к redis server (находящегося за nginx) передать предварительно nginx логин и пароль что бы lua скрипт их проверил для создания внутреннего редиректа? 2. Как заставить nginx держать коннект до отключения redis клиента от сервера? Заранее премного вам благодарен. С уважением и наилучшими пожеланиями! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283863,283863#msg-283863 From nginx-forum на forum.nginx.org Mon Apr 22 15:17:37 2019 From: nginx-forum на forum.nginx.org (bagas) Date: Mon, 22 Apr 2019 11:17:37 -0400 Subject: =?UTF-8?B?0L7RgtC/0YDQsNCy0LrQsCDQv9C+0YfRgtGLINC+0YIg0L7Qv9GA0LXQtNC10Ls=?= =?UTF-8?B?0LXQvdC90L7Qs9C+INC/0L7Rh9GC0L7QstC+0LPQviDRj9GJ0LjQutCw?= Message-ID: <7e23a46e0ccc663712015d2fd5bfcbbd.NginxMailingListRussian@forum.nginx.org> Добрый вечер. Столкнулся с проблемой отправки писем у сайта. На сервере больше одного сайта. При отправке письма через консоль сервер все нормально отправляется. echo "Test mail from work service. Тестовое письмо, проверка работоспособности." | sendmail -fwww@мой_сайт.net мой_ящик@ya.ru Но вот если через php отправка, то письмо как бы отправляет от основного домена на сервер который в бит в настройках exim primary_hostname = мой_домен.ru Письмо приходит с пометкой что отправлено через: мой_домен.ru подписан: мой_сайт.net система FreeBSD. мта exim4 php 7.2 nginx 1.14 В виртуал хосте пробовал добавлять в обработчик php fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f www@мой_сайт.net"; и так fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i -fwww@мой_сайт.net"; Не получается не в какую. Уже попробовал указать в php-fpm php_admin_value[sendmail_path] = "/usr/sbin/sendmail -t -i -fwww@мой_сайт.net" Не работает. На apache24 достаточно было указать в настройках виртуал хоста параметр php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -fwww@мой_сайт.net" Подскажите пожалуйста что я делаю не так, уже все пере пробовал Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283870,283870#msg-283870 From dmitriy на lyalyuev.info Tue Apr 23 06:31:11 2019 From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev) Date: Tue, 23 Apr 2019 09:31:11 +0300 Subject: =?UTF-8?B?UmU6INC+0YLQv9GA0LDQstC60LAg0L/QvtGH0YLRiyDQvtGCINC+0L/RgNC10LQ=?= =?UTF-8?B?0LXQu9C10L3QvdC+0LPQviDQv9C+0YfRgtC+0LLQvtCz0L4g0Y/RidC40Lo=?= =?UTF-8?B?0LA=?= In-Reply-To: <7e23a46e0ccc663712015d2fd5bfcbbd.NginxMailingListRussian@forum.nginx.org> References: <7e23a46e0ccc663712015d2fd5bfcbbd.NginxMailingListRussian@forum.nginx.org> Message-ID: <06EB0F10-DC60-494B-83CA-5C52C010B0AA@lyalyuev.info> Простите за мое непонимание, но при чем тут Nginx? > 22 апр. 2019 г., в 18:17, bagas написал(а): > > Добрый вечер. > > Столкнулся с проблемой отправки писем у сайта. > > На сервере больше одного сайта. > При отправке письма через консоль сервер все нормально отправляется. > echo "Test mail from work service. Тестовое письмо, проверка > работоспособности." | sendmail -fwww@мой_сайт.net мой_ящик@ya.ru > Но вот если через php отправка, то письмо как бы отправляет от основного > домена на сервер который в бит в настройках exim primary_hostname = > мой_домен.ru > > Письмо приходит с пометкой что > отправлено через: мой_домен.ru > подписан: мой_сайт.net > > система FreeBSD. > мта exim4 > php 7.2 > nginx 1.14 > > В виртуал хосте пробовал добавлять в обработчик php > fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f > www@мой_сайт.net"; > и так > fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i > -fwww@мой_сайт.net"; > Не получается не в какую. > Уже попробовал указать в php-fpm > php_admin_value[sendmail_path] = "/usr/sbin/sendmail -t -i > -fwww@мой_сайт.net" > Не работает. > > На apache24 достаточно было указать в настройках виртуал хоста параметр > php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -fwww@мой_сайт.net" > > Подскажите пожалуйста что я делаю не так, уже все пере пробовал > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283870,283870#msg-283870 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: smime.p7s Тип: application/pkcs7-signature Размер: 3884 байтов Описание: отсутствует URL: From ano на bestmx.net Tue Apr 23 06:54:33 2019 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Tue, 23 Apr 2019 09:54:33 +0300 Subject: =?UTF-8?B?UmU6INC+0YLQv9GA0LDQstC60LAg0L/QvtGH0YLRiyDQvtGCINC+0L/RgNC10LQ=?= =?UTF-8?B?0LXQu9C10L3QvdC+0LPQviDQv9C+0YfRgtC+0LLQvtCz0L4g0Y/RidC40Lo=?= =?UTF-8?B?0LA=?= In-Reply-To: <7e23a46e0ccc663712015d2fd5bfcbbd.NginxMailingListRussian@forum.nginx.org> References: <7e23a46e0ccc663712015d2fd5bfcbbd.NginxMailingListRussian@forum.nginx.org> Message-ID: nginx тут, действительно, совершенно не при делах. exim разрешает задавать envelope_from только суперпользователю (root) и тем системным пользователям, которые перечислены в trusted_users. Чтобы пых имел возможность подставлять любой envelope_from при отправке почты, надо написать в конфиге exim нечто вроде trusted_users = www-data (вместо www-data должно быть имя юзера, под которым пых у вас запускается) Отдельный вопрос, надо ли задавать envelope_from для каждого сайта. Получатель видит в письме заголовки From и Reply-To, а не Return-Path, и, нажимая кнопку Reply, отвечает на адрес из заголовка Reply-To (если задан), или From (если заголовка Reply-To нет). From nginx-forum на forum.nginx.org Tue Apr 23 06:57:46 2019 From: nginx-forum на forum.nginx.org (anatolr) Date: Tue, 23 Apr 2019 02:57:46 -0400 Subject: =?UTF-8?B?0YHQv9C10YbQuNCw0LvRjNC90YvQtSDRgdC40LzQstC+0LvRiyDQsiDQt9Cw0L8=?= =?UTF-8?B?0YDQvtGB0LDRhQ==?= Message-ID: Пытаюсь закрыть выполнение такого вида запросов к сайту содержащих специальный символ < или > http://www.host.ru/index.php/> 3C пробовал в hex кодe как-то так (.*)[^\3С]+(.*) как правильно указать в location такого вида символы? Прошу помогите пожайлуста как запретить такие строки в nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283878,283878#msg-283878 From vladget на gmail.com Tue Apr 23 07:52:09 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Tue, 23 Apr 2019 10:52:09 +0300 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0LjQsNC70YzQvdGL0LUg0YHQuNC80LLQvtC70Ysg0LIg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdCw0YU=?= In-Reply-To: References: Message-ID: ИМХО, вы не тем занимаетесь, боритесь с XSS на backend + хидер для браузеров: # This header enables the Cross-site scripting (XSS) filter built into most recent web browsers. # It's usually enabled by default anyway, so the role of this header is to re-enable the filter for # this particular website if it was disabled by the user. # https://www.owasp.org/index.php/List_of_useful_HTTP_headers add_header X-XSS-Protection "1; mode=block"; On Tue, Apr 23, 2019 at 9:57 AM anatolr wrote: > Пытаюсь закрыть выполнение такого вида запросов к сайту > содержащих специальный символ < или > > > http://www.host.ru/index.php/> > > > делаю с помощью > > location ~* ^(.*)(\<)+(.*)$ { > return 404; > } > > но запрос не перехватывается код > 3C > > пробовал в hex кодe как-то так (.*)[^\3С]+(.*) > > как правильно указать в location такого вида символы? > > Прошу помогите пожайлуста как запретить такие строки в nginx? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,283878,283878#msg-283878 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Apr 23 08:10:30 2019 From: nginx-forum на forum.nginx.org (anatolr) Date: Tue, 23 Apr 2019 04:10:30 -0400 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0LjQsNC70YzQvdGL0LUg0YHQuNC80LLQvtC70Ysg0LIg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdCw0YU=?= In-Reply-To: References: Message-ID: <2dc509a03ec86f721c8c1139cc895ef0.NginxMailingListRussian@forum.nginx.org> в том то и дело что в nginx есть опция включенная add_header X-XSS-Protection "1; mode=block"; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283878,283880#msg-283880 From nginx-forum на forum.nginx.org Tue Apr 23 08:48:25 2019 From: nginx-forum на forum.nginx.org (anatolr) Date: Tue, 23 Apr 2019 04:48:25 -0400 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0LjQsNC70YzQvdGL0LUg0YHQuNC80LLQvtC70Ysg0LIg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdCw0YU=?= In-Reply-To: <2dc509a03ec86f721c8c1139cc895ef0.NginxMailingListRussian@forum.nginx.org> References: <2dc509a03ec86f721c8c1139cc895ef0.NginxMailingListRussian@forum.nginx.org> Message-ID: <7b491ddc438677d3c43bbf5b583b6a89.NginxMailingListRussian@forum.nginx.org> Server: nginx Date: Tue, 23 Apr 2019 08:45:51 GMT Content-Type: text/html; charset=windows-1251 Transfer-Encoding: chunked Connection: keep-alive charset: windows-1251 Cash-Control: no-cash, no-store, must-revalidate Set-Cookie: wid=rs88kjs7n7u5k95pdtsqo8o9n3; path=/; HTTPOnly; Secure Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-XSS-Protection: 1; mode=block Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283878,283881#msg-283881 From nginx-forum на forum.nginx.org Tue Apr 23 08:59:38 2019 From: nginx-forum на forum.nginx.org (anatolr) Date: Tue, 23 Apr 2019 04:59:38 -0400 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0LjQsNC70YzQvdGL0LUg0YHQuNC80LLQvtC70Ysg0LIg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdCw0YU=?= In-Reply-To: <7b491ddc438677d3c43bbf5b583b6a89.NginxMailingListRussian@forum.nginx.org> References: <2dc509a03ec86f721c8c1139cc895ef0.NginxMailingListRussian@forum.nginx.org> <7b491ddc438677d3c43bbf5b583b6a89.NginxMailingListRussian@forum.nginx.org> Message-ID: <2218867d0eee121a5f917a9b3a822d85.NginxMailingListRussian@forum.nginx.org> включаю debug как понять почему строку location не использует location: ~ "^(.*)/\<(.*)$" { return 404; } 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: "/" 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: "images/" 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ "^(.*)alert(.*)$" 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ "^(.*)document(.*)$" 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ "\.php" 2019/04/23 11:43:55 [debug] 2737#0: *23 using configuration "\.php" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283878,283882#msg-283882 From mdounin на mdounin.ru Tue Apr 23 12:39:39 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 Apr 2019 15:39:39 +0300 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0LjQsNC70YzQvdGL0LUg0YHQuNC80LLQvtC70Ysg0LIg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdCw0YU=?= In-Reply-To: <2218867d0eee121a5f917a9b3a822d85.NginxMailingListRussian@forum.nginx.org> References: <2dc509a03ec86f721c8c1139cc895ef0.NginxMailingListRussian@forum.nginx.org> <7b491ddc438677d3c43bbf5b583b6a89.NginxMailingListRussian@forum.nginx.org> <2218867d0eee121a5f917a9b3a822d85.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190423123939.GF1877@mdounin.ru> Hello! On Tue, Apr 23, 2019 at 04:59:38AM -0400, anatolr wrote: > включаю debug как понять почему строку location не использует > > location: ~ "^(.*)/\<(.*)$" { > return 404; > } > > 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: "/" > 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: "images/" > 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ "^(.*)alert(.*)$" > 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ > "^(.*)document(.*)$" > 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ "\.php" > 2019/04/23 11:43:55 [debug] 2737#0: *23 using configuration "\.php" Когда речь идёт о location'ах, заданных регулярными выражениями - используется первое совпавшее. В вашем случае это "location ~ \.php", как ясно видно из debug log'а. Подробнее стоит почитать в документации: http://nginx.org/ru/docs/http/ngx_http_core_module.html#location Отдельно отмечу, что location отвечает только за проверку собственно URI запроса, без учёта аргументов. Соответственно закрыть так наиболее типичные XSS-уязвимости - в аргументах запроса - не получится, надо вместо этого использовать if'ы. И там кроме этого - вылезет отдельная проблема с необходимостью учитывать возможный URL encoding. Но вообще, как вам уже совершенно верно сказали, подобный путь решения проблем безопасности - крайне сомнителен. -- Maxim Dounin http://mdounin.ru/ From swood на fotofor.biz Tue Apr 23 13:42:48 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Tue, 23 Apr 2019 14:42:48 +0100 Subject: unitd + php5.6 Message-ID: Здравствуйте. Пытаюсь собрать модуль для unitd для запуска php5.6 (на сервере есть и 7-й, но в данном случае нужен именно 5-й). Сам php5.6 есть, у него есть php-config5.6, однако unitd при сборке упорно утверждает, что у него что-то не так: # ./configure php --module=php5.6 --config=/usr/bin/php-config5.6 --lib-path=/usr/lib/apache2/modules configuring PHP module checking for PHP ... found + PHP SAPI: [apache2handler cgi cli fpm] checking for PHP embed SAPI ... not found ./configure: error: no PHP embed SAPI found. Как бы точно понять, что не так? Файлы-то есть. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Tue Apr 23 14:09:08 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 Apr 2019 17:09:08 +0300 Subject: nginx-1.16.0 Message-ID: <20190423140908.GJ1877@mdounin.ru> Изменения в nginx 1.16.0 23.04.2019 *) Стабильная ветка 1.16.x. -- Maxim Dounin http://nginx.org/ From nginx на mva.name Tue Apr 23 14:11:24 2019 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 23 Apr 2019 17:11:24 +0300 Subject: unitd + php5.6 In-Reply-To: References: Message-ID: <5202407.HUOmCVu1JV@note> > ./configure: error: no PHP embed SAPI found. From vbart на nginx.com Tue Apr 23 14:13:48 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 23 Apr 2019 17:13:48 +0300 Subject: unitd + php5.6 In-Reply-To: References: Message-ID: <2223142.eXLkJihODV@vbart-workstation> On Tuesday 23 April 2019 14:42:48 Anton Kiryushkin wrote: > Здравствуйте. > > Пытаюсь собрать модуль для unitd для запуска php5.6 (на сервере есть и 7-й, > но в данном случае нужен именно 5-й). > > Сам php5.6 есть, у него есть php-config5.6, однако unitd при сборке упорно > утверждает, что у него что-то не так: > > # ./configure php --module=php5.6 --config=/usr/bin/php-config5.6 > --lib-path=/usr/lib/apache2/modules Это видимо директория с модулями Apache, которые к Unit-у никакого отношения не имеют. > configuring PHP module > checking for PHP ... found > + PHP SAPI: [apache2handler cgi cli fpm] В списке нет embed, т.е. php был собран без библиотеки libphp. > checking for PHP embed SAPI ... not found > > ./configure: error: no PHP embed SAPI found. > > > Как бы точно понять, что не так? Файлы-то есть. > $ ./configure php --module=php56 --config=/usr/lib64/php5.6/bin/php-config --lib-path=/usr/lib64/php5.6/lib64 configuring PHP module checking for PHP ... found + PHP SAPI: [embed cli cgi fpm] checking for PHP embed SAPI ... found checking for PHP zend_signal_startup() ... not found checking for PHP version ... 5.6.38-pl0-gentoo + PHP module: php56.unit.so $ ls /usr/lib64/php5.6/lib64 libphp5.so opcache.so $ /usr/lib64/php5.6/bin/php-config --php-sapis embed cli cgi fpm $ /usr/lib64/php5.6/bin/php-config --configure-options | grep embed --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --docdir=/usr/share/doc/php-5.6.38 --htmldir=/usr/share/doc/php-5.6.38/html --prefix=/usr/lib64/php5.6 --mandir=/usr/lib64/php5.6/man --infodir=/usr/lib64/php5.6/info --libdir=/usr/lib64/php5.6/lib --with-libdir=lib64 --localstatedir=/var --without-pear --enable-maintainer-zts --disable-bcmath --without-bz2 --disable-calendar --disable-gcov --disable-ctype --without-curl --disable-dom --without-enchant --disable-exif --disable-fileinfo --disable-filter --disable-ftp --without-gettext --without-gmp --enable-hash --without-mhash --without-iconv --disable-intl --disable-ipv6 --disable-json --without-kerberos --disable-libxml --without-libxml-dir --disable-mbstring --without-mcrypt --without-mssql --without-onig --without-openssl --without-openssl-dir --disable-pcntl --disable-phar --disable-pdo --enable-opcache --without-pgsql --disable-posix --without-pspell --without-recode --disable-simplexml --disable-shmop --without-snmp --disable-soap --disable-sockets --without-sqlite3 --without-sybase-ct --disable-sysvmsg --disable-sysvsem --disable-sysvshm --without-tidy --disable-tokenizer --disable-wddx --disable-xml --disable-xmlreader --disable-xmlwriter --without-xmlrpc --without-xsl --disable-zip --without-zlib --disable-debug --without-cdb --without-db4 --disable-flatfile --without-gdbm --disable-inifile --without-qdbm --without-freetype-dir --without-t1lib --disable-gd-jis-conv --without-jpeg-dir --without-png-dir --without-xpm-dir --without-vpx-dir --without-gd --without-interbase --without-mysql --with-mysqli=mysqlnd --without-mysql-sock --without-unixODBC --without-iodbc --without-oci8 --with-readline=/usr --without-libedit --disable-session --with-pic --with-pcre-regex=/usr --with-pcre-dir=/usr --cache-file=/dev/shm/portage/dev-lang/php-5.6.38/temp/config.cache --with-config-file-path=/etc/php/embed-php5.6 --with-config-file-scan-dir=/etc/php/embed-php5.6/ext-active --enable-embed --disable-cli --disable-cgi --disable-fpm --without-apxs2 build_alias=x86_64-pc-linux-gnu host_alias=x86_64-pc-linux-gnu CFLAGS=-Ofast -march=native -pipe LDFLAGS=-Wl,-O1 -Wl,--as-needed CPPFLAGS= CXXFLAGS=-Ofast -march=native -pipe Среди опций можно заметить --enable-embed. -- Валентин Бартене From swood на fotofor.biz Tue Apr 23 14:16:29 2019 From: swood на fotofor.biz (Anton Kiryushkin) Date: Tue, 23 Apr 2019 15:16:29 +0100 Subject: unitd + php5.6 In-Reply-To: <2223142.eXLkJihODV@vbart-workstation> References: <2223142.eXLkJihODV@vbart-workstation> Message-ID: Валентин, спасибо, как-то я это или пропустил в доке, или не написано. Теперь собралось, вопрос снят. вт, 23 апр. 2019 г. в 15:13, Валентин Бартенев : > On Tuesday 23 April 2019 14:42:48 Anton Kiryushkin wrote: > > Здравствуйте. > > > > Пытаюсь собрать модуль для unitd для запуска php5.6 (на сервере есть и > 7-й, > > но в данном случае нужен именно 5-й). > > > > Сам php5.6 есть, у него есть php-config5.6, однако unitd при сборке > упорно > > утверждает, что у него что-то не так: > > > > # ./configure php --module=php5.6 --config=/usr/bin/php-config5.6 > > --lib-path=/usr/lib/apache2/modules > > Это видимо директория с модулями Apache, которые к Unit-у никакого > отношения не имеют. > > > > configuring PHP module > > checking for PHP ... found > > + PHP SAPI: [apache2handler cgi cli fpm] > > В списке нет embed, т.е. php был собран без библиотеки libphp. > > > > checking for PHP embed SAPI ... not found > > > > ./configure: error: no PHP embed SAPI found. > > > > > > Как бы точно понять, что не так? Файлы-то есть. > > > > $ ./configure php --module=php56 --config=/usr/lib64/php5.6/bin/php-config > --lib-path=/usr/lib64/php5.6/lib64 > configuring PHP module > checking for PHP ... found > + PHP SAPI: [embed cli cgi fpm] > checking for PHP embed SAPI ... found > checking for PHP zend_signal_startup() ... not found > checking for PHP version ... 5.6.38-pl0-gentoo > + PHP module: php56.unit.so > > $ ls /usr/lib64/php5.6/lib64 > libphp5.so opcache.so > > $ /usr/lib64/php5.6/bin/php-config --php-sapis > embed cli cgi fpm > > $ /usr/lib64/php5.6/bin/php-config --configure-options | grep embed > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > --sysconfdir=/etc --localstatedir=/var/lib > --docdir=/usr/share/doc/php-5.6.38 --htmldir=/usr/share/doc/php-5.6.38/html > --prefix=/usr/lib64/php5.6 --mandir=/usr/lib64/php5.6/man > --infodir=/usr/lib64/php5.6/info --libdir=/usr/lib64/php5.6/lib > --with-libdir=lib64 --localstatedir=/var --without-pear > --enable-maintainer-zts --disable-bcmath --without-bz2 --disable-calendar > --disable-gcov --disable-ctype --without-curl --disable-dom > --without-enchant --disable-exif --disable-fileinfo --disable-filter > --disable-ftp --without-gettext --without-gmp --enable-hash --without-mhash > --without-iconv --disable-intl --disable-ipv6 --disable-json > --without-kerberos --disable-libxml --without-libxml-dir --disable-mbstring > --without-mcrypt --without-mssql --without-onig --without-openssl > --without-openssl-dir --disable-pcntl --disable-phar --disable-pdo > --enable-opcache --without-pgsql --disable-posix --without-pspell > --without-recode --disable-simplexml --disable-shmop --without-snmp > --disable-soap --disable-sockets --without-sqlite3 --without-sybase-ct > --disable-sysvmsg --disable-sysvsem --disable-sysvshm --without-tidy > --disable-tokenizer --disable-wddx --disable-xml --disable-xmlreader > --disable-xmlwriter --without-xmlrpc --without-xsl --disable-zip > --without-zlib --disable-debug --without-cdb --without-db4 > --disable-flatfile --without-gdbm --disable-inifile --without-qdbm > --without-freetype-dir --without-t1lib --disable-gd-jis-conv > --without-jpeg-dir --without-png-dir --without-xpm-dir --without-vpx-dir > --without-gd --without-interbase --without-mysql --with-mysqli=mysqlnd > --without-mysql-sock --without-unixODBC --without-iodbc --without-oci8 > --with-readline=/usr --without-libedit --disable-session --with-pic > --with-pcre-regex=/usr --with-pcre-dir=/usr > --cache-file=/dev/shm/portage/dev-lang/php-5.6.38/temp/config.cache > --with-config-file-path=/etc/php/embed-php5.6 > --with-config-file-scan-dir=/etc/php/embed-php5.6/ext-active --enable-embed > --disable-cli --disable-cgi --disable-fpm --without-apxs2 > build_alias=x86_64-pc-linux-gnu host_alias=x86_64-pc-linux-gnu > CFLAGS=-Ofast -march=native -pipe LDFLAGS=-Wl,-O1 -Wl,--as-needed CPPFLAGS= > CXXFLAGS=-Ofast -march=native -pipe > > > Среди опций можно заметить --enable-embed. > > -- > Валентин Бартене > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Wed Apr 24 17:21:06 2019 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Wed, 24 Apr 2019 13:21:06 -0400 Subject: =?UTF-8?B?0KTQsNC50LvRiyDQuNC3INC60Y3RiNCwINGD0LTQsNC70Y/RjtGC0YHRjyDQv9GA?= =?UTF-8?B?0LXQttC00LXQstGA0LXQvNC10L3QvdC+?= Message-ID: <5618ed152d7443d58f8cdef548583e26.NginxMailingListRussian@forum.nginx.org> Nginx 1.15.11 Система - CentOS 7 с ядром 4.18 /data живёт на Cepf. Обнаружено преждевременное удаление файлов из кэша Nginx. Кэш настроен так: proxy_cache_path /data/user123/nginx_cache keys_zone=user123:3000m max_size=20000g inactive=30d levels=1:2 use_temp_path=off; В /data/user123/nginx_cache сейчас лежит около 5 миллионов файлов (т.е. примерно 20% от максимума 3000m), которые занимают 6 терабайт (30% от максимума 20TB). Например, из кэша исчез файл mtime "2019-04-17 22:00 msk" и таким заголовком: KEY: /file/0123456789abcdef/720/s-02345.ts HTTP/1.1 200 OK Server: nginx/1.14.2 Date: Wed, 17 Apr 2019 19:00:21 GMT Content-Type: video/mp2t Content-Length: 1911020 Connection: keep-alive Last-Modified: Wed, 31 Jan 2018 11:38:18 GMT ETag: "1234aaaa-123456" Access-Control-Allow-Origin: * Expires: Thu, 16 Apr 2020 19:00:21 GMT Cache-Control: max-age=31536000 Accept-Ranges: bytes Он не должен был пролежать в кэше до 17 мая? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283908,283908#msg-283908 From mdounin на mdounin.ru Thu Apr 25 14:51:55 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 25 Apr 2019 17:51:55 +0300 Subject: =?UTF-8?B?UmU6INCk0LDQudC70Ysg0LjQtyDQutGN0YjQsCDRg9C00LDQu9GP0Y7RgtGB0Y8g?= =?UTF-8?B?0L/RgNC10LbQtNC10LLRgNC10LzQtdC90L3Qvg==?= In-Reply-To: <5618ed152d7443d58f8cdef548583e26.NginxMailingListRussian@forum.nginx.org> References: <5618ed152d7443d58f8cdef548583e26.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190425145155.GP1877@mdounin.ru> Hello! On Wed, Apr 24, 2019 at 01:21:06PM -0400, Ilya Evseev wrote: > Nginx 1.15.11 > Система - CentOS 7 с ядром 4.18 > /data живёт на Cepf. > > Обнаружено преждевременное удаление файлов из кэша Nginx. > Кэш настроен так: > > proxy_cache_path /data/user123/nginx_cache keys_zone=user123:3000m > max_size=20000g inactive=30d levels=1:2 use_temp_path=off; > > В /data/user123/nginx_cache сейчас лежит около 5 миллионов файлов (т.е. > примерно 20% от максимума 3000m), > которые занимают 6 терабайт (30% от максимума 20TB). На вскидку вспоминаются две причины, почему может быть так: - При работе на экзотических файловых системах сообщаемый nginx'у размер на диске может значительно отличаться от собственно размера файла и/или значительно меняться в процессе. Такое, например, наблюдается на XFS (https://trac.nginx.org/nginx/ticket/157). - Если вдруг из каталога кэша кто-то удалил часть файлов в процессе работы - nginx будет продолжать считать, что эти файлы существуют, и учитывать их при очистке кэша по max_size. Частным случаем этой ситуации может являться запуск другого nginx'а, использующего тот же каталог для хранения кэша - уже наблюдал, как люди пытаются таким образом строить "общий кэш" на нескольких серверах, однако следует понимать, что такой подход принципиально неверен и чреват проблемами. С учётом использования Ceph для хранения кэша (зачем?!) - я бы предположил, что причиной может быть как любая из этих причин, так и обе они вместе. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Apr 25 21:27:24 2019 From: nginx-forum на forum.nginx.org (dimademin) Date: Thu, 25 Apr 2019 17:27:24 -0400 Subject: =?UTF-8?B?0JrQsNC6INGD0LTQsNC70LjRgtGMIGluZGV4LnBocCDQuNC3IHVybA==?= Message-ID: <10aef2837edfe7a8a1b33734d7a20795.NginxMailingListRussian@forum.nginx.org> Приветствую На сервере работает nginx+fpm, все как часы, есть такой, не очень правильный, кусок конфига: location / { try_files $uri $uri/ @rewrite; } location @rewrite { rewrite ^/(.*)$ /index.php?q=$1; } location ~ \.php{ ......... } Есть банальная задача, удалить index.php из uri, то есть делать что-то вроде location =/index.php { return 301 /; } Но тогда бесконечный редирект и все ломается. Подскажите пожалуйста, сам не догоняю, гугл не сильно помог. Спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283927,283927#msg-283927 From cnst++ на freebsd.org Fri Apr 26 08:20:16 2019 From: cnst++ на freebsd.org (Constantine A. Murenin) Date: Fri, 26 Apr 2019 03:20:16 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: <10aef2837edfe7a8a1b33734d7a20795.NginxMailingListRussian@forum.nginx.org> References: <10aef2837edfe7a8a1b33734d7a20795.NginxMailingListRussian@forum.nginx.org> Message-ID: On Thu, 25 Apr 2019 at 16:27, dimademin wrote: > Приветствую > На сервере работает nginx+fpm, все как часы, есть такой, не очень > правильный, кусок конфига: > > location / { > try_files $uri $uri/ @rewrite; > } > location @rewrite { > rewrite ^/(.*)$ /index.php?q=$1; > } > location ~ \.php{ > ......... > } > > Есть банальная задача, удалить index.php из uri, то есть делать что-то > вроде > location =/index.php { > return 301 /; > } > Но тогда бесконечный редирект и все ломается. > Подскажите пожалуйста, сам не догоняю, гугл не сильно помог. > Спасибо > index index.php; if ($request_uri ~ "^(.*/)index.php$") { return 301 $1; } См. https://stackoverflow.com/questions/21687288/nginx-redirect-loop-remove-index-php-from-url/21813759#21813759 К. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Apr 26 08:22:51 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 26 Apr 2019 13:22:51 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: <10aef2837edfe7a8a1b33734d7a20795.NginxMailingListRussian@forum.nginx.org> References: <10aef2837edfe7a8a1b33734d7a20795.NginxMailingListRussian@forum.nginx.org> Message-ID: location = / { ... } location / { ... } пт, 26 апр. 2019 г. в 02:27, dimademin : > Приветствую > На сервере работает nginx+fpm, все как часы, есть такой, не очень > правильный, кусок конфига: > > location / { > try_files $uri $uri/ @rewrite; > } > location @rewrite { > rewrite ^/(.*)$ /index.php?q=$1; > } > location ~ \.php{ > ......... > } > > Есть банальная задача, удалить index.php из uri, то есть делать что-то > вроде > location =/index.php { > return 301 /; > } > Но тогда бесконечный редирект и все ломается. > Подскажите пожалуйста, сам не догоняю, гугл не сильно помог. > Спасибо > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,283927,283927#msg-283927 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Apr 26 13:52:56 2019 From: nginx-forum на forum.nginx.org (dymov.ra) Date: Fri, 26 Apr 2019 09:52:56 -0400 Subject: limit_conn_zone Message-ID: Добрый день. Столкнулся со след проблемой. В версии 1.14 не работает limit_conn_zone (ubuntu 18 lts\nginx-extras). Соответственно на старой версии 1.10, все было корректно (ubuntu 16 lts\nginx-extras) Так же проверял в докере с nginx-alpine соответствующих версий - там картина индетинчная. limit_conn_zone $binary_remote_addr zone=ip:16m; limit_conn ip 1; limit_conn_zone $server_name zone=server:8m; limit_conn server 5; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283932,283932#msg-283932 From slw на zxy.spb.ru Fri Apr 26 13:55:31 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 26 Apr 2019 16:55:31 +0300 Subject: limit_conn_zone In-Reply-To: References: Message-ID: <20190426135531.GF2161@zxy.spb.ru> On Fri, Apr 26, 2019 at 09:52:56AM -0400, dymov.ra wrote: > Добрый день. Столкнулся со след проблемой. > > В версии 1.14 не работает limit_conn_zone (ubuntu 18 lts\nginx-extras). > Соответственно на старой версии 1.10, все было корректно (ubuntu 16 > lts\nginx-extras) > Так же проверял в докере с nginx-alpine соответствующих версий - там картина > индетинчная. > > limit_conn_zone $binary_remote_addr zone=ip:16m; > limit_conn ip 1; > limit_conn_zone $server_name zone=server:8m; > limit_conn server 5; а разве в докере это имеет хоть какой-то смысл? From nginx-forum на forum.nginx.org Fri Apr 26 14:00:03 2019 From: nginx-forum на forum.nginx.org (dymov.ra) Date: Fri, 26 Apr 2019 10:00:03 -0400 Subject: limit_conn_zone In-Reply-To: <20190426135531.GF2161@zxy.spb.ru> References: <20190426135531.GF2161@zxy.spb.ru> Message-ID: <1541ee75473aae2f4778ab380acb7b3b.NginxMailingListRussian@forum.nginx.org> была мысль что сборка ubuntu (ubuntu-extras) могла испорить nginx, хотел проверить. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283932,283934#msg-283934 From nginx-forum на forum.nginx.org Fri Apr 26 14:29:26 2019 From: nginx-forum на forum.nginx.org (dimademin) Date: Fri, 26 Apr 2019 10:29:26 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: <06d41e6cb9cdb0f219397d333393e9bf.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ Попробовал так: location ~ ^/index.php$ { return 301 /; } location =/ { try_files $uri $uri/ /index.php?q=$request_uri; } location / { fastcgi_pass ... ... ничего не изменилось, too many redirects. Может я что-то не так понял и не то прописал? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283935#msg-283935 From koticka на mail.ru Fri Apr 26 18:26:11 2019 From: koticka на mail.ru (Kostya Alexandrov) Date: Fri, 26 Apr 2019 21:26:11 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: <06d41e6cb9cdb0f219397d333393e9bf.NginxMailingListRussian@forum.nginx.org> References: <06d41e6cb9cdb0f219397d333393e9bf.NginxMailingListRussian@forum.nginx.org> Message-ID:         location / {                 index  index.php index.html index.htm;                 try_files $uri $uri/ /index.php?$query_string;         }         location ~ \.php$ {                 postpone_output 0;                 root /var/www;                 try_files $uri =404;                 fastcgi_pass unix:/var/run/php5-fpm.sock;                 include fastcgi_params;         } On 26/04/2019 17:29, dimademin wrote: > Спасибо за ответ > Попробовал так: > > location ~ ^/index.php$ { > return 301 /; > } > location =/ { > try_files $uri $uri/ /index.php?q=$request_uri; > } > location / { > fastcgi_pass ... > ... > > ничего не изменилось, too many redirects. Может я что-то не так понял и не > то прописал? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283935#msg-283935 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Fri Apr 26 18:47:05 2019 From: nginx-forum на forum.nginx.org (dimademin) Date: Fri, 26 Apr 2019 14:47:05 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: Спасибо. Но это вы привели как раз стандартную настройку, универсальную, при которой работают и чистые урлы и урл с index.php и без index.php А мне нужно что-бы при http://bla.tld/index.php, быд 301-й на /, то есть на http://bla.tld/ и при этом не ломались чистые урлы, то есть работал этот рерайт "try_files $uri $uri/ /index.php?$query_string" (ну или аналоги, что я выше писал) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283942#msg-283942 From annulen на yandex.ru Fri Apr 26 19:18:29 2019 From: annulen на yandex.ru (Konstantin Tokarev) Date: Fri, 26 Apr 2019 22:18:29 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= References: Message-ID: <3614051556306309@iva5-049509bcc5d6.qloud-c.yandex.net> 26.04.2019, 21:47, "dimademin" : > Спасибо. Но это вы привели как раз стандартную настройку, универсальную, при > которой работают и чистые урлы и урл с index.php и без index.php > А мне нужно что-бы при http://bla.tld/index.php, быд 301-й на /, то есть на > http://bla.tld/ и при этом не ломались чистые урлы, то есть работал этот > рерайт "try_files $uri $uri/ /index.php?$query_string" (ну или аналоги, что > я выше писал) Наверное нужно что-то вроде https://serverfault.com/questions/254191/how-to-combine-url-rewriting-and-fastcgi-in-nginx/262060#262060 > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283942#msg-283942 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From koticka на mail.ru Fri Apr 26 19:44:53 2019 From: koticka на mail.ru (Kostya Alexandrov) Date: Fri, 26 Apr 2019 22:44:53 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: Тгда для location ~ \.php$ { http://nginx.org/ru/docs/http/ngx_http_core_module.html#internal On 26/04/2019 21:47, dimademin wrote: > Спасибо. Но это вы привели как раз стандартную настройку, универсальную, при > которой работают и чистые урлы и урл с index.php и без index.php > А мне нужно что-бы при http://bla.tld/index.php, быд 301-й на /, то есть на > http://bla.tld/ и при этом не ломались чистые урлы, то есть работал этот > рерайт "try_files $uri $uri/ /index.php?$query_string" (ну или аналоги, что > я выше писал) > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283942#msg-283942 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From constantine на mellodesign.ru Sat Apr 27 09:12:50 2019 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Sat, 27 Apr 2019 13:12:50 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: Попробуйте такой вариант https://symfony.com/doc/master/setup/web_server_configuration.html#nginx пт, 26 апр. 2019 г. в 23:45, Kostya Alexandrov via nginx-ru < nginx-ru на nginx.org>: > Тгда для location ~ \.php$ { > http://nginx.org/ru/docs/http/ngx_http_core_module.html#internal > > On 26/04/2019 21:47, dimademin wrote: > > Спасибо. Но это вы привели как раз стандартную настройку, универсальную, > при > > которой работают и чистые урлы и урл с index.php и без index.php > > А мне нужно что-бы при http://bla.tld/index.php, быд 301-й на /, то > есть на > > http://bla.tld/ и при этом не ломались чистые урлы, то есть работал этот > > рерайт "try_files $uri $uri/ /index.php?$query_string" (ну или аналоги, > что > > я выше писал) > > > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,232265,283942#msg-283942 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Константин! Web-разработчик Mello . Best regards, Constantine Mello Web developer. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Apr 27 13:07:00 2019 From: nginx-forum на forum.nginx.org (dimademin) Date: Sat, 27 Apr 2019 09:07:00 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: <3614051556306309@iva5-049509bcc5d6.qloud-c.yandex.net> References: <3614051556306309@iva5-049509bcc5d6.qloud-c.yandex.net> Message-ID: <3b986e77675f209e617a152c7b3e047a.NginxMailingListRussian@forum.nginx.org> К сожалению не то, ведь index.php из первоначального запроса никуда не исчезнет Вся эта схема вообще не работает без /index.php?q=, это отыечает за "чистые урлы" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283948#msg-283948 From nginx-forum на forum.nginx.org Sat Apr 27 13:09:37 2019 From: nginx-forum на forum.nginx.org (dimademin) Date: Sat, 27 Apr 2019 09:09:37 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: <60bddb65fbe07a2f1e6193f662cb2ca2.NginxMailingListRussian@forum.nginx.org> Попробовал, не помогло, ну результат немного другой, видимо из-за internal возвращается 404-я Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283949#msg-283949 From nginx-forum на forum.nginx.org Sat Apr 27 16:52:16 2019 From: nginx-forum на forum.nginx.org (bagas) Date: Sat, 27 Apr 2019 12:52:16 -0400 Subject: nginx/1.16.0 ssl Message-ID: <7c665a01b65039462855f6bd90f6d7c9.NginxMailingListRussian@forum.nginx.org> Вечер добрый. Переношу проекты со старого сервера. После переноса вэб проекта не работают ссл сертификаты. # nginx -V nginx version: nginx/1.16.0 built with OpenSSL 1.1.1a-freebsd 20 Nov 2018 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-threads --with-stream=dynamic система FreeBSD 12.0-RELEASE-p3 amd64 виртуал хоcт с такой настройкой. server { listen 9.9.2.1:443 http2; server_name www.site.local; rewrite ^(.*) https://site.local$uri permanent; ssl_certificate /usr/local/etc/letsencrypt/live/site.local/fullchain.pem; ssl_certificate_key /usr/local/etc/letsencrypt/live/site.local/privkey.pem; ssl_trusted_certificate /usr/local/etc/letsencrypt/live/site.local/chain.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; } Пробовал через разные браузеры гугл/мозила/опера. гугл хром Версия 73.0.3683.103 (Официальная сборка), (64 бит) Ошибка Этот сайт не может обеспечить безопасное соединение Сайт ionpower.ru отправил недействительный ответ. ERR_SSL_PROTOCOL_ERROR На старом сервере система. FreeBSD 11.2-RELEASE-p9 amd64 nginx # nginx -V nginx version: nginx/1.14.2 built with OpenSSL 1.0.2o-freebsd 27 Mar 2018 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-stream=dynamic Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283954,283954#msg-283954 From nginx-forum на forum.nginx.org Sat Apr 27 18:03:04 2019 From: nginx-forum на forum.nginx.org (bagas) Date: Sat, 27 Apr 2019 14:03:04 -0400 Subject: =?UTF-8?B?bmdpbngvMS4xNi4wINC90LUg0YDQsNCx0L7RgtCw0LXRgiDRgdGB0Ls=?= Message-ID: <8eef78d85f4287619cbc612307a74794.NginxMailingListRussian@forum.nginx.org> Вечер добрый. Переношу проекты со старого сервера. После переноса вэб проекта не работают ссл сертификаты. # nginx -V nginx version: nginx/1.16.0 built with OpenSSL 1.1.1a-freebsd 20 Nov 2018 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-threads --with-stream=dynamic система FreeBSD 12.0-RELEASE-p3 amd64 виртуал хоcт с такой настройкой. server { listen 9.9.2.1:443 http2; server_name www.site.local; rewrite ^(.*) https://site.local$uri permanent; ssl_certificate /usr/local/etc/letsencrypt/live/site.local/fullchain.pem; ssl_certificate_key /usr/local/etc/letsencrypt/live/site.local/privkey.pem; ssl_trusted_certificate /usr/local/etc/letsencrypt/live/site.local/chain.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; } Пробовал через разные браузеры гугл/мозила/опера. гугл хром ошибка такая Версия 73.0.3683.103 (Официальная сборка), (64 бит) Ошибка Этот сайт не может обеспечить безопасное соединение Сайт site.local отправил недействительный ответ. ERR_SSL_PROTOCOL_ERROR В логах nginx ошибок нет. nginx -t проходит без ошибок. Временно вернул все обратно на старый сервер, на нем все работает хорошо. Мне кажется что дело в версии openssl. Пробовал сертификаты от двух разных регистраторов, reg.ru и Let’s Encrypt, выхлоп на всех одинаков, не работает, ошибка в браузере одинаковая. На старом сервере система. FreeBSD 11.2-RELEASE-p9 amd64 nginx # nginx -V nginx version: nginx/1.14.2 built with OpenSSL 1.0.2o-freebsd 27 Mar 2018 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-stream=dynamic Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283957,283957#msg-283957 From nginx-forum на forum.nginx.org Sat Apr 27 18:40:53 2019 From: nginx-forum на forum.nginx.org (bagas) Date: Sat, 27 Apr 2019 14:40:53 -0400 Subject: =?UTF-8?B?UmU6IG5naW54LzEuMTYuMCDQvdC1INGA0LDQsdC+0YLQsNC10YIg0YHRgdC7?= In-Reply-To: <8eef78d85f4287619cbc612307a74794.NginxMailingListRussian@forum.nginx.org> References: <8eef78d85f4287619cbc612307a74794.NginxMailingListRussian@forum.nginx.org> Message-ID: Проблему решил. listen 9.9.2.1:443 http2 ssl; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283957,283958#msg-283958 From constantine на mellodesign.ru Sun Apr 28 07:45:30 2019 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Sun, 28 Apr 2019 11:45:30 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: <3b986e77675f209e617a152c7b3e047a.NginxMailingListRussian@forum.nginx.org> References: <3614051556306309@iva5-049509bcc5d6.qloud-c.yandex.net> <3b986e77675f209e617a152c7b3e047a.NginxMailingListRussian@forum.nginx.org> Message-ID: сб, 27 апр. 2019 г. в 17:07, dimademin : > К сожалению не то, ведь index.php из первоначального запроса никуда не > исчезнет > Вся эта схема вообще не работает без /index.php?q=, это отыечает за "чистые > урлы" > > Перечитал еще раз тему. У вас похож конфиг на конфиг от друпала 7. Приведете пример входящей uri и что должно получиться. -- С уважением, Константин! Web-разработчик Mello . Best regards, Constantine Mello Web developer. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From constantine на mellodesign.ru Sun Apr 28 07:51:58 2019 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Sun, 28 Apr 2019 11:51:58 +0400 Subject: nginx/1.16.0 ssl In-Reply-To: <7c665a01b65039462855f6bd90f6d7c9.NginxMailingListRussian@forum.nginx.org> References: <7c665a01b65039462855f6bd90f6d7c9.NginxMailingListRussian@forum.nginx.org> Message-ID: Первое что бросилось в глаза - нет ssl директивы у listen Также проверить работу сертификатов, как тут советовали, лучше с помощью openssl, например так: $ openssl s_client -servername ИМЯ -connect ХОСТ:ПОРТ сб, 27 апр. 2019 г. в 20:52, bagas : > Вечер добрый. > Переношу проекты со старого сервера. > После переноса вэб проекта не работают ссл сертификаты. > > # nginx -V > nginx version: nginx/1.16.0 > built with OpenSSL 1.1.1a-freebsd 20 Nov 2018 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx/error.log --user=www --group=www > --modules-path=/usr/local/libexec/nginx --with-file-aio > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx/access.log --with-http_v2_module > --with-http_addition_module --with-http_auth_request_module > --with-http_dav_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_random_index_module > --with-http_realip_module --with-pcre --with-http_secure_link_module > --with-http_slice_module --with-http_ssl_module > --with-http_stub_status_module --with-http_sub_module > --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' > --without-mail_imap_module --without-mail_pop3_module > --without-mail_smtp_module --with-threads --with-stream=dynamic > > система > FreeBSD 12.0-RELEASE-p3 amd64 > > виртуал хоcт с такой настройкой. > > server { > listen 9.9.2.1:443 http2; > server_name www.site.local; > rewrite ^(.*) https://site.local$uri permanent; > ssl_certificate /usr/local/etc/letsencrypt/live/site.local/fullchain.pem; > ssl_certificate_key > /usr/local/etc/letsencrypt/live/site.local/privkey.pem; > ssl_trusted_certificate > /usr/local/etc/letsencrypt/live/site.local/chain.pem; > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > ssl_prefer_server_ciphers on; > } > > Пробовал через разные браузеры > гугл/мозила/опера. > гугл хром > Версия 73.0.3683.103 (Официальная сборка), (64 бит) > Ошибка > Этот сайт не может обеспечить безопасное соединение Сайт ionpower.ru > отправил недействительный ответ. > ERR_SSL_PROTOCOL_ERROR > > На старом сервере система. > FreeBSD 11.2-RELEASE-p9 amd64 > > nginx > # nginx -V > nginx version: nginx/1.14.2 > built with OpenSSL 1.0.2o-freebsd 27 Mar 2018 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx/error.log --user=www --group=www > --modules-path=/usr/local/libexec/nginx --with-file-aio > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx/access.log --with-http_v2_module > --with-http_addition_module --with-http_auth_request_module > --with-http_gunzip_module --with-http_gzip_static_module > --with-http_random_index_module --with-http_realip_module --with-pcre > --with-http_secure_link_module --with-http_slice_module > --with-http_ssl_module --with-http_stub_status_module > --with-http_sub_module > --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' > --without-mail_imap_module --without-mail_pop3_module > --without-mail_smtp_module --with-stream_ssl_module > --with-stream_ssl_preread_module --with-threads --with-stream=dynamic > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,283954,283954#msg-283954 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Константин! Web-разработчик Mello . Best regards, Constantine Mello Web developer. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Apr 28 09:57:16 2019 From: nginx-forum на forum.nginx.org (dimademin) Date: Sun, 28 Apr 2019 05:57:16 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: Движок там MODx, связка nginx + php-fpm, схематично конфиг такой location / { try_files $uri $uri/ @rewrite; } location @rewrite { rewrite ^/(.*)$ /index.php?q=$1; } location ~ \.php { ...... тут настроено кэширование отдельных страниц сайта } ну и дальше там еще второстепенные location, статика, закрытые урлы и пр. обычные урлы разделов, товаров и какие-то доп. типа урл на сортировки выглядят примерно так http://dom.com/cat1/ http://dom.com/tovar_blabla/ http://dom.com/tovar_blabla/?color=red С приведенным куском конфига все работает. СЕОшники возжелали склеить корень "/" и "/index.php", то есть что-бы: http://dom.com/index.php редиректило(301) на http://dom.com/ Уже не первый день экспериментирую, перепробовал кучу всего и подозреваю что силами только nginx, это может не получится, как раз по причине использования php-fpm. Все попытки это в конфиге nginx приводят к рекурсии. На виртуалке поднял аналогичный конфиг только nginx + apache, через htaccess это делается без проблем: RewriteBase / RewriteCond /index.php [NC] RewriteRule ^(.*)index\.php$ $1 [R=301,L] Видимо конкретно в моем случае, в роли htaccess, должен выступить скрипт, то есть этот рерайт наверное нужно делать там. Ну у меня просто идеи уже кончились и свои и не свои, может вы свежим взглядом что-нить подскажете :) Вот как-то так, вроде ничего не забыл. Спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283965#msg-283965 From nginx-forum на forum.nginx.org Sun Apr 28 16:35:34 2019 From: nginx-forum на forum.nginx.org (bagas) Date: Sun, 28 Apr 2019 12:35:34 -0400 Subject: nginx/1.16.0 ssl In-Reply-To: References: Message-ID: <6baa02e82cb811b97094649c874ed603.NginxMailingListRussian@forum.nginx.org> И для чего было моя старую тему поднимать из удаленных? Я сам разобрался что не было ssl в листене. Удалите эту тему, смысл две одинаковые темы держать. Вот мой пост рабочий по этой информации/ситуации. https://forum.nginx.org/read.php?21,283957 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283964,283967#msg-283967 From cnst++ на freebsd.org Sun Apr 28 22:09:52 2019 From: cnst++ на freebsd.org (Constantine A. Murenin) Date: Sun, 28 Apr 2019 17:09:52 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: Почитайте ещё раз данное сообщение: https://forum.nginx.org/read.php?21,232265,283930#msg-283930 Проблема решается в nginx элементарнейшим образом: index index.php; if ($request_uri ~ "^(.*/)index.php$") { return 301 $1; } См. https://stackoverflow.com/questions/21687288/nginx-redirect-loop-remove-index-php-from-url/21813759#21813759 Смысл здесь в разнице между внешними и внутренними перенаправлениями. При использовании $uri (например, через location или rewrite), вы ловите внутреннее (служебное) перенаправление на /index.php при внешнем запросе на /, и выдаёте внешнее перенаправление опять на /, тогда как клиент и так уже запрашивал /. Для правильной работы нужно использовать не $uri, а $request_uri, и перенаправлять исключительно внешние запросы /index.php. http://nginx.org/r/$uri/ru http://nginx.org/r/$request_uri/ru К. http://cm.su/ On Sun, 28 Apr 2019 at 04:57, dimademin wrote: > Движок там MODx, связка nginx + php-fpm, схематично конфиг такой > > location / { > try_files $uri $uri/ @rewrite; > } > location @rewrite { > rewrite ^/(.*)$ /index.php?q=$1; > } > location ~ \.php { > ...... > тут настроено кэширование отдельных страниц сайта > } > ну и дальше там еще второстепенные location, статика, закрытые урлы и пр. > > обычные урлы разделов, товаров и какие-то доп. типа урл на сортировки > выглядят примерно так > http://dom.com/cat1/ > http://dom.com/tovar_blabla/ > http://dom.com/tovar_blabla/?color=red > > С приведенным куском конфига все работает. СЕОшники возжелали склеить > корень > "/" и "/index.php", то есть что-бы: > http://dom.com/index.php редиректило(301) на http://dom.com/ > > Уже не первый день экспериментирую, перепробовал кучу всего и подозреваю > что > силами только nginx, это может не получится, как раз по причине > использования php-fpm. Все попытки это в конфиге nginx приводят к рекурсии. > > > На виртуалке поднял аналогичный конфиг только nginx + apache, через > htaccess > это делается без проблем: > > RewriteBase / > RewriteCond /index.php [NC] > RewriteRule ^(.*)index\.php$ $1 [R=301,L] > > Видимо конкретно в моем случае, в роли htaccess, должен выступить скрипт, > то > есть этот рерайт наверное нужно делать там. > Ну у меня просто идеи уже кончились и свои и не свои, может вы свежим > взглядом что-нить подскажете :) > > Вот как-то так, вроде ничего не забыл. > Спасибо > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,232265,283965#msg-283965 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Apr 29 08:49:28 2019 From: nginx-forum на forum.nginx.org (dimademin) Date: Mon, 29 Apr 2019 04:49:28 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCBpbmRleC5waHAg0LjQtyB1cmw=?= In-Reply-To: References: Message-ID: <9202d13cd9376fc593bc59ebb87e5d11.NginxMailingListRussian@forum.nginx.org> Приветствую. Большое спасибо! Все понял. В моем случае работает в таком виде: if ($request_uri ~ "^(.*/)index.php$"){return 301 $1;} location / { try_files $uri $uri/ /index.php?q=$request_uri; } location ~ \.php { .... } > Почитайте ещё раз данное сообщение: > > https://forum.nginx.org/read.php?21,232265,283930#msg-283930 > > Проблема решается в nginx элементарнейшим образом: > > index index.php; > if ($request_uri ~ "^(.*/)index.php$") { return 301 $1; } > > См. > https://stackoverflow.com/questions/21687288/nginx-redirect-loop-remov > e-index-php-from-url/21813759#21813759 > > Смысл здесь в разнице между внешними и внутренними перенаправлениями. > При > использовании $uri (например, через location или rewrite), вы ловите > внутреннее (служебное) перенаправление на /index.php при внешнем > запросе на > /, и выдаёте внешнее перенаправление опять на /, тогда как клиент и > так уже > запрашивал /. Для правильной работы нужно использовать не $uri, а > $request_uri, и перенаправлять исключительно внешние запросы > /index.php. > > http://nginx.org/r/$uri/ru > http://nginx.org/r/$request_uri/ru > > К. > http://cm.su/ > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,232265,283970#msg-283970 From nginx-forum на forum.nginx.org Mon Apr 29 09:01:17 2019 From: nginx-forum на forum.nginx.org (bagas) Date: Mon, 29 Apr 2019 05:01:17 -0400 Subject: nginx/1.16.0 ssl In-Reply-To: <6baa02e82cb811b97094649c874ed603.NginxMailingListRussian@forum.nginx.org> References: <6baa02e82cb811b97094649c874ed603.NginxMailingListRussian@forum.nginx.org> Message-ID: <53517078c8eda969f6f478a91f687419.NginxMailingListRussian@forum.nginx.org> Просил удалить эту тему куда я сейчас пишу, а в итоге удалил мою тему https://forum.nginx.org/read.php?21,283957 жуть. В точности да наоборот! Браво! Логика зашкаливает! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283964,283971#msg-283971 From nginx на mva.name Mon Apr 29 11:05:19 2019 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 29 Apr 2019 14:05:19 +0300 Subject: nginx/1.16.0 ssl In-Reply-To: <53517078c8eda969f6f478a91f687419.NginxMailingListRussian@forum.nginx.org> References: <6baa02e82cb811b97094649c874ed603.NginxMailingListRussian@forum.nginx.org> <53517078c8eda969f6f478a91f687419.NginxMailingListRussian@forum.nginx.org> Message-ID: <5611858.WQKQCMEL9s@note> 1) если вы решили свои проблемы, то какая разница? 2) давайте начнём с того, что это не форум и здесь нет "тем". Это почтовый список рассылки с веб-мордой в виде форума для тех, кто слишком неосилянт для списков рассылки. И у всех участников рассылки оба треда на месте. From nginx-forum на forum.nginx.org Mon Apr 29 12:17:41 2019 From: nginx-forum на forum.nginx.org (bagas) Date: Mon, 29 Apr 2019 08:17:41 -0400 Subject: nginx/1.16.0 ssl In-Reply-To: <5611858.WQKQCMEL9s@note> References: <5611858.WQKQCMEL9s@note> Message-ID: <5b6bb4427679ec8d69a9e1412eccb09e.NginxMailingListRussian@forum.nginx.org> Буду иметь ввиду. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283972,283973#msg-283973 From chipitsine на gmail.com Tue Apr 30 08:58:20 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 30 Apr 2019 13:58:20 +0500 Subject: epoll_ctl: file exists ? Message-ID: привет, насколько опасно вот такое ? 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188) failed (17: File exists) while proxying upgraded connection, client: 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/ HTTP/2.0", upstream: "http://192.168.188.40:2339/wsapi/", host: "xxx.xxx.xxx" ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Apr 30 14:39:51 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 30 Apr 2019 17:39:51 +0300 Subject: epoll_ctl: file exists ? In-Reply-To: References: Message-ID: <20190430143951.GW1877@mdounin.ru> Hello! On Tue, Apr 30, 2019 at 01:58:20PM +0500, Илья Шипицин wrote: > привет, > > насколько опасно вот такое ? > > > 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188) failed > (17: File exists) while proxying upgraded connection, client: > 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/ HTTP/2.0", > upstream: "http://192.168.188.40:2339/wsapi/", host: "xxx.xxx.xxx" Судя по всему, имеет место попытка запихнуть вебсокеты в HTTP/2. Работать - не будет. -- Maxim Dounin http://mdounin.ru/