Странная ситуация с levels

2018-11-08 Пенетрантность CoDDoC 
nginx-debug -v
nginx version: nginx/1.15.6

Специально обновился, до этого была версия 1.13.12, там то же самое.
Изменение levels в proxy_cache_path применяется только после полного рестарта 
(service nginx-debug restart)
nginx-debug -s reload ожидаемого результата не дает

Как воспроизвести:
1. В контексте http:
proxy_cache_path /var/www/html/cache levels=1:2:1 use_temp_path=off 
keys_zone=testcache:5m inactive=10m max_size=50m;
2. service nginx-debug restart
3. В error.log:
cache manager process  exited with code 0
start cache manager process 
start cache loader process 
4. Делаю запрос в локейшен, для которого активирована зона testcache
5. Получаю ожидаемое:
/var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
6. Удаляю ветку '3/05/8/e62d74fdc44e220f0225168323c28053'

7. Меняю levels 1:2:1 -> levels 1
8. nginx-debug -s reload
9. В error.log:
cache "testcache" had previously different levels
10. Запрос в тот же локейшен дает тот же результат:
/var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
11. Опять удаляю '3/05/8/e62d74fdc44e220f0225168323c28053'
12. service nginx-debug restart
13. В error.log:
cache manager process  exited with code 0
start cache manager process 
start cache loader process 
14. Запрос в тот же локейшен опять дает ожидаемое:
/var/www/html/cache/3/e62d74fdc44e220f0225168323c28053

Если это нормальное поведение, может, имеет смысл как-то отметить в 
документации необходимость рестарта?

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

Re: pipe to http

2018-11-08 Пенетрантность Nick Knutov 

Очевидно, но nginx ведь не умеет сам ничего запускать.
Попробовал fcgiwrap, но или я что-то делаю неправильно, или когда клиент 
отваливается - sigpipe до скрипта не доходит.



07.11.2018 12:07, Dmitriy Lyalyuev пишет:

X-Accel-Redirect похоже то, что вам нужно.

--
With best regards,
Dmitriy Lyalyuev
dmit...@lyalyuev.info 



On Nov 7, 2018, at 02:59, Nick Knutov > wrote:


Доброго времени суток,

подскажите, как лучше реализовать такую задачу:

запрос приходит к nginx, отправляется некоторому скрипту 
(uwsgi->perl), который проверяет авторизацию, и если всё ок, то 
необходимо запустить какой-то процесс, который отдаст много гигабайт 
данных в stdout и это надо отдать хттп-клиенту.


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

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


--
Best Regards,
Nick Knutov
http://knutov.com
ICQ: 272873706
Voice: +7-904-84-23-130

___
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,
Nick Knutov
http://knutov.com
ICQ: 272873706
Voice: +7-904-84-23-130

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

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

2018-11-08 Пенетрантность Maxim Dounin 
Hello!

On Thu, Nov 08, 2018 at 12:10:57PM +0300, Sergey Bondarev wrote:

> Здравствуйте, Nginx-ru.
> 
> При  использовании сертификатов от letsencrypt, возникает проблема при
> первоначальном запуске.
> 
> Как  правило  новые  вирт.  хосты  с новыми доменами добавляются в уже
> существующий nginx, и на момент добавления у нас еще нет сертификатов.
> 
> соответсвенно  приходится  сначала  руками  добавлять конфиг nginx без
> SSL,  запускать  cert-bot,  для  получения  сертификата, менять конфиг
> nginx, добавляя туда listen ssl и сертификаты.
> 
> Жизнеспособна  ли  такая  идея  ?  Если  при  запуске nginx не находит
> сертификатов  по  тем  путям,  что  есть в конфиге он пишет ворнинг, и
> генерирует самоподписанный сертификат, который и начинает использовать
> для обслуживания хоста.

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

Поэтому nginx требует, чтобы указанное в конфиге - существовало, а 
если оно не существует и/или некорректно - то отказывается 
применять такую конфигурацию.  Это, в частности, отлично спасает 
от замены работающей конфигурации на неработающую при перезагрузке 
конфигурации.

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

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

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

2018-11-08 Пенетрантность Pavel 
On Thu, 8 Nov 2018 12:10:57 +0300 Sergey Bondarev 
 wrote:


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


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

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


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


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


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


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


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


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

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

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

2018-11-08 Пенетрантность Gena Makhomed 

On 08.11.2018 11:10, Sergey Bondarev wrote:


При  использовании сертификатов от letsencrypt, возникает проблема при
первоначальном запуске.

Как  правило  новые  вирт.  хосты  с новыми доменами добавляются в уже
существующий nginx, и на момент добавления у нас еще нет сертификатов.

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


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

После того как certbot сгенерирует сертификат - достаточно будет только
раскоментировать эти две директивы и сделать systemctl reload nginx
- после этого сайт будет полностью рабочим.


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


Или просто пишет warning о том, что не удалось найти файлов на диске
и ведет себя так, словно в конфиге для хоста нет директивы/директив
ssl_certificate и/или ssl_certificate_key.

--
Best regards,
 Gena

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

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

2018-11-08 Пенетрантность Sergey Bondarev 
Здравствуйте, Nginx-ru.

При  использовании сертификатов от letsencrypt, возникает проблема при
первоначальном запуске.

Как  правило  новые  вирт.  хосты  с новыми доменами добавляются в уже
существующий nginx, и на момент добавления у нас еще нет сертификатов.

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

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

-- 
С уважением,
 Sergey  mailto:s.bonda...@southbridge.ru

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

Re: один alias

2018-11-08 Пенетрантность Maksim Kulik 
Может просто на уровне server прописать root /srv/www/frontend/build/, а
для основного проекта прописать alias, либо root для location / ?
Не проверял, но мне кажется, что должно работать.

чт, 8 нояб. 2018 г. в 7:00, inkognito0609 :

> Slawa Olhovchenkov Wrote:
> ---
> > On Wed, Nov 07, 2018 at 07:34:18AM -0500, inkognito0609 wrote:
> >
> > > кейс такой:
> > > Основной проект лежит
> > > root   /srv/www/app/web;
> > >
> > > Появился новый проект по url /restore, отдаем html по другому адресу
> > > location /restore {
> > > alias /srv/www/frontend/build/;
> > >
> > > В дальнейшем планируется n количество url, например /some для
> > которого
> > > придется пилить свой и т.д.
> > > location /some {
> > > alias /srv/www/frontend/build/;
> > >
> > > Какие есть практики чтоб не кошмарить такой большой конф файл, со
> > своим
> > > location для каждого будущего url.
> > > На ум приходит создать location в который вкладывать остальные..
> >
> > я сделал скрипт на lua и он из редиса достает мапинги
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> установка дополнительного софта не вариант, необходимо решить в рамках
> самого nginx
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,281855,281868#msg-281868
>
> ___
> 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