Quantcast
Channel: Nginx Forum
Viewing all 53287 articles
Browse latest View live
↧

Re: как правильно проксировать вебсокеты ?

November 28, 2017, 5:44 am
$
0
0
Hello!

On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote:

> Привет!
>
> в официальной документации https://nginx.ru/ru/docs/http/websocket.html
>
> есть пример
>
> map $http_upgrade $connection_upgrade {
> default upgrade;
> '' close;
> }
>
>
> получается, что соединение будет закрываться каждый раз.
>
> не будет ли логичнее сделать
>
> map $http_upgrade $connection_upgrade {
> default upgrade;
> '' '';
> }
>
> ?
>
> или это какая-то задумка ? расскажите ?

По умолчанию соединения к бэкенду используют HTTP/1.0 и
закрываются каждый раз. Если хочется, чтобы они не закрывались,
нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не
отправлял на бэкенд "Connection: close", а также включить кэш
keepalive-соединений в блоке upstream. Подробнее об этом
рассказано тут:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive

Если хочется использовать keepalive к бэкендам одновременно с
проксированием вебсокетов - то пример в статье про проксирование
вебсокетов, естественно, не будет работать как есть, в нём надо
"close" заменить на пустую строку - как и предложено выше.

Однако если это сделать без включения кэша keepalive-соединений,
то никаких положительных последствий не будет. Наоборот, появится
лишняя задержка перед закрытием соединения, и закрывать соединения
будет nginx, а не бэкенд, что в свою очередь может привести к
проблемам, так как time-wait сокеты вместо стороны бэкенда
окажутся на стороне nginx'а.

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

Re: как правильно проксировать вебсокеты ?

November 28, 2017, 6:06 am
$
0
0
28 ноября 2017 г., 18:42 пользователь Maxim Dounin <mdounin@mdounin.ru>
написал:

> Hello!
>
> On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote:
>
> > Привет!
> >
> > в официальной документации https://nginx.ru/ru/docs/http/websocket.html
> >
> > есть пример
> >
> > map $http_upgrade $connection_upgrade {
> > default upgrade;
> > '' close;
> > }
> >
> >
> > получается, что соединение будет закрываться каждый раз.
> >
> > не будет ли логичнее сделать
> >
> > map $http_upgrade $connection_upgrade {
> > default upgrade;
> > '' '';
> > }
> >
> > ?
> >
> > или это какая-то задумка ? расскажите ?
>
> По умолчанию соединения к бэкенду используют HTTP/1.0 и
> закрываются каждый раз. Если хочется, чтобы они не закрывались,
> нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не
> отправлял на бэкенд "Connection: close", а также включить кэш
> keepalive-соединений в блоке upstream. Подробнее об этом
> рассказано тут:
>

собственно, в примере про вебсокеты у вас:

proxy_http_version 1.1;



>
> http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive
>
> Если хочется использовать keepalive к бэкендам одновременно с
> проксированием вебсокетов - то пример в статье про проксирование
> вебсокетов, естественно, не будет работать как есть, в нём надо
> "close" заменить на пустую строку - как и предложено выше.
>
> Однако если это сделать без включения кэша keepalive-соединений,
> то никаких положительных последствий не будет. Наоборот, появится
> лишняя задержка перед закрытием соединения, и закрывать соединения
> будет nginx, а не бэкенд, что в свою очередь может привести к
> проблемам, так как time-wait сокеты вместо стороны бэкенда
> окажутся на стороне nginx'а.
>

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


>
> --
> 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
↧
↧

Re: как правильно проксировать вебсокеты ?

November 28, 2017, 6:10 am
$
0
0
(сорян за топпостинг)

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

1) в апстриме НЕ указан keepalive, в правилах проксирования указан
2) в апстриме указан keepalive, в правилах проксирования протокол 1.0

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

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

28 ноября 2017 г., 18:42 пользователь Maxim Dounin <mdounin@mdounin.ru>
написал:

> Hello!
>
> On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote:
>
> > Привет!
> >
> > в официальной документации https://nginx.ru/ru/docs/http/websocket.html
> >
> > есть пример
> >
> > map $http_upgrade $connection_upgrade {
> > default upgrade;
> > '' close;
> > }
> >
> >
> > получается, что соединение будет закрываться каждый раз.
> >
> > не будет ли логичнее сделать
> >
> > map $http_upgrade $connection_upgrade {
> > default upgrade;
> > '' '';
> > }
> >
> > ?
> >
> > или это какая-то задумка ? расскажите ?
>
> По умолчанию соединения к бэкенду используют HTTP/1.0 и
> закрываются каждый раз. Если хочется, чтобы они не закрывались,
> нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не
> отправлял на бэкенд "Connection: close", а также включить кэш
> keepalive-соединений в блоке upstream. Подробнее об этом
> рассказано тут:
>
> http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive
>
> Если хочется использовать keepalive к бэкендам одновременно с
> проксированием вебсокетов - то пример в статье про проксирование
> вебсокетов, естественно, не будет работать как есть, в нём надо
> "close" заменить на пустую строку - как и предложено выше.
>
> Однако если это сделать без включения кэша keepalive-соединений,
> то никаких положительных последствий не будет. Наоборот, появится
> лишняя задержка перед закрытием соединения, и закрывать соединения
> будет nginx, а не бэкенд, что в свою очередь может привести к
> проблемам, так как time-wait сокеты вместо стороны бэкенда
> окажутся на стороне nginx'а.
>
> --
> 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
↧

Re: как правильно проксировать вебсокеты ?

November 28, 2017, 6:12 am
$
0
0
28.11.2017, 17:04, "Илья Шипицин" <chipitsine@gmail.com>:
> 28 ноября 2017 г., 18:42 пользователь Maxim Dounin <mdounin@mdounin.ru> написал:
>> Hello!
>>
>> On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote:
>>
>>> Привет!
>>>
>>> в официальной документации https://nginx.ru/ru/docs/http/websocket.html
>>>
>>> есть пример
>>>
>>>     map $http_upgrade $connection_upgrade {
>>>         default upgrade;
>>>         ''      close;
>>>     }
>>>
>>>
>>> получается, что соединение будет закрываться каждый раз.
>>>
>>> не будет ли логичнее сделать
>>>
>>>     map $http_upgrade $connection_upgrade {
>>>         default upgrade;
>>>         ''      '';
>>>     }
>>>
>>> ?
>>>
>>> или это какая-то задумка ? расскажите ?
>>
>> По умолчанию соединения к бэкенду используют HTTP/1.0 и
>> закрываются каждый раз.  Если хочется, чтобы они не закрывались,
>> нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не
>> отправлял на бэкенд "Connection: close", а также включить кэш
>> keepalive-соединений в блоке upstream.  Подробнее об этом
>> рассказано тут:
>
> собственно, в примере про вебсокеты у вас:
>
> proxy_http_version 1.1;
>
>> http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive
>>
>> Если хочется использовать keepalive к бэкендам одновременно с
>> проксированием вебсокетов - то пример в статье про проксирование
>> вебсокетов, естественно, не будет работать как есть, в нём надо
>> "close" заменить на пустую строку - как и предложено выше.
>>
>> Однако если это сделать без включения кэша keepalive-соединений,
>> то никаких положительных последствий не будет.  Наоборот, появится
>> лишняя задержка перед закрытием соединения, и закрывать соединения
>> будет nginx, а не бэкенд, что в свою очередь может привести к
>> проблемам, так как time-wait сокеты вместо стороны бэкенда
>> окажутся на стороне nginx'а.
>
> это понятно. как минимум, стоит это обговорить, в текущем виде пример неочевидный.
> подозреваю, что его копипастят и драг-н-дропят по принципу "ну это же официальная документация, там фигню не посоветуют"

Я думаю, имелось в виду, что location с websocket не должен обрабатывать посторонние
HTTP-запросы, и для них соединения можно смело разрывать и не тратить место в кэше.

>
>> --
>> 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


-- 
Regards,
Konstantin
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: как правильно проксировать вебсокеты ?

November 28, 2017, 6:26 am
$
0
0
Hello!

On Tue, Nov 28, 2017 at 07:04:05PM +0500, Илья Шипицин wrote:

> 28 ноября 2017 г., 18:42 пользователь Maxim Dounin <mdounin@mdounin.ru>
> написал:
>
> > Hello!
> >
> > On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote:
> >
> > > Привет!
> > >
> > > в официальной документации https://nginx.ru/ru/docs/http/websocket.html
> > >
> > > есть пример
> > >
> > > map $http_upgrade $connection_upgrade {
> > > default upgrade;
> > > '' close;
> > > }
> > >
> > >
> > > получается, что соединение будет закрываться каждый раз.
> > >
> > > не будет ли логичнее сделать
> > >
> > > map $http_upgrade $connection_upgrade {
> > > default upgrade;
> > > '' '';
> > > }
> > >
> > > ?
> > >
> > > или это какая-то задумка ? расскажите ?
> >
> > По умолчанию соединения к бэкенду используют HTTP/1.0 и
> > закрываются каждый раз. Если хочется, чтобы они не закрывались,
> > нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не
> > отправлял на бэкенд "Connection: close", а также включить кэш
> > keepalive-соединений в блоке upstream. Подробнее об этом
> > рассказано тут:
>
> собственно, в примере про вебсокеты у вас:
>
> proxy_http_version 1.1;

И этого, очевидно, недостаточно.

> > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive
> >
> > Если хочется использовать keepalive к бэкендам одновременно с
> > проксированием вебсокетов - то пример в статье про проксирование
> > вебсокетов, естественно, не будет работать как есть, в нём надо
> > "close" заменить на пустую строку - как и предложено выше.
> >
> > Однако если это сделать без включения кэша keepalive-соединений,
> > то никаких положительных последствий не будет. Наоборот, появится
> > лишняя задержка перед закрытием соединения, и закрывать соединения
> > будет nginx, а не бэкенд, что в свою очередь может привести к
> > проблемам, так как time-wait сокеты вместо стороны бэкенда
> > окажутся на стороне nginx'а.
> >
>
> это понятно. как минимум, стоит это обговорить, в текущем виде пример
> неочевидный.
> подозреваю, что его копипастят и драг-н-дропят по принципу "ну это же
> официальная документация, там фигню не посоветуют"

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

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

Openvpn via nginx reverse proxy

November 28, 2017, 7:18 am
$
0
0
I am currently running a cloud https server and a document https server behind an nginx reverse proxy server. Additionally I am running an openvpn server on UDP port 1194 (also on the cloud sever), which I would like to route via the nginx reverse proxy server on TCP port 443. I would appreciate any hints as I lack any experience on nginx.

This is my configuration file, naturally, example.org is not my real URL:

worker_processes 4; # Default 1
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;

events {
worker_connections 512; # Default 1024
}


http {
include mime.types;
default_type application/octet-stream;

keepalive_timeout 65;

## Compression
gzip on;
gzip_buffers 16 8k;
gzip_comp_level 9;
gzip_http_version 1.1;
gzip_min_length 10;
gzip_types text/plain text/css application/x-javascript text/xml;
gzip_vary on;
gzip_static on; #Needs compilation with gzip_static support
gzip_proxied any;
gzip_disable "MSIE [1-6]\.";

## Server configuration
server {
listen 443 ssl;
server_name example.org;
ssl on;
ssl_certificate /root/fullchain.pem;
ssl_certificate_key /root/privkey.pem;
server_name_in_redirect off;
access_log logs/access.log;
client_max_body_size 10G ;


## proxy the PHP scripts to Apache listening on 127.0.0.1:80
location /nextcloud {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
proxy_pass https://cloudserver:443;
}
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#proxy_redirect off;
proxy_buffering off;
proxy_pass https://documentserver:443/;
}
}
}
↧

Fwd: Problem with CAS on nginx configuration

November 28, 2017, 7:46 am
$
0
0
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧

nginx и смена симлинков

November 28, 2017, 7:54 am
$
0
0
Здравствуйте!

nginx 1.12.2, debian 8, php-fpm (5.6)
*# *nginx -V


Есть самописное приложение на php. У него есть две версии: stable и current. Для
быстрой смены используется следующая схема:
/var/www/stable/ - тут лежит stable
/var/www/current/ - тут лежит current
/var/www/html - симлинк на на /var/www/stable или /var/www/current

В nginx пыха сконфигурирована как

root /var/www/html;
location / {
fastcgi_pass unix:/run/php-fpm.socket;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}

Проблема в том. что при переключение stable->current (и наоборот), которая
происходит примерно так:
# /var/www/html указывает на /var/www/stable , переключаемся на current
rm /var/www/html; ln -s /var/www/current/ /var/www/html

до упора используются файлы из старой директории (stable в примере выше). Не
помогает ни очистка opcache, ни рестарт пыхи. Только restart (возможно reload, не
уверен) nginx.
Хотелось бы
1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк?
2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в принципе готовы
поменять воркфлоу, но пока не понимаем как.

С уважением, Иван.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
Search

domain only reachable with https:// in front

November 28, 2017, 8:27 am
$
0
0
Hi,

I'm using nginx as reverse proxy for guacamole, I can only reach my domain with https://pstn.host or https://www.pstn.host, it won't work without https or with even with https.

here's my sites-enabled/pstn.host https://pastebin.com/raw/dKiEi72q

any ideas what's wrong or missing?

thanks!
↧
↧

Re: domain only reachable with https:// in front

November 28, 2017, 8:36 am
$
0
0
Hi,

you have :
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
in your config, that redirects everything to https.


Mit freundlichen Grüßen / best regards
Alexander Naumann

artcom venture GmbH

----- Ursprüngliche Mail -----

Von: "pstnta" <nginx-forum@forum.nginx.org>
An: nginx@nginx.org
Gesendet: Dienstag, 28. November 2017 17:27:57
Betreff: domain only reachable with https:// in front

Hi,

I'm using nginx as reverse proxy for guacamole, I can only reach my domain
with https://pstn.host or https://www.pstn.host, it won't work without https
or with even with https.

here's my sites-enabled/pstn.host https://pastebin.com/raw/dKiEi72q

any ideas what's wrong or missing?

thanks!

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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧

Re: domain only reachable with https:// in front

November 28, 2017, 8:40 am
$
0
0
hi,

thanks for answering,

shouldn't that forward everything to https? so shouldn't it work with just pstn.host? instead of https://pstn.host
↧

Re: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm

November 28, 2017, 8:54 am
$
0
0
Вам что-то мешает установить redhat-lsb-core?

2017-11-28 4:56 GMT+02:00 Dothris <nginx-forum@forum.nginx.org>:

> Добрый день!
> Посмотрите эту ошибку?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,277518,277530#msg-277530
>
> _______________________________________________
> 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: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm

November 28, 2017, 8:56 am
$
0
0
Мне интересно почему его нет в buildrequires или requires
↧
↧

Re: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm

November 28, 2017, 9:06 am
$
0
0
> On 28 Nov 2017, at 19:56, Dothris <nginx-forum@forum.nginx.org> wrote:
>
> Мне интересно почему его нет в buildrequires или requires

Есть:
http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l20

Но все макросы обрабатываются видимо до проверок собственно
по директивам spec-файла, отсюда ошибка.

Сходу не придумывается решение, но при случае поразмышляем,
что тут можно сделать.

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

Re: domain only reachable with https:// in front

November 28, 2017, 9:18 am
$
0
0
I think it is unfortunate that certbot does it this way, with an if
statement, which i believe is evaluated in every request. I use something
like the following (with your names):

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name pstn.host www.pstn.host;
return 301 https://$host$request_uri;
}


server {
listen 443 ssl default_server;
ssl_certificate /etc/letsencrypt/live/pstn.host/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/pstn.host/privkey.pem;

....reset of config
}

Not part of your question, but I also use the hooks in webroot mode, rather
than nginx, for certbot, so it's never modifies my configuration, as the
sites-enabled files are managed by a configuration management system across
about 100 domains, some with special requirements.

HTH,
Jeff

On Tue, Nov 28, 2017 at 11:40 AM, pstnta <nginx-forum@forum.nginx.org>
wrote:

