Nginx ssl
Добрый день Есть сервер nginx работает как обратный прокси сервер, для некоторого количества сайтов, один из них нужно перевести на https, конфиг server { server_name www.example.com example.com; location / { proxy_pass http://192.168.0.23; proxy_redirect http://localhost/ http://$host:$server_port/; proxy_buffering off; proxy_set_headerHost$host; proxy_set_headerX-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 8M; } По адресу 192.168.0.23 Виртуалка с Nginx + phpfpm Вопрос где включать ssl на гипервизоре(обратная прокся) или на виртуалке с сайтом? И если можно в двух словах о том как это сделать. Спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266240,266240#msg-266240 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Slice cache
Hello! On Mon, Apr 18, 2016 at 04:37:52PM -0400, S.A.N wrote: > Я хотел бы узнать, Nginx умеет отдавать клиентам из своего кеша, ответы > частями? Да. > Корректный заголовок Range: bytes... клиент отправляет, но Nginx из кеша > отдает весь ответ статус - 200, вместо частичного ответа со статусом 206. По умолчанию range-запросы из кеша работают только в том случае, если в ответе бекенда был заголовок Accept-Ranges и должна быть явно указана длина ответа. Если заголовка Accept-Ranges нет - можно форсировать поддержку range-запросов с помощью директивы proxy_force_ranges (http://nginx.org/r/proxy_force_ranges/ru), но лучше его просто добавить в ответ бекенда. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Slice cache
Здравствуйте. Я хотел бы узнать, Nginx умеет отдавать клиентам из своего кеша, ответы частями? Корректный заголовок Range: bytes... клиент отправляет, но Nginx из кеша отдает весь ответ статус - 200, вместо частичного ответа со статусом 206. По сути нужен функционал обратный модулю Slice. Наш use case: Бекенд отдает, большой ресурсоемкий ответ (аналитик отчет - это результат многих сложных SQL) разным клиентам в разное время нужны только части этого отчета и иногда весь целиком. Модуль Slice только усложнит ситуацию, потому что он сгенерирует много подзапросов на бекенд, вот именно этого и нужно избежать, чтобы бекенд не генерировал куски отчета много раз, а один раз сделал полный отчет и отдал в кеш Nginx. Надеюсь это можно сделать. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266232,266232#msg-266232 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Инвалидация кэша
Спасибо за ответы, буду разбираться Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266217,266229#msg-266229 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx reload & restart
Hello! On Mon, Apr 18, 2016 at 06:50:27PM +0300, Анатолий Коростелев wrote: > Здравствуйте! > > Подскажите, пожалуйста, есть ли список параметров в конфигурационном файле > nginx, при изменении/добавлении/удаления которых достаточно и беспроблемно > использовать nginx reload, а не nginx restart/upgrade? В моей конфигурации > на множество серверов прилетают обновления конфигурационных файлов nginx и > хотелось бы минимизировать использовать restart/upgrade. Проблемы с reload'ом могут быть в случаях, когда затрагиваются параметры, разделяемые между многими процессами. В частности: - При изменениях зон разделяемой памяти - нельзя менять размеры существующих зон и/или их использование (скажем, в limit_req нельзя поменять одну переменную на другую). При этом можно создать новую зону с произвольными параметрами - при этом в старых рабочих процессах останется старая зона, а в новых - будет использоваться уже новая. - На Linux'е могут быть проблемы с изменением слушающих сокетов, т.к. скажем слушать на *:80 и 127.0.0.1:80 одновременно Linux не разрешает. Соответственно, при замене в конфигах одного на другое reload будет невозможен, т.к. Linux не разрешит сделать bind() для сокета из новой конфигурации Если nginx не может сделать reload по каким либо причинам, в том числе - по перечисленным выше, а равно из-за каких-либо ошибок, - об этом будет написано в логе, а сам nginx останется работать с прежней конфигурацией. > В основном, мой вопрос касается в случае обновления файлов ssl-сертификата и > ключа, достаточно будет в этом случае reload или будут подводные камни? Каких-либо специфических проблем при обновлении сертификатов - быть не должно. Однако в любом случае могут возникнуть непредвиденные проблемы - e.g., может банально кончится память. Т.е. в любом случае - стоит смотреть в логи. Использовать restart/upgrade для обновления сертификатов - однозначно не надо. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx reload & restart
В письме от 18 апреля 2016 18:50:27 пользователь Анатолий Коростелев написал: > Здравствуйте! > > Подскажите, пожалуйста, есть ли список параметров в конфигурационном > файле nginx, при изменении/добавлении/удаления которых достаточно и > беспроблемно использовать nginx reload, а не nginx restart/upgrade? В > моей конфигурации на множество серверов прилетают обновления > конфигурационных файлов nginx и хотелось бы минимизировать использовать > restart/upgrade. > > В основном, мой вопрос касается в случае обновления файлов > ssl-сертификата и ключа, достаточно будет в этом случае reload или будут > подводные камни? > > P.S. Версия nginx/1.9.13 Здравствуйте! > SIGHUP Reload configuration, start the new worker process with a > new configuration, and gracefully shut down old worker pro‐> > cesses. Так что можете использовать reload при любом обновлении конфигурации. Касательно обновления сертификатов у меня по крону обновляются сертификаты от letsencrypt с дальнейшим nginx reload. Подводных камней не заметил. Только не забывайте проверять файлы конфигурации на ошибки. nginx, получивший SIGHUP промолчит при ошибках в конфиге. Поэтому перед этим надо делать nginx -t. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Инвалидация кэша
On Monday 18 April 2016 11:56:33 vitcool wrote: > я считал что proxy_cache_bypass не приводит к инвалидации кэша, а просто > отправляет запрос к бекенду напрямую > [..] Но соответствующая запись кэша может быть при этом обновлена. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Инвалидация кэша
я считал что proxy_cache_bypass не приводит к инвалидации кэша, а просто отправляет запрос к бекенду напрямую Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266217,266223#msg-266223 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx reload & restart
Здравствуйте! Подскажите, пожалуйста, есть ли список параметров в конфигурационном файле nginx, при изменении/добавлении/удаления которых достаточно и беспроблемно использовать nginx reload, а не nginx restart/upgrade? В моей конфигурации на множество серверов прилетают обновления конфигурационных файлов nginx и хотелось бы минимизировать использовать restart/upgrade. В основном, мой вопрос касается в случае обновления файлов ssl-сертификата и ключа, достаточно будет в этом случае reload или будут подводные камни? P.S. Версия nginx/1.9.13 -- С уважением, Коростелев Анатолий ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Инвалидация кэша
On Monday 18 April 2016 06:50:51 vitcool wrote: > Добрый день! > > Правильно ли я понимаю, что инвалидировать кэш заголовком в запросе можно > только в "платной" версии nginx? > Если речь идет про директиву "proxy_cache_purge" )и подобные в scgi, fastcgi, uwsgi модулях), то правильно. http://nginx.org/r/proxy_cache_purge/ru Если про "proxy_cache_bypass", то она доступна бесплатно. http://nginx.org/r/proxy_cache_bypass/ru -- Валентин Бартенев ___ 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,266217,266217#msg-266217 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Redirect в случае если файл присутствует
On 18 Apr 2016, at 13:33, siroco wrote: Вот это ># we are checking files plus ".sha256" extentions >set $filetocheck $uri.sha256; > >set $cdn_server_name our-cdn.domain.com; лучше сразу подставить в директивы. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Redirect в случае если файл присутствует
Спасибо! Сделал так, все работает как надо: location /some-location { # where we store sha256 sums root /var/www/sha256sums; # we are checking files plus ".sha256" extentions set $filetocheck $uri.sha256; set $cdn_server_name our-cdn.domain.com; if (!-f $document_root$filetocheck) { return 404; break; } return 302 http://$cdn_server_name$request_uri; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266212,266215#msg-266215 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Redirect в случае если файл присутствует
если файлы уникальные, то может быть вам подойдет http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store 18 апреля 2016 г., 14:09 пользователь siroco написал: > Привет! > > Хочется сделать такую вещь - проверять наличие файла (это файл с > контрольной > суммой, например, "/myfile.txt.sha256") и в случае наличия файла делать > редирект на CDN на "/myfile.txt". А в случае отсутствия файла - просто > выдавать 404. > > Поскольку "if"(ы) это плохо, то напрашивается решение с try_files. > > Однако вот такой вот конфиг редиректит на CDN только в случае отсутствия > файла с контрольной суммой: > > # if file with checksum exists then redirect to CDN > location / { > root /var/www/myfiles; > try_files $uri.sha256 @redirect_to_cdn; > } > > location @redirect_to_cdn { > return 302 http://mycdn.domain.com$request_uri; > } > > > Возможно ли как-то инвертировать условие try_files? > > -- > S. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,266212,266212#msg-266212 > > ___ > 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: Redirect в случае если файл присутствует
On 18 Apr 2016, at 12:09, siroco wrote: > Привет! > > Хочется сделать такую вещь - проверять наличие файла (это файл с контрольной > суммой, например, "/myfile.txt.sha256") и в случае наличия файла делать > редирект на CDN на "/myfile.txt". А в случае отсутствия файла - просто > выдавать 404. > > Поскольку "if"(ы) это плохо, то напрашивается решение с try_files. > > Однако вот такой вот конфиг редиректит на CDN только в случае отсутствия > файла с контрольной суммой: > ># if file with checksum exists then redirect to CDN >location / { >root /var/www/myfiles; >try_files $uri.sha256 @redirect_to_cdn; >} > >location @redirect_to_cdn { >return 302 http://mycdn.domain.com$request_uri; >} > > > Возможно ли как-то инвертировать условие try_files? if это, конечно, плохо, но в сочетании с return не имеет побочных эффектов. Можно использовать. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Redirect в случае если файл присутствует
Привет! Хочется сделать такую вещь - проверять наличие файла (это файл с контрольной суммой, например, "/myfile.txt.sha256") и в случае наличия файла делать редирект на CDN на "/myfile.txt". А в случае отсутствия файла - просто выдавать 404. Поскольку "if"(ы) это плохо, то напрашивается решение с try_files. Однако вот такой вот конфиг редиректит на CDN только в случае отсутствия файла с контрольной суммой: # if file with checksum exists then redirect to CDN location / { root /var/www/myfiles; try_files $uri.sha256 @redirect_to_cdn; } location @redirect_to_cdn { return 302 http://mycdn.domain.com$request_uri; } Возможно ли как-то инвертировать условие try_files? -- S. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266212,266212#msg-266212 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru