from:"raven...@megaline.kg"

Re: /usr/sbin/nginx alternatives

2024-09-15 Пенетрантность raven...@megaline.kg

Предположим, опакетить freenginx для семейства RHEL 8-9 совершенно не 
проблема, хотя и есть отдельные вопросы (именование юнита, разрешение 
конфликтов и т.д.). Но вот эта вот часть про alternatives вызывает 
некоторые вопросы к автору и его дилеру.


Во-первых, вы предлагаете объединить в один пакет кучу ОТДЕЛЬНЫХ 
проектов, сама по себе суть возникновения которых была в том, чтобы 
существовать ОТДЕЛЬНО.


Во-вторых, само по себе использование alternatives - весьма спорное 
предложение. Как мы помним, alternatives формирует цепочку симлинков: 
/usr/sbin/ -> /etc/alternatives/ -> 
/usr/sbin/. В моей практике несколько раз случались 
ситуации, когда после обновления пакетов симлинк 
/etc/alternatives/ начинал указывать в пустоту. Да, это 
вероятно была какая-то ошибка сборщика пакетов, но тем не менее, это 
достаточно неприятный инцидент. В случае с (free)nginx такое проишествие 
способно повлечь за собой достаточно неприятные последствия и лично мне 
очень бы не хотелось иметь на серверах мины замедленного действия.



15.09.2024 20:32, Hennadii Makhomed пишет:

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

nginx развивается в разных направлениях,

freenginx
Angie
OpenResty
Tengine
nginx-plus
nginx

https://freenginx.org/ развивается достаточно динамично,
много исправлений ошибок, часто выходят новые mainline версии.

Но на странице https://freenginx.org/en/download.html не понятная
ситуация - есть .tar.gz архивы с исходными текстами, есть .zip архивы
с бинарными версиями nginx для операционных систем семейства Windows,
но нет rpm-пакетов и yum-репозиториев для Rocky Linux 9 / RHEL 9.

То есть, ситуация выглядит так, что поддержка операционных систем
семейства Windows даже на более высоком уровне, чем поддержка
операционных сисем семейства Enterprise Linux, у которых 10 лет
срок жизни дистрибутива и наивысший уровень надежности
и стабильности среди вообще всех дистрибутивов Linux.

Особенно - после того, как Solar Designer присоединился к проекту
Rocky Linux - https://x.com/solardiz/status/1709574519688487374

А вот с freenginx ситуация не понятная совершенно - его же сейчас
можно нормально использовать только в FreeBSD, потому что там есть
соответствующий порт. А для для Rocky Linux 9 / RHEL 9 - бинарников
на сайте https://freenginx.org/ нет, так что использовать его легко
и просто не получится - надо каждому пользователю freenginx самому
делать rpm пакеты, самому делать yum-репозитории, и потом - это все
еще и надо поддерживать в актулаьном состоянии, оперативно выпуская
новые версии с каждым выходом freenginx. То есть, пока что он не для
production? Или только для early adopters, у которых есть время
и возможность и желание, чтобы самим у себя поддерживать эту
инфранструктуру для сборки новых версий freenginx?

Просто не понимаю, как использовать freenginx в production.
Кто-либо это делает на Rocky Linux 9 / RHEL 9 ? Каким образом?

Или все пользователи freenginx - это только пользователи FreeBSD?
Там то все просто, потому что есть соответствующий порт в системе.

Так не хочется самому этим всем заморачиваться, потому что я ведь
внутрь одного rpm-пакета могу захотеть поместить все четыре бинарника,
биранринки nginx и nginx-debug, собранные из
https://freenginx.org/download/freenginx-1.27.4.tar.gz
и бинарники nginx и nginx-debug, собарнные из
https://nginx.org/download/nginx-1.27.1.tar.gz

To Konstantin Pavlov:

возможно ли будет внутрь https://nginx.org/en/linux_packages.html
хотя бы для Rocky Linux 9 / RHEL 9 включить не два бинарника,
как сейчас - nginx и nginx-debug, собранных на основании исходников
с сайта https://nginx.org/ но и еще два бинарника nginx и nginx-debug
собранных на основании исходников с сайта https://freenginx.org/ ?

тогда можно будет иметь всего один юнит-файл nginx.service
а переключение между различными реализациями бинарника nginx
можно будет делать через alternatives, как это уже сделано
для других программ в операционной системе Rocky Linux 9 / RHEL 9

# alternatives --list
# alternatives --display ld
# man alternatives

это было бы очень удобно и для /usr/sbin/nginx, потому что сейчас,
когда не используется alternatives - то приходится сооружать костыли
из двух unit-файлов

/usr/lib/systemd/system/nginx-debug.service
/usr/lib/systemd/system/nginx.service

которые отличаются между собой только именем бинарника:

-ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
+ExecStart=/usr/sbin/nginx-debug -c /etc/nginx/nginx.conf

а во всем остальном - полностью идентичны между собой.

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

пока что - четыре варианта бинарников, но в будущем можно добавить
и другие форки и другие варианты бинарного файла /usr/sbin/nginx

To Konstantin Pavlov:

можно так сделать? хотя бы только для Rocky Linux 9 / RHEL 9

но вообще, сам механизм alternatives есть во многих дистрибутивах.
В Rocky Linux 9 / RHEL 9 бинарник alternatives - это

Re: announcing freenginx.org

2024-02-16 Пенетрантность raven...@megaline.kg

В данной конкретной истори особо доставляет то, что обсуждение форка (и 
будущего этого самого форка) происходит в списке рассылки форкнутого 
продукта 😆

16.02.2024 19:21, Илья Шипицин пишет:

пт, 16 февр. 2024 г. в 10:25, Evgeniy Berdnikov :

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

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

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

отдельно доставляет в подобных историях наличие code conduct и 
contribution policy.
по идее, в каждом проекте есть некие разделяемые всеми правила, как 
поступать,

как комитить и так далее.

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

но каждый божий раз эти code of conduct оказываются филькиной грамотой ))
как жить то, одни понятия, никаких законов

-- 
 Eugene Berdnikov

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

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

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

Re: announcing freenginx.org

2024-02-15 Пенетрантность raven...@megaline.kg


Боюсь, придется с этим смириться и перебороть свою лень)
https://mailman.nginx.org/pipermail/nginx-devel/2024-February/YIFSHIYSKDFBYZ2QRA3WF6SRPGIBDBKI.html

15.02.2024 17:24, izor...@gmail.com пишет:


Добрый день, Raven.


Только вот вполне вероятно, что большинству людей проще работать с 
git. Я как


пытался сделать несколько коммитов mercurial, а потом 
подкорректировать их,


но в итоге не справился :( А дальше было лень разбираться.

Да и в web-интерфейсе mercurial нет возможности создать вопросы и/или 
отправить


PR. Для этого надо писать письмо с вложенным патчем.

Вы писали 15 февраля 2024 г., 13:27:29:


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


--
С уважением,
 Izorkin mailto:izor...@gmail.com 

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


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

Re: announcing freenginx.org

2024-02-15 Пенетрантность raven...@megaline.kg

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

15.02.2024 16:20, izor...@gmail.com пишет:

Добрый день, Raven.

Как вариант есть новый формат форумов на базе flarum и discourse.

Ещё можно поднять свой git репозиторий на базе Gitea/Forgejo. К тому

же в Forgejo планируется внедрение протокола ForgeFed, который позволит

создавать запросы и PR между другими git инстансами:

https://forgefed.org

Вы писали 15 февраля 2024 г., 5:41:17:

Форумы давно мертвы как формат общения. Исправно рабатают только
старые площадки, с давно наруленным сообществом, но и они
переживают не лучшие времена. Списки рассылки, кстати,
направляются туда же. Всем теперь issues на github-е подавай :smile:

--
С уважением,
Izorkin mailto:izor...@gmail.com

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

Re: announcing freenginx.org

2024-02-14 Пенетрантность raven...@megaline.kg


15.02.2024 01:25, izor...@gmail.com пишет:

Некоторым людям удобнее работать с форумом, попробовать можно :)


Форумы давно мертвы как формат общения. Исправно рабатают только старые 
площадки, с давно наруленным сообществом, но и они переживают не лучшие 
времена. Списки рассылки, кстати, направляются туда же. Всем теперь 
issues на github-е подавай :smile:
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Пользовательская переменная между секциями server

2022-09-08 Пенетрантность raven...@megaline.kg


08.09.2022 15:57, raven...@megaline.kg пишет:
proxy_pass http://$upstream; 


прошу прощения, сам запутался в переменных 😁 Тут должно быть 
http://$backend


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

Re: Пользовательская переменная между секциями server

2022-09-08 Пенетрантность raven...@megaline.kg


08.09.2022 15:47, sunrules пишет:

Существует Nginx балансер в нем прописаны несколько бэкендов.
На бэках находятся сайты, к которым можно обратиться, указав в части url
определенную аббревиатуру. По сути, это отдельные сайты со своими
собственными именами.
Задача, на балансере нужно настроить возможность отправлять запрос на нужный
сайт бэкенда в зависимости от получаемого url.
В моей конфигурации есть проблема, я пытаюсь задать пользовательскую
переменную в Nginx на балансере, которая содержит в себе эту аббревиатуру
(которую нужно использовать в url для бэков) в одной секции server и
передать ее в другую секцию server, все это в одном конфигурационном файле.
На мой взгляд данное решение самое простое, но похоже такой способ в Nginx
не работает. В итоге переменная ничего не отдает, то есть данные из секции в
секцию не передаются.
В логах: http://.site.back1.example.org

### Balancing
server {
   listen 80;
   server_name "~(?[a-z0-9\-\.]+)\.site\.example\.org$";
   set $site_release $release;
   location / {
 proxy_http_version 1.1;
 proxy_pass http://upstr_release_site__X/;
   }
}

### Backend
server {
   listen unix:/tmp/nginx/nginx_release__X.site.back1.socket;
   access_log off;
   location / {
 proxy_http_version 1.1;
 proxy_pass http://$site_release.site.back1.example.org/;
   }
}
  
Подскажите пожалуйста, какое решение можно применить в данном случае?


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

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


Я бы покурил в сторону map. Пример с коленки, не уверен в 100% 
работоспособности, но я бы опробовал что-то типа:


map $host $backend {

    default localhost;

 "~(?[a-z0-9\-\.]+)\.site\.example\.org$" 
$release.site.back1.example.org/;


}

...

proxy_pass http://$upstream;

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

Re: certbot

2022-07-05 Пенетрантность raven...@megaline.kg

Если уж хочется bash-скриптов, то acme.sh хорошая альтернатива, однако, 
врочем как и в случае с ЛЮБЫМ софтом - сперва нужно ознакомиться с 
мануалами или хотя бы с тем, что в --help. certbot тоже вполне вменяемо 
выписывает сертификаты без манипуляций с конфигами веб-серверов)))


06.07.2022 03:52, Maxim Dounin пишет:

Hello!

On Tue, Jul 05, 2022 at 10:09:33PM +0300, Gena Makhomed wrote:


On 05.07.2022 15:55, Maxim Dounin wrote:


Отмечу, что если сертификаты обновлялись с помощью Certbot, то он
при обновлении модифицирует конфиги nginx'а (а потом возвращает
всё "как было").  Это может заканчиваться, скажем так, неожиданно.
Лично я рекомендую для выпуска сертификатов использовать
Dehydrated и необходимые дополнения в конфиг прописывать руками.

certbot так криво себя ведет только в дефолтовой конфигурации.

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

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



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

Re: nginx-1.22 lua-resty-core-0.1.23 not working.

2022-05-28 Пенетрантность raven...@megaline.kg


Hi,

I believe you can reach them by opening a github issue 
https://github.com/openresty/lua-nginx-module/issues



28.05.2022 12:33, bagas wrote:

Maxim Dounin Wrote:
---

Hello!

On Fri, May 27, 2022 at 02:33:21AM -0400, bagas wrote:


Maxim Dounin Wrote:
---

Hello!

On Wed, May 25, 2022 at 02:33:10AM -0400, bagas wrote:


Hello.
nginx-1.22 lua-resty-core-0.1.23 not working.

My system FreeBSD 12.3-RELEASE-p5 amd64.
Installed ports:
nginx-1.22.0,2
lua-resty-core-0.1.23
pcre-8.45_1
pcre2-10.40

Error:
nginx -t
nginx: [emerg] dlopen()

"/usr/local/libexec/nginx/ngx_http_lua_module.so"

failed (/usr/local/libexec/nginx/ngx_http_lua_module.so:

Undefined

symbol

"pcre_free") in /usr/local/etc/nginx/nginx.conf:2
nginx: configuration file /usr/local/etc/nginx/nginx.conf test

failed

This looks like a lua module issue, it tries to use pcre_free()
directly instead of using nginx interfaces, and fails because
nginx was compiled with PCRE2 instead of PCRE.  Try to recompile
nginx with PCRE instead of PCRE2, this should work till the issue
in the lua module is fixed.

(The nginx-devel port provides explicit options to do PCRE vs.
PCRE2 selection.  The nginx port maintainer probably should copy
this.)

Thanks for the info.
I had to fix the port /usr/ports/www/nginx/.
When will the situation with pcre2 be resolved?

That's the question to the author of the lua module.

--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org


How to contact the developer of the lua module?
I want to inform him about this situation.

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

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



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

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

2022-04-27 Пенетрантность raven...@megaline.kg

Если "на основе лога", то да - fail2ban самое оно. Выписать эти запросы 
в отдельный лог и скормить его специально обученному fail2ban-ну)))
А если не "на основе лога", то либо 444 возвращать, либо внедрять в 
конфиг логику (например на lua)


27.04.2022 13:17, alexander_st пишет:

Добрый день.
Можно ли на основе лога типа такого

2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule,
client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host:
"*"
2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule,
client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host:
"*"
2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule,
client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host:
"*"
2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule,
client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host:
"*"
2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule,
client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host:
"*"

отправлять адреса в бан? Только сторонним парсингом лога?
Понятно, что правилом на такие запросы (не GET, не POST) отдаю 444. Плюс
настроены ограничения зон. Плюс стоит fail2ban.

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

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



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

Re: libgd

2021-09-28 Пенетрантность raven...@megaline.kg


Куда елементарнее было бы подключить репозитории remi и обновить gd

yum localinstallhttp://rpms.famillecollet.com/enterprise/remi-release-7.rpm  

yum install gd-last


gd-last выступает как прозрачная замена системной и при этом таки

# rpm -qa | grep gd gd-last-2.3.3-2.el7.remi.x86_64


29.09.2021 00:01, Vladimir jdwuzhere пишет:

Элементарно, Ватсон :)

Благодарю! Не такой прямой способ, как указать путь к исходникам 
libgd, но проблему решает.


Ещё раз спасибо!


On 28 Sep 2021, at 20:38, Илья Шипицин  wrote:

у меня получался нужный фокус через --with-cc-opt и --with-ld-opt, 
типа такого (но скомпилять libgd в нужную папку нужно предварительно 
самому).

убедиться, что слинковано с нужным libgd можно через "ldd nginx"



export PREFIX=/opt/libgd
./configure ... --with-cc-opt=" -I${PREFIX}/include" 
--with-ld-opt="-L${PREFIX}/lib -fPIC -Wl,-rpath,${PREFIX}/lib"


вт, 28 сент. 2021 г. в 21:55, Vladimir jdwuzhere :

Привет!

Досталась коробочка с CentOS 7 и вместе с ней gblib 2.0.34 :( а
так хочется нагрузить её ресайзом webp, аж зубы сводит. Нет ли
возможности указать в ./configure путь к исходникам libgd-2.3.3
по аналогии с --with-openssl  --with-zlib и --with-pcre?

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

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



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


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

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

2021-04-08 Пенетрантность raven...@megaline.kg


08.04.2021 19:06, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 07:03:19PM +0600, raven...@megaline.kg wrote:


По поводу скорости - да, я возможно не совсем корректно охарактеризовал
суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?)

08.04.2021 18:56, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:

топквотинг



Сударь использует GPRS?)


такую, что в топквотинговой переписке я объяснений давать не буду

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


Чтож, это ваше право)

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

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

2021-04-08 Пенетрантность raven...@megaline.kg

По поводу скорости - да, я возможно не совсем корректно охарактеризовал 
суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?)


08.04.2021 18:56, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:

топквотинг



Сударь использует GPRS?)


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

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

2021-04-08 Пенетрантность raven...@megaline.kg

Я не отрицаю, что ssl требует больше времени на шифрование. Но почему 
оно более чем в 2 раза для ttfb?


08.04.2021 18:46, Slawa Olhovchenkov пишет:

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:


Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на 200мс дольше.

а откуда идея что должно быть иначе?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru



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

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

2021-04-08 Пенетрантность raven...@megaline.kg

Это я уже опробовал. Также пробовал сборку с патчем от Cloudflare 
(динамический размер записей TLS) с дефолтными настройками:


ssl_dyn_rec_enable    on;
ssl_dyn_rec_size_lo   1369;
ssl_dyn_rec_size_hi   4229;
ssl_dyn_rec_threshold 20;
ssl_dyn_rec_timeout   10;

получил даже небольшую регрессию)

08.04.2021 18:18, Константин Ткаченко пишет:



8 апр. 2021 г., в 15:04, Илья Шипицин <mailto:chipits...@gmail.com>> написал(а):


Действительно. Я проглядел

On Thu, Apr 8, 2021, 2:32 PM raven...@megaline.kg 
<mailto:raven...@megaline.kg> <mailto:raven...@megaline.kg>> wrote:


Включен)
> ssl_stapling on;


08.04.2021 17:29, Илья Шипицин пишет:

Попробуйте stapling включить

On Thu, Apr 8, 2021, 2:28 PM raven...@megaline.kg
<mailto:raven...@megaline.kg> mailto:raven...@megaline.kg>> wrote:

Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на
200мс дольше.


# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
https:///robots.txt
Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
http:///robots.txt
Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732


Для меня не новость, что SSL требует время для шифрования,
но не слишком-ли много? Ниже выдержки из конфига со всем,
что касается SSL:


ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ssl_ciphers

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

ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSLCache:16m;
ssl_session_timeout   10m;
ssl_session_tickets   off;
ssl_dhparam /etc/nginx/ssl/dh1024.pem;
ssl_ecdh_curve    secp384r1;
ssl_buffer_size   16k;

server {

listen :80 fastopen=256;

listen :443 fastopen=256 ssl; #http2

ssl_certificate_key /etc/nginx/ssl/.key;
ssl_certificate /etc/nginx/ssl/.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/.pem;

...

}


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


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



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

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


Можно уменьшить ssl_buffer_size до 4k;
Об этом в доках тоже есть
https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_buffer_size 
<https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_buffer_size>


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



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

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

2021-04-08 Пенетрантность raven...@megaline.kg


Включен)
> ssl_stapling on;


08.04.2021 17:29, Илья Шипицин пишет:

Попробуйте stapling включить

On Thu, Apr 8, 2021, 2:28 PM raven...@megaline.kg 
<mailto:raven...@megaline.kg> <mailto:raven...@megaline.kg>> wrote:


Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на 200мс
дольше.


# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
https:///robots.txt
Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB:
%{time_starttransfer} Total time: %{time_total} \n"
http:///robots.txt
Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732


Для меня не новость, что SSL требует время для шифрования, но не
слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:


ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ssl_ciphers

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

ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSLCache:16m;
ssl_session_timeout   10m;
ssl_session_tickets   off;
ssl_dhparam   /etc/nginx/ssl/dh1024.pem;
ssl_ecdh_curve    secp384r1;
ssl_buffer_size   16k;

server {

listen :80 fastopen=256;

listen :443 fastopen=256 ssl; #http2

ssl_certificate_key /etc/nginx/ssl/.key;
ssl_certificate /etc/nginx/ssl/.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/.pem;

...

}


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


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



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

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

2021-04-08 Пенетрантность raven...@megaline.kg


Доброго дня!

nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

Замечено, что по https отдача первого байта происходит на 200мс дольше.


# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
%{time_starttransfer} Total time: %{time_total} \n" 
https:///robots.txt

Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
# curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
%{time_starttransfer} Total time: %{time_total} \n" 
http:///robots.txt

Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732


Для меня не новость, что SSL требует время для шифрования, но не 
слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:



   ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

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

   ssl_prefer_server_ciphers off;
   ssl_session_cache shared:SSLCache:16m;
   ssl_session_timeout   10m;
   ssl_session_tickets   off;
   ssl_dhparam   /etc/nginx/ssl/dh1024.pem;
   ssl_ecdh_curve    secp384r1;
   ssl_buffer_size   16k;

   server {

   listen :80 fastopen=256;

   listen :443 fastopen=256 ssl; #http2

   ssl_certificate_key /etc/nginx/ssl/.key;
   ssl_certificate /etc/nginx/ssl/.pem;
   ssl_stapling on;
   ssl_stapling_verify on;
   ssl_trusted_certificate /etc/nginx/ssl/.pem;

   ...

   }


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

Re: Ошибки при использовании zlib-ng

2021-03-31 Пенетрантность raven...@megaline.kg

В одном из предыдущих сообщений есть ссылка на патч, подключающий 
zlib-ng, собранную без совмесимости с zlib


01.04.2021 02:18, izor...@gmail.com пишет:

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

Если в сборке zlib-ng отключить совместимость с zlib, то nginx не видит zlib-ng 
и собирается с zlib 1.2.11.
Или эти патчи работают только в режиме совместимости с zlib?

Вы писали 29 марта 2021 г., 16:19:47:


Hello!
On Mon, Mar 29, 2021 at 01:00:21PM +0600, raven...@megaline.kg wrote:
[...]

Будут-ли эти правки включены в какой-либо из релизов?

Да, как только пройдут review.




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

Re: Ошибки при использовании zlib-ng

2021-03-29 Пенетрантность raven...@megaline.kg

Это патч, позволяющий использовать zlib-ng собранную без совместимости с 
нативной zlib, т.е. исключается возможность выбора библиотеки.


29.03.2021 13:04, izor...@gmail.com пишет:

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

А патч, который расположен тут - 
https://github.com/zlib-ng/patches/tree/master/nginx не подойдёт?

Вы писали 29 марта 2021 г., 5:09:14:


Взглянул, урезал.
...




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

Re: Ошибки при использовании zlib-ng

2021-03-29 Пенетрантность raven...@megaline.kg


29.03.2021 08:09, Maxim Dounin пишет:

Hello!

On Fri, Mar 26, 2021 at 09:54:43PM +0300, Maxim Dounin wrote:


Hello!

On Fri, Mar 26, 2021 at 01:32:48PM +0300, Sergey Kandaurov wrote:


On 26 Mar 2021, at 13:14, raven...@megaline.kg wrote:

После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме 
совместимости с zlib) лог буквально завален ошибками:

"gzip filter failed to use preallocated memory: 65536 of 0 while sending to 
client"

Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к 
какой-то из версий 1.13.


Попробуйте патч, при сборке с zlib-ng:

diff --git a/src/http/modules/ngx_http_gzip_filter_module.c 
b/src/http/modules/ngx_http_gzip_filter_module.c
--- a/src/http/modules/ngx_http_gzip_filter_module.c
+++ b/src/http/modules/ngx_http_gzip_filter_module.c
@@ -516,7 +516,7 @@ ngx_http_gzip_filter_memory(ngx_http_req
   */
  
  if (conf->level == 1) {

-wbits = ngx_max(wbits, 13);
+wbits = ngx_max(wbits, 15);

Насколько я вижу, в zlib-ng используюся те же 13, что и в варианте
от Intel:

https://github.com/jtkukunas/zlib/blob/master/deflate.c#L296
https://github.com/zlib-ng/zlib-ng/blob/develop/deflate.c#L304

А вот аллокация под hash стала 2x64k.

(В интеловском варианте, кстати, за последнее время и hash
подужался, и windowBits в 13 ставится только для значений, больших
13.  Возможно, на него стоит ещё разок взглянуть и урезать осетра.)

Взглянул, урезал.

# HG changeset patch
# User Maxim Dounin 
# Date 1616983280 -10800
#  Mon Mar 29 05:01:20 2021 +0300
# Node ID d82e9d8285e2552cafcea2033069cdd31f4a5d32
# Parent  1ebd78df4ce7262967c5dadce7bac454c4086896
Gzip: support for zlib-ng.

diff --git a/src/http/modules/ngx_http_gzip_filter_module.c 
b/src/http/modules/ngx_http_gzip_filter_module.c
--- a/src/http/modules/ngx_http_gzip_filter_module.c
+++ b/src/http/modules/ngx_http_gzip_filter_module.c
@@ -57,6 +57,7 @@ typedef struct {
  unsigned nomem:1;
  unsigned buffering:1;
  unsigned intel:1;
+unsigned zlib_ng:1;
  
  size_t   zin;

  size_t   zout;
@@ -214,6 +215,7 @@ static ngx_http_output_header_filter_pt
  static ngx_http_output_body_filter_ptngx_http_next_body_filter;
  
  static ngx_uint_t  ngx_http_gzip_assume_intel;

+static ngx_uint_t  ngx_http_gzip_assume_zlib_ng;
  
  
  static ngx_int_t

@@ -506,7 +508,7 @@ ngx_http_gzip_filter_memory(ngx_http_req
  if (!ngx_http_gzip_assume_intel) {
  ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9));
  
-} else {

+} else if (!ngx_http_gzip_assume_zlib_ng) {
  /*
   * A zlib variant from Intel, https://github.com/jtkukunas/zlib.
   * It can force window bits to 13 for fast compression level,
@@ -523,6 +525,20 @@ ngx_http_gzip_filter_memory(ngx_http_req
   + (1 << (ngx_max(memlevel, 8) + 8))
   + (1 << (memlevel + 8));
  ctx->intel = 1;
+
+} else {
+/*
+ * Another zlib variant, https://github.com/zlib-ng/zlib-ng.
+ * Similar to Intel's variant, though uses 128K hash.
+ */
+
+if (conf->level == 1) {
+wbits = ngx_max(wbits, 13);
+}
+
+ctx->allocated = 8192 + 16 + (1 << (wbits + 2))
+ + 131072 + (1 << (memlevel + 8));
+ctx->zlib_ng = 1;
  }
  }
  
@@ -945,11 +961,14 @@ ngx_http_gzip_filter_alloc(void *opaque,

  return p;
  }
  
-if (ctx->intel) {

+if (ctx->zlib_ng) {
  ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0,
"gzip filter failed to use preallocated memory: "
"%ud of %ui", items * size, ctx->allocated);
  
+} else if (ctx->intel) {

+ngx_http_gzip_assume_zlib_ng = 1;
+
  } else {
  ngx_http_gzip_assume_intel = 1;
  }
# HG changeset patch
# User Maxim Dounin 
# Date 1616983654 -10800
#  Mon Mar 29 05:07:34 2021 +0300
# Node ID e70b352ddb2ed1e92997408b3926e64aa55b4a14
# Parent  d82e9d8285e2552cafcea2033069cdd31f4a5d32
Gzip: updated handling of zlib variant from Intel.

In current versions (all versions based on zlib 1.2.11, at least
since 2018) it no longer uses 64K hash and does not force window
bits to 13 if it is less than 13.  That is, it needs just 16 bytes
more memory than normal zlib, so these bytes are simply added to
the normal size calculation.

diff --git a/src/http/modules/ngx_http_gzip_filter_module.c 
b/src/http/modules/ngx_http_gzip_filter_module.c
--- a/src/http/modules/ngx_http_gzip_filter_module.c
+++ b/src/http/modules/ngx_http_gzip_filter_module.c
@@ -56,7 +56,6 @@ typedef struct {
  unsigned done:1;
  unsigned nomem:1;
  unsigned buffering:1;
-uns

Re: Ошибки при использовании zlib-ng

2021-03-26 Пенетрантность raven...@megaline.kg


Т.е. использовать нативную сборку nginx не получится?

26.03.2021 16:32, Sergey Kandaurov пишет:

On 26 Mar 2021, at 13:14, raven...@megaline.kg wrote:

После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме 
совместимости с zlib) лог буквально завален ошибками:

"gzip filter failed to use preallocated memory: 65536 of 0 while sending to 
client"

Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к 
какой-то из версий 1.13.


Попробуйте патч, при сборке с zlib-ng:

diff --git a/src/http/modules/ngx_http_gzip_filter_module.c 
b/src/http/modules/ngx_http_gzip_filter_module.c
--- a/src/http/modules/ngx_http_gzip_filter_module.c
+++ b/src/http/modules/ngx_http_gzip_filter_module.c
@@ -516,7 +516,7 @@ ngx_http_gzip_filter_memory(ngx_http_req
   */
  
  if (conf->level == 1) {

-wbits = ngx_max(wbits, 13);
+wbits = ngx_max(wbits, 15);
  }
  
  ctx->allocated = 8192 + 16 + (1 << (wbits + 2))





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

Ошибки при использовании zlib-ng

2021-03-26 Пенетрантность raven...@megaline.kg

После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме 
совместимости с zlib) лог буквально завален ошибками:


"gzip filter failed to use preallocated memory: 65536 of 0 while sending 
to client"


Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в 
анонсе к какой-то из версий 1.13.


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

Re: nginx 1.18 lua51

2020-09-15 Пенетрантность raven...@megaline.kg

Одно дело собрать с нужным модулем, другое дело - запустить с ним. 
Модуль собран динамически, соотв. должен быть загружен 
черезhttp://nginx.org/ru/docs/ngx_core_module.html#load_module 



15.09.2020 19:21, bagas пишет:

Добрый день.
Подскажите пожалуйста по проблеме как быть.
Установил lua51 и указала поддержку в nginx lua.
Создал виртуал хост, делаю проверку синтаксиса.

Nginx ставил из портов.

  nginx -t
nginx: [emerg] unknown directive "content_by_lua_block" in
/usr/local/etc/nginx/sites-enabled/test.jpeg_png:49
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

Почему-то не видится директива content_by_lua_block.

Система freebsd 11.3

Nginx собран с
--add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.17

nginx -V
nginx version: nginx/1.18.0
built with OpenSSL 1.1.1g  21 Apr 2020
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-pcre --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_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
--add-dynamic-module=/usr/ports/www/nginx/work/ngx_devel_kit-0.3.1
--add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.17

Софт в системе установлен такой:

lua-resty-core-0.1.19  =
lua-resty-lrucache-0.10=
lua51-5.1.5_9  =
lua51-luarocks-3.3.1   =
luajit-openresty-2.1.20200102  =

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

___
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

Использование переменных в proxy_cache_valid

2020-07-08 Пенетрантность raven...@megaline.kg


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

Возникла необходимость задавать разное время кэширования для некоторых 
IP, возможно-ли это реализовать в nginx не дробя в разные локейшены?


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


   geo $cache_time {

    default 1m;

 192.168.0.12 10s;

   }

   ...

   proxy_cache_valid 200 301 $cache_time;


тоже не сработала:

   nginx: [emerg] invalid time value "$cache_time"

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

Re: Простейший пример прокси

2019-05-21 Пенетрантность raven...@megaline.kg

что-то мне подсказывает, что где-то нужен try_files $uri $uri @apache; и 
сам @apache описать

21.05.2019 15:58, medved пишет:

В файле /etc/nginx/sites-enabled/default в location также добавил

 proxy_cache all;
 proxy_cache_valid any 1h;

Не помогло...

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

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



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

Re: signer certificate not found после обновления

2019-05-20 Пенетрантность raven...@megaline.kg


Благодарю, откат libressl до 2.8.3 решил проблему.

17.05.2019 18:50, Maxim Dounin пишет:

Hello!

On Fri, May 17, 2019 at 05:49:09PM +0600, raven...@megaline.kg wrote:


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

Обновил Nginx c 1.14 до 1.16, посыпались ошибки в лог

2019/05/17 11:22:50 [error] 2487#2487: OCSP_basic_verify() failed (SSL:
error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not
found) while requesting certificate status, responder:
ocsp.int-x3.letsencrypt.org, peer: 2.21.33.128:80, certificate:
"/etc/pki/letsencrypt/домен/fullchain.cer"
2019/05/17 11:33:46 [error] 2487#2487: OCSP_basic_verify() failed (SSL:
error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not
found) while requesting certificate status, responder:
ocsp.int-x3.letsencrypt.org, peer: 23.203.249.34:80, certificate:
"/etc/pki/letsencrypt/домен/fullchain.cer"

Сайты (их, к слову, куда больше чем один) при этом продолжают работать.
fullchain.cer содержит и сертификат домена и промежуточный сертификат.

Откатываюсь обратно на 1.14.2 - ошибки пропадают. С чем может быть
связано такое изменение поведения?

С вот этим:


 built with LibreSSL 2.9.1

Подробности тут:

http://mailman.nginx.org/pipermail/nginx-ru/2019-May/062150.html
http://mailman.nginx.org/pipermail/nginx-devel/2019-May/012212.html



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

signer certificate not found после обновления

2019-05-17 Пенетрантность raven...@megaline.kg


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

Обновил Nginx c 1.14 до 1.16, посыпались ошибки в лог

2019/05/17 11:22:50 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
found) while requesting certificate status, responder: 
ocsp.int-x3.letsencrypt.org, peer: 2.21.33.128:80, certificate: 
"/etc/pki/letsencrypt/домен/fullchain.cer"
2019/05/17 11:33:46 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
found) while requesting certificate status, responder: 
ocsp.int-x3.letsencrypt.org, peer: 23.203.249.34:80, certificate: 
"/etc/pki/letsencrypt/домен/fullchain.cer"


Сайты (их, к слову, куда больше чем один) при этом продолжают работать. 
fullchain.cer содержит и сертификат домена и промежуточный сертификат.


Откатываюсь обратно на 1.14.2 - ошибки пропадают. С чем может быть 
связано такое изменение поведения?


Часть конфига, ответственная за SSL:

    # SSL
    ssl_certificate_key /etc/pki/letsencrypt/домен/домен.key;
    ssl_certificate /etc/pki/letsencrypt/домен/fullchain.cer;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/pki/letsencrypt/домен/fullchain.cer;


P.S. Вот на такой обновляюсь:

   nginx version: nginx/1.16.0 (Custom)
   built with LibreSSL 2.9.1
   TLS SNI support enabled
   configure arguments: --build='Custom' --prefix=/usr/share/nginx
   --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules
   --conf-path=/etc/nginx/nginx.conf
   --error-log-path=/var/log/nginx/error_log
   --http-log-path=/var/log/nginx/access_log
   --http-client-body-temp-path=/var/lib/nginx/tmp/client_body
   --http-proxy-temp-path=/var/lib/nginx/tmp/proxy
   --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi
   --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
   --http-scgi-temp-path=/var/lib/nginx/tmp/scgi
   --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx
   --user=nginx --group=nginx --with-file-aio --with-threads
   --with-http_ssl_module --with-http_v2_module
   --with-http_v2_hpack_enc --with-http_realip_module
   --with-http_addition_module --with-http_xslt_module=dynamic
   --with-http_image_filter_module=dynamic
   --with-http_geoip_module=dynamic --with-http_sub_module
   --with-http_dav_module --with-http_flv_module --with-http_mp4_module
   --with-http_gunzip_module --with-http_gzip_static_module
   --with-http_random_index_module --with-http_secure_link_module
   --with-http_degradation_module --with-http_slice_module
   --with-http_stub_status_module --with-http_perl_module=dynamic
   --with-mail=dynamic --with-mail_ssl_module --with-pcre
   --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module
   --with-google_perftools_module --with-debug
   --add-dynamic-module=headers-more-nginx-module-0.33
   --add-dynamic-module=ngx_devel_kit-0.3.1rc1
   --add-dynamic-module=lua-nginx-module-0.10.15
   --add-dynamic-module=nginx-eval-module-master
   --add-dynamic-module=ngx_brotli --with-ld-opt='-L/opt/libressl/lib
   -Wl,-rpath=/opt/libressl/lib -lrt -lcrypto -lssl -ltls -Wl,-z,relro
   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'
   --with-cc-opt='-DNGX_LUA_ABORT_AT_PANIC -I/opt/libressl/include -O2
   -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
   -fstack-protector-strong --param=ssp-buffer-size=4
   -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
   -m64 -mtune=generic -DTCP_FASTOPEN=23'

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

Re: Listen и default server

2019-05-15 Пенетрантность raven...@megaline.kg

И да, 0.0.0.0:8000 и 127.0.0.1:8000 - это разные сокеты, соотв. если в 
запросе указан http://127.0.0.1:8000, то он не попадет в сокет другого 
IP, что бы там в Host не было передано. Так что тут нужно строить конфиг 
изначально с учетом этого нюансика)


15.05.2019 14:35, raven...@megaline.kg пишет:

Где нужен конкретный IP - указывать IP, где нет - использовать 0.0.0.0

15.05.2019 14:32, ingtar пишет:

Столкнулся с такой ситуацией:
Есть много разных виртуальных хостов, что висят на разных адресах у 
машины.

Где-то указаны конкретные IP, где-то звездочка.
При добавлении нового виртуального хоста иногда возникает ситуация, что
запросы начинают обрабатываться другими хостами, т.е. меняется логика в
обработке запросов.
Пример конфига:

server {
 listen 8000;
 server_name test1;

 location / {
 return 200 'responce from test1';
 }
}

server {
 listen 8000 default_server;
 server_name test2;

 location / {
 return 200 'responce from test2!';
 }
}

server {
 listen 8000 ;
 server_name test3;

 location / {
 return 200 'responce from test3!';
 }
}

Тут все хорошо, запросы с заголовками test1,2,3 попадают в нужные 
хосты, без

заголовков попадают в default
но если указать у любого listen конкретный ip, например 127.0.0.1 то все
запросы начинает обрабатывать именно он, игнорируя заголовки Host и
default_server

Чисто логически я понимаю, что у него приоритет ИП, но выглядит 
странно :)

Есть какие-то практики в этом случае - только ИП везде или все без ИП?

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


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



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



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

Re: Listen и default server

2019-05-15 Пенетрантность raven...@megaline.kg


Где нужен конкретный IP - указывать IP, где нет - использовать 0.0.0.0

15.05.2019 14:32, ingtar пишет:

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

server {
 listen 8000;
 server_name test1;

 location / {
 return 200 'responce from test1';
 }
}

server {
 listen 8000 default_server;
 server_name test2;

 location / {
 return 200 'responce from test2!';
 }
}

server {
 listen 8000 ;
 server_name test3;

 location / {
 return 200 'responce from test3!';
 }
}

Тут все хорошо, запросы с заголовками test1,2,3 попадают в нужные хосты, без
заголовков попадают в default
но если указать у любого listen конкретный ip, например 127.0.0.1 то все
запросы начинает обрабатывать именно он, игнорируя заголовки Host и
default_server

Чисто логически я понимаю, что у него приоритет ИП, но выглядит странно :)
Есть какие-то практики в этом случае - только ИП везде или все без ИП?

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

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



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

Re: map + access log = bug

2018-12-24 Пенетрантность raven...@megaline.kg


Криво, но суть думаю ясна:
map $bot $not_bot {
default 1
1 0;
}
...

access_log /var/log/nginx/recipes.log main if=$not_bot;

if в access_log понимает только 1 (true)

24.12.2018 16:20, SmakPHP пишет:

Есть конфигурация

http {
...
   # The map is bot browsers
   map $http_user_agent $bot {
 default 0;
 "~Chrome" 1;
   }
...
}

server {
...
   # Logging access to the site
   access_log /var/log/nginx/recipes.log main if=!$bot;
   access_log /var/log/nginx/recipes.bot.log main if=$bot;
...
}

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

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/71.0.3578.98 Safari/537.36

хотя по идеи должно писаться только в файл recipes.bot.log

Может кто-нибудь сталкивался с подобной проблемой?

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

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



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

Re: Не работает reload

2018-11-02 Пенетрантность raven...@megaline.kg

В сторону systemd, если он есть. В /etc/systemd/system/ создать каталог 
nginx.service.d, в который положить rlimit_nofile.conf со сл. содержимым:


[Service]
LimitNOFILE=65536

и systemctl daemon-reload

02.11.2018 13:00, zxek пишет:

Добрый день.

Колво активных сайтов выросло и точно такая же ситуация.
при reload в журнал пишется
2018/11/02 11:55:11 [emerg] 1615#1615: open()
"/var/www/httpd-logs/*.ru.access.log" failed (24: Too many open files)

в настройках nginx
===
user www-data;
worker_processes  16;

worker_rlimit_nofile  20;

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

events {
 #-worker_connections  1;
 worker_connections  5120;
 multi_accept on;
 use epoll;
}
===

# ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 64232
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files  (-n) 30
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 64232
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

кто может подсказать, в какую сторону смотреть?

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

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



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

Re: Невозможно отключить http2

2018-10-03 Пенетрантность raven...@megaline.kg


Да, вы оказались правы, в одной из listen все же остался параметр http2.
В связи с этим возник следующий вопрос - получается, мне не
обязательно вписывать http2 в listen каждого блока server {}, если
все они слушают один и тот же сокет, например 0.0.0.0:443, а достаточно
указать только в одном?

02.10.2018 18:32, Maxim Dounin пишет:

Hello!

On Tue, Oct 02, 2018 at 06:11:53PM +0600, raven...@megaline.kg wrote:


Потребовалось отключить http2 для всех хостов, убрал из всех listen
упоминания http2, перезапустил nginx. В логах так и продолжают сыпаться
запросы HTTP/2.0. Чем может быть обусловлено такое поведение?

Наиболее вероятна одна из двух причин:

- из какой-то директивы listen параметр http2 не убран, и
   соответственно HTTP/2 используется для данного listen-сокета.

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



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

Невозможно отключить http2

2018-10-02 Пенетрантность raven...@megaline.kg


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

Потребовалось отключить http2 для всех хостов, убрал из всех listen 
упоминания http2, перезапустил nginx. В логах так и продолжают сыпаться 
запросы HTTP/2.0. Чем может быть обусловлено такое поведение?


# nginx -V
nginx version: nginx/1.14.0
built with LibreSSL 2.7.4
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx 
--sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules 
--conf-path=/etc/nginx/nginx.conf 
--error-log-path=/var/log/nginx/error_log 
--http-log-path=/var/log/nginx/access_log 
--http-client-body-temp-path=/var/lib/nginx/tmp/client_body 
--http-proxy-temp-path=/var/lib/nginx/tmp/proxy 
--http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi 
--http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi 
--http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid 
--lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx 
--with-file-aio --with-threads --with-http_ssl_module 
--with-http_v2_module --with-http_v2_hpack_enc --with-http_realip_module 
--with-http_addition_module --with-http_xslt_module=dynamic 
--with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic 
--with-http_sub_module --with-http_dav_module --with-http_flv_module 
--with-http_mp4_module --with-http_gunzip_module 
--with-http_gzip_static_module --with-http_random_index_module 
--with-http_secure_link_module --with-http_degradation_module 
--with-http_slice_module --with-http_stub_status_module 
--with-http_perl_module=dynamic --with-mail=dynamic 
--with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic 
--with-stream_ssl_module --with-google_perftools_module --with-debug 
--add-dynamic-module=headers-more-nginx-module-0.32 
--add-dynamic-module=ngx_devel_kit-0.3.1rc1 
--add-dynamic-module=lua-nginx-module-0.10.13 
--add-dynamic-module=nginx-eval-module-master 
--add-dynamic-module=ngx_brotli --with-ld-opt='-lcrypto -lssl -ltls 
-L/opt/libressl/lib -Wl,-rpath=/opt/libressl/lib -lrt -Wl,-z,relro 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E' 
--with-cc-opt='-DNGX_LUA_ABORT_AT_PANIC -I/opt/libressl/include -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic 
-DTCP_FASTOPEN=23'


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

Re: /usr/sbin/nginx alternatives

Re: announcing freenginx.org

Re: announcing freenginx.org

Re: announcing freenginx.org

Re: announcing freenginx.org

Re: Пользовательская переменная между секциями server

Re: Пользовательская переменная между секциями server

Re: certbot

Re: nginx-1.22 lua-resty-core-0.1.23 not working.

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

Re: libgd

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

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

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

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

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

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

Re: Ошибки при использовании zlib-ng

Re: Ошибки при использовании zlib-ng

Re: Ошибки при использовании zlib-ng

Re: Ошибки при использовании zlib-ng

Ошибки при использовании zlib-ng

Re: nginx 1.18 lua51

Использование переменных в proxy_cache_valid

Re: Простейший пример прокси

Re: signer certificate not found после обновления

signer certificate not found после обновления

Re: Listen и default server

Re: Listen и default server

Re: map + access log = bug

Re: Не работает reload

Re: Невозможно отключить http2

Невозможно отключить http2

33 matches

Site Navigation

Mail list logo

Footer information