> hi,
>
> thanks for answering,
>
> shouldn't that forward everything to https? so shouldn't it work with just
> pstn.host? instead of https://pstn.host
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?2,277546,277548#msg-277548
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧
Search

Re: cts-submit

November 28, 2017, 9:36 am
$
0
0
Am 27.11.2017 um 22:21 schrieb Ángel:
> On 2017-11-26 at 14:17 +0100, A. Schulze wrote:
>> Hello,
>>
>> experiments with nginx-ct ¹) show that I need a tool to submit a certificate to some public logs.
>> cts-submit ²) seems useful. But it require me to install php on every host :-/
>>
>> I know there are also python implementations. but
>> is anybody aware of an implementation in *plain posix shell + openssl* ?
>>
>> Andreas
>
> Doesn't your CA already submit them to the Certificate Transparency
> logs?

I think LE in my case does. But at the end of the day I need a simple program to fetch
Signed Certificate Timestamp data from one/multiple logs.

Installing php or go (even only for compiling) is inconvenient for me.

Are there other ways to only /fetch/ signed certificate timestamp data?

Andreas

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧

Re: nginx и смена симлинков

November 28, 2017, 10:26 am
$
0
0
28 ноября 2017 г., 18:52 пользователь Иван <nginx@kinetiksoft.com> написал:

> Здравствуйте!
>
>
>
> nginx 1.12.2, debian 8, php-fpm (5.6)
>
>
> /var/www/html - симлинк на на /var/www/stable или /var/www/current
>
>
>
...

> Хотелось бы
>
> 1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк?
>
> 2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в
> принципе готовы поменять воркфлоу, но пока не понимаем как.
>

>

Nginx тут не причем. Смотрите в сторону настроек вашего php-бекенда, в
частности кеша realpath.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Re: nginx и смена симлинков

November 28, 2017, 10:36 am
$
0
0
28 ноября 2017 г., 20:52 пользователь Иван <nginx@kinetiksoft.com> написал:

> Здравствуйте!
>
>
>
> nginx 1.12.2, debian 8, php-fpm (5.6)
>
> # nginx -V
> nginx version: nginx/1.12.2
> built by gcc 4.9.2 (Debian 4.9.2-10)
> built with OpenSSL 1.0.1t 3 May 2016
> TLS SNI support enabled
> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/va
> r/log/nginx/error.log --http-log-path=/var/log/nginx/access.log
> --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
> --http-client-body-temp-path=/var/c
> ache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp
> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
> --http-uwsgi-temp-path=/var/cach
> e/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp
> --user=nginx --group=nginx --with-compat --with-file-aio --with-threads
> --with-http_addition_
> module --with-http_auth_request_module --with-http_dav_module
> --with-http_flv_module --with-http_gunzip_module
> --with-http_gzip_static_module --with-http_mp4_mod
> ule --with-http_random_index_module --with-http_realip_module
> --with-http_secure_link_module --with-http_slice_module
> --with-http_ssl_module --with-http_stub_sta
> tus_module --with-http_sub_module --with-http_v2_module --with-mail
> --with-mail_ssl_module --with-stream --with-stream_realip_module
> --with-stream_ssl_module --w
> ith-stream_ssl_preread_module --with-cc-opt='-g -O2
> -fstack-protector-strong -Wformat -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-
> z,relro -Wl,-z,now -Wl,--as-needed -pie'
>
>
>
> Есть самописное приложение на php. У него есть две версии: stable и
> current. Для быстрой смены используется следующая схема:
>
> /var/www/stable/ - тут лежит stable
>
> /var/www/current/ - тут лежит current
>
> /var/www/html - симлинк на на /var/www/stable или /var/www/current
>
>
>
> В nginx пыха сконфигурирована как
>
>
>
> root /var/www/html;
>
> location / {
>
> fastcgi_pass unix:/run/php-fpm.socket;
>

сделайте тут проксирование на апстрим (в котором перечислены несколько
бекендов)
fastcgi_connect_timeout сделайте минимальным



> include fastcgi_params;
>
> fastcgi_param SCRIPT_FILENAME $document_root/index.php;
>
> }
>
>
>
> Проблема в том. что при переключение stable->current (и наоборот),
>

достаточно будет запустить тот или иной бекенд

(не уверен, что с unix-сокетами получится, в крайнем случае можно на tcp
проксировать)



> которая происходит примерно так:
>
> # /var/www/html указывает на /var/www/stable , переключаемся на current
>
> rm /var/www/html; ln -s /var/www/current/ /var/www/html
>
>
>
> до упора используются файлы из старой директории (stable в примере выше).
> Не помогает ни очистка opcache, ни рестарт пыхи. Только restart (возможно
> reload, не уверен) nginx.
>
> Хотелось бы
>
> 1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк?
>
> 2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в
> принципе готовы поменять воркфлоу, но пока не понимаем как.
>
>
>
> С уважением, Иван.
>
> _______________________________________________
> 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
↧

access problem

November 28, 2017, 10:55 am
$
0
0
Nginx-RTMP setup: something does not allow this HLS stream to be linked by another host then the one it is created on. The HTML at the bottom is on another VPS with another IP. I can play the stream in my browser from the origin server with the HLS addon in Chrome or Firefox anywhere. I can also play the html at the bottom from my local disk, though I can't play the html uploaded on a virtual host. I'm stuck. Below my server setup and the html to play.

server {
listen 80;

location / {
# Disable cache
add_header 'Cache-Control' 'no-cache';

# CORS setup
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Expose-Headers' 'Content-Length';
add_header X-Frame-Options "ALLOW-FROM https://my.site/";

# allow CORS preflight requests
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
add_header X-Frame-Options "ALLOW-FROM https://my.site/";
return 204;
}

types {
application/dash+xml mpd;
application/vnd.apple.mpegurl m3u8;
video/mp2t ts;
}

root /mnt/;
}
}

player (below video js, but same for vlc and clappr setup)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta name="generator" content="PSPad editor, www.pspad.com">
<title></title>
</head>
<body>
<video id=example-video width=960 height=540 class="video-js vjs-default-skin" controls>
<source
src="http://77.72.149.125:80/hls/stream.m3u8"
type="application/x-mpegURL">
</video>
<link href="http://vjs.zencdn.net/5.19/video-js.css" rel="stylesheet">
<script src="http://vjs.zencdn.net/ie8/1.1/videojs-ie8.min.js"></script>
<script src="http://vjs.zencdn.net/5.19/video.js"></script>
<script src="https://unpkg.com/videojs-contrib-hls/dist/videojs-contrib-hls.js"></script>
<script>
var player = videojs('example-video');
player.play();
</script>
</body>
</html>
↧

Re: domain only reachable with https:// in front

November 28, 2017, 11:32 am
$
0
0
Your ISP is blocking port 80, so you cannot get redirected to HTTPS.

http://www.dslreports.com/faq/11852

On Tue, Nov 28, 2017 at 6:17 PM, Jeff Dyke <jeff.dyke@gmail.com> wrote:

> I think it is unfortunate that certbot does it this way, with an if
> statement, which i believe is evaluated in every request. I use something
> like the following (with your names):
>
> server {
> listen 80 default_server;
> listen [::]:80 default_server;
> server_name pstn.host www.pstn.host;
> return 301 https://$host$request_uri;
> }
>
>
> server {
> listen 443 ssl default_server;
> ssl_certificate /etc/letsencrypt/live/pstn.host/fullchain.pem;
> ssl_certificate_key /etc/letsencrypt/live/pstn.host/privkey.pem;
>
> ....reset of config
> }
>
> Not part of your question, but I also use the hooks in webroot mode,
> rather than nginx, for certbot, so it's never modifies my configuration, as
> the sites-enabled files are managed by a configuration management system
> across about 100 domains, some with special requirements.
>
> HTH,
> Jeff
>
> On Tue, Nov 28, 2017 at 11:40 AM, pstnta <nginx-forum@forum.nginx.org>
> wrote:
>
>> hi,
>>
>> thanks for answering,
>>
>> shouldn't that forward everything to https? so shouldn't it work with just
>> pstn.host? instead of https://pstn.host
>>
>> Posted at Nginx Forum: https://forum.nginx.org/read.p
>> hp?2,277546,277548#msg-277548
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧
Viewing all 53287 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>