From nginx-forum at nginx.us Mon Apr 1 07:40:38 2013 From: nginx-forum at nginx.us (vren) Date: Mon, 01 Apr 2013 03:40:38 -0400 Subject: =?UTF-8?B?bmdpbnggMS4yLjctMSBjZW50b3MgcmVwbyDQvtGC0YHRg9GC0YHRgtCy0YPQtdGC?= =?UTF-8?B?INC80L7QtNGD0LvRjCBnZW9pcC4=?= Message-ID: Nginx установлен из http://nginx.org/packages/centos/6/x86_64/, после обновления пропал модуль geoip, пришлось компилировать руками. Его вернут назад? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237996,237996#msg-237996 From nginx-forum at nginx.us Mon Apr 1 07:59:54 2013 From: nginx-forum at nginx.us (vren) Date: Mon, 01 Apr 2013 03:59:54 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IDEuMi43LTEgY2VudG9zIHJlcG8g0L7RgtGB0YPRgtGB0YLQstGD?= =?UTF-8?B?0LXRgiDQvNC+0LTRg9C70YwgZ2VvaXAu?= In-Reply-To: References: Message-ID: Извиняюсь, понял в чем дело, раньше стоял nginx из epel. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237996,237997#msg-237997 From nginx-forum at nginx.us Mon Apr 1 08:13:20 2013 From: nginx-forum at nginx.us (vstaf) Date: Mon, 01 Apr 2013 04:13:20 -0400 Subject: =?UTF-8?B?0J7RgtC60LDQtyDQsiDQvtCx0YHQu9GD0LbQuNCy0LDQvdC40Lgg0L3QsCDQvtC/?= =?UTF-8?B?0YDQtdC00LXQu9C10L3QvdC+0Lwg0L/QvtGA0YLRgy4=?= Message-ID: <0f673d55a7825c53af59cf4e2408bf37.NginxMailingListRussian@forum.nginx.org> Коллеги, надеюсь на помощь в решении периодически возникающей проблемы. Суть: Есть nginx, обслуживающий 1 домен на 5 портах + SSL. Периодически (раз в несколько недель) возникает ситуация, что при попытке коннекта на определенный порт (назовем его "Х") не проходят даже syn - ack. Обычно это возникает при цифре 6к syn-запросов в секунду к серверу на пресловутый порт "Х". На других портах nginx работает нормально и без проблем выполняет все свои функции. О сервере: 2хXeon E5620, HT on, 12 gb ram. Centos 5 (2.6.18-238.19.1.el5PAE i386) Пиковая статистика из stub_status: rps ~1k, active connections ~8k sysctl.conf: net.ipv4.tcp_syncookies = 0 net.ipv4.netfilter.ip_conntrack_max = 10000000 net.ipv4.tcp_fin_timeout = 1 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 1 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 1 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 1 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=1 net.ipv4.ip_local_port_range = 5000 65000 net.ipv4.tcp_max_syn_backlog = 3240000 net.core.somaxconn = 3240000 net.ipv4.tcp_max_tw_buckets = 1440000 net.core.netdev_max_backlog=10000 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_mem = 1048576 2097152 3145728 net.ipv4.tcp_rmem = 4096 65536 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 nginx:conf: worker_processes 16; events { worker_connections 16384; use epoll; multi_accept on; } http { tcp_nopush on; tcp_nodelay on; sendfile on; keepalive_timeout 10; keepalive_requests 100000; reset_timedout_connection on; send_timeout 2; client_header_timeout 10; client_body_timeout 10; proxy_buffering off; fastcgi_buffers 4 256k; fastcgi_buffer_size 256k; client_max_body_size 10m; Понимаю, что по сути сам nginx тут не при чем, но хотелось бы понять направление куда копать. Экспериментировал с разными параметрами ядра - профита так и не получил. Когда количество синов в секунду падает (до 1-1.5к) - все приходит в норму. Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237998,237998#msg-237998 From unlexx at gmail.com Mon Apr 1 08:33:59 2013 From: unlexx at gmail.com (Un Lexx) Date: Mon, 1 Apr 2013 14:33:59 +0600 Subject: =?UTF-8?B?UmU6INCe0YLQutCw0Lcg0LIg0L7QsdGB0LvRg9C20LjQstCw0L3QuNC4INC90LAg?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvQtdC90L3QvtC8INC/0L7RgNGC0YMu?= In-Reply-To: <0f673d55a7825c53af59cf4e2408bf37.NginxMailingListRussian@forum.nginx.org> References: <0f673d55a7825c53af59cf4e2408bf37.NginxMailingListRussian@forum.nginx.org> Message-ID: Tcp пакет то на указанный порт приходит? вообще судя по тому что то появляется то исчезает думаю где то выше у вас стоит какое то фаерволл который отфильтровывает по кол-ву запросов на указанный порт X 1 апреля 2013 г., 14:13 пользователь vstaf написал: > Коллеги, надеюсь на помощь в решении периодически возникающей проблемы. > > Суть: > > Есть nginx, обслуживающий 1 домен на 5 портах + SSL. Периодически (раз в > несколько недель) возникает ситуация, что при попытке коннекта на > определенный порт (назовем его "Х") не проходят даже syn - ack. Обычно это > возникает при цифре 6к syn-запросов в секунду к серверу на пресловутый порт > "Х". На других портах nginx работает нормально и без проблем выполняет все > свои функции. > > О сервере: 2хXeon E5620, HT on, 12 gb ram. Centos 5 (2.6.18-238.19.1.el5PAE > i386) > Пиковая статистика из stub_status: rps ~1k, active connections ~8k > > sysctl.conf: > > net.ipv4.tcp_syncookies = 0 > net.ipv4.netfilter.ip_conntrack_max = 10000000 > > net.ipv4.tcp_fin_timeout = 1 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 1 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 1 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 1 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=1 > net.ipv4.ip_local_port_range = 5000 65000 > > net.ipv4.tcp_max_syn_backlog = 3240000 > net.core.somaxconn = 3240000 > net.ipv4.tcp_max_tw_buckets = 1440000 > net.core.netdev_max_backlog=10000 > > net.core.rmem_default = 8388608 > net.core.rmem_max = 16777216 > net.core.wmem_max = 16777216 > net.ipv4.tcp_mem = 1048576 2097152 3145728 > net.ipv4.tcp_rmem = 4096 65536 16777216 > net.ipv4.tcp_wmem = 4096 65536 16777216 > > nginx:conf: > > worker_processes 16; > > events { > worker_connections 16384; > use epoll; > multi_accept on; > } > > http { > > tcp_nopush on; > tcp_nodelay on; > sendfile on; > keepalive_timeout 10; > keepalive_requests 100000; > reset_timedout_connection on; > send_timeout 2; > client_header_timeout 10; > client_body_timeout 10; > proxy_buffering off; > > fastcgi_buffers 4 256k; > fastcgi_buffer_size 256k; > > client_max_body_size 10m; > > > Понимаю, что по сути сам nginx тут не при чем, но хотелось бы понять > направление куда копать. Экспериментировал с разными параметрами ядра - > профита так и не получил. Когда количество синов в секунду падает (до > 1-1.5к) - все приходит в норму. > > Заранее спасибо. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237998,237998#msg-237998 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Apr 1 09:31:15 2013 From: nginx-forum at nginx.us (psevdokot) Date: Mon, 01 Apr 2013 05:31:15 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQutCw0Lcg0LIg0L7QsdGB0LvRg9C20LjQstCw0L3QuNC4INC90LAg?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvQtdC90L3QvtC8INC/0L7RgNGC0YMu?= In-Reply-To: References: Message-ID: <5c6e95114f99280939a2d204003ddd1b.NginxMailingListRussian@forum.nginx.org> по tcpdump-у видим, что syn-пакет на сервер приходит, но syn+ack в ответ не отправляется. Un Lexx Wrote: ------------------------------------------------------- > Tcp пакет то на указанный порт приходит? вообще судя по тому что то > появляется то исчезает думаю где то выше у вас стоит какое то > фаерволл > который отфильтровывает по кол-ву запросов на указанный порт X > > > > 1 апреля 2013 г., 14:13 пользователь vstaf > написал: > > > Коллеги, надеюсь на помощь в решении периодически возникающей > проблемы. > > > > Суть: > > > > Есть nginx, обслуживающий 1 домен на 5 портах + SSL. Периодически > (раз в > > несколько недель) возникает ситуация, что при попытке коннекта на > > определенный порт (назовем его "Х") не проходят даже syn - ack. > Обычно это > > возникает при цифре 6к syn-запросов в секунду к серверу на > пресловутый порт > > "Х". На других портах nginx работает нормально и без проблем > выполняет все > > свои функции. > > > > О сервере: 2хXeon E5620, HT on, 12 gb ram. Centos 5 > (2.6.18-238.19.1.el5PAE > > i386) > > Пиковая статистика из stub_status: rps ~1k, active connections ~8k > > > > sysctl.conf: > > > > net.ipv4.tcp_syncookies = 0 > > net.ipv4.netfilter.ip_conntrack_max = 10000000 > > > > net.ipv4.tcp_fin_timeout = 1 > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 1 > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 1 > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 1 > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=1 > > net.ipv4.ip_local_port_range = 5000 65000 > > > > net.ipv4.tcp_max_syn_backlog = 3240000 > > net.core.somaxconn = 3240000 > > net.ipv4.tcp_max_tw_buckets = 1440000 > > net.core.netdev_max_backlog=10000 > > > > net.core.rmem_default = 8388608 > > net.core.rmem_max = 16777216 > > net.core.wmem_max = 16777216 > > net.ipv4.tcp_mem = 1048576 2097152 3145728 > > net.ipv4.tcp_rmem = 4096 65536 16777216 > > net.ipv4.tcp_wmem = 4096 65536 16777216 > > > > nginx:conf: > > > > worker_processes 16; > > > > events { > > worker_connections 16384; > > use epoll; > > multi_accept on; > > } > > > > http { > > > > tcp_nopush on; > > tcp_nodelay on; > > sendfile on; > > keepalive_timeout 10; > > keepalive_requests 100000; > > reset_timedout_connection on; > > send_timeout 2; > > client_header_timeout 10; > > client_body_timeout 10; > > proxy_buffering off; > > > > fastcgi_buffers 4 256k; > > fastcgi_buffer_size 256k; > > > > client_max_body_size 10m; > > > > > > Понимаю, что по сути сам nginx тут не при чем, но хотелось бы > понять > > направление куда копать. Экспериментировал с разными параметрами > ядра - > > профита так и не получил. Когда количество синов в секунду падает > (до > > 1-1.5к) - все приходит в норму. > > > > Заранее спасибо. > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?21,237998,237998#msg-237998 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237998,238000#msg-238000 From corochoone at gmail.com Mon Apr 1 11:19:18 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Mon, 1 Apr 2013 15:19:18 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQutCw0Lcg0LIg0L7QsdGB0LvRg9C20LjQstCw0L3QuNC4INC90LAg?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvQtdC90L3QvtC8INC/0L7RgNGC0YMu?= In-Reply-To: <5c6e95114f99280939a2d204003ddd1b.NginxMailingListRussian@forum.nginx.org> References: <5c6e95114f99280939a2d204003ddd1b.NginxMailingListRussian@forum.nginx.org> Message-ID: У меня такое бывает на серверах с CentOS 5.x/6.x. Помогает рестарт iptables. Попробуйте. 1 апреля 2013 г., 13:31 пользователь psevdokot написал: > по tcpdump-у видим, что syn-пакет на сервер приходит, но syn+ack в ответ не > отправляется. > > Un Lexx Wrote: > ------------------------------------------------------- > > Tcp пакет то на указанный порт приходит? вообще судя по тому что то > > появляется то исчезает думаю где то выше у вас стоит какое то > > фаерволл > > который отфильтровывает по кол-ву запросов на указанный порт X > > > > > > > > 1 апреля 2013 г., 14:13 пользователь vstaf > > написал: > > > > > Коллеги, надеюсь на помощь в решении периодически возникающей > > проблемы. > > > > > > Суть: > > > > > > Есть nginx, обслуживающий 1 домен на 5 портах + SSL. Периодически > > (раз в > > > несколько недель) возникает ситуация, что при попытке коннекта на > > > определенный порт (назовем его "Х") не проходят даже syn - ack. > > Обычно это > > > возникает при цифре 6к syn-запросов в секунду к серверу на > > пресловутый порт > > > "Х". На других портах nginx работает нормально и без проблем > > выполняет все > > > свои функции. > > > > > > О сервере: 2хXeon E5620, HT on, 12 gb ram. Centos 5 > > (2.6.18-238.19.1.el5PAE > > > i386) > > > Пиковая статистика из stub_status: rps ~1k, active connections ~8k > > > > > > sysctl.conf: > > > > > > net.ipv4.tcp_syncookies = 0 > > > net.ipv4.netfilter.ip_conntrack_max = 10000000 > > > > > > net.ipv4.tcp_fin_timeout = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=1 > > > net.ipv4.ip_local_port_range = 5000 65000 > > > > > > net.ipv4.tcp_max_syn_backlog = 3240000 > > > net.core.somaxconn = 3240000 > > > net.ipv4.tcp_max_tw_buckets = 1440000 > > > net.core.netdev_max_backlog=10000 > > > > > > net.core.rmem_default = 8388608 > > > net.core.rmem_max = 16777216 > > > net.core.wmem_max = 16777216 > > > net.ipv4.tcp_mem = 1048576 2097152 3145728 > > > net.ipv4.tcp_rmem = 4096 65536 16777216 > > > net.ipv4.tcp_wmem = 4096 65536 16777216 > > > > > > nginx:conf: > > > > > > worker_processes 16; > > > > > > events { > > > worker_connections 16384; > > > use epoll; > > > multi_accept on; > > > } > > > > > > http { > > > > > > tcp_nopush on; > > > tcp_nodelay on; > > > sendfile on; > > > keepalive_timeout 10; > > > keepalive_requests 100000; > > > reset_timedout_connection on; > > > send_timeout 2; > > > client_header_timeout 10; > > > client_body_timeout 10; > > > proxy_buffering off; > > > > > > fastcgi_buffers 4 256k; > > > fastcgi_buffer_size 256k; > > > > > > client_max_body_size 10m; > > > > > > > > > Понимаю, что по сути сам nginx тут не при чем, но хотелось бы > > понять > > > направление куда копать. Экспериментировал с разными параметрами > > ядра - > > > профита так и не получил. Когда количество синов в секунду падает > > (до > > > 1-1.5к) - все приходит в норму. > > > > > > Заранее спасибо. > > > > > > Posted at Nginx Forum: > > > http://forum.nginx.org/read.php?21,237998,237998#msg-237998 > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237998,238000#msg-238000 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Apr 1 14:13:58 2013 From: nginx-forum at nginx.us (psevdokot) Date: Mon, 01 Apr 2013 10:13:58 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQutCw0Lcg0LIg0L7QsdGB0LvRg9C20LjQstCw0L3QuNC4INC90LAg?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvQtdC90L3QvtC8INC/0L7RgNGC0YMu?= In-Reply-To: References: Message-ID: <421064271aa73be8597c178627d990a6.NginxMailingListRussian@forum.nginx.org> iptables вообще выключали, но не помогало. При этом в логах каких-либо подзрительных сообщений нет. Виктор Вислобоков Wrote: ------------------------------------------------------- > У меня такое бывает на серверах с CentOS 5.x/6.x. Помогает рестарт > iptables. Попробуйте. > > > 1 апреля 2013 г., 13:31 пользователь psevdokot > написал: > > > по tcpdump-у видим, что syn-пакет на сервер приходит, но syn+ack в > ответ не > > отправляется. > > > > Un Lexx Wrote: > > ------------------------------------------------------- > > > Tcp пакет то на указанный порт приходит? вообще судя по тому что > то > > > появляется то исчезает думаю где то выше у вас стоит какое то > > > фаерволл > > > который отфильтровывает по кол-ву запросов на указанный порт X > > > > > > > > > > > > 1 апреля 2013 г., 14:13 пользователь vstaf > > > написал: > > > > > > > Коллеги, надеюсь на помощь в решении периодически возникающей > > > проблемы. > > > > > > > > Суть: > > > > > > > > Есть nginx, обслуживающий 1 домен на 5 портах + SSL. > Периодически > > > (раз в > > > > несколько недель) возникает ситуация, что при попытке коннекта > на > > > > определенный порт (назовем его "Х") не проходят даже syn - ack. > > > Обычно это > > > > возникает при цифре 6к syn-запросов в секунду к серверу на > > > пресловутый порт > > > > "Х". На других портах nginx работает нормально и без проблем > > > выполняет все > > > > свои функции. > > > > > > > > О сервере: 2хXeon E5620, HT on, 12 gb ram. Centos 5 > > > (2.6.18-238.19.1.el5PAE > > > > i386) > > > > Пиковая статистика из stub_status: rps ~1k, active connections > ~8k > > > > > > > > sysctl.conf: > > > > > > > > net.ipv4.tcp_syncookies = 0 > > > > net.ipv4.netfilter.ip_conntrack_max = 10000000 > > > > > > > > net.ipv4.tcp_fin_timeout = 1 > > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 1 > > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 1 > > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 1 > > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=1 > > > > net.ipv4.ip_local_port_range = 5000 65000 > > > > > > > > net.ipv4.tcp_max_syn_backlog = 3240000 > > > > net.core.somaxconn = 3240000 > > > > net.ipv4.tcp_max_tw_buckets = 1440000 > > > > net.core.netdev_max_backlog=10000 > > > > > > > > net.core.rmem_default = 8388608 > > > > net.core.rmem_max = 16777216 > > > > net.core.wmem_max = 16777216 > > > > net.ipv4.tcp_mem = 1048576 2097152 3145728 > > > > net.ipv4.tcp_rmem = 4096 65536 16777216 > > > > net.ipv4.tcp_wmem = 4096 65536 16777216 > > > > > > > > nginx:conf: > > > > > > > > worker_processes 16; > > > > > > > > events { > > > > worker_connections 16384; > > > > use epoll; > > > > multi_accept on; > > > > } > > > > > > > > http { > > > > > > > > tcp_nopush on; > > > > tcp_nodelay on; > > > > sendfile on; > > > > keepalive_timeout 10; > > > > keepalive_requests 100000; > > > > reset_timedout_connection on; > > > > send_timeout 2; > > > > client_header_timeout 10; > > > > client_body_timeout 10; > > > > proxy_buffering off; > > > > > > > > fastcgi_buffers 4 256k; > > > > fastcgi_buffer_size 256k; > > > > > > > > client_max_body_size 10m; > > > > > > > > > > > > Понимаю, что по сути сам nginx тут не при чем, но хотелось бы > > > понять > > > > направление куда копать. Экспериментировал с разными > параметрами > > > ядра - > > > > профита так и не получил. Когда количество синов в секунду > падает > > > (до > > > > 1-1.5к) - все приходит в норму. > > > > > > > > Заранее спасибо. > > > > > > > > Posted at Nginx Forum: > > > > http://forum.nginx.org/read.php?21,237998,237998#msg-237998 > > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?21,237998,238000#msg-238000 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237998,238004#msg-238004 From mdounin at mdounin.ru Mon Apr 1 14:25:56 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 1 Apr 2013 18:25:56 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQutCw0Lcg0LIg0L7QsdGB0LvRg9C20LjQstCw0L3QuNC4INC90LAg?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvQtdC90L3QvtC8INC/0L7RgNGC0YMu?= In-Reply-To: <0f673d55a7825c53af59cf4e2408bf37.NginxMailingListRussian@forum.nginx.org> References: <0f673d55a7825c53af59cf4e2408bf37.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130401142556.GK62550@mdounin.ru> Hello! On Mon, Apr 01, 2013 at 04:13:20AM -0400, vstaf wrote: > Коллеги, надеюсь на помощь в решении периодически возникающей проблемы. > > Суть: > > Есть nginx, обслуживающий 1 домен на 5 портах + SSL. Периодически (раз в > несколько недель) возникает ситуация, что при попытке коннекта на > определенный порт (назовем его "Х") не проходят даже syn - ack. Обычно это > возникает при цифре 6к syn-запросов в секунду к серверу на пресловутый порт > "Х". На других портах nginx работает нормально и без проблем выполняет все > свои функции. [...] > Понимаю, что по сути сам nginx тут не при чем, но хотелось бы понять > направление куда копать. Экспериментировал с разными параметрами ядра - > профита так и не получил. Когда количество синов в секунду падает (до > 1-1.5к) - все приходит в норму. Начать имеет смысл с простого - посмотреть на размеры listen queue и количество соединений в ней (смотреть "ss -nlt"). В большинстве linux'ов, насколько я понимаю, по умолчанию net.ipv4.tcp_abort_on_overflow стоит в 0, и при переполнении listen queue syn-пакеты просто тихо дропаются на пол. По умолчанию на linux'е nginx использует listen queue 511, для 6k соединений в секунду - это может быть мало, особенно если машина при этом нагружена. Тюнить - с помощью парметра backlog= директивы listen, nginx.org/r/listen. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon Apr 1 14:45:11 2013 From: nginx-forum at nginx.us (green1000) Date: Mon, 01 Apr 2013 10:45:11 -0400 Subject: =?UTF-8?B?0KfRgtC+INC+0LfQvdCw0YfQsNGO0YIg0LTQsNC90L3Ri9C1INC00LjRgNC10Lo=?= =?UTF-8?B?0YLQuNCy0Ys/ICjQsiDQtNC+0LrRg9C80LXQvdGC0LDRhtC40Lgg0L4g0L0=?= =?UTF-8?B?0LjRhSDQvdC10YIg0L7Qv9C40YHQsNC90LjRjyk=?= Message-ID: Открыл SimpleRubyFCGI (http://wiki.nginx.org/SimpleRubyFCGI), а там используются директивы, которых нет в документации. Конечно, можно догадаться по смыслу, что они значат, но хотелось бы почитать полную документацию о них: user http; worker_processes 3; include mime.types; include C:/path/to/config/*.txt; Особенно неясен include. С одной стороны вроде подключает mime типы, а с другой - служит для перевода на другой конфиг. Где о них можно подробно почитать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238006,238006#msg-238006 From nginx-forum at nginx.us Mon Apr 1 14:53:33 2013 From: nginx-forum at nginx.us (green1000) Date: Mon, 01 Apr 2013 10:53:33 -0400 Subject: =?UTF-8?B?UmU6INCn0YLQviDQvtC30L3QsNGH0LDRjtGCINC00LDQvdC90YvQtSDQtNC40YA=?= =?UTF-8?B?0LXQutGC0LjQstGLPyAo0LIg0LTQvtC60YPQvNC10L3RgtCw0YbQuNC4INC+?= =?UTF-8?B?INC90LjRhSDQvdC10YIg0L7Qv9C40YHQsNC90LjRjyk=?= In-Reply-To: References: Message-ID: Нашел! Вот они, на этой странице - http://nginx.org/ru/docs/ngx_core_module.html Просто кликал на их ссылки в wiki, а там для них нет документации. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238006,238007#msg-238007 From denis at webmaster.spb.ru Mon Apr 1 15:23:42 2013 From: denis at webmaster.spb.ru (denis) Date: Mon, 01 Apr 2013 19:23:42 +0400 Subject: =?UTF-8?B?UmU6INC/0L7Qu9C90LDRjyDQsdC70L7QutC40YDQvtCy0LrQsCBuZ2lueD8=?= In-Reply-To: <51541ECC.4050406@webmaster.spb.ru> References: <51541ECC.4050406@webmaster.spb.ru> Message-ID: <5159A67E.7020800@webmaster.spb.ru> 28.03.2013 14:43, denis пишет: > У нас несколько серверов глубокой ночью бэкапятся, и при запуске s3cmd > sync сервер становится полностью недоступен, несмотря на секцию > upstream. При этом при росте нагрузки от клиентов или ошибке на резерв > переключает как надо. > Что можно сделать, кроме как запустить 2 nginx чисто как балансер? И > кстати, как это правильнее делать во freebsd (8.2) > Так чего, может кто подсказать что делать? From chipitsine at gmail.com Mon Apr 1 15:42:19 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 1 Apr 2013 21:42:19 +0600 Subject: =?UTF-8?B?UmU6INC/0L7Qu9C90LDRjyDQsdC70L7QutC40YDQvtCy0LrQsCBuZ2lueD8=?= In-Reply-To: <5159A67E.7020800@webmaster.spb.ru> References: <51541ECC.4050406@webmaster.spb.ru> <5159A67E.7020800@webmaster.spb.ru> Message-ID: в режиме "чисто как балансер" nginx может сохранять ответ сервера во временный файл (если от апстрима ответ получен, а клиент не спешит его забирать). по вашим симптомам, скорее всего копать в сторону http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering наверняка можно сказать, только изучив отладку. подробно тут: http://nginx.org/en/docs/debugging_log.html 1 апреля 2013 г., 21:23 пользователь denis написал: > 28.03.2013 14:43, denis пишет: > >> У нас несколько серверов глубокой ночью бэкапятся, и при запуске s3cmd >> sync сервер становится полностью недоступен, несмотря на секцию upstream. >> При этом при росте нагрузки от клиентов или ошибке на резерв переключает как >> надо. >> Что можно сделать, кроме как запустить 2 nginx чисто как балансер? И >> кстати, как это правильнее делать во freebsd (8.2) >> > Так чего, может кто подсказать что делать? > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Mon Apr 1 18:11:42 2013 From: nginx-forum at nginx.us (green1000) Date: Mon, 01 Apr 2013 14:11:42 -0400 Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDRjtGCIGF1dGggYmFzaWMg0LggYXV0aCBiYXNpYyB1?= =?UTF-8?B?c2VyIGZpbGUg0L/RgNC4INC/0L7RgdC70LXQtNGD0Y7RidC40YUg0L7QsdGA?= =?UTF-8?B?0LDRidC10L3QuNGP0YUuINCd0LUg0LLRi9Cy0L7QtNC40YIg0L7QutC90L4g?= =?UTF-8?B?0LvQvtCz0LjQvdCw?= Message-ID: Осваиваю nginx. На Windows XP. Имею такой простой конфиг: worker_processes 1; pid "C:/nginx-1.2.7/logs/nginx.pid"; http { allow 127.0.0.1; auth_basic "hello world"; auth_basic_user_file conf/htpasswd; server { listen 127.0.0.1:8080; } } Обращаюсь на адрес http://localhost:8080 Все, что хочу - это вывести окно аутентификации, попробовать ввести логин и пароль правильно и неправильно и увидеть, что происходит. Что выяснил: 1. Директивы по одной не работают. Только в паре. Хотя в мануале об этом ни слова. Проблема: Окно аутентификации появилось только один раз. Ввел неправильные логин и пароль. Вывелась страница "500 Internal Server Error". Снова делаю обращение на страницу http://localhost:8080/ (через F5). И больше окно аутентификации не появляется. Постоянно только страница "500 Internal Server Error". Пробовал перезагружать сервер через nginx -s reload. Не помагает. Пробовал полный перезапуск nginx -s quit. Все равно при заходе на http://localhost:8080 только "500 Internal Server Error". Никакого окна аутентификации. Почему? Считаю, что при таких настройках оно должно появлятся каждом обращении. Но оно не появляется. Может что-то не знаю? Что делаю не так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238011,238011#msg-238011 From andrey at kopeyko.ru Tue Apr 2 05:32:58 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Tue, 02 Apr 2013 09:32:58 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0Y7RgiBhdXRoIGJhc2ljINC4IGF1dGggYmFz?= =?UTF-8?B?aWMgdXNlciBmaWxlINC/0YDQuCDQv9C+0YHQu9C10LTRg9GO0YnQuNGFINC+?= =?UTF-8?B?0LHRgNCw0YnQtdC90LjRj9GFLiDQndC1INCy0YvQstC+0LTQuNGCINC+0Lo=?= =?UTF-8?B?0L3QviDQu9C+0LPQuNC90LA=?= In-Reply-To: References: Message-ID: <515A6D8A.6090503@kopeyko.ru> 01.04.2013 22:11, green1000 пишет: > Доброе утро, green1000! > Проблема: > Окно аутентификации появилось только один раз. Ввел неправильные логин и > пароль. Вывелась страница "500 Internal Server Error". > Снова делаю обращение на страницу http://localhost:8080/ (через F5). И > больше окно аутентификации не появляется. Постоянно только страница "500 > Internal Server Error". > > ... Что делаю не так? Вы браузер не перегрузили. Он запомнил URL и теперь сразу, не дожидаясь 401-го ответа от сервера, посылает туда заголовок запроса Authorization: Basic bW9*****MTE= А мог и запомнить логин\пароль - смотрите его настройки, и сбросьте "сохраненные пароли" для вашего сайта\URL. Вам стоит освоить тулзу типа LiveHTTPHeaders - наверняка есть аналог и для IE. Она позволяет смотреть все заголовки запросов\ответов - это даёт сильно больше полезной информации для расследований. -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Tue Apr 2 09:03:56 2013 From: nginx-forum at nginx.us (psevdokot) Date: Tue, 02 Apr 2013 05:03:56 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQutCw0Lcg0LIg0L7QsdGB0LvRg9C20LjQstCw0L3QuNC4INC90LAg?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvQtdC90L3QvtC8INC/0L7RgNGC0YMu?= In-Reply-To: <20130401142556.GK62550@mdounin.ru> References: <20130401142556.GK62550@mdounin.ru> Message-ID: <903765816be25f39212a47905c91b0ac.NginxMailingListRussian@forum.nginx.org> Спасибо за совет, будем пробовать. Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Mon, Apr 01, 2013 at 04:13:20AM -0400, vstaf wrote: > > > Коллеги, надеюсь на помощь в решении периодически возникающей > проблемы. > > > > Суть: > > > > Есть nginx, обслуживающий 1 домен на 5 портах + SSL. Периодически > (раз в > > несколько недель) возникает ситуация, что при попытке коннекта на > > определенный порт (назовем его "Х") не проходят даже syn - ack. > Обычно это > > возникает при цифре 6к syn-запросов в секунду к серверу на > пресловутый порт > > "Х". На других портах nginx работает нормально и без проблем > выполняет все > > свои функции. > > [...] > > > Понимаю, что по сути сам nginx тут не при чем, но хотелось бы понять > > направление куда копать. Экспериментировал с разными параметрами > ядра - > > профита так и не получил. Когда количество синов в секунду падает > (до > > 1-1.5к) - все приходит в норму. > > Начать имеет смысл с простого - посмотреть на размеры listen queue > и количество соединений в ней (смотреть "ss -nlt"). В > большинстве linux'ов, насколько я понимаю, по умолчанию > net.ipv4.tcp_abort_on_overflow стоит в 0, и при переполнении > listen queue syn-пакеты просто тихо дропаются на пол. > > По умолчанию на linux'е nginx использует listen queue 511, для 6k > соединений в секунду - это может быть мало, особенно если машина > при этом нагружена. Тюнить - с помощью парметра backlog= > директивы listen, nginx.org/r/listen. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237998,238014#msg-238014 From m-garanin at yandex.ru Tue Apr 2 12:36:17 2013 From: m-garanin at yandex.ru (Garanin Michael) Date: Tue, 02 Apr 2013 16:36:17 +0400 Subject: =?UTF-8?B?0L/QviBwcm94eV9jYWNoZV9rZXk=?= Message-ID: <435841364906177@web7g.yandex.ru> Подскажите пожалуйста на счёт кеширования. У меня на сервер приходят запросы вида "/live/FOLDER_PATH/z([0-9]*)/start.dat" которые nginx проксирует на прокси с путём "/FOLDER_PATH/start.dat" (кусок (z[0-9]*) в пути для прокси НЕ нужен). Я хочу чтобы ответы от прокси кешировались под первоначальным урлом, но похоже что всё кешируется под одним ключём, скорей всего под конечным $uri (FOLDER_PATH/start.dat). То есть на все запросы - один кеш-объект, а мне нужно их различать на основе части "(z[0-9]*)". Cкажите каким образом решить задачу? Заранее спасибо! (версия nginx 1.2.5 ) location ~ z([0-9]*)/start.dat$ { proxy_cache live-cache; proxy_cache_valid 200 302 20m; proxy_cache_valid 404 1m; proxy_cache_lock on; proxy_cache_lock_timeout 20s; proxy_cache_key $scheme$proxy_host$request_uri; # избавляюсь от z[0-9] rewrite ^(.*)/z([0-9]*)/start.dat$ $1/start.dat; # избавляюсь от live rewrite /live/(.*) $1 break; # проксирую proxy_pass http://127.0.0.1:8087/$uri; } From vbart at nginx.com Tue Apr 2 12:46:28 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 2 Apr 2013 16:46:28 +0400 Subject: =?UTF-8?B?UmU6INC/0L4gcHJveHlfY2FjaGVfa2V5?= In-Reply-To: <435841364906177@web7g.yandex.ru> References: <435841364906177@web7g.yandex.ru> Message-ID: <201304021646.28899.vbart@nginx.com> On Tuesday 02 April 2013 16:36:17 Garanin Michael wrote: > Подскажите пожалуйста на счёт кеширования. > У меня на сервер приходят запросы вида > "/live/FOLDER_PATH/z([0-9]*)/start.dat" которые nginx проксирует на > прокси с путём "/FOLDER_PATH/start.dat" (кусок (z[0-9]*) в пути для прокси > НЕ нужен). > Я хочу чтобы ответы от прокси кешировались под первоначальным урлом, но Согласно вашим настройкам, которые вы привели, у вас всё кэшируется с использованием первоначального URI. > похоже что всё кешируется под одним ключём, скорей всего под конечным $uri > (FOLDER_PATH/start.dat). То есть на все запросы - один кеш-объект, а мне > нужно их различать на основе части "(z[0-9]*)". Подозреваю, что объекты в кэше таки разные, а вот на одинаковый запрос ваш бэкенд выдает одинаковый ответ, что вполне логично. -- Валентин Бартенев http://nginx.org/en/donation.html > Cкажите каким образом > решить задачу? Заранее спасибо! > > (версия nginx 1.2.5 ) > > location ~ z([0-9]*)/start.dat$ { > proxy_cache live-cache; > proxy_cache_valid 200 302 20m; > proxy_cache_valid 404 1m; > proxy_cache_lock on; > proxy_cache_lock_timeout 20s; > proxy_cache_key $scheme$proxy_host$request_uri; > > # избавляюсь от z[0-9] > rewrite ^(.*)/z([0-9]*)/start.dat$ $1/start.dat; > > # избавляюсь от live > rewrite /live/(.*) $1 break; > > # проксирую > proxy_pass http://127.0.0.1:8087/$uri; > > } > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue Apr 2 12:54:21 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 2 Apr 2013 16:54:21 +0400 Subject: nginx-1.2.8 Message-ID: <20130402125421.GP62550@mdounin.ru> Изменения в nginx 1.2.8 02.04.2013 *) Исправление: при использовании директивы "ssl_session_cache shared" новые сессии могли не сохраняться, если заканчивалось место в разделяемой памяти. Спасибо Piotr Sikora. *) Исправление: ответы могли зависать, если использовались подзапросы и при обработке подзапроса происходила DNS-ошибка. Спасибо Lanshun Zhou. *) Исправление: в модуле ngx_http_mp4_module. Спасибо Gernot Vormayr. *) Исправление: в процедуре учёта использования бэкендов. -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Tue Apr 2 14:34:53 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 2 Apr 2013 18:34:53 +0400 Subject: =?UTF-8?B?UmU6ICDQndC1INGA0LDQsdC+0YLQsNGO0YIgYXV0aCBiYXNpYyDQuCBhdXRoIGJh?= =?UTF-8?B?c2ljIHVzZXIgZmlsZSDQv9GA0Lgg0L/QvtGB0LvQtdC00YPRjtGJ0LjRhSA=?= =?UTF-8?B?0L7QsdGA0LDRidC10L3QuNGP0YUuINCd0LUg0LLRi9Cy0L7QtNC40YIg0L4=?= =?UTF-8?B?0LrQvdC+INC70L7Qs9C40L3QsA==?= In-Reply-To: References: Message-ID: <201304021834.53335.vbart@nginx.com> On Monday 01 April 2013 22:11:42 green1000 wrote: > Осваиваю nginx. На Windows XP. > Имею такой простой конфиг: > > worker_processes 1; > pid "C:/nginx-1.2.7/logs/nginx.pid"; > > http { > allow 127.0.0.1; > > auth_basic "hello world"; > auth_basic_user_file conf/htpasswd; > > server { > listen 127.0.0.1:8080; > } > } > > Обращаюсь на адрес http://localhost:8080 > Все, что хочу - это вывести окно аутентификации, попробовать ввести логин и > пароль правильно и неправильно и увидеть, что происходит. > > Что выяснил: > 1. Директивы по одной не работают. Только в паре. Хотя в мануале об этом ни > слова. > > Проблема: > Окно аутентификации появилось только один раз. Ввел неправильные логин и > пароль. Вывелась страница "500 Internal Server Error". > Снова делаю обращение на страницу http://localhost:8080/ (через F5). И > больше окно аутентификации не появляется. Постоянно только страница "500 > Internal Server Error". > Пробовал перезагружать сервер через nginx -s reload. Не помагает. > Пробовал полный перезапуск nginx -s quit. Все равно при заходе на > http://localhost:8080 только "500 Internal Server Error". Никакого окна > аутентификации. Почему? > > Считаю, что при таких настройках оно должно появлятся каждом обращении. Но > оно не появляется. Может что-то не знаю? Что делаю не так? > А в логах что? -- Валентин Бартенев http://nginx.org/en/donation.html From vas at mpeks.tomsk.su Wed Apr 3 02:25:53 2013 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Wed, 3 Apr 2013 09:25:53 +0700 Subject: =?UTF-8?B?VXNlckRpciDQuCDQvtGC0LTQsNGH0LAg0YTQsNC50LvQvtCyINC90LDQv9GA0Y8=?= =?UTF-8?B?0LzRg9GO?= Message-ID: <20130403022553.GB84627@admin.sibptus.tomsk.ru> Коллеги, Есть nginx-devel-1.3.14 в качестве frontend к apache22. Чтобы отдавать видеоролики без участия апача, написал в конфиге сервера: location ~* ^.+\.(avi|flv)$ { root /home/www/data ; expires 30d; } Файлы по ссылке вида http://site.ru/some/dir/file.flv теперь отдаются напрямую. Но проблема в том, что в backend-e включены UserDir, и надо чтобы http://site.ru/~pupkin/some/dir/file.flv тоже работало. Как бы это покрасивее сконфигурить? Если убрать вышеприведенную секцию, то разумеется всё работает (через backend). Заранее спасибо за совет. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From pl-xek at yandex.ru Wed Apr 3 07:25:55 2013 From: pl-xek at yandex.ru (Xek PL) Date: Wed, 03 Apr 2013 11:25:55 +0400 Subject: resolver cname ttl Message-ID: <1209361364973955@web28g.yandex.ru> Привет всем! Такая проблема: resolver не учитывает TTL для CNAME записей. Например,в DNS указано: upstream 60 CNAME cname1 cname1 86400 A 10.10.10.10 По тестам получается, что upstream резолвится раз в сутки. Хотя должен раз в 60 сек. Протестировал на версиях 1.2.7, 1.3.15 Баг? Или есть какие-то соображения для такой работы? Удачи, Павел From citrin at citrin.ru Wed Apr 3 07:35:35 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Wed, 03 Apr 2013 11:35:35 +0400 Subject: =?UTF-8?B?UmU6IFVzZXJEaXIg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70L7QsiDQvdCw0L8=?= =?UTF-8?B?0YDRj9C80YPRjg==?= In-Reply-To: <20130403022553.GB84627@admin.sibptus.tomsk.ru> References: <20130403022553.GB84627@admin.sibptus.tomsk.ru> Message-ID: <515BDBC7.3010607@citrin.ru> On 04/03/13 06:25, Victor Sudakov wrote: > Чтобы отдавать > видеоролики без участия апача, написал в конфиге сервера: > > location ~* ^.+\.(avi|flv)$ { > root /home/www/data ; > expires 30d; > } > > Файлы по ссылке вида http://site.ru/some/dir/file.flv теперь отдаются напрямую. > > Но проблема в том, что в backend-e включены UserDir, и надо чтобы > http://site.ru/~pupkin/some/dir/file.flv тоже работало. Как бы это > покрасивее сконфигурить? Проще всего проксировать http://site.ru/~ на апач: location ~* ^.+\.(avi|flv)$ { root /home/www/data ; expires 30d; } location ^~ /~ { proxy_pass ...; } Но можно заморочаться и сэмулировать поведение UserDir средствами nginx, хотя это будет сложнее. From vas at mpeks.tomsk.su Wed Apr 3 08:14:05 2013 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Wed, 3 Apr 2013 15:14:05 +0700 Subject: =?UTF-8?B?UmU6IFVzZXJEaXIg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70L7QsiDQvdCw0L8=?= =?UTF-8?B?0YDRj9C80YPRjg==?= In-Reply-To: <515BDBC7.3010607@citrin.ru> References: <20130403022553.GB84627@admin.sibptus.tomsk.ru> <515BDBC7.3010607@citrin.ru> Message-ID: <20130403081405.GA94141@admin.sibptus.tomsk.ru> Anton Yuzhaninov wrote: > > Чтобы отдавать > > видеоролики без участия апача, написал в конфиге сервера: > > > > location ~* ^.+\.(avi|flv)$ { > > root /home/www/data ; > > expires 30d; > > } > > > > Файлы по ссылке вида http://site.ru/some/dir/file.flv теперь отдаются напрямую. > > > > Но проблема в том, что в backend-e включены UserDir, и надо чтобы > > http://site.ru/~pupkin/some/dir/file.flv тоже работало. Как бы это > > покрасивее сконфигурить? > > Проще всего проксировать http://site.ru/~ на апач: > > location ~* ^.+\.(avi|flv)$ { > root /home/www/data ; > expires 30d; > } > > location ^~ /~ { > proxy_pass ...; > } Я пока так сделал: location / { proxy_pass http://127.0.0.1:8418; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~ /~ { proxy_pass http://127.0.0.1:8418; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* \.(avi|flv|mov|mp3|mpg|pdf|pps|ppt|psd|rar|rtf|swf|wmv|zip|doc)$ { root /home/www/data ; expires 30d; } > > Но можно заморочаться и сэмулировать поведение UserDir средствами > nginx, хотя это будет сложнее. Хотелось бы, чтобы .flv и прочее из юзерских каталогов тоже отдавалось бы nginx-ом напрямую. Можно взять за основу http://wiki.nginx.org/UserDir и творчески переработать, но вдруг у кого уже готовое есть и поделиться не жалко. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From chipitsine at gmail.com Wed Apr 3 09:57:08 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 3 Apr 2013 15:57:08 +0600 Subject: resolver cname ttl In-Reply-To: <1209361364973955@web28g.yandex.ru> References: <1209361364973955@web28g.yandex.ru> Message-ID: соображение ровно одно, для установления соединения с бекендом нужен адрес, поэтому в момент чтения конфигурации имена ресолвятся в адреса (обращение к ресолверу заблокирует worker-процесс). закешировать внутри worker-процесса строго в соответствии с TTL возможности нет, но можно сделать лайфхак и ресолвить при каждом обращении: set $noop ""; proxy_pass http://some.host$noop; 3 апреля 2013 г., 13:25 пользователь Xek PL написал: > Привет всем! > > Такая проблема: resolver не учитывает TTL для CNAME записей. > > Например,в DNS указано: > upstream 60 CNAME cname1 > cname1 86400 A 10.10.10.10 > > По тестам получается, что upstream резолвится раз в сутки. > Хотя должен раз в 60 сек. > > Протестировал на версиях 1.2.7, 1.3.15 > Баг? > Или есть какие-то соображения для такой работы? > > > Удачи, > Павел > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-ru at sadok.spb.ru Wed Apr 3 10:15:13 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 3 Apr 2013 14:15:13 +0400 Subject: resolver cname ttl In-Reply-To: <1209361364973955@web28g.yandex.ru> References: <1209361364973955@web28g.yandex.ru> Message-ID: <1322306425.20130403141513@sadok.spb.ru> Здравствуйте, Xek. Вы писали 3 апреля 2013 г., 11:25:55: > Такая проблема: resolver не учитывает TTL для CNAME записей. > Протестировал на версиях 1.2.7, 1.3.15 > Баг? > Или есть какие-то соображения для такой работы? ИМХО, это by design у bind и nginx тут не при чем. Наверняка при reload'e бинда возникает [1]. Похожая история [2] Я с этим сталкивался (правда для TXT). Инфа есть тут (но там нет про CNAME) [3] [1] http://marc.info/?l=bind-users&m=98864612614783&w=2 [2] https://lists.isc.org/pipermail/bind-users/2004-January/048216.html [3] http://www.netwidget.net/books/apress/dns/info/ttl.html -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From mdounin at mdounin.ru Wed Apr 3 10:42:44 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 3 Apr 2013 14:42:44 +0400 Subject: resolver cname ttl In-Reply-To: <1209361364973955@web28g.yandex.ru> References: <1209361364973955@web28g.yandex.ru> Message-ID: <20130403104244.GU62550@mdounin.ru> Hello! On Wed, Apr 03, 2013 at 11:25:55AM +0400, Xek PL wrote: > Привет всем! > > Такая проблема: resolver не учитывает TTL для CNAME записей. > > Например,в DNS указано: > upstream 60 CNAME cname1 > cname1 86400 A 10.10.10.10 > > По тестам получается, что upstream резолвится раз в сутки. > Хотя должен раз в 60 сек. > > Протестировал на версиях 1.2.7, 1.3.15 > Баг? > Или есть какие-то соображения для такой работы? Во встроенном резолвере не очень хорошо сделана обработка нескольких записей в одном DNS-ответе, и в частности в вышеописанном случае, если обе записи приходят вместе - то CNAME будет "пропущен", и кеш resolver'а попадёт сразу адрес, с ttl 86400. Простой workaround - использовать resolver ... valid=30s; См. http://nginx.org/r/resolver. Если не лень - было бы полезно нарисовать тикет в trac'е, http://trac.nginx.org. Если проблема очень болит и мешает ходить - приходите на http://nginx.com, договоримся. -- Maxim Dounin http://nginx.org/en/donation.html From maxim at nginx.com Wed Apr 3 13:18:03 2013 From: maxim at nginx.com (Maxim Konovalov) Date: Wed, 03 Apr 2013 17:18:03 +0400 Subject: nginx-1.3.15 In-Reply-To: <51541F86.7000709@nginx.com> References: <20130326133007.GQ62550@mdounin.ru> <201303280016.17883.vbart@nginx.com> <51540DF7.4070304@meganuke.ru> <51541F86.7000709@nginx.com> Message-ID: <515C2C0B.2050004@nginx.com> On 3/28/13 2:46 PM, Maxim Konovalov wrote: > On 3/28/13 1:31 PM, Nikita Stupin wrote: >> Добрый день. >> >> Валентин, а планируется на http://nginx.org/packages/ubuntu/ >> выкладывать сборки и development ветки? >> > Планируется, работаем над этим. > http://mailman.nginx.org/pipermail/nginx/2013-April/038389.html -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/services.html From anatoly at sonru.com Wed Apr 3 13:48:32 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 3 Apr 2013 14:48:32 +0100 Subject: nginx-1.3.15 In-Reply-To: <515C2C0B.2050004@nginx.com> References: <20130326133007.GQ62550@mdounin.ru> <201303280016.17883.vbart@nginx.com> <51540DF7.4070304@meganuke.ru> <51541F86.7000709@nginx.com> <515C2C0B.2050004@nginx.com> Message-ID: On Apr 3, 2013, at 2:18 PM, Maxim Konovalov wrote: > On 3/28/13 2:46 PM, Maxim Konovalov wrote: >> On 3/28/13 1:31 PM, Nikita Stupin wrote: >>> Добрый день. >>> >>> Валентин, а планируется на http://nginx.org/packages/ubuntu/ >>> выкладывать сборки и development ветки? >>> >> Планируется, работаем над этим. >> > http://mailman.nginx.org/pipermail/nginx/2013-April/038389.html насколько я понимаю, проект wiki.nginx.org никак не аффилирован и вообще не связан с Nginx, Inc. > > -- > Maxim Konovalov > +7 (910) 4293178 > http://nginx.com/services.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From maxim at nginx.com Wed Apr 3 14:19:27 2013 From: maxim at nginx.com (Maxim Konovalov) Date: Wed, 03 Apr 2013 18:19:27 +0400 Subject: nginx-1.3.15 In-Reply-To: References: <20130326133007.GQ62550@mdounin.ru> <201303280016.17883.vbart@nginx.com> <51540DF7.4070304@meganuke.ru> <51541F86.7000709@nginx.com> <515C2C0B.2050004@nginx.com> Message-ID: <515C3A6F.9000406@nginx.com> On 4/3/13 5:48 PM, Anatoly Mikhailov wrote: > > On Apr 3, 2013, at 2:18 PM, Maxim Konovalov wrote: > >> On 3/28/13 2:46 PM, Maxim Konovalov wrote: >>> On 3/28/13 1:31 PM, Nikita Stupin wrote: >>>> Добрый день. >>>> >>>> Валентин, а планируется на http://nginx.org/packages/ubuntu/ >>>> выкладывать сборки и development ветки? >>>> >>> Планируется, работаем над этим. >>> >> http://mailman.nginx.org/pipermail/nginx/2013-April/038389.html > > насколько я понимаю, проект wiki.nginx.org никак не аффилирован > и вообще не связан с Nginx, Inc. > А как это связано с пакетами? -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/services.html From matwey.kornilov at gmail.com Wed Apr 3 17:55:14 2013 From: matwey.kornilov at gmail.com (Matwey V. Kornilov) Date: Wed, 03 Apr 2013 21:55:14 +0400 Subject: SSI: flastmod, fsize Message-ID: Привет, Выглядит так, как-будто модуль SSI не поддерживает директивы #flastmod и #fsize. Интересно, почему. Сложно реализовать? Чрезмерные затраты? Никому не нужно? Это создает некоторые проблемы при переносе некоторого простенького сайта с lighttpd. From vbart at nginx.com Wed Apr 3 18:38:19 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 3 Apr 2013 22:38:19 +0400 Subject: SSI: flastmod, fsize In-Reply-To: References: Message-ID: <201304032238.19749.vbart@nginx.com> On Wednesday 03 April 2013 21:55:14 Matwey V. Kornilov wrote: > Привет, > > Выглядит так, как-будто модуль SSI не поддерживает директивы #flastmod и > #fsize. Интересно, почему. Сложно реализовать? Чрезмерные затраты? Никому > не нужно? > ИМХО крайне редко функциональность, если я не ошибся с запросом, то похоже за всю историю существования рассылки и форума спрашивал только один человек: https://www.google.com/search?q=%23flastmod+OR+%23fsize+site%3Anginx.org На SO нашлось всего 5 вопросов в которых хоть как-то упомянуты эти SSI команды, и все эти вопросы не связаны с nginx. На SF похоже вообще нет упоминаний. Да и странно на такое подзапрос делать. В вашем случае, например, оно как используется? -- Валентин Бартенев http://nginx.org/en/donation.html > Это создает некоторые проблемы при переносе некоторого простенького сайта с > lighttpd. > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From lego12239 at yandex.ru Wed Apr 3 19:06:28 2013 From: lego12239 at yandex.ru (Oleg) Date: Wed, 3 Apr 2013 23:06:28 +0400 Subject: =?UTF-8?B?0LTQvtCx0LDQstC70LXQvdC40LUg0L/QtdGA0LXQvNC10L3QvdGL0YU=?= Message-ID: <20130403190628.GA18958@localhost> Всем привет. Хочется добавлять переменные не перед конфигурацией процесса, а в процессе обработки запроса. Такое возможно? Везде, где нашёл описание создания переменных, написано, что только в preconfiguration можно. Я так понимаю, что $cookie_* и $http_* динамически создаются? From vbart at nginx.com Wed Apr 3 19:24:18 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 3 Apr 2013 23:24:18 +0400 Subject: =?UTF-8?B?UmU6INC00L7QsdCw0LLQu9C10L3QuNC1INC/0LXRgNC10LzQtdC90L3Ri9GF?= In-Reply-To: <20130403190628.GA18958@localhost> References: <20130403190628.GA18958@localhost> Message-ID: <201304032324.18881.vbart@nginx.com> On Wednesday 03 April 2013 23:06:28 Oleg wrote: > Всем привет. > > Хочется добавлять переменные не перед конфигурацией процесса, а > в процессе обработки запроса. Такое возможно? Везде, где нашёл описание > создания переменных, написано, что только в preconfiguration можно. > Я так понимаю, что $cookie_* и $http_* динамически создаются? > Советую использовать grep src/. У этих переменных отдельные хуки в ngx_http_get_variable(): http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_variables.c#L569 Переменные можно добавлять и во время конфигурации, смотрите например как работает директива set из rewrite-модуля. -- Валентин Бартенев http://nginx.org/en/donation.html From lego12239 at yandex.ru Wed Apr 3 21:04:24 2013 From: lego12239 at yandex.ru (Oleg) Date: Thu, 4 Apr 2013 01:04:24 +0400 Subject: =?UTF-8?B?UmU6INC00L7QsdCw0LLQu9C10L3QuNC1INC/0LXRgNC10LzQtdC90L3Ri9GF?= In-Reply-To: <201304032324.18881.vbart@nginx.com> References: <20130403190628.GA18958@localhost> <201304032324.18881.vbart@nginx.com> Message-ID: <20130403210424.GA15171@localhost> On Wed, Apr 03, 2013 at 11:24:18PM +0400, Валентин Бартенев wrote: > On Wednesday 03 April 2013 23:06:28 Oleg wrote: > > Всем привет. > > > > Хочется добавлять переменные не перед конфигурацией процесса, а > > в процессе обработки запроса. Такое возможно? Везде, где нашёл описание > > создания переменных, написано, что только в preconfiguration можно. > > Я так понимаю, что $cookie_* и $http_* динамически создаются? > > > > Советую использовать grep src/. А разве есть какой-то другой способ :-)? > У этих переменных отдельные хуки в ngx_http_get_variable(): > http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_variables.c#L569 Это я видел. Т.е. цивильного способа, не выходя за пределы модуля, такую переменную использовать нет? Надо ngx_http_get_variable править? From vbart at nginx.com Wed Apr 3 21:31:38 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 4 Apr 2013 01:31:38 +0400 Subject: =?UTF-8?B?UmU6INC00L7QsdCw0LLQu9C10L3QuNC1INC/0LXRgNC10LzQtdC90L3Ri9GF?= In-Reply-To: <20130403210424.GA15171@localhost> References: <20130403190628.GA18958@localhost> <201304032324.18881.vbart@nginx.com> <20130403210424.GA15171@localhost> Message-ID: <201304040131.38590.vbart@nginx.com> On Thursday 04 April 2013 01:04:24 Oleg wrote: > On Wed, Apr 03, 2013 at 11:24:18PM +0400, Валентин Бартенев wrote: > > On Wednesday 03 April 2013 23:06:28 Oleg wrote: > > > Всем привет. > > > > > > Хочется добавлять переменные не перед конфигурацией процесса, а > > > > > > в процессе обработки запроса. Такое возможно? Везде, где нашёл описание > > > создания переменных, написано, что только в preconfiguration можно. > > > > > > Я так понимаю, что $cookie_* и $http_* динамически создаются? > > > > Советую использовать grep src/. > > А разве есть какой-то другой способ :-)? > > > У этих переменных отдельные хуки в ngx_http_get_variable(): > > http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_variabl > > es.c#L569 > > Это я видел. > Т.е. цивильного способа, не выходя за пределы модуля, такую переменную > использовать нет? Надо ngx_http_get_variable править? > А для чего вам ещё одна magic-переменная, если не секрет? Если не выходя за пределы модуля, то можно исхитриться и сделать две переменные так: set $var_key "abc"; return 200 $var_value; $var_value будет возвращать значение для имени записанного в $var_key. Получится некий аналог с более сложным доступом. -- Валентин Бартенев http://nginx.org/en/donation.html From lego12239 at yandex.ru Thu Apr 4 04:04:53 2013 From: lego12239 at yandex.ru (Oleg) Date: Thu, 4 Apr 2013 08:04:53 +0400 Subject: =?UTF-8?B?UmU6INC00L7QsdCw0LLQu9C10L3QuNC1INC/0LXRgNC10LzQtdC90L3Ri9GF?= In-Reply-To: <201304040131.38590.vbart@nginx.com> References: <20130403190628.GA18958@localhost> <201304032324.18881.vbart@nginx.com> <20130403210424.GA15171@localhost> <201304040131.38590.vbart@nginx.com> Message-ID: <20130404040453.GA14201@localhost> On Thu, Apr 04, 2013 at 01:31:38AM +0400, Валентин Бартенев wrote: > On Thursday 04 April 2013 01:04:24 Oleg wrote: > > On Wed, Apr 03, 2013 at 11:24:18PM +0400, Валентин Бартенев wrote: > > > On Wednesday 03 April 2013 23:06:28 Oleg wrote: > > > > Всем привет. > > > > > > > > Хочется добавлять переменные не перед конфигурацией процесса, а > > > > > > > > в процессе обработки запроса. Такое возможно? Везде, где нашёл описание > > > > создания переменных, написано, что только в preconfiguration можно. > > > > > > > > Я так понимаю, что $cookie_* и $http_* динамически создаются? > > > > > > Советую использовать grep src/. > > > > А разве есть какой-то другой способ :-)? > > > > > У этих переменных отдельные хуки в ngx_http_get_variable(): > > > http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_variabl > > > es.c#L569 > > > > Это я видел. > > Т.е. цивильного способа, не выходя за пределы модуля, такую переменную > > использовать нет? Надо ngx_http_get_variable править? > > > > А для чего вам ещё одна magic-переменная, если не секрет? У меня есть модуль аутентификации, который после своей работы должен создавать некоторые переменные, в случае удачной аутентификации. Например, $my_user, $my_http_addr, $my_http_port, где последнии два используются для обратного прокси. Т.к. возможны конфигурации, где некоторых переменных нет, а при старте nginx не известно, какой набор данных есть для каждого пользователя, то не хотелось бы заранее забивать жёстко в исходник все возможные переменные. Можно, конечно, формировать такой список переменных через конфиг, вроде: my_module_need_var "var1"; my_module_need_var "var2"; И уже при старте nginx создавать обычным образом только то, что указано в конфиге явно. Но мне это кажется не красивым. From nginx-forum at nginx.us Thu Apr 4 08:47:38 2013 From: nginx-forum at nginx.us (skeletor) Date: Thu, 04 Apr 2013 04:47:38 -0400 Subject: nginx rewrite ?& Message-ID: <04c91149b8c7d218d6c6ad20420f0d2f.NginxMailingListRussian@forum.nginx.org> Всем привет. Нужно сделать редирект со страницы вида http://domain.com/?&... на страницу http://domain.com. То есть, если строка запроса начинается с ?& - то просто перенаправить на главную. Пробовал такие варианты: [code] rewrite ^/?& http://$host permanent; [/code] [code] if ($request_uri ~* ^/?&) { rewrite ^ http://$host permanent; } [/code] а так же пробовал экранировать ? и & - не работает. Либо не перенаправляет, либо получаем безконечный редирект. Прочитал, что амперсанд используется для отделения параметров при GET-запросе и понял и вроде как нельзя его использовать в regexp. Или я неправ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238083,238083#msg-238083 From vadim.lazovskiy at gmail.com Thu Apr 4 09:03:23 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 4 Apr 2013 13:03:23 +0400 Subject: nginx rewrite ?& In-Reply-To: <04c91149b8c7d218d6c6ad20420f0d2f.NginxMailingListRussian@forum.nginx.org> References: <04c91149b8c7d218d6c6ad20420f0d2f.NginxMailingListRussian@forum.nginx.org> Message-ID: Здравствуйте. Директива rewrite работает с URI, аргументы запроса туда не попадают. Второй вариант быть может заработает, если заменить $request_uri на $args, а регулярное выражение исправить на ^& 4 апреля 2013 г., 12:47 пользователь skeletor написал: > Всем привет. > Нужно сделать редирект со страницы вида http://domain.com/?&... на > страницу > http://domain.com. То есть, если строка запроса начинается с ?& - то > просто > перенаправить на главную. Пробовал такие варианты: > > [code] > rewrite ^/?& http://$host permanent; > [/code] > [code] > if ($request_uri ~* ^/?&) { > rewrite ^ http://$host permanent; > } > [/code] > а так же пробовал экранировать ? и & - не работает. Либо не перенаправляет, > либо получаем безконечный редирект. > Прочитал, что амперсанд используется для отделения параметров при > GET-запросе и понял и вроде как нельзя его использовать в regexp. Или я > неправ? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238083,238083#msg-238083 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Apr 4 09:10:32 2013 From: nginx-forum at nginx.us (skeletor) Date: Thu, 04 Apr 2013 05:10:32 -0400 Subject: nginx rewrite ?& In-Reply-To: References: Message-ID: К сожалению и с args тоже не заработал. Пробовал вот так: if ($args ~* ^&) { rewrite ^ http://$host permanent; } if ($args ~* "^&") { rewrite ^ http://$host permanent; } if ($args ~* "^\&") { rewrite ^ http://$host permanent; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238083,238087#msg-238087 From matwey.kornilov at gmail.com Thu Apr 4 09:51:19 2013 From: matwey.kornilov at gmail.com (Matwey V. Kornilov) Date: Thu, 04 Apr 2013 13:51:19 +0400 Subject: SSI: flastmod, fsize References: <201304032238.19749.vbart@nginx.com> Message-ID: Ну как обычно: Скачать здесь [], последний раз обновлялось Валентин Бартенев wrote: > Да и странно на такое подзапрос делать. В вашем случае, например, оно как > используется? From vadim.lazovskiy at gmail.com Thu Apr 4 10:33:03 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 4 Apr 2013 14:33:03 +0400 Subject: nginx rewrite ?& In-Reply-To: References: Message-ID: Попробовал: location = /test { if ($args ~ ^&) { return 301 http://example.com/work/; } default_type text/plain; return 200 $args; } Робит: либо выводит переменную, либо делает редирект. 4 апреля 2013 г., 13:10 пользователь skeletor написал: > К сожалению и с args тоже не заработал. Пробовал вот так: > > if ($args ~* ^&) { > rewrite ^ http://$host permanent; > } > > if ($args ~* "^&") { > rewrite ^ http://$host permanent; > } > > if ($args ~* "^\&") { > rewrite ^ http://$host permanent; > } > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238083,238087#msg-238087 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Apr 4 10:58:39 2013 From: nginx-forum at nginx.us (skeletor) Date: Thu, 04 Apr 2013 06:58:39 -0400 Subject: nginx rewrite ?& In-Reply-To: References: Message-ID: <02dad04d1027877ee94a9af73f049383.NginxMailingListRussian@forum.nginx.org> Спасибо, Вадим. Пока пробовал и гуглил, натолкнулся на такую конструкцию (немного подправив под себя): if ($query_string ~ "&(.*)"){ rewrite ^(.*)$ $1? permanent; } Но и вашу конструкцию тоже попробую. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238083,238095#msg-238095 From anatoly at sonru.com Thu Apr 4 11:04:37 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 4 Apr 2013 12:04:37 +0100 Subject: =?UTF-8?B?0L/RgNC+0LfRgNCw0YfQvdC+0LUg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg?= =?UTF-8?B?0YEgQVdTIFMz?= Message-ID: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> Добрый день, появилась бизнес-задача организовать контролируемую доставку файлов с S3, разумеется, nginx будет заниматься проверкой условий и отдавать файл при их соблюдении. Заодно у нас появится возможность использовать SPDY для файлов с S3. пока нашел вариант с X-Accel-Redirect (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) с отключенным proxy_max_temp_file_size и proxy_hide_header Content-Disposition. вопрос - использует ли кто данный подход и как правильно организовать прозрачное проксирование? Анатолий From onokonem at gmail.com Thu Apr 4 12:01:54 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 4 Apr 2013 16:01:54 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> Message-ID: > пока нашел вариант с X-Accel-Redirect (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) X-Accel-Redirect вам нужен, если вы хотите отдать локальный файл, но проверить право доступа к нему на бекенде. С S3 это не так, насколько мне известно. > вопрос - использует ли кто данный подход и как правильно организовать прозрачное проксирование? nginx - это продукт для реверсного, а не для прозрачного проксирования. Вы уверены, что правильно ставите задачу? From denis at webmaster.spb.ru Thu Apr 4 12:13:05 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 04 Apr 2013 16:13:05 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> Message-ID: <515D6E51.5060100@webmaster.spb.ru> 04.04.2013 15:04, Anatoly Mikhailov пишет: > Добрый день, > > появилась бизнес-задача организовать контролируемую доставку файлов > с S3, разумеется, nginx будет заниматься проверкой условий и отдавать > файл при их соблюдении. Заодно у нас появится возможность использовать > SPDY для файлов с S3. > > пока нашел вариант с X-Accel-Redirect (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) > с отключенным proxy_max_temp_file_size и proxy_hide_header Content-Disposition. > > вопрос - использует ли кто данный подход и как правильно организовать прозрачное проксирование? А какой смысл? У меня есть в планах чуть другая система: запрошенный файл качаем с S3, кладём локально и в дальнейшем он будет отдаваться только локально. Но нужно такое чуть для другого: если у нас произошел полный отказ сервера, разворачиваем ядро сайта на новом месте + конфиги, и система сама будет качать нужные файлы из резервного хранилища, а остатки потом докачать в фоне с минимальным приоритетом. У вас получается, что файл будет каждый раз закачиваться с S3 на машину и отдаваться, то есть трафик до амазона, трафик до юзера, нагрузка на сервер даже больше, лаг отдачи (для файлов более 1мб может быть очень заметно). Лучше тогда запустить инстанс в амазоне, который будет этот файл читать почти как локальный, и уже напрямую отдавать (на поддомене может висеть). Плюс там же можно отдавать через безопасные линки. From denis at webmaster.spb.ru Thu Apr 4 12:14:16 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 04 Apr 2013 16:14:16 +0400 Subject: =?UTF-8?B?UmU6INC00L7QsdCw0LLQu9C10L3QuNC1INC/0LXRgNC10LzQtdC90L3Ri9GF?= In-Reply-To: <20130404040453.GA14201@localhost> References: <20130403190628.GA18958@localhost> <201304032324.18881.vbart@nginx.com> <20130403210424.GA15171@localhost> <201304040131.38590.vbart@nginx.com> <20130404040453.GA14201@localhost> Message-ID: <515D6E98.9020503@webmaster.spb.ru> > my_module_need_var "var1"; > my_module_need_var "var2"; > > И уже при старте nginx создавать обычным образом только то, что указано в > конфиге явно. Но мне это кажется не красивым. > > map? From vbart at nginx.com Thu Apr 4 13:41:40 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 4 Apr 2013 17:41:40 +0400 Subject: =?UTF-8?B?UmU6INC00L7QsdCw0LLQu9C10L3QuNC1INC/0LXRgNC10LzQtdC90L3Ri9GF?= In-Reply-To: <20130404040453.GA14201@localhost> References: <20130403190628.GA18958@localhost> <201304040131.38590.vbart@nginx.com> <20130404040453.GA14201@localhost> Message-ID: <201304041741.40455.vbart@nginx.com> On Thursday 04 April 2013 08:04:53 Oleg wrote: > On Thu, Apr 04, 2013 at 01:31:38AM +0400, Валентин Бартенев wrote: > > On Thursday 04 April 2013 01:04:24 Oleg wrote: > > > On Wed, Apr 03, 2013 at 11:24:18PM +0400, Валентин Бартенев wrote: > > > > On Wednesday 03 April 2013 23:06:28 Oleg wrote: > > > > > Всем привет. > > > > > > > > > > Хочется добавлять переменные не перед конфигурацией процесса, а > > > > > > > > > > в процессе обработки запроса. Такое возможно? Везде, где нашёл > > > > > описание создания переменных, написано, что только в > > > > > preconfiguration можно. > > > > > > > > > > Я так понимаю, что $cookie_* и $http_* динамически создаются? > > > > > > > > Советую использовать grep src/. > > > > > > > А разве есть какой-то другой способ :-)? > > > > > > > У этих переменных отдельные хуки в ngx_http_get_variable(): > > > > http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_var > > > > iabl es.c#L569 > > > > > > > Это я видел. > > > Т.е. цивильного способа, не выходя за пределы модуля, такую > > > переменную > > > > > > использовать нет? Надо ngx_http_get_variable править? > > > > А для чего вам ещё одна magic-переменная, если не секрет? > > У меня есть модуль аутентификации, который после своей работы должен > создавать некоторые переменные, в случае удачной аутентификации. Например, > $my_user, $my_http_addr, $my_http_port, где последнии два используются для > обратного прокси. Т.к. возможны конфигурации, где некоторых переменных нет, > а при старте nginx не известно, какой набор данных есть для каждого > пользователя, то не хотелось бы заранее забивать жёстко в исходник все > возможные переменные. > Можно, конечно, формировать такой список переменных через конфиг, вроде: > > my_module_need_var "var1"; > my_module_need_var "var2"; > > И уже при старте nginx создавать обычным образом только то, что указано в > конфиге явно. Но мне это кажется не красивым. > Нормальный способ. Можно списком: my_module_vars var1 var2 var3; -- Валентин Бартенев http://nginx.org/en/donation.html From public-mail at alekciy.ru Thu Apr 4 14:32:56 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Thu, 4 Apr 2013 18:32:56 +0400 Subject: =?UTF-8?B?W29mZnRvcF0gY3RwcCAyLjgg0Lgg0L/Rg9GB0YLRi9C1INC60L7QvdGC0LXQutGB?= =?UTF-8?B?0YLQvdGL0LUg0L/QtdGA0LXQvNC10L3QvdGL0LUgX19rZXlfXyDQuCBfX3Np?= =?UTF-8?B?emVfXw==?= Message-ID: Извиняюсь за небольшой офтопик, но хотел уточнить у общественности использующей ctpp 2.8 есть ли проблемы с контекстными переменными __key__ и __size__? Столкнулся с тем, что в цикле невозможно получить размер __size__ для текущего цикла. _____________________ Пример: Исходные json данные: [root at mail testdata]# cat items.json { 'EMPLOYEE_INFO': [ { 'NAME': "Иванов Иван", 'JOB': "Архитектор" }, { 'NAME': "Петров Петр", 'JOB': "Строитель" }, { 'NAME': "Сидоров Сидор", 'JOB': "Рабочий" }, { 'NAME': "Вася Пупки", 'JOB': "Учитель" } ] } Сам шаблон: [root at mail testdata]# cat items.tmpl
#: first=, last=, index=, key=, inner=, odd=, even=, size= Имя: Должность:
Получаю: [root at mail testdata]# /opt/ctpp2/2.8.2/bin/ctpp2c items.tmpl items.ct2 [root at mail testdata]# /opt/ctpp2/2.8.2/bin/ctpp2vm items.ct2 items.json WARNING: [limit of steps] not set, use default value of 10240 ... From vladsm at mail.ru Thu Apr 4 15:12:45 2013 From: vladsm at mail.ru (=?UTF-8?B?0JLQu9Cw0LQg0JzQsNC60YHQuNC80L7Qsg==?=) Date: Thu, 04 Apr 2013 19:12:45 +0400 Subject: =?UTF-8?B?UmU6IFtvZmZ0b3BdIGN0cHAgMi44INC4INC/0YPRgdGC0YvQtSDQutC+0L3RgtC1?= =?UTF-8?B?0LrRgdGC0L3Ri9C1INC/0LXRgNC10LzQtdC90L3Ri9C1IF9fa2V5X18g0Lgg?= =?UTF-8?B?X19zaXplX18=?= Message-ID: <1365088365.170393850@f377.i.mail.ru> Насколько удалось выяснить: __size__ вообще нету, т.е. упоминание его --  косяк в CHANGES __key__ справедлив в случае итерирования хэша. т.е. если бы EMPLOYEE_INFO был не массив, а хэш: {         'EMPLOYEE_INFO': {               'a':  { 'NAME': "Иванов Иван", 'JOB': "Архитектор" },               'b': { 'NAME': "Петров Петр", 'JOB': "Строитель" },               'c':  { 'NAME': "Сидоров Сидор", 'JOB': "Рабочий" },               'd':  { 'NAME': "Вася Пупки", 'JOB': "Учитель" }         } } ..... if (oRegs[iSrcReg].GetType() == CDT::HASH_VAL) {   CDT::Iterator it = oRegs[iSrcReg].Begin();   for (INT_32 iI = 0; iI < iIdx; ++iI) { ++it; }   oItVal["__value__"] = it->second;   oItVal["__key__"] = it->first;   oRegs[iDstReg >> 8] = oItVal; } else {   oItVal["__value__"] = oRegs[iSrcReg][iIdx];   oItVal["__index__"] = iIdx;   oRegs[iDstReg >> 8] = oItVal; } ... Четверг, 4 апреля 2013, 18:32 +04:00 от Алексей Сундуков: >Извиняюсь за небольшой офтопик, но хотел уточнить у общественности >использующей ctpp 2.8 есть ли проблемы с контекстными переменными >__key__ и __size__? Столкнулся с тем, что в цикле невозможно получить >размер __size__ для текущего цикла. > >_____________________ >Пример: >Исходные json данные: >[root at mail testdata]# cat items.json >{ >        'EMPLOYEE_INFO': [ >                { 'NAME': "Иванов Иван", 'JOB': "Архитектор" }, >                { 'NAME': "Петров Петр", 'JOB': "Строитель" }, >                { 'NAME': "Сидоров Сидор", 'JOB': "Рабочий" }, >                { 'NAME': "Вася Пупки", 'JOB': "Учитель" } >        ] >} > > >Сам шаблон: >[root at mail testdata]# cat items.tmpl >
#: first=1, last=, index=0, key=, inner=, odd=1, even=, size= Имя: Иванов Иван Должность: Архитектор
>     >     >         >         >         >     >         >
#: >                        first=, >                        last=, >                        index=, >                        key=, >                        inner=, >                        odd=, >                        even=, >                        size= >                Имя: Должность:
> > >Получаю: >[root at mail testdata]# /opt/ctpp2/2.8.2/bin/ctpp2c items.tmpl items.ct2 >[root at mail testdata]# /opt/ctpp2/2.8.2/bin/ctpp2vm items.ct2 items.json >WARNING: [limit of steps] not set, use default value of 10240 > > >     >         >         >         >     >... >_______________________________________________ >nginx-ru mailing list >nginx-ru at nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From public-mail at alekciy.ru Thu Apr 4 16:58:56 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Thu, 4 Apr 2013 20:58:56 +0400 Subject: =?UTF-8?B?UmU6IFtvZmZ0b3BdIGN0cHAgMi44INC4INC/0YPRgdGC0YvQtSDQutC+0L3RgtC1?= =?UTF-8?B?0LrRgdGC0L3Ri9C1INC/0LXRgNC10LzQtdC90L3Ri9C1IF9fa2V5X18g0Lgg?= =?UTF-8?B?X19zaXplX18=?= In-Reply-To: <1365088365.170393850@f377.i.mail.ru> References: <1365088365.170393850@f377.i.mail.ru> Message-ID: 4 апреля 2013 г., 19:12 пользователь Влад Максимов написал: > Насколько удалось выяснить: > > __size__ вообще нету, т.е. упоминание его -- косяк в CHANGES В смысле, что предполагалось, что __size__ не будет? Я просто пытался разобраться по исходнику, но скудные познания в С++ не позволили разобраться в них. А контекст получился такой, что нужен либо __size__ либо __last__=1 когда итерация только одна: [root at mail testdata]# cat items.json { 'EMPLOYEE_INFO': [ { 'NAME': "Вася Пупки", 'JOB': "Учитель" } ] } [root at mail testdata]# /opt/ctpp2/2.8.2/bin/ctpp2vm items.ct2 items.json WARNING: [limit of steps] not set, use default value of 10240
#: >                        first=1, >                        last=, >                        index=0, >                        key=, >                        inner=, >                        odd=1, >                        even=, >                        size= >                Имя: Иванов ИванДолжность: Архитектор
#: first=1, last=, index=0, key=, inner=, odd=1, even=, size= Имя: Вася Пупки Должность: Учитель
Сейчас выходит так, что при генерации ul/li списка не получается задать класс для последнего элемента если итерация одна, т.к. в шаблоне мы не знаем что это одновременно первый и последний элемент. Вопрос пока решил css-ом с псевдоклассами, но хочется и работающего решения на уровне шаблонизатора. From nginx-forum at nginx.us Thu Apr 4 21:44:48 2013 From: nginx-forum at nginx.us (nginx_x) Date: Thu, 04 Apr 2013 17:44:48 -0400 Subject: =?UTF-8?B?0L3QtdC/0L7QvdGP0YLQutC4INGB0L4g0YHQu9C10YjQtdC8?= Message-ID: <5949d4f75290d434183f507c38b7bd1b.NginxMailingListRussian@forum.nginx.org> Приветствую, уважаемые. Вопрос: вот так работает: location ~* /([a-z]+?)/(.*)\.html$ { return 301 $uri/; } - добавляет слэш а вот так нет location ~* /([a-z]+?)/(.*)\.html/$ { return 301 $uri; } - циклические переадресации, Как правильно убрать слэш с помощmю return? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238116,238116#msg-238116 From pl-xek at yandex.ru Fri Apr 5 05:11:05 2013 From: pl-xek at yandex.ru (Xek PL) Date: Fri, 05 Apr 2013 09:11:05 +0400 Subject: resolver cname ttl In-Reply-To: <20130403104244.GU62550@mdounin.ru> References: <1209361364973955@web28g.yandex.ru> <20130403104244.GU62550@mdounin.ru> Message-ID: <2013571365138665@web3d.yandex.ru> Спасибо! Создал тикет #331 03.04.2013, 14:43, "Maxim Dounin" : > Hello! > > On Wed, Apr 03, 2013 at 11:25:55AM +0400, Xek PL wrote: > >>  Привет всем! >> >>  Такая проблема: resolver не учитывает TTL для CNAME записей. >> >>  Например,в DNS указано: >>  upstream 60 CNAME cname1 >>  cname1  86400 A 10.10.10.10 >> >>  По тестам получается, что upstream резолвится раз в сутки. >>  Хотя должен раз в 60 сек. >> >>  Протестировал на версиях 1.2.7, 1.3.15 >>  Баг? >>  Или есть какие-то соображения для такой работы? > > Во встроенном резолвере не очень хорошо сделана обработка > нескольких записей в одном DNS-ответе, и в частности в > вышеописанном случае, если обе записи приходят вместе - то CNAME > будет "пропущен", и кеш resolver'а попадёт сразу адрес, с ttl > 86400. > > Простой workaround - использовать > >     resolver ... valid=30s; > > См. http://nginx.org/r/resolver. > > Если не лень - было бы полезно нарисовать тикет в trac'е, > http://trac.nginx.org.  Если проблема очень болит и мешает > ходить - приходите на http://nginx.com, договоримся. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Apr 5 05:15:47 2013 From: nginx-forum at nginx.us (heroin) Date: Fri, 05 Apr 2013 01:15:47 -0400 Subject: =?UTF-8?B?bmdpbngg0LTQvtGB0YLRg9C/INC6INGB0YLRgNCw0L3QuNGG0LUg0L/QviDQstGA?= =?UTF-8?B?0LXQvNC10L3QuA==?= Message-ID: <517432c54b01645b4a16001592812055.NginxMailingListRussian@forum.nginx.org> Всем добрый день. Подскажите как ограничить время доступа к странице в nginx ? Есть установленный BigBlueButton, нужно чтобы доступ к созданному вебинару был только в определенное время, а в другое время выдавалась нужная заглушка. В apache я так понимаю это делается модулем mod_rewrite и записью в .htaccess в директории с нужной страницей что то вроде Код: RewriteEngine on RewriteCond %{TIME_HOUR}%{TIME_MIN} > 900 RewriteCond %{TIME_HOUR}%{TIME_MIN} < 1800 RewriteRule .* - [ F ] Как сделать в nginx ? Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238121,238121#msg-238121 From vadim.lazovskiy at gmail.com Fri Apr 5 07:40:16 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Fri, 5 Apr 2013 11:40:16 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: <517432c54b01645b4a16001592812055.NginxMailingListRussian@forum.nginx.org> References: <517432c54b01645b4a16001592812055.NginxMailingListRussian@forum.nginx.org> Message-ID: Здравствуйте. Начиная с версий 1.3.12 и 1.2.7 доступна переменная $time_iso8601 (раньше была только в log_module). Ее можно смапить в флажок доступа: map $time_iso8601 $hour { "~\d{4}-\d{2}-\d{2}T(?\d{2}):" $h; } map $hour $forbidden { 09 0; 10 0; 11 0; 12 0; default 1; } ... server { ... location /webinar/ { error_page 403 /webinar_forbidden.html; if ($forbidden) { return 403; } } Можно обойтись и без промежуточной переменной $hour, забив в регулярное выражение нужные часы. В более старых версиях, imho, только встроенный perl. 5 апреля 2013 г., 9:15 пользователь heroin написал: > Всем добрый день. > > Подскажите как ограничить время доступа к странице в nginx ? > Есть установленный BigBlueButton, нужно чтобы доступ к созданному вебинару > был только в определенное время, а в другое время выдавалась нужная > заглушка. > В apache я так понимаю это делается модулем mod_rewrite и записью в > .htaccess в директории с нужной страницей что то вроде > > Код: > RewriteEngine on > > RewriteCond %{TIME_HOUR}%{TIME_MIN} > 900 > RewriteCond %{TIME_HOUR}%{TIME_MIN} < 1800 > RewriteRule .* - [ F ] > > > Как сделать в nginx ? > > Заранее спасибо. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238121,238121#msg-238121 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncleandyv at gmail.com Fri Apr 5 08:52:30 2013 From: uncleandyv at gmail.com (Andrey Velikoredchanin) Date: Fri, 5 Apr 2013 12:52:30 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: References: <517432c54b01645b4a16001592812055.NginxMailingListRussian@forum.nginx.org> Message-ID: Не обязательно встроенный. Можно скриптом проверять время и делать внутреннее перенаправление на страницу если доступ разрешен. IMHO, самый простой и гибкий вариант. 5 апреля 2013 г., 11:40 пользователь Vadim Lazovskiy < vadim.lazovskiy at gmail.com> написал: > Здравствуйте. > > Начиная с версий 1.3.12 и 1.2.7 доступна переменная $time_iso8601 (раньше > была только в log_module). Ее можно смапить в флажок доступа: > > map $time_iso8601 $hour { > "~\d{4}-\d{2}-\d{2}T(?\d{2}):" $h; > } > > map $hour $forbidden { > 09 0; > 10 0; > 11 0; > 12 0; > default 1; > > } > > ... > server { > ... > location /webinar/ { > error_page 403 /webinar_forbidden.html; > if ($forbidden) { > return 403; > } > } > > Можно обойтись и без промежуточной переменной $hour, забив в регулярное > выражение нужные часы. > В более старых версиях, imho, только встроенный perl. > > > 5 апреля 2013 г., 9:15 пользователь heroin написал: > > Всем добрый день. >> >> Подскажите как ограничить время доступа к странице в nginx ? >> Есть установленный BigBlueButton, нужно чтобы доступ к созданному вебинару >> был только в определенное время, а в другое время выдавалась нужная >> заглушка. >> В apache я так понимаю это делается модулем mod_rewrite и записью в >> .htaccess в директории с нужной страницей что то вроде >> >> Код: >> RewriteEngine on >> >> RewriteCond %{TIME_HOUR}%{TIME_MIN} > 900 >> RewriteCond %{TIME_HOUR}%{TIME_MIN} < 1800 >> RewriteRule .* - [ F ] >> >> >> Как сделать в nginx ? >> >> Заранее спасибо. >> >> Posted at Nginx Forum: >> http://forum.nginx.org/read.php?21,238121,238121#msg-238121 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Best Regards, > Vadim Lazovskiy > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Apr 5 10:15:34 2013 From: nginx-forum at nginx.us (heroin) Date: Fri, 05 Apr 2013 06:15:34 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: References: Message-ID: >Не обязательно встроенный. Можно скриптом проверять время и делать >внутреннее перенаправление на страницу если доступ разрешен. IMHO, самый >простой и гибкий вариант. Можно уточнить как это сделать ? Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238121,238132#msg-238132 From uncleandyv at gmail.com Fri Apr 5 10:28:11 2013 From: uncleandyv at gmail.com (Andrey Velikoredchanin) Date: Fri, 5 Apr 2013 14:28:11 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: References: Message-ID: 5 апреля 2013 г., 14:15 пользователь heroin написал: > >Не обязательно встроенный. Можно скриптом проверять время и делать > >внутреннее перенаправление на страницу если доступ разрешен. IMHO, самый > >простой и гибкий вариант. > > Можно уточнить как это сделать ? > Заранее спасибо. > Типа вот такого: location /files { proxy_pass http://127.0.0.1:8080/ } location /int_files { internal; root_path /var/www/files; } На порту 3000 повесить скрипт, который будет получать запрос, анализировать, имеет-ли право данный юзер на данный запрос в данное время и если имеет - выдавать в ответ заголовок с X-Accel-Redirect на путь "/int_files/..." на нужный файл. Если прав нет, можно выдавать, например, статус 404 или перенаправить внешним редиректом на страницу с объяснением что типа "Время вышло". Для пользователя все это будет прозрачно и незаметно, т.к. перенаправление внутреннее. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Apr 5 10:31:08 2013 From: nginx-forum at nginx.us (heroin) Date: Fri, 05 Apr 2013 06:31:08 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: References: Message-ID: Спасибо, обновил nginx данный способ работает. А можно узнать как еще в map дни недели подсунуть ? Заранее спасибо. Vadim Lazovskiy Wrote: ------------------------------------------------------- > Здравствуйте. > > Начиная с версий 1.3.12 и 1.2.7 доступна переменная $time_iso8601 > (раньше > была только в log_module). Ее можно смапить в флажок доступа: > > map $time_iso8601 $hour { > "~\d{4}-\d{2}-\d{2}T(?\d{2}):" $h; > } > > map $hour $forbidden { > 09 0; > 10 0; > 11 0; > 12 0; > default 1; > > } > > ... > server { > ... > location /webinar/ { > error_page 403 /webinar_forbidden.html; > if ($forbidden) { > return 403; > } > } > > Можно обойтись и без промежуточной переменной $hour, забив в > регулярное > выражение нужные часы. > В более старых версиях, imho, только встроенный perl. > > > 5 апреля 2013 г., 9:15 пользователь heroin > написал: > > > Всем добрый день. > > > > Подскажите как ограничить время доступа к странице в nginx ? > > Есть установленный BigBlueButton, нужно чтобы доступ к созданному > вебинару > > был только в определенное время, а в другое время выдавалась нужная > > заглушка. > > В apache я так понимаю это делается модулем mod_rewrite и записью в > > .htaccess в директории с нужной страницей что то вроде > > > > Код: > > RewriteEngine on > > > > RewriteCond %{TIME_HOUR}%{TIME_MIN} > 900 > > RewriteCond %{TIME_HOUR}%{TIME_MIN} < 1800 > > RewriteRule .* - [ F ] > > > > > > Как сделать в nginx ? > > > > Заранее спасибо. > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?21,238121,238121#msg-238121 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Best Regards, > Vadim Lazovskiy > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238121,238135#msg-238135 From vadim.lazovskiy at gmail.com Fri Apr 5 10:57:04 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Fri, 5 Apr 2013 14:57:04 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: References: Message-ID: День недели с мапом - никак. На перле что-то примерно такое: http { perl_set $forbidden 'sub { ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); if($wday > 0 && $wday < 6 && $hour > 9 && $hour < 18) { return 0; } return 1; }'; server { location ... { ... if ($forbidden) { ... } } } } 5 апреля 2013 г., 14:31 пользователь heroin написал: > Спасибо, обновил nginx данный способ работает. > А можно узнать как еще в map дни недели подсунуть ? > Заранее спасибо. > > Vadim Lazovskiy Wrote: > ------------------------------------------------------- > > Здравствуйте. > > > > Начиная с версий 1.3.12 и 1.2.7 доступна переменная $time_iso8601 > > (раньше > > была только в log_module). Ее можно смапить в флажок доступа: > > > > map $time_iso8601 $hour { > > "~\d{4}-\d{2}-\d{2}T(?\d{2}):" $h; > > } > > > > map $hour $forbidden { > > 09 0; > > 10 0; > > 11 0; > > 12 0; > > default 1; > > > > } > > > > ... > > server { > > ... > > location /webinar/ { > > error_page 403 /webinar_forbidden.html; > > if ($forbidden) { > > return 403; > > } > > } > > > > Можно обойтись и без промежуточной переменной $hour, забив в > > регулярное > > выражение нужные часы. > > В более старых версиях, imho, только встроенный perl. > > > > > > 5 апреля 2013 г., 9:15 пользователь heroin > > написал: > > > > > Всем добрый день. > > > > > > Подскажите как ограничить время доступа к странице в nginx ? > > > Есть установленный BigBlueButton, нужно чтобы доступ к созданному > > вебинару > > > был только в определенное время, а в другое время выдавалась нужная > > > заглушка. > > > В apache я так понимаю это делается модулем mod_rewrite и записью в > > > .htaccess в директории с нужной страницей что то вроде > > > > > > Код: > > > RewriteEngine on > > > > > > RewriteCond %{TIME_HOUR}%{TIME_MIN} > 900 > > > RewriteCond %{TIME_HOUR}%{TIME_MIN} < 1800 > > > RewriteRule .* - [ F ] > > > > > > > > > Как сделать в nginx ? > > > > > > Заранее спасибо. > > > > > > Posted at Nginx Forum: > > > http://forum.nginx.org/read.php?21,238121,238121#msg-238121 > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > -- > > Best Regards, > > Vadim Lazovskiy > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238121,238135#msg-238135 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Apr 5 11:18:09 2013 From: nginx-forum at nginx.us (heroin) Date: Fri, 05 Apr 2013 07:18:09 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: References: Message-ID: <160003470a3d052791a905b13fe78c43.NginxMailingListRussian@forum.nginx.org> Спасибо за ответы. Подскажите, если nginx -V не выводит в списке ключей --with-http_perl_module, то перл работать не будет ? Я прошу прощения за такие вопросы, на nginx смотрю второй день, а задача стоит приоритетная. Еще раз всем спасибо. Vadim Lazovskiy Wrote: ------------------------------------------------------- > День недели с мапом - никак. На перле что-то примерно такое: > > http { > > perl_set $forbidden 'sub { > ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) > = > localtime(time); > > if($wday > 0 && $wday < 6 && $hour > 9 && $hour < 18) > { > return 0; > } > > return 1; > }'; > > server { > location ... { > ... > if ($forbidden) { > ... > } > } > } > } > > > 5 апреля 2013 г., 14:31 пользователь heroin > написал: > > > Спасибо, обновил nginx данный способ работает. > > А можно узнать как еще в map дни недели подсунуть ? > > Заранее спасибо. > > > > Vadim Lazovskiy Wrote: > > ------------------------------------------------------- > > > Здравствуйте. > > > > > > Начиная с версий 1.3.12 и 1.2.7 доступна переменная $time_iso8601 > > > (раньше > > > была только в log_module). Ее можно смапить в флажок доступа: > > > > > > map $time_iso8601 $hour { > > > "~\d{4}-\d{2}-\d{2}T(?\d{2}):" $h; > > > } > > > > > > map $hour $forbidden { > > > 09 0; > > > 10 0; > > > 11 0; > > > 12 0; > > > default 1; > > > > > > } > > > > > > ... > > > server { > > > ... > > > location /webinar/ { > > > error_page 403 /webinar_forbidden.html; > > > if ($forbidden) { > > > return 403; > > > } > > > } > > > > > > Можно обойтись и без промежуточной переменной $hour, забив в > > > регулярное > > > выражение нужные часы. > > > В более старых версиях, imho, только встроенный perl. > > > > > > > > > 5 апреля 2013 г., 9:15 пользователь heroin > > > написал: > > > > > > > Всем добрый день. > > > > > > > > Подскажите как ограничить время доступа к странице в nginx ? > > > > Есть установленный BigBlueButton, нужно чтобы доступ к > созданному > > > вебинару > > > > был только в определенное время, а в другое время выдавалась > нужная > > > > заглушка. > > > > В apache я так понимаю это делается модулем mod_rewrite и > записью в > > > > .htaccess в директории с нужной страницей что то вроде > > > > > > > > Код: > > > > RewriteEngine on > > > > > > > > RewriteCond %{TIME_HOUR}%{TIME_MIN} > 900 > > > > RewriteCond %{TIME_HOUR}%{TIME_MIN} < 1800 > > > > RewriteRule .* - [ F ] > > > > > > > > > > > > Как сделать в nginx ? > > > > > > > > Заранее спасибо. > > > > > > > > Posted at Nginx Forum: > > > > http://forum.nginx.org/read.php?21,238121,238121#msg-238121 > > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > > > > -- > > > Best Regards, > > > Vadim Lazovskiy > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?21,238121,238135#msg-238135 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > -- > Best Regards, > Vadim Lazovskiy > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238121,238138#msg-238138 From vadim.lazovskiy at gmail.com Fri Apr 5 11:20:29 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Fri, 5 Apr 2013 15:20:29 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC00L7RgdGC0YPQvyDQuiDRgdGC0YDQsNC90LjRhtC1INC/0L4g?= =?UTF-8?B?0LLRgNC10LzQtdC90Lg=?= In-Reply-To: <160003470a3d052791a905b13fe78c43.NginxMailingListRussian@forum.nginx.org> References: <160003470a3d052791a905b13fe78c43.NginxMailingListRussian@forum.nginx.org> Message-ID: Не будет. 5 апреля 2013 г., 15:18 пользователь heroin написал: > Спасибо за ответы. > > Подскажите, если nginx -V не выводит в списке ключей > --with-http_perl_module, то перл работать не будет ? > > Я прошу прощения за такие вопросы, на nginx смотрю второй день, а задача > стоит приоритетная. > Еще раз всем спасибо. > > Vadim Lazovskiy Wrote: > ------------------------------------------------------- > > День недели с мапом - никак. На перле что-то примерно такое: > > > > http { > > > > perl_set $forbidden 'sub { > > ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) > > = > > localtime(time); > > > > if($wday > 0 && $wday < 6 && $hour > 9 && $hour < 18) > > { > > return 0; > > } > > > > return 1; > > }'; > > > > server { > > location ... { > > ... > > if ($forbidden) { > > ... > > } > > } > > } > > } > > > > > > 5 апреля 2013 г., 14:31 пользователь heroin > > написал: > > > > > Спасибо, обновил nginx данный способ работает. > > > А можно узнать как еще в map дни недели подсунуть ? > > > Заранее спасибо. > > > > > > Vadim Lazovskiy Wrote: > > > ------------------------------------------------------- > > > > Здравствуйте. > > > > > > > > Начиная с версий 1.3.12 и 1.2.7 доступна переменная $time_iso8601 > > > > (раньше > > > > была только в log_module). Ее можно смапить в флажок доступа: > > > > > > > > map $time_iso8601 $hour { > > > > "~\d{4}-\d{2}-\d{2}T(?\d{2}):" $h; > > > > } > > > > > > > > map $hour $forbidden { > > > > 09 0; > > > > 10 0; > > > > 11 0; > > > > 12 0; > > > > default 1; > > > > > > > > } > > > > > > > > ... > > > > server { > > > > ... > > > > location /webinar/ { > > > > error_page 403 /webinar_forbidden.html; > > > > if ($forbidden) { > > > > return 403; > > > > } > > > > } > > > > > > > > Можно обойтись и без промежуточной переменной $hour, забив в > > > > регулярное > > > > выражение нужные часы. > > > > В более старых версиях, imho, только встроенный perl. > > > > > > > > > > > > 5 апреля 2013 г., 9:15 пользователь heroin > > > > написал: > > > > > > > > > Всем добрый день. > > > > > > > > > > Подскажите как ограничить время доступа к странице в nginx ? > > > > > Есть установленный BigBlueButton, нужно чтобы доступ к > > созданному > > > > вебинару > > > > > был только в определенное время, а в другое время выдавалась > > нужная > > > > > заглушка. > > > > > В apache я так понимаю это делается модулем mod_rewrite и > > записью в > > > > > .htaccess в директории с нужной страницей что то вроде > > > > > > > > > > Код: > > > > > RewriteEngine on > > > > > > > > > > RewriteCond %{TIME_HOUR}%{TIME_MIN} > 900 > > > > > RewriteCond %{TIME_HOUR}%{TIME_MIN} < 1800 > > > > > RewriteRule .* - [ F ] > > > > > > > > > > > > > > > Как сделать в nginx ? > > > > > > > > > > Заранее спасибо. > > > > > > > > > > Posted at Nginx Forum: > > > > > http://forum.nginx.org/read.php?21,238121,238121#msg-238121 > > > > > > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > > > > > > > > > -- > > > > Best Regards, > > > > Vadim Lazovskiy > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > Posted at Nginx Forum: > > > http://forum.nginx.org/read.php?21,238121,238135#msg-238135 > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > -- > > Best Regards, > > Vadim Lazovskiy > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238121,238138#msg-238138 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Apr 6 12:53:15 2013 From: nginx-forum at nginx.us (lokoArt90) Date: Sat, 06 Apr 2013 08:53:15 -0400 Subject: ngx_slab_alloc() failed: no memory Message-ID: Всем привет. Я пишу модуль, там мне нужно использовать shared_memory. Так вот, в методе init при попытке выделить память при помощи ngx_slab_alloc происходит crash. Пишет failed: no memory. Мне нужно что-то поправить в конфиге nginx, или это мой модуль не так память выделяет? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238161,238161#msg-238161 From nginx-forum at nginx.us Mon Apr 8 05:28:38 2013 From: nginx-forum at nginx.us (lokoArt90) Date: Mon, 08 Apr 2013 01:28:38 -0400 Subject: ngx_slab_alloc() failed: no memory In-Reply-To: References: Message-ID: <11fc7f975632c13ed5359eb1afa5b403.NginxMailingListRussian@forum.nginx.org> Ошибка исчезла после того, как размер при ngx_shared_memory add я увеличил до размера страницы. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238161,238191#msg-238191 From nginx-forum at nginx.us Mon Apr 8 11:52:42 2013 From: nginx-forum at nginx.us (Namaste) Date: Mon, 08 Apr 2013 07:52:42 -0400 Subject: fastcgi_cache_use_stale Message-ID: <2956d2a15f34bba25a3f1d08cf286197.NginxMailingListRussian@forum.nginx.org> Привет! на wiki.nginx.org есть пример использования fastcgi_cache_use_stale с такими параметрами: fastcgi_cache_use_stale error timeout invalid_header http_500; в доках nginx вижу: синтаксис: fastcgi_cache_use_stale error | timeout | invalid_header | updating | http_500 | http_503 | http_404 | off ...; т.е. тут в добавок к http_500 есть еще http_503.. У меня настройки из примера из вики: fastcgi_cache_use_stale error timeout invalid_header http_500; При этом, если скрипт выдает 503, то ответ выдается из кэша. Почему так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238194,238194#msg-238194 From alp at sfedu.ru Mon Apr 8 12:27:50 2013 From: alp at sfedu.ru (Alexander Pyhalov) Date: Mon, 08 Apr 2013 16:27:50 +0400 Subject: =?UTF-8?B?0JDQstGC0L7RgNC40LfQsNGG0LjRjyDQuCDQsNGD0YLQtdC90YLQuNGE0LjQutCw?= =?UTF-8?B?0YbQuNGPINCyIG5naW54?= Message-ID: <5162B7C6.1060209@sfedu.ru> Здравствуйте. У меня возник следующий вопрос. Под Apache можно разделить стадии авторизации и аутентификации и таким образом реализовать, например, следующую схему: 1) аутентификацию проводит mod_auth_krb5 (через GSSAPI или c fallback'ом в Basic Auth) 2) авторизацию доступа выполняет mod_auth_ldap Для nginx удалось найти и допилить до рабочего состояния модуль аутентификации для kerberos и модуль аутентификации для ldap. Но есть ли возможность заставить их работать вместе? Чтобы пароль проверял mod_auth_krb5 и дополнительно mod_auth_ldap проверял членство в группах? Я понимаю, что, в принципе, можно возложить и то, и другое на mod_auth_ldap, но не хотелось бы отказываться от GSSAPI. -- С уважением, Александр Пыхалов, системный администратор ЮГИНФО ЮФУ. From sakutylev at mitht.ru Mon Apr 8 15:52:04 2013 From: sakutylev at mitht.ru (=?KOI8-R?B?69XU2czF1ywg88XSx8XK?=) Date: Mon, 8 Apr 2013 19:52:04 +0400 Subject: =?UTF-8?B?0JDQstGC0L7RgNC40LfQsNGG0LjRjyBjb29raWU=?= Message-ID: Привет всем, несколько недель мучаюсь с тем как организовать авторизацию на сайте, есть nginx/1.2.8 на нем крутится сайт на старой доброй джумле. вот части конфига виртуалхоста ... server { listen 127.0.0.6:80; server_name bla.net www.bla.net; if ( $host = 'bla.net' ) { rewrite ^/(.*)$ http://www.bla.net/$1 permanent; } charset utf-8; access_log /usr/home/www-data/blanet/public_html/access_log main; error_log /usr/home/www-data/blanet/public_html/error_log error; satisfy any; ###access from lan bla company### allow 172.16.0.0/16; ###end access from lan bla company### deny all; auth_basic "Access denied, please login!"; auth_basic_user_file /home/www-data/blanet/conf/htpasswd; location / { ... } раньше была авторизация как видно двумя путями, или ты находишься в локалке компании и без вопросов заходишь на сайт, если из вне заходишьто выскакивает авторизация сервера и после успешного логина сервер пускает тебя на сайт. сейчас хотелось бы задействовать авторизацию через почту в домене @bla.netхостящуюся на Google App's, т.е. такая схема случай первый: человек заходит из локалки на сайт и все по старому, его пускают по айпи адрессу случай второй: человек заходит из вне у него проверяется как-нибудь наличие cookie авторизации в gmail и передается серверу, если человек авторизован в gmail то его пускает на сайт, если нет то предлагает авторизоваться в gmail. Возможно ли это сделать средствами nginx? если да, то в какую сторону копать? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Apr 9 06:59:50 2013 From: nginx-forum at nginx.us (lokoArt90) Date: Tue, 09 Apr 2013 02:59:50 -0400 Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDICLRgdC/0LjRgiIgd29ya2VyINC00L4g0L/QtdGA0LLQvtCz?= =?UTF-8?B?0L4g0LfQsNC/0YDQvtGB0LA/?= Message-ID: Добрый день. Ситуация такая. Если в http модуле создать поток(при помощи pthread_create), и в функции обработки этого потока, поставить цикл и sleep. Т.е. примерно так: while(1) { if(время пришло) { вызвать function1(); } sleep(5); } То вот function1() вызовется после первого реквеста. Но вызовется он после первого реквеста только у первого worker'а, а у остальных она будет вызываться стабильно. Т.е. если 4 воркера, то у последних трех функция будет вызываться, а у первого нет, до первого запроса. Такое ощущение что спит процесс(???). 1 )Почему так? 2) Получается воркеры различаются? И работают не совсем одинаково? С nginx я совсем новичок. Так что если этот вопрос глуп не сердитесь. Спасибо. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238217,238217#msg-238217 From anatoly at sonru.com Tue Apr 9 12:37:07 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 13:37:07 +0100 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> Message-ID: <1F03C148-EFAA-4BB0-BE10-271437408C50@sonru.com> On Apr 4, 2013, at 1:01 PM, Daniel Podolsky wrote: >> пока нашел вариант с X-Accel-Redirect (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) > X-Accel-Redirect вам нужен, если вы хотите отдать локальный файл, но > проверить право доступа к нему на бекенде. С S3 это не так, насколько > мне известно. я не зря предоставил ссылку на блог пост, прочтите его еще раз. S3 - обычная файловая помойка со своим API для доступа к public/private файлам > >> вопрос - использует ли кто данный подход и как правильно организовать прозрачное проксирование? > nginx - это продукт для реверсного, а не для прозрачного > проксирования. Вы уверены, что правильно ставите задачу? с точки зрения клиента эти термины равнозначные, для меня важно организовать отдачу файлов с нашего субдомена, CNAME для S3 корзины подходит до тех пор, пока у вас нет HTTPS Анатолий > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From uncleandyv at gmail.com Tue Apr 9 12:39:29 2013 From: uncleandyv at gmail.com (Andrey Velikoredchanin) Date: Tue, 9 Apr 2013 16:39:29 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: <1F03C148-EFAA-4BB0-BE10-271437408C50@sonru.com> References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> <1F03C148-EFAA-4BB0-BE10-271437408C50@sonru.com> Message-ID: А в чем проблема? Задача довольно тривиальная. 9 апреля 2013 г., 16:37 пользователь Anatoly Mikhailov написал: > > On Apr 4, 2013, at 1:01 PM, Daniel Podolsky wrote: > > >> пока нашел вариант с X-Accel-Redirect ( > http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) > > X-Accel-Redirect вам нужен, если вы хотите отдать локальный файл, но > > проверить право доступа к нему на бекенде. С S3 это не так, насколько > > мне известно. > > я не зря предоставил ссылку на блог пост, прочтите его еще раз. > S3 - обычная файловая помойка со своим API для доступа к public/private > файлам > > > > >> вопрос - использует ли кто данный подход и как правильно организовать > прозрачное проксирование? > > nginx - это продукт для реверсного, а не для прозрачного > > проксирования. Вы уверены, что правильно ставите задачу? > > с точки зрения клиента эти термины равнозначные, для меня важно > организовать > отдачу файлов с нашего субдомена, CNAME для S3 корзины подходит до тех пор, > пока у вас нет HTTPS > > Анатолий > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Tue Apr 9 12:45:17 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 13:45:17 +0100 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: <515D6E51.5060100@webmaster.spb.ru> References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> <515D6E51.5060100@webmaster.spb.ru> Message-ID: <3922388F-F40D-49F5-9CDA-E91C164A9FAD@sonru.com> On Apr 4, 2013, at 1:13 PM, denis wrote: > 04.04.2013 15:04, Anatoly Mikhailov пишет: >> Добрый день, >> >> появилась бизнес-задача организовать контролируемую доставку файлов >> с S3, разумеется, nginx будет заниматься проверкой условий и отдавать >> файл при их соблюдении. Заодно у нас появится возможность использовать >> SPDY для файлов с S3. >> >> пока нашел вариант с X-Accel-Redirect (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) >> с отключенным proxy_max_temp_file_size и proxy_hide_header Content-Disposition. >> >> вопрос - использует ли кто данный подход и как правильно организовать прозрачное проксирование? > А какой смысл? У меня есть в планах чуть другая система: запрошенный файл качаем с S3, кладём локально и в дальнейшем он будет отдаваться только локально. Но нужно такое чуть для другого: если у нас произошел полный отказ сервера, разворачиваем ядро сайта на новом месте + конфиги, и система сама будет качать нужные файлы из резервного хранилища, а остатки потом докачать в фоне с минимальным приоритетом. > > У вас получается, что файл будет каждый раз закачиваться с S3 на машину и отдаваться, то есть трафик до амазона, трафик до юзера, нагрузка на сервер даже больше, лаг отдачи (для файлов более 1мб может быть очень заметно). Лучше тогда запустить инстанс в амазоне, который будет этот файл читать почти как локальный, и уже напрямую отдавать (на поддомене может висеть). Плюс там же можно отдавать через безопасные линки. Смысл следующий, S3 - это не standalone сервер, а нормальное высокодоступное и отказоустойчивое распределенное файловое хранилище, поэтому мы используем его по назначению без лишних абстракций, сейчас задача - скрыть URL как это делает CNAME, но у нас HTTPS, поэтому CNAME отдается с невалидным сертификатом, что само по себе очевидно. У вас хорошая идея, но в нашем случае кэширование - это не та задача, которую мы решаем, у нас данные, что называется горячие, поэтому cache hit rate будет невысоким, а overhead лишним, так как придется очищать локальный кэш. Насколько мне известно, входящий и/или (надо уточнить про и/или) исходящий трафик внутри AWS бесплатный, и сервера у нас в тех же зонах, что и S3 корзины, поэтому я не вижу проблем со скоростью доступа к файлам, мы даже уберем буфер, чтобы отдавать напрямую Анатолий > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Tue Apr 9 12:46:14 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 13:46:14 +0100 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> <1F03C148-EFAA-4BB0-BE10-271437408C50@sonru.com> Message-ID: <277C6D2F-46CD-4866-A269-1D9FC29EC389@sonru.com> On Apr 9, 2013, at 1:39 PM, Andrey Velikoredchanin wrote: > А в чем проблема? Задача довольно тривиальная. не знаю что вам ответить, наверное ничего. > > > 9 апреля 2013 г., 16:37 пользователь Anatoly Mikhailov написал: > > On Apr 4, 2013, at 1:01 PM, Daniel Podolsky wrote: > > >> пока нашел вариант с X-Accel-Redirect (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) > > X-Accel-Redirect вам нужен, если вы хотите отдать локальный файл, но > > проверить право доступа к нему на бекенде. С S3 это не так, насколько > > мне известно. > > я не зря предоставил ссылку на блог пост, прочтите его еще раз. > S3 - обычная файловая помойка со своим API для доступа к public/private файлам > > > > >> вопрос - использует ли кто данный подход и как правильно организовать прозрачное проксирование? > > nginx - это продукт для реверсного, а не для прозрачного > > проксирования. Вы уверены, что правильно ставите задачу? > > с точки зрения клиента эти термины равнозначные, для меня важно организовать > отдачу файлов с нашего субдомена, CNAME для S3 корзины подходит до тех пор, > пока у вас нет HTTPS > > Анатолий > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Tue Apr 9 12:48:13 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 9 Apr 2013 16:48:13 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: <1F03C148-EFAA-4BB0-BE10-271437408C50@sonru.com> References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> <1F03C148-EFAA-4BB0-BE10-271437408C50@sonru.com> Message-ID: > я не зря предоставил ссылку на блог пост, прочтите его еще раз. Больно Вас разочаровывать, но - совершенно зря предоставили, никто по ней не пойдет. > S3 - обычная файловая помойка со своим API для доступа к public/private файлам Именно! А имеет ли X-Accel-Redirect отношение к этому API - вы не выясняли? >> nginx - это продукт для реверсного, а не для прозрачного > с точки зрения клиента эти термины равнозначные, для меня важно организовать ни с какой точки зрения они не равнозначные, точно Вам говорю. From anatoly at sonru.com Tue Apr 9 13:10:16 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 14:10:16 +0100 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: References: <448E6FCD-65FA-40FE-AEF4-3E1AA3BC1507@sonru.com> <1F03C148-EFAA-4BB0-BE10-271437408C50@sonru.com> Message-ID: <5BB09B77-64FA-4530-9677-2C6662B7ABEA@sonru.com> On Apr 9, 2013, at 1:48 PM, Daniel Podolsky wrote: >> я не зря предоставил ссылку на блог пост, прочтите его еще раз. > Больно Вас разочаровывать, но - совершенно зря предоставили, никто по > ней не пойдет. > >> S3 - обычная файловая помойка со своим API для доступа к public/private файлам > Именно! А имеет ли X-Accel-Redirect отношение к этому API - вы не выясняли? > >>> nginx - это продукт для реверсного, а не для прозрачного >> с точки зрения клиента эти термины равнозначные, для меня важно организовать > ни с какой точки зрения они не равнозначные, точно Вам говорю. берегите свое и чужое время, отвечайте по теме, либо не отвечайте вовсе > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From motienko at gmail.com Tue Apr 9 14:10:13 2013 From: motienko at gmail.com (Oleg Motienko) Date: Tue, 9 Apr 2013 18:10:13 +0400 Subject: =?UTF-8?B?0L7Qs9GA0LDQvdC40YfQtdC90LjRjyDQv9C+INC60L7Qu9C40YfQtdGB0YLQstGD?= =?UTF-8?B?INC30LDQv9C40YHQtdC5INCyIG1hcA==?= Message-ID: Добрый день. Существуют ли ограничения по количеству записей в map ? Требуется поместить в map список соответствия hostname/url внутреннему идентификатору и передавать идентификатор на backend в заголовках. Количество в 20-30 тыс записей не будет проблемой? -- Regards, Oleg From nginx-forum at nginx.us Tue Apr 9 14:20:05 2013 From: nginx-forum at nginx.us (misha_shar53) Date: Tue, 09 Apr 2013 10:20:05 -0400 Subject: =?UTF-8?B?0LfQsNC/0YPRgdC6IE5naW54INC+0YIg0LjQvNC10L3QuCDQvdC10L/RgNC40LI=?= =?UTF-8?B?0LjQu9C40LPQuNGA0L7QstCw0L3QvdC+0LPQviDQv9C+0LvRjNC30L7QstCw?= =?UTF-8?B?0YLQtdC70Y8=?= Message-ID: Подскажите пожалуйста как запустить nginx от имени непривилигированного пользователя. OS SUSE 12.3 из репозитариея загрузил nginx и установил его. В каталоге /etc/init.d есть программа запуск nginx ее можно запустить от имени root, но от имени обычного пользователя она не запускается. Из терминала с помощью команды sudo /etc/init/d/nginx start nginx запускается. Но мне надо запускать с рабочего стола. создал на рабочем столе файл nginxStart #! /bin/sh sudo /etc/init/d/nginx start И пытаюсь его запустить щелкая на нем но ничего не происходит. Я подозреваю что делаю что то не так. Но очень не силен в Linux. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238230,238230#msg-238230 From denis at webmaster.spb.ru Tue Apr 9 14:33:39 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 09 Apr 2013 18:33:39 +0400 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YHQuiBOZ2lueCDQvtGCINC40LzQtdC90Lgg0L3QtdC/0YA=?= =?UTF-8?B?0LjQstC40LvQuNCz0LjRgNC+0LLQsNC90L3QvtCz0L4g0L/QvtC70YzQt9C+?= =?UTF-8?B?0LLQsNGC0LXQu9GP?= In-Reply-To: References: Message-ID: <516426C3.4090706@webmaster.spb.ru> 09.04.2013 18:20, misha_shar53 пишет: > #! /bin/sh > sudo /etc/init/d/nginx start > > И пытаюсь его запустить щелкая на нем но ничего не происходит. > Я подозреваю что делаю что то не так. > Но очень не силен в Linux. /init/d/ - точно не запустится, там ошибка ) А вообще в конфиг user www www например, и от рута будет только мастер-процесс, который открывает порты и сокеты и управляет воркерами. И читать документацию о том, как включать сервисы. From citrin at citrin.ru Tue Apr 9 14:37:06 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 09 Apr 2013 18:37:06 +0400 Subject: =?UTF-8?B?UmU6INC+0LPRgNCw0L3QuNGH0LXQvdC40Y8g0L/QviDQutC+0LvQuNGH0LXRgdGC?= =?UTF-8?B?0LLRgyDQt9Cw0L/QuNGB0LXQuSDQsiBtYXA=?= In-Reply-To: References: Message-ID: <51642792.7070307@citrin.ru> On 04/09/13 18:10, Oleg Motienko wrote: > Существуют ли ограничения по количеству записей в map ? > > Требуется поместить в map список соответствия hostname/url внутреннему > идентификатору и передавать идентификатор на backend в заголовках. > > Количество в 20-30 тыс записей не будет проблемой? 20-30 тыс записей это не много, но может на этапе конфигураци выдать ошибку, тогда нужно будет увеличить map_hash_max_size (и в некоторых случаях map_hash_bucket_size) подробнее см. в http://nginx.org/ru/docs/hash.html From nginx-forum at nginx.us Tue Apr 9 14:49:28 2013 From: nginx-forum at nginx.us (misha_shar53) Date: Tue, 09 Apr 2013 10:49:28 -0400 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YHQuiBOZ2lueCDQvtGCINC40LzQtdC90Lgg0L3QtdC/0YA=?= =?UTF-8?B?0LjQstC40LvQuNCz0LjRgNC+0LLQsNC90L3QvtCz0L4g0L/QvtC70YzQt9C+?= =?UTF-8?B?0LLQsNGC0LXQu9GP?= In-Reply-To: <516426C3.4090706@webmaster.spb.ru> References: <516426C3.4090706@webmaster.spb.ru> Message-ID: <0ce1a09cbc0cdca453a2036984378fed.NginxMailingListRussian@forum.nginx.org> Да ошибка в сообщении. команда выглядит по другому sudo /etc/init.d/nginx start Но суть понятна. Надо запускать сервис. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238230,238233#msg-238233 From anatoly at sonru.com Tue Apr 9 15:57:43 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 16:57:43 +0100 Subject: ngx_http_auth_request_module Message-ID: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, как nginx начнет сохранять BODY запроса на диск. Basic Authentication подходит в целом, но в данном случае мне необходимо проверять API_KEY через backend. Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, какие еще варианты решения данной задачи? Анатолий From anatoly at sonru.com Tue Apr 9 16:09:18 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 17:09:18 +0100 Subject: load balancer backend failed condition In-Reply-To: References: <20130328092224.GB65443@lo0.su> Message-ID: <03706AFF-B9C4-4333-8FBD-3E01F03AE720@sonru.com> On Mar 28, 2013, at 9:53 AM, tolikkk wrote: > За proxy_next_upstream спасибо. > > По изменению метода проверки доступности backend'ов нештатными средствами - > подходящих сторонних модулей не знаете случайных? Единственное, что я пока > смог придумать - это поставить в cron скрипт, который будет через curl или > wget отправлять нужные запросы на backend'ы и если получен ответ, отличный > от ожидаемого, то менять конф. файл nginx (добавлять атрибут down > проблемному серверу) и перезапускать процесс nginx. Но это, честно говоря, > кривизна какая-то. Неужели, у меня первого возникла такая задача? > динамическая проверка бэкэндов *своим способом* и перезагрузка конфигурации в зависимости от результата проверки - это интересная нетиповая задача, иначе она была бы решена давным давно. Как раз давным давно ее пытались решить с помощью ZeroMQ: https://github.com/igrigorik/zeroconf-router Но проект был запрошен и не поддерживается. Кстати, что у вас на backend? > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237866,237875#msg-237875 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue Apr 9 16:25:21 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 9 Apr 2013 20:25:21 +0400 Subject: ngx_http_auth_request_module In-Reply-To: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> Message-ID: <20130409162520.GD62550@mdounin.ru> Hello! On Tue, Apr 09, 2013 at 04:57:43PM +0100, Anatoly Mikhailov wrote: > Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only > мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, > как nginx начнет сохранять BODY запроса на диск. > > Basic Authentication подходит в целом, но в данном случае мне необходимо проверять > API_KEY через backend. > > Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, > какие еще варианты решения данной задачи? А что там обновлять? Он работает. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Apr 9 17:12:11 2013 From: nginx-forum at nginx.us (ast) Date: Tue, 09 Apr 2013 13:12:11 -0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtC30YDQsNGH0L3QvtC1INC/0YDQvtC60YHQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjQtSDRgSBBV1MgUzM=?= In-Reply-To: <3922388F-F40D-49F5-9CDA-E91C164A9FAD@sonru.com> References: <3922388F-F40D-49F5-9CDA-E91C164A9FAD@sonru.com> Message-ID: location @s3 { expires max; proxy_pass https://n.s3-us-west-2.amazonaws.com; proxy_set_header Host "n.s3-us-west-2.amazonaws.com"; proxy_set_header Authorization ""; proxy_hide_header X-Amz-Id-2; proxy_hide_header x-amz-request-id; add_header Last-Modified ""; proxy_hide_header ETag; proxy_redirect off; } ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238096,238237#msg-238237 From vas at mpeks.tomsk.su Tue Apr 9 18:23:54 2013 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Wed, 10 Apr 2013 01:23:54 +0700 Subject: =?UTF-8?B?0LLQtdCxLdC60LDQvNC10YDQsA==?= Message-ID: <20130409182354.GA34064@admin.sibptus.tomsk.ru> Коллеги, Не решал ли кто задачу кэширования видео с вебкамеры, например типа D-Link DCS-2130? Чтобы нагрузка от многих пользователей приходилась на веб-сервер (прокси), а не на собственно камеру. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From anatoly at sonru.com Tue Apr 9 18:53:50 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 19:53:50 +0100 Subject: ngx_http_auth_request_module In-Reply-To: <20130409162520.GD62550@mdounin.ru> References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> Message-ID: <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> On Apr 9, 2013, at 5:25 PM, Maxim Dounin wrote: > Hello! > > On Tue, Apr 09, 2013 at 04:57:43PM +0100, Anatoly Mikhailov wrote: > >> Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only >> мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, >> как nginx начнет сохранять BODY запроса на диск. >> >> Basic Authentication подходит в целом, но в данном случае мне необходимо проверять >> API_KEY через backend. >> >> Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, >> какие еще варианты решения данной задачи? > > А что там обновлять? Он работает. смотрю документацию и не совсем понимаю как это работает http://mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README обязательно ли делать отдельный location для auth_request? с таким конфигом бэкэнд повисает и не отдает отдает ответ обратно, хотя при прямом обращении на /authentication/check ответ приходит, код 200 upstream unicorn_api { server unix:/tmp/unicorn.sock fail_timeout=0; } location =/upload { auth_request /authentication/check; limit_except POST { deny all; } proxy_redirect off; proxy_pass http://unicorn_api/attachments; } location =/authentication/check { proxy_pass http://unicorn_api/authentication/check; # одноименный локэйшн на бэкэнде proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; } Анатолий > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Tue Apr 9 18:57:00 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 19:57:00 +0100 Subject: ngx_http_auth_request_module In-Reply-To: <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> Message-ID: <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> On Apr 9, 2013, at 7:53 PM, Anatoly Mikhailov wrote: > > On Apr 9, 2013, at 5:25 PM, Maxim Dounin wrote: > >> Hello! >> >> On Tue, Apr 09, 2013 at 04:57:43PM +0100, Anatoly Mikhailov wrote: >> >>> Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only >>> мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, >>> как nginx начнет сохранять BODY запроса на диск. >>> >>> Basic Authentication подходит в целом, но в данном случае мне необходимо проверять >>> API_KEY через backend. >>> >>> Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, >>> какие еще варианты решения данной задачи? >> >> А что там обновлять? Он работает. > > смотрю документацию и не совсем понимаю как это работает > http://mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README > обязательно ли делать отдельный location для auth_request? > > с таким конфигом бэкэнд повисает и не отдает отдает ответ обратно, > хотя при прямом обращении на /authentication/check ответ приходит, код 200 > > upstream unicorn_api { > server unix:/tmp/unicorn.sock fail_timeout=0; > } > > location =/upload { > auth_request /authentication/check; > limit_except POST { deny all; } > proxy_redirect off; > proxy_pass http://unicorn_api/attachments; > } > > > location =/authentication/check { > proxy_pass http://unicorn_api/authentication/check; # одноименный локэйшн на бэкэнде > proxy_pass_request_body off; > proxy_set_header Content-Length ""; > proxy_set_header X-Original-URI $request_uri; > } > подвисает это я глупо написал, вот такое исключение на бэкэнде вылетает: EOFError (bad content body) > > Анатолий > >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Tue Apr 9 19:30:17 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 9 Apr 2013 20:30:17 +0100 Subject: ngx_http_auth_request_module In-Reply-To: <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> Message-ID: <53E5E89E-628A-47EF-A033-43732228EFE6@sonru.com> On Apr 9, 2013, at 7:57 PM, Anatoly Mikhailov wrote: > > On Apr 9, 2013, at 7:53 PM, Anatoly Mikhailov wrote: > >> >> On Apr 9, 2013, at 5:25 PM, Maxim Dounin wrote: >> >>> Hello! >>> >>> On Tue, Apr 09, 2013 at 04:57:43PM +0100, Anatoly Mikhailov wrote: >>> >>>> Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only >>>> мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, >>>> как nginx начнет сохранять BODY запроса на диск. >>>> >>>> Basic Authentication подходит в целом, но в данном случае мне необходимо проверять >>>> API_KEY через backend. >>>> >>>> Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, >>>> какие еще варианты решения данной задачи? >>> >>> А что там обновлять? Он работает. >> >> смотрю документацию и не совсем понимаю как это работает >> http://mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README >> обязательно ли делать отдельный location для auth_request? >> >> с таким конфигом бэкэнд повисает и не отдает отдает ответ обратно, >> хотя при прямом обращении на /authentication/check ответ приходит, код 200 >> >> upstream unicorn_api { >> server unix:/tmp/unicorn.sock fail_timeout=0; >> } >> >> location =/upload { >> auth_request /authentication/check; >> limit_except POST { deny all; } >> proxy_redirect off; >> proxy_pass http://unicorn_api/attachments; >> } >> >> >> location =/authentication/check { >> proxy_pass http://unicorn_api/authentication/check; # одноименный локэйшн на бэкэнде >> proxy_pass_request_body off; >> proxy_set_header Content-Length ""; >> proxy_set_header X-Original-URI $request_uri; >> } >> > > подвисает это я глупо написал, вот такое исключение на бэкэнде вылетает: > > EOFError (bad content body) при проксировании на уже существующий location для бэкэнда, вылетает другое исключение Unicorn::ClientShutdown (bytes_read=0), конфиг следующий: location =/upload { auth_request http://unicorn_api/authentication/check; limit_except POST { deny all; } proxy_redirect off; proxy_pass http://unicorn_api/v2/attachments; } > >> >> Анатолий >> >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/en/donation.html >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From a.vasilishin at kpi.ua Tue Apr 9 21:25:43 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Wed, 10 Apr 2013 00:25:43 +0300 Subject: =?UTF-8?B?UmU6INCy0LXQsS3QutCw0LzQtdGA0LA=?= In-Reply-To: <20130409182354.GA34064@admin.sibptus.tomsk.ru> References: <20130409182354.GA34064@admin.sibptus.tomsk.ru> Message-ID: <51648757.7040905@kpi.ua> 09.04.2013 21:23, Victor Sudakov пишет: > Коллеги, > > Не решал ли кто задачу кэширования видео с вебкамеры, например типа > D-Link DCS-2130? > > Чтобы нагрузка от многих пользователей приходилась на веб-сервер > (прокси), а не на собственно камеру. > Решал когда-то с длинками (модели уже не помню) с помощью VLC -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From mdounin at mdounin.ru Tue Apr 9 23:43:56 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 10 Apr 2013 03:43:56 +0400 Subject: ngx_http_auth_request_module In-Reply-To: <53E5E89E-628A-47EF-A033-43732228EFE6@sonru.com> References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> <53E5E89E-628A-47EF-A033-43732228EFE6@sonru.com> Message-ID: <20130409234356.GE62550@mdounin.ru> Hello! On Tue, Apr 09, 2013 at 08:30:17PM +0100, Anatoly Mikhailov wrote: > > On Apr 9, 2013, at 7:57 PM, Anatoly Mikhailov wrote: > > > > > On Apr 9, 2013, at 7:53 PM, Anatoly Mikhailov wrote: > > > >> > >> On Apr 9, 2013, at 5:25 PM, Maxim Dounin wrote: > >> > >>> Hello! > >>> > >>> On Tue, Apr 09, 2013 at 04:57:43PM +0100, Anatoly Mikhailov wrote: > >>> > >>>> Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only > >>>> мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, > >>>> как nginx начнет сохранять BODY запроса на диск. > >>>> > >>>> Basic Authentication подходит в целом, но в данном случае мне необходимо проверять > >>>> API_KEY через backend. > >>>> > >>>> Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, > >>>> какие еще варианты решения данной задачи? > >>> > >>> А что там обновлять? Он работает. > >> > >> смотрю документацию и не совсем понимаю как это работает > >> http://mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README > >> обязательно ли делать отдельный location для auth_request? > >> > >> с таким конфигом бэкэнд повисает и не отдает отдает ответ обратно, > >> хотя при прямом обращении на /authentication/check ответ приходит, код 200 > >> > >> upstream unicorn_api { > >> server unix:/tmp/unicorn.sock fail_timeout=0; > >> } > >> > >> location =/upload { > >> auth_request /authentication/check; > >> limit_except POST { deny all; } > >> proxy_redirect off; > >> proxy_pass http://unicorn_api/attachments; > >> } > >> > >> > >> location =/authentication/check { > >> proxy_pass http://unicorn_api/authentication/check; # одноименный локэйшн на бэкэнде > >> proxy_pass_request_body off; > >> proxy_set_header Content-Length ""; > >> proxy_set_header X-Original-URI $request_uri; > >> } > >> > > > > подвисает это я глупо написал, вот такое исключение на бэкэнде вылетает: > > > > EOFError (bad content body) Так - должно работать, смотрите внимательно, что у вас в коде авторизатора на бекенде происходит. Видимо, он пытается лезть в тело, и вполне логично, что тела не находит - его ещё не читали. > при проксировании на уже существующий location для бэкэнда, > вылетает другое исключение Unicorn::ClientShutdown (bytes_read=0), > конфиг следующий: > > location =/upload { > auth_request http://unicorn_api/authentication/check; > limit_except POST { deny all; } > proxy_redirect off; > proxy_pass http://unicorn_api/v2/attachments; > } Так - ничего хорошего не будет. В директиве auth_request указывается URI для внутреннего перенаправления, и попытка указать там полный URL смысла не имеет. -- Maxim Dounin http://nginx.org/en/donation.html From vas at mpeks.tomsk.su Wed Apr 10 02:02:14 2013 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Wed, 10 Apr 2013 09:02:14 +0700 Subject: =?UTF-8?B?UmU6INCy0LXQsS3QutCw0LzQtdGA0LA=?= In-Reply-To: <51648757.7040905@kpi.ua> References: <20130409182354.GA34064@admin.sibptus.tomsk.ru> <51648757.7040905@kpi.ua> Message-ID: <20130410020214.GA97488@admin.sibptus.tomsk.ru> Андрей Василишин wrote: > > > > Не решал ли кто задачу кэширования видео с вебкамеры, например типа > > D-Link DCS-2130? > > > > Чтобы нагрузка от многих пользователей приходилась на веб-сервер > > (прокси), а не на собственно камеру. > > > > Решал когда-то с длинками (модели уже не помню) с помощью VLC Для интранета это наверное приемлемо, я сам когда-то решал задачу вещания звука мультикастом по RTP, см. ссылки в конце письма. Но здесь я спрашивал про какое-нибудь Web решение, может модуль к nginx или апачу есть? http://victor-sudakov.dreamwidth.org/68437.html http://victor-sudakov.dreamwidth.org/68975.html http://victor-sudakov.dreamwidth.org/69243.html -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From ufaweb at gmail.com Wed Apr 10 03:29:56 2013 From: ufaweb at gmail.com (=?UTF-8?B?0KDRg9GB0LvQsNC9INCo0LDRgNC40L/QvtCy?=) Date: Wed, 10 Apr 2013 09:29:56 +0600 Subject: =?UTF-8?B?UmU6INCy0LXQsS3QutCw0LzQtdGA0LA=?= In-Reply-To: <20130410020214.GA97488@admin.sibptus.tomsk.ru> References: <20130409182354.GA34064@admin.sibptus.tomsk.ru> <51648757.7040905@kpi.ua> <20130410020214.GA97488@admin.sibptus.tomsk.ru> Message-ID: http://erlyvideo.ru 10 апреля 2013 г., 8:02 пользователь Victor Sudakov написал: > Андрей Василишин wrote: >> > >> > Не решал ли кто задачу кэширования видео с вебкамеры, например типа >> > D-Link DCS-2130? >> > >> > Чтобы нагрузка от многих пользователей приходилась на веб-сервер >> > (прокси), а не на собственно камеру. >> > >> >> Решал когда-то с длинками (модели уже не помню) с помощью VLC > > Для интранета это наверное приемлемо, я сам когда-то решал задачу > вещания звука мультикастом по RTP, см. ссылки в конце письма. > > Но здесь я спрашивал про какое-нибудь Web решение, может модуль к > nginx или апачу есть? > > http://victor-sudakov.dreamwidth.org/68437.html > http://victor-sudakov.dreamwidth.org/68975.html > http://victor-sudakov.dreamwidth.org/69243.html > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > sip:sudakov at sibptus.tomsk.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Шарипов Руслан. Руководитель отдела разработки и сопровождения программного обеспечения ОАО "Уфанет". Контактная информация: google+: http://gplus.to/ruslan jid: serafim at jabber.ufanet.ru wave: ufaweb at googlewave.com skype: ufaweb phone: +7(917)4775460 vkontakte: http://vkontakte.ru/ufaweb myspace: http://www.myspace.com/ufaweb facebook: http://facebook.com/sharipov linkedin: http://www.linkedin.com/in/ufaweb twitter: http://twitter.com/ufaweb From nginx-forum at nginx.us Wed Apr 10 05:07:46 2013 From: nginx-forum at nginx.us (INF[SZ]) Date: Wed, 10 Apr 2013 01:07:46 -0400 Subject: =?UTF-8?B?UmU6INCy0LXQsS3QutCw0LzQtdGA0LA=?= In-Reply-To: <20130409182354.GA34064@admin.sibptus.tomsk.ru> References: <20130409182354.GA34064@admin.sibptus.tomsk.ru> Message-ID: https://github.com/arut/nginx-rtmp-module применение http://habrahabr.ru/post/174089/ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238238,238254#msg-238254 From nginx-forum at nginx.us Wed Apr 10 06:09:21 2013 From: nginx-forum at nginx.us (lokoArt90) Date: Wed, 10 Apr 2013 02:09:21 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyAi0YHQv9C40YIiIHdvcmtlciDQtNC+INC/0LXRgNCy?= =?UTF-8?B?0L7Qs9C+INC30LDQv9GA0L7RgdCwPw==?= In-Reply-To: References: Message-ID: <4074bae47a4097ca8e61fd3900d53d84.NginxMailingListRussian@forum.nginx.org> UPD: Ошибся, спят все. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238217,238255#msg-238255 From a.vasilishin at kpi.ua Wed Apr 10 18:31:17 2013 From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Wed, 10 Apr 2013 21:31:17 +0300 Subject: epoll_ctl(3, 11) failed (2: No such file or directory) Message-ID: <5165AFF5.8030704@kpi.ua> Добрый вечер! Сегодня непонятно почему на работающей уже не один месяц системе вдруг начал падать нгинкс В ерор логе куча записей, лог разрастается с неимоверной скоростью и забивает диск под 0: 2013/04/10 22:24:05 [alert] 17334#0: epoll_ctl(3, 11) failed (2: No such file or directory) 2013/04/10 22:24:05 [alert] 17334#0: epoll_ctl(3, 11) failed (2: No such file or directory) # tail /var/log/messages Apr 10 22:22:42 s4 kernel: [2786136.647694] nginx[21492]: segfault at 0 ip 00007f959ff00a79 sp 00007fffbf8e52c0 error 4 in libc-2.13.so[7f959fe85000+180000] Apr 10 22:23:31 s4 kernel: [2786185.477983] nginx[19815] general protection ip:405e18 sp:7fffbf8e5320 error:0 in nginx[400000+99000] Apr 10 22:23:33 s4 kernel: [2786187.675622] nginx[21494] general protection ip:407e85 sp:7fffbf8e51d0 error:0 in nginx[400000+99000] Apr 10 22:24:15 s4 kernel: [2786229.578820] nginx[21488] general protection ip:437b7a sp:7fffbf8e52a0 error:0 in nginx[400000+99000] Apr 10 22:24:16 s4 kernel: [2786230.540701] nginx[17312] general protection ip:7f959fefd895 sp:7fffbf8e5200 error:0 in libc-2.13.so[7f959fe85000+180000] Apr 10 22:24:27 s4 kernel: [2786242.111014] nginx[17335] general protection ip:425411 sp:7fffbf8e4910 error:0 in nginx[400000+99000] Apr 10 22:24:47 s4 kernel: [2786261.332506] nginx[17330] general protection ip:4326f5 sp:7fffbf8e5300 error:0 in nginx[400000+99000] Apr 10 22:25:08 s4 kernel: [2786282.498360] nginx[18137] general protection ip:407e85 sp:7fffbf8e51d0 error:0 in nginx[400000+99000] Apr 10 22:25:15 s4 kernel: [2786289.181497] nginx[17321] general protection ip:4326f5 sp:7fffbf8e5300 error:0 in nginx[400000+99000] Apr 10 22:25:38 s4 kernel: [2786312.975670] nginx[21520]: segfault at 0 ip 00007f959ff00a79 sp 00007fffbf8e52c0 error 4 in libc-2.13.so[7f959fe85000+180000] Что это может быть? # nginx -V nginx version: nginx/1.1.14 configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-file-aio --with-http_flv_module --with-http_geoip_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --without-http_scgi_module --without-http_uwsgi_module --add-module=/home/andron/nginx-1.1.14/debian/modules/nginx-upload-module --add-module=/home/andron/nginx-1.1.14/debian/modules/nginx-upload-progress -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From vbart at nginx.com Wed Apr 10 22:27:01 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 11 Apr 2013 02:27:01 +0400 Subject: epoll_ctl(3, 11) failed (2: No such file or directory) In-Reply-To: <5165AFF5.8030704@kpi.ua> References: <5165AFF5.8030704@kpi.ua> Message-ID: <201304110227.01963.vbart@nginx.com> On Wednesday 10 April 2013 22:31:17 Андрей Василишин wrote: > Добрый вечер! > Сегодня непонятно почему на работающей уже не один месяц системе вдруг > начал падать нгинкс > В ерор логе куча записей, лог разрастается с неимоверной скоростью и > забивает диск под 0: > [...] > > > Что это может быть? > # nginx -V > nginx version: nginx/1.1.14 > configure arguments: --prefix=/etc/nginx > --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-client-body-temp-path=/var/lib/nginx/body > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > --http-log-path=/var/log/nginx/access.log > --http-proxy-temp-path=/var/lib/nginx/proxy > --http-scgi-temp-path=/var/lib/nginx/scgi > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi > --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid > --with-debug --with-file-aio --with-http_flv_module > --with-http_geoip_module --with-http_mp4_module > --with-http_realip_module --with-http_secure_link_module > --with-http_stub_status_module --without-http_scgi_module > --without-http_uwsgi_module > --add-module=/home/andron/nginx-1.1.14/debian/modules/nginx-upload-module > --add-module=/home/andron/nginx-1.1.14/debian/modules/nginx-upload-progres Как минимум стоит сперва поставить одну из свежих поддерживаемых версий, вместо devel более чем годичной давности. И избавиться от сторонних модулей. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Apr 11 06:56:16 2013 From: nginx-forum at nginx.us (mad_boy) Date: Thu, 11 Apr 2013 02:56:16 -0400 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIGVycm9yLCByb290INC90LUg0LLQuNC00LjRgiDQtNGA0YM=?= =?UTF-8?B?0LPQuNC1INGE0LDQudC70Ys=?= In-Reply-To: <509ad4409756e071e8dc7b06129c9269.NginxMailingListRussian@forum.nginx.org> References: <20121029123304.GM40452@mdounin.ru> <509ad4409756e071e8dc7b06129c9269.NginxMailingListRussian@forum.nginx.org> Message-ID: <00115c442e1a7fcc8b995c9ed8c2d8ef.NginxMailingListRussian@forum.nginx.org> Хотелось бы поднять тему. Возникла точно такая же ситуация, но указанное решение не помогает. Есть подозрение, что проблема в локэйшене, который отдает всю статику. Только как обойти, пока не придумал. Буду признателен за помощь. Исходный конфиг: server { listen 80; server_name mysite.ru; access_log /var/www/mysite.ru.access.log; #access_log off; location / { root /var/www/mysite.ru; index index.php; } error_page 404 /errors/404/index.html; location /errors/ { #internal; root /var/www; } # location ~ \.php$ { #limit_req zone=one burst=20 nodelay; #limit_req_log_level info; log_not_found off; root /var/www/mysite.ru; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_intercept_errors on; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name; include fastcgi_params; } #Cached static files location location ~* \.(jpg|jpeg|gif|png|css|js|ico)$ { root /var/www/mysite.ru; access_log off; expires 30d; add_header Cache-Control public; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,232318,238274#msg-238274 From nginx-forum at nginx.us Thu Apr 11 07:00:26 2013 From: nginx-forum at nginx.us (mad_boy) Date: Thu, 11 Apr 2013 03:00:26 -0400 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIGVycm9yLCByb290INC90LUg0LLQuNC00LjRgiDQtNGA0YM=?= =?UTF-8?B?0LPQuNC1INGE0LDQudC70Ys=?= In-Reply-To: <00115c442e1a7fcc8b995c9ed8c2d8ef.NginxMailingListRussian@forum.nginx.org> References: <20121029123304.GM40452@mdounin.ru> <509ad4409756e071e8dc7b06129c9269.NginxMailingListRussian@forum.nginx.org> <00115c442e1a7fcc8b995c9ed8c2d8ef.NginxMailingListRussian@forum.nginx.org> Message-ID: <723beb93a5189bcfe8fd1f40b8123a83.NginxMailingListRussian@forum.nginx.org> Вот пока не попросишь помощи, не подумаешь. Разобрался сам, заработало со вложенным локэшеном: location ~* ^/errors/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /var/www; } Всем спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,232318,238275#msg-238275 From motienko at gmail.com Thu Apr 11 07:12:18 2013 From: motienko at gmail.com (Oleg Motienko) Date: Thu, 11 Apr 2013 11:12:18 +0400 Subject: =?UTF-8?B?UmU6INGP0L3QtNC10LrRgS3Qv9GA0L7QutGB0Lg=?= In-Reply-To: <1985791021.20121117010135@mtu-net.ru> References: <133168612.20121116215051@softsearch.ru> <1985791021.20121117010135@mtu-net.ru> Message-ID: У нас для этого дела DNAT поднят по списку подсетей на отдельный порт и дальше уже конфиг примерно такой #yandex turbo set_real_ip_from 5.45.192.0/24; # Opera Turbo proxies set_real_ip_from 91.203.96.0/24; set_real_ip_from 94.246.126.0/23; set_real_ip_from 195.189.142.0/23; # other turbo set_real_ip_from 64.255.180.0/24; set_real_ip_from 80.239.242.0/23; set_real_ip_from 80.232.117.0/24; set_real_ip_from 59.151.106.240/28; real_ip_header X-Forwarded-For; 2012/11/17 Andrey Repin : > Здравствуйте, Уважаемый(-ая, -ое) Aleksandr Sytar! > >>> Похоже, что у яндекса по аналогии с Оперой появились прокси-сервера >>> для своего браузера. Никто не знает ip-шки этих проксей и заголовки, >>> где реальный ip передаётся? > > > AS> На презенации они рассказывали что используют технологию Opera Turbo - > AS> соотвественно и их же сервера > > Используют технологию =/= используют сервера. > Опера как раз зарабатывает на продаже этих сервисов. > > > -- > С уважением > > Andrey Repin (hell-for-yahoo at umail.ru) суббота, 17.11.2012, <01:00> > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Oleg From a.vasilishin at kpi.ua Thu Apr 11 07:45:24 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 11 Apr 2013 10:45:24 +0300 Subject: epoll_ctl(3, 11) failed (2: No such file or directory) In-Reply-To: <201304110227.01963.vbart@nginx.com> References: <5165AFF5.8030704@kpi.ua> <201304110227.01963.vbart@nginx.com> Message-ID: <51666A14.9080900@kpi.ua> 11.04.2013 1:27, Валентин Бартенев пишет: > Как минимум стоит сперва поставить одну из свежих поддерживаемых версий, > вместо devel более чем годичной давности. И избавиться от сторонних модулей. > Поставил 1.2.8 с тем же набором модулей,вроде проблема ушла. К сожалению без nginx-upload-module и nginx-upload-progres никак, потеряется один из функционалов проекта. -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From nginx-forum at nginx.us Thu Apr 11 10:09:52 2013 From: nginx-forum at nginx.us (Denis P.) Date: Thu, 11 Apr 2013 06:09:52 -0400 Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QsCDQu9C4INCx0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCA=?= =?UTF-8?B?0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= Message-ID: Добрый день! Есть две ноды приложения и нужно закрепить за ними сессии пользователей. К тому же должна работать балансировка нагрузки по нодам. Уникальные пользователи с разных ip в первый раз идут по ссылке http://app и равномерно распределяются по нодам. По какой-то причине пользователи подключенные к первой ноде ушли все и часть со второй. При следующем заходе пользователь бывший на второй ноде будет направлен на вторую ноду или сработает балансировка и его перекинет на первую ? Конфиг : upstream backend { least_conn; ip_hash; server server1:36011; server server2:48003; } server { listen 80; server_name app; access_log /var/log/nginx/upstream_access.log; error_log /var/log/nginx/upstream_error.log; client_max_body_size 1024m; location / { proxy_pass http://backend/; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238281,238281#msg-238281 From swood at fotofor.biz Thu Apr 11 10:11:18 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Thu, 11 Apr 2013 14:11:18 +0400 Subject: nginx + php-fpm Message-ID: Всем добрый день Возможно это боян и только я не знаю как так получается. Но столкнулся с интересной вещью. Есть сайт, туда пользователи могут загружать картинки. И загружают. Но, если вместо картинки, под видом картинки, они загрузят php-код, то, казалось бы, и черт с ним. Сервер его не обработает. Но нашли ведь лаз обращаться к файлу так: ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php В location nginx прописано тоже вроде бы корректно: location ~ "^(.+\.php)($|/)" { set $script $uri; if ($uri ~ "^(.+\.php)($|/)") { set $script $1; } if ($uri ~ "^(.+\.php)(/.+)") { set $script $1; } fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass fpm-backend; include fastcgi_params; fastcgi_param SCRIPT_NAME $script; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } То есть все, что оканчивается на .php. Соблюдается. Но ведь файла нет. Я имею ввиду ".php". Почему nginx считает файлом ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php, ведь тут есть обычный слэш? -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Apr 11 11:09:19 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 11 Apr 2013 15:09:19 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L7QstC6?= =?UTF-8?B?0LAg0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= In-Reply-To: References: Message-ID: <20130411110919.GK62550@mdounin.ru> Hello! On Thu, Apr 11, 2013 at 06:09:52AM -0400, Denis P. wrote: > Добрый день! > > Есть две ноды приложения и нужно закрепить за ними сессии пользователей. К > тому же должна работать балансировка нагрузки по нодам. > > Уникальные пользователи с разных ip в первый раз идут по ссылке http://app и > равномерно распределяются по нодам. По какой-то причине пользователи > подключенные к первой ноде ушли все и часть со второй. При следующем заходе > пользователь бывший на второй ноде будет направлен на вторую ноду или > сработает балансировка и его перекинет на первую ? > > > Конфиг : > > upstream backend { > least_conn; > ip_hash; > server server1:36011; > server server2:48003; > } Нда, надо добавлять warning на переопределение балансировщиков... И least_conn, и ip_hash - балансировщики, и они полностью определяют распределение пользователей по серверам. В случае least_conn - в зависимости от количества запросов к серверу, в случае ip_hash - в зависимости от ip клиента. В приведённом выше конфиге - будет работать только ip_hash. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Thu Apr 11 11:17:47 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 11 Apr 2013 15:17:47 +0400 Subject: nginx + php-fpm In-Reply-To: References: Message-ID: <20130411111747.GL62550@mdounin.ru> Hello! On Thu, Apr 11, 2013 at 02:11:18PM +0400, Anton Kiryushkin wrote: > Всем добрый день > > Возможно это боян и только я не знаю как так получается. Но столкнулся с > интересной вещью. > Есть сайт, туда пользователи могут загружать картинки. И загружают. Но, > если вместо картинки, под видом картинки, они загрузят php-код, то, > казалось бы, и черт с ним. Сервер его не обработает. Но нашли ведь лаз > обращаться к файлу так: > ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php > > В location nginx прописано тоже вроде бы корректно: > > location ~ "^(.+\.php)($|/)" { > set $script $uri; > if ($uri ~ "^(.+\.php)($|/)") { > set $script $1; > } > if ($uri ~ "^(.+\.php)(/.+)") { > set $script $1; > } > fastcgi_index index.php; > fastcgi_split_path_info ^(.+\.php)(.*)$; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_pass fpm-backend; > include fastcgi_params; > fastcgi_param SCRIPT_NAME $script; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > } > > То есть все, что оканчивается на .php. Соблюдается. Но ведь файла нет. Я > имею ввиду ".php". Почему nginx считает файлом > ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php, ведь тут есть обычный > слэш? Потому что nginx вообще ничего не считает, файла вообще может не быть, или он может быть на другой машине. Если вы хотите, чтобы nginx проверял существование файла, то добавьте try_files - и будет проверять. В данном случае, однако, правильное решение - это не городить костыли в nginx'е, а исправить поведение php, чтобы он открывал ровно то, что сказали, а не пытался придумать правильное имя файла сам. AFAIK, выключить cgi.fix_pathinfo - помогает. -- Maxim Dounin http://nginx.org/en/donation.html From swood at fotofor.biz Thu Apr 11 11:34:52 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Thu, 11 Apr 2013 15:34:52 +0400 Subject: nginx + php-fpm In-Reply-To: <20130411111747.GL62550@mdounin.ru> References: <20130411111747.GL62550@mdounin.ru> Message-ID: Максим, спасибо за ответ. Если вы про определение переменной $script, то даже если от него отказаться и использовать штатную переменную $fastcgi_script_name, то от этого то, к ему обращается nginx не меняется. Для меня остается вопросом, почему игнорируется / в пути, то есть почему nginx обращается к файлу: /ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php А не к : /.php Что же до ничего не считает, то это абсолютно понятно и к этому вопросов нет. 11 апреля 2013 г., 15:17 пользователь Maxim Dounin написал: > Hello! > > On Thu, Apr 11, 2013 at 02:11:18PM +0400, Anton Kiryushkin wrote: > > > Всем добрый день > > > > Возможно это боян и только я не знаю как так получается. Но столкнулся с > > интересной вещью. > > Есть сайт, туда пользователи могут загружать картинки. И загружают. Но, > > если вместо картинки, под видом картинки, они загрузят php-код, то, > > казалось бы, и черт с ним. Сервер его не обработает. Но нашли ведь лаз > > обращаться к файлу так: > > ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php > > > > В location nginx прописано тоже вроде бы корректно: > > > > location ~ "^(.+\.php)($|/)" { > > set $script $uri; > > if ($uri ~ "^(.+\.php)($|/)") { > > set $script $1; > > } > > if ($uri ~ "^(.+\.php)(/.+)") { > > set $script $1; > > } > > fastcgi_index index.php; > > fastcgi_split_path_info ^(.+\.php)(.*)$; > > fastcgi_param PATH_INFO $fastcgi_path_info; > > fastcgi_pass fpm-backend; > > include fastcgi_params; > > fastcgi_param SCRIPT_NAME $script; > > fastcgi_param SCRIPT_FILENAME > > $document_root$fastcgi_script_name; > > } > > > > То есть все, что оканчивается на .php. Соблюдается. Но ведь файла нет. Я > > имею ввиду ".php". Почему nginx считает файлом > > ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php, ведь тут есть обычный > > слэш? > > Потому что nginx вообще ничего не считает, файла вообще может не > быть, или он может быть на другой машине. Если вы хотите, чтобы > nginx проверял существование файла, то добавьте try_files - и будет > проверять. > > В данном случае, однако, правильное решение - это не городить > костыли в nginx'е, а исправить поведение php, чтобы он открывал > ровно то, что сказали, а не пытался придумать правильное имя файла > сам. AFAIK, выключить cgi.fix_pathinfo - помогает. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Apr 11 11:45:14 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 11 Apr 2013 15:45:14 +0400 Subject: nginx + php-fpm In-Reply-To: References: <20130411111747.GL62550@mdounin.ru> Message-ID: <20130411114513.GN62550@mdounin.ru> Hello! On Thu, Apr 11, 2013 at 03:34:52PM +0400, Anton Kiryushkin wrote: > Максим, спасибо за ответ. > > Если вы про определение переменной $script, то даже если от него отказаться > и использовать штатную переменную $fastcgi_script_name, то от этого то, к > ему обращается nginx не меняется. Для меня остается вопросом, почему > игнорируется / в пути, то есть почему nginx обращается к файлу: > /ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php > А не к : > /.php Я даже и не знаю, что ответить. Так написано регулярное выражение (точнее, все четыре). > Что же до ничего не считает, то это абсолютно понятно и к этому вопросов > нет. > > > 11 апреля 2013 г., 15:17 пользователь Maxim Dounin написал: > > > Hello! > > > > On Thu, Apr 11, 2013 at 02:11:18PM +0400, Anton Kiryushkin wrote: > > > > > Всем добрый день > > > > > > Возможно это боян и только я не знаю как так получается. Но столкнулся с > > > интересной вещью. > > > Есть сайт, туда пользователи могут загружать картинки. И загружают. Но, > > > если вместо картинки, под видом картинки, они загрузят php-код, то, > > > казалось бы, и черт с ним. Сервер его не обработает. Но нашли ведь лаз > > > обращаться к файлу так: > > > ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php > > > > > > В location nginx прописано тоже вроде бы корректно: > > > > > > location ~ "^(.+\.php)($|/)" { > > > set $script $uri; > > > if ($uri ~ "^(.+\.php)($|/)") { > > > set $script $1; > > > } > > > if ($uri ~ "^(.+\.php)(/.+)") { > > > set $script $1; > > > } > > > fastcgi_index index.php; > > > fastcgi_split_path_info ^(.+\.php)(.*)$; > > > fastcgi_param PATH_INFO $fastcgi_path_info; > > > fastcgi_pass fpm-backend; > > > include fastcgi_params; > > > fastcgi_param SCRIPT_NAME $script; > > > fastcgi_param SCRIPT_FILENAME > > > $document_root$fastcgi_script_name; > > > } > > > > > > То есть все, что оканчивается на .php. Соблюдается. Но ведь файла нет. Я > > > имею ввиду ".php". Почему nginx считает файлом > > > ff9cf78666f326226e5328cd01e82e53804d7a44.png/.php, ведь тут есть обычный > > > слэш? > > > > Потому что nginx вообще ничего не считает, файла вообще может не > > быть, или он может быть на другой машине. Если вы хотите, чтобы > > nginx проверял существование файла, то добавьте try_files - и будет > > проверять. > > > > В данном случае, однако, правильное решение - это не городить > > костыли в nginx'е, а исправить поведение php, чтобы он открывал > > ровно то, что сказали, а не пытался придумать правильное имя файла > > сам. AFAIK, выключить cgi.fix_pathinfo - помогает. > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Best regards, > Anton Kiryushkin > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Apr 11 12:10:30 2013 From: nginx-forum at nginx.us (Denis P.) Date: Thu, 11 Apr 2013 08:10:30 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L7QstC6?= =?UTF-8?B?0LAg0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= In-Reply-To: <20130411110919.GK62550@mdounin.ru> References: <20130411110919.GK62550@mdounin.ru> Message-ID: <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> А получится ли закрепить пользователя за определенной нодой , пока он активен, а при следующем логине закидывать на менее нагруженную? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238286,238292#msg-238292 From anatoly at sonru.com Thu Apr 11 16:15:15 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 11 Apr 2013 17:15:15 +0100 Subject: ngx_http_auth_request_module In-Reply-To: <20130409234356.GE62550@mdounin.ru> References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> <53E5E89E-628A-47EF-A033-43732228EFE6@sonru.com> <20130409234356.GE62550@mdounin.ru> Message-ID: On Apr 10, 2013, at 12:43 AM, Maxim Dounin wrote: > Hello! > > On Tue, Apr 09, 2013 at 08:30:17PM +0100, Anatoly Mikhailov wrote: > >> >> On Apr 9, 2013, at 7:57 PM, Anatoly Mikhailov wrote: >> >>> >>> On Apr 9, 2013, at 7:53 PM, Anatoly Mikhailov wrote: >>> >>>> >>>> On Apr 9, 2013, at 5:25 PM, Maxim Dounin wrote: >>>> >>>>> Hello! >>>>> >>>>> On Tue, Apr 09, 2013 at 04:57:43PM +0100, Anatoly Mikhailov wrote: >>>>> >>>>>> Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only >>>>>> мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, >>>>>> как nginx начнет сохранять BODY запроса на диск. >>>>>> >>>>>> Basic Authentication подходит в целом, но в данном случае мне необходимо проверять >>>>>> API_KEY через backend. >>>>>> >>>>>> Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, >>>>>> какие еще варианты решения данной задачи? >>>>> >>>>> А что там обновлять? Он работает. >>>> >>>> смотрю документацию и не совсем понимаю как это работает >>>> http://mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README >>>> обязательно ли делать отдельный location для auth_request? >>>> >>>> с таким конфигом бэкэнд повисает и не отдает отдает ответ обратно, >>>> хотя при прямом обращении на /authentication/check ответ приходит, код 200 >>>> >>>> upstream unicorn_api { >>>> server unix:/tmp/unicorn.sock fail_timeout=0; >>>> } >>>> >>>> location =/upload { >>>> auth_request /authentication/check; >>>> limit_except POST { deny all; } >>>> proxy_redirect off; >>>> proxy_pass http://unicorn_api/attachments; >>>> } >>>> >>>> >>>> location =/authentication/check { >>>> proxy_pass http://unicorn_api/authentication/check; # одноименный локэйшн на бэкэнде >>>> proxy_pass_request_body off; >>>> proxy_set_header Content-Length ""; >>>> proxy_set_header X-Original-URI $request_uri; >>>> } >>>> >>> >>> подвисает это я глупо написал, вот такое исключение на бэкэнде вылетает: >>> >>> EOFError (bad content body) > > Так - должно работать, смотрите внимательно, что у вас в коде > авторизатора на бекенде происходит. Видимо, он пытается лезть в > тело, и вполне логично, что тела не находит - его ещё не читали. на бэкэнде у нас примитивный Rack, который к сожалению не пускает запрос с пустым BODY, придется ограничиться Basic HTTP Auth для запроса /upload... > >> при проксировании на уже существующий location для бэкэнда, >> вылетает другое исключение Unicorn::ClientShutdown (bytes_read=0), >> конфиг следующий: >> >> location =/upload { >> auth_request http://unicorn_api/authentication/check; >> limit_except POST { deny all; } >> proxy_redirect off; >> proxy_pass http://unicorn_api/v2/attachments; >> } > > Так - ничего хорошего не будет. В директиве auth_request > указывается URI для внутреннего перенаправления, и попытка указать > там полный URL смысла не имеет. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Fri Apr 12 09:29:31 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 12 Apr 2013 13:29:31 +0400 Subject: ngx_http_auth_request_module In-Reply-To: References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> <53E5E89E-628A-47EF-A033-43732228EFE6@sonru.com> <20130409234356.GE62550@mdounin.ru> Message-ID: <20130412092931.GE62550@mdounin.ru> Hello! On Thu, Apr 11, 2013 at 05:15:15PM +0100, Anatoly Mikhailov wrote: > > On Apr 10, 2013, at 12:43 AM, Maxim Dounin wrote: > > > Hello! > > > > On Tue, Apr 09, 2013 at 08:30:17PM +0100, Anatoly Mikhailov wrote: > > > >> > >> On Apr 9, 2013, at 7:57 PM, Anatoly Mikhailov wrote: > >> > >>> > >>> On Apr 9, 2013, at 7:53 PM, Anatoly Mikhailov wrote: > >>> > >>>> > >>>> On Apr 9, 2013, at 5:25 PM, Maxim Dounin wrote: > >>>> > >>>>> Hello! > >>>>> > >>>>> On Tue, Apr 09, 2013 at 04:57:43PM +0100, Anatoly Mikhailov wrote: > >>>>> > >>>>>> Для контролируемого аплоада больших файлов напрямую через client_body_in_file_only > >>>>>> мне необходимо ограничнить доступ и реализовать backend аутентификацию перед тем, > >>>>>> как nginx начнет сохранять BODY запроса на диск. > >>>>>> > >>>>>> Basic Authentication подходит в целом, но в данном случае мне необходимо проверять > >>>>>> API_KEY через backend. > >>>>>> > >>>>>> Найденный плагин ngx_http_auth_request_module последний раз обновлен больше 2-х лет назад, > >>>>>> какие еще варианты решения данной задачи? > >>>>> > >>>>> А что там обновлять? Он работает. > >>>> > >>>> смотрю документацию и не совсем понимаю как это работает > >>>> http://mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README > >>>> обязательно ли делать отдельный location для auth_request? > >>>> > >>>> с таким конфигом бэкэнд повисает и не отдает отдает ответ обратно, > >>>> хотя при прямом обращении на /authentication/check ответ приходит, код 200 > >>>> > >>>> upstream unicorn_api { > >>>> server unix:/tmp/unicorn.sock fail_timeout=0; > >>>> } > >>>> > >>>> location =/upload { > >>>> auth_request /authentication/check; > >>>> limit_except POST { deny all; } > >>>> proxy_redirect off; > >>>> proxy_pass http://unicorn_api/attachments; > >>>> } > >>>> > >>>> > >>>> location =/authentication/check { > >>>> proxy_pass http://unicorn_api/authentication/check; # одноименный локэйшн на бэкэнде > >>>> proxy_pass_request_body off; > >>>> proxy_set_header Content-Length ""; > >>>> proxy_set_header X-Original-URI $request_uri; > >>>> } > >>>> > >>> > >>> подвисает это я глупо написал, вот такое исключение на бэкэнде вылетает: > >>> > >>> EOFError (bad content body) > > > > Так - должно работать, смотрите внимательно, что у вас в коде > > авторизатора на бекенде происходит. Видимо, он пытается лезть в > > тело, и вполне логично, что тела не находит - его ещё не читали. > > на бэкэнде у нас примитивный Rack, который к сожалению не пускает > запрос с пустым BODY, придется ограничиться Basic HTTP Auth для > запроса /upload... Как вам будет угодно. Но вообще - сделать body непустым, или убрать из запроса то, что ваш бекенд воспринимает в штыки - это ни разу не проблема: http://nginx.org/r/proxy_set_header http://nginx.org/r/proxy_set_body http://nginx.org/r/proxy_method Собственно, есть все механизмы для того, чтобы полностью сформировать запрос на бекенд. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Fri Apr 12 11:20:05 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 12 Apr 2013 12:20:05 +0100 Subject: ngx_http_auth_request_module In-Reply-To: <20130412092931.GE62550@mdounin.ru> References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> <53E5E89E-628A-47EF-A033-43732228EFE6@sonru.com> <20130409234356.GE62550@mdounin.ru> <20130412092931.GE62550@mdounin.ru> Message-ID: On Apr 12, 2013, at 10:29 AM, Maxim Dounin wrote: > Hello! > > On Thu, Apr 11, 2013 at 05:15:15PM +0100, Anatoly Mikhailov wrote: > >> >> On Apr 10, 2013, at 12:43 AM, Maxim Dounin wrote: >> >>> Hello! >>> >>> On Tue, Apr 09, 2013 at 08:30:17PM +0100, Anatoly Mikhailov wrote: >>> >>> >>> Так - должно работать, смотрите внимательно, что у вас в коде >>> авторизатора на бекенде происходит. Видимо, он пытается лезть в >>> тело, и вполне логично, что тела не находит - его ещё не читали. >> >> на бэкэнде у нас примитивный Rack, который к сожалению не пускает >> запрос с пустым BODY, придется ограничиться Basic HTTP Auth для >> запроса /upload... > > Как вам будет угодно. Но вообще - сделать body непустым, или > убрать из запроса то, что ваш бекенд воспринимает в штыки - это ни > разу не проблема: > > http://nginx.org/r/proxy_set_header > http://nginx.org/r/proxy_set_body > http://nginx.org/r/proxy_method > > Собственно, есть все механизмы для того, чтобы полностью > сформировать запрос на бекенд. > так (proxy_set_body off) заработало, спасибо location = /authentication/check { proxy_set_header Content-Length ""; proxy_pass_request_body off; proxy_set_body off; proxy_buffering off; proxy_pass http://unicorn_api/authentication/check; } В итоге "client_body_in_file_only on" и плагин "http_auth_request" в тандеме превращаются в отличное решение для аплоада больших файлов без необходимости пропускать их файл через сокет (лишние операции копирования). Плюс ко всему - предварительная бэкэнд-аутентификация, которая не дает начать аплоад, если она не пройдена. Насколько я понимаю, при обычном аплоаде бэкэнд-аутентификация запускается только после того, как файл уже загружен и пропущен через сокет? Вопрос только один - почему эти просто замечательные вещи слабо документированы? :) Вы даже не представляете, насколько это востребованная типовая задача, которую почти всегда решают с помощью костылей, но nginx уже имеет все, что нужно. > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Fri Apr 12 12:51:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 12 Apr 2013 16:51:33 +0400 Subject: ngx_http_auth_request_module In-Reply-To: References: <8D627852-F8A5-47DD-9920-EA6CDEEEED9E@sonru.com> <20130409162520.GD62550@mdounin.ru> <62A570BB-2916-48CC-9784-8543AF364B8E@sonru.com> <27FBF22A-BFBA-4658-8AA4-E12CBD048E69@sonru.com> <53E5E89E-628A-47EF-A033-43732228EFE6@sonru.com> <20130409234356.GE62550@mdounin.ru> <20130412092931.GE62550@mdounin.ru> Message-ID: <20130412125132.GG62550@mdounin.ru> Hello! On Fri, Apr 12, 2013 at 12:20:05PM +0100, Anatoly Mikhailov wrote: > > On Apr 12, 2013, at 10:29 AM, Maxim Dounin wrote: > > > Hello! > > > > On Thu, Apr 11, 2013 at 05:15:15PM +0100, Anatoly Mikhailov wrote: > > > >> > >> On Apr 10, 2013, at 12:43 AM, Maxim Dounin wrote: > >> > >>> Hello! > >>> > >>> On Tue, Apr 09, 2013 at 08:30:17PM +0100, Anatoly Mikhailov wrote: > >>> > >>> > >>> Так - должно работать, смотрите внимательно, что у вас в коде > >>> авторизатора на бекенде происходит. Видимо, он пытается лезть в > >>> тело, и вполне логично, что тела не находит - его ещё не читали. > >> > >> на бэкэнде у нас примитивный Rack, который к сожалению не пускает > >> запрос с пустым BODY, придется ограничиться Basic HTTP Auth для > >> запроса /upload... > > > > Как вам будет угодно. Но вообще - сделать body непустым, или > > убрать из запроса то, что ваш бекенд воспринимает в штыки - это ни > > разу не проблема: > > > > http://nginx.org/r/proxy_set_header > > http://nginx.org/r/proxy_set_body > > http://nginx.org/r/proxy_method > > > > Собственно, есть все механизмы для того, чтобы полностью > > сформировать запрос на бекенд. > > > > так (proxy_set_body off) заработало, спасибо > > location = /authentication/check { > proxy_set_header Content-Length ""; > proxy_pass_request_body off; > proxy_set_body off; > proxy_buffering off; > proxy_pass http://unicorn_api/authentication/check; > } Даже странно, честно говоря: - "proxy_set_body off" установит тело запроса в "off", что вероятно не совсем то, что вы хотели получить; - при этом "proxy_set_header Content-Length" таки уберёт из запроса Content-Length, и в результате передаваемые данные тела ("off") повиснут в воздухе; - "proxy_pass_request_body off" при использовании proxy_set_body смысла не имеет, исходное тело запроса в любом случае передано не будет. Скорее всего для удовлетворения поребностей вашего бекенда достаточно будет сделать так: location = /authentication/check { proxy_set_body "stub"; proxy_pass http://unicorn_api/authentication/check; } > В итоге "client_body_in_file_only on" и плагин "http_auth_request" в тандеме превращаются > в отличное решение для аплоада больших файлов без необходимости пропускать их > файл через сокет (лишние операции копирования). Для того, чтобы данные лишний раз не пропускались через сокет - вполне достаточно одного client_body_in_file_only. Если мне не изменяет память, прозрачная поддержка этого со стороны php была одной из killer features php-fpm. Исходно документация была, судя по всему, тут: http://php-fpm.org/wiki/Features#Accelerated_upload_support К сожалению, сейчас по ссылке выше возвращается ошибка. > Плюс ко всему - предварительная > бэкэнд-аутентификация, которая не дает начать аплоад, если она не пройдена. > Насколько я понимаю, при обычном аплоаде бэкэнд-аутентификация запускается > только после того, как файл уже загружен и пропущен через сокет? Да. Но есть нюанс: если аутентификация таки не пройдёт, то, как и в случае ошибки 413, у браузера может не получиться нормально прочитать ответ. > Вопрос только один - почему эти просто замечательные вещи слабо документированы? :) > Вы даже не представляете, насколько это востребованная типовая задача, которую > почти всегда решают с помощью костылей, но nginx уже имеет все, что нужно. Да, недостаток HOWTO, не требующих думать, для типовых задач - это одна из основных проблем нашей текущей документации. С другой стороны, вот конкретно эта задача - она из области нетривиальных оптимизаций, и вряд ли стоит ожидать, что под неё в официальной документации найдётся HOWTO, из которого можно будет скопировать конфиг. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Sat Apr 13 04:59:05 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Sat, 13 Apr 2013 00:59:05 -0400 Subject: nginx/freebsd and broken sockets Message-ID: <5f01aba81414f65d7dee90a6ab374e36.NginxMailingListRussian@forum.nginx.org> Nginx на фронтенде. Freebsd 8.3 сетевой драйвер bge sockstat -4 www nginx 1153 10 tcp4 127.0.0.1:8093 *:* www nginx 1153 11 tcp4 127.0.0.1:8098 *:* www nginx 1153 12 tcp4 127.0.0.1:8109 *:* www nginx 1153 13 tcp4 127.0.0.1:8091 *:* www nginx 1153 14 tcp4 127.0.0.1:8092 *:* www nginx 1153 15 tcp4 127.0.0.1:8099 *:* www nginx 1153 26 tcp4 xx.xx.xx.91:80 95.105.67.10:52298 www nginx 1152 7 tcp4 *:80 *:* www nginx 1152 8 tcp4 127.0.0.1:8094 *:* www nginx 1152 9 tcp4 127.0.0.1:8107 *:* www nginx 1152 10 tcp4 127.0.0.1:8093 *:* www nginx 1152 11 tcp4 127.0.0.1:8098 *:* www nginx 1152 12 tcp4 127.0.0.1:8109 *:* www nginx 1152 13 tcp4 127.0.0.1:8091 *:* www nginx 1152 14 tcp4 127.0.0.1:8092 *:* www nginx 1152 15 tcp4 127.0.0.1:8099 *:* root syslogd 908 7 udp4 *:514 *:* ? ? ? ? tcp4 xx.xx.xx.88:80 99.35.43.19:55627 ? ? ? ? tcp4 xx.xx.xx.88:80 46.61.38.113:3838 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2874 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2882 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2880 ? ? ? ? tcp4 xx.xx.xx.87:80 92.127.115.68:1083 ? ? ? ? tcp4 xx.xx.xx.87:80 92.127.115.68:1085 ? ? ? ? tcp4 xx.xx.xx.87:80 92.127.115.68:1087 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6840 ? ? ? ? tcp4 xx.xx.xx.91:80 188.186.22.220:12684 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6114 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6246 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6510 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6280 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6676 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6774 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6064 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6346 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6708 ? ? ? ? tcp4 xx.xx.xx.88:80 188.232.132.30:6972 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2904 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2906 ? ? ? ? tcp4 xx.xx.xx.91:80 92.112.42.117:51231 ? ? ? ? tcp4 xx.xx.xx.91:80 92.112.42.117:51230 ? ? ? ? tcp4 xx.xx.xx.91:80 92.112.42.117:51229 ? ? ? ? tcp4 xx.xx.xx.91:80 92.112.42.117:51232 ? ? ? ? tcp4 xx.xx.xx.91:80 86.106.252.179:10741 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2914 ? ? ? ? tcp4 xx.xx.xx.91:80 92.112.42.117:51239 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2924 ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2926 ? ? ? ? tcp4 xx.xx.xx.92:80 86.106.252.179:10753 ? ? ? ? tcp4 xx.xx.xx.91:80 176.15.207.229:1849 ? ? ? ? tcp4 xx.xx.xx.91:80 176.15.207.229:1850 ? ? ? ? tcp4 xx.xx.xx.91:80 176.15.207.229:1851 ? ? ? ? tcp4 xx.xx.xx.91:80 176.15.207.229:1852 ? ? ? ? tcp4 xx.xx.xx.91:80 176.15.207.229:1853 Кто-нибудь сталкивался? Перепробовал все. Аналогично настроенная машинка на FreeBSD 8.2 и em не имеет таких глюков. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238337,238337#msg-238337 From public-mail at alekciy.ru Sat Apr 13 10:10:19 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Sat, 13 Apr 2013 14:10:19 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L7QstC6?= =?UTF-8?B?0LAg0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= In-Reply-To: <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> Message-ID: Проблем с клиентами с динамическими адреса разве не возникает? 11 апреля 2013 г., 16:10 пользователь Denis P. написал: > А получится ли закрепить пользователя за определенной нодой , пока он > активен, а при следующем логине закидывать на менее нагруженную? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238286,238292#msg-238292 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From public-mail at alekciy.ru Sat Apr 13 10:19:35 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Sat, 13 Apr 2013 14:19:35 +0400 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8gY29va2ll?= In-Reply-To: References: Message-ID: 8 апреля 2013 г., 19:52 пользователь Кутылев, Сергей написал: > случай второй: человек заходит из вне у него проверяется как-нибудь наличие > cookie авторизации в gmail Браузер не отдаст куки gmail-а какому-то example.com. From mdounin at mdounin.ru Sat Apr 13 12:59:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 13 Apr 2013 16:59:07 +0400 Subject: nginx/freebsd and broken sockets In-Reply-To: <5f01aba81414f65d7dee90a6ab374e36.NginxMailingListRussian@forum.nginx.org> References: <5f01aba81414f65d7dee90a6ab374e36.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130413125907.GS62550@mdounin.ru> Hello! On Sat, Apr 13, 2013 at 12:59:05AM -0400, Gaidamak wrote: > Nginx на фронтенде. Freebsd 8.3 сетевой драйвер bge > > sockstat -4 [...] > www nginx 1152 15 tcp4 127.0.0.1:8099 *:* > root syslogd 908 7 udp4 *:514 *:* > ? ? ? ? tcp4 xx.xx.xx.88:80 99.35.43.19:55627 > ? ? ? ? tcp4 xx.xx.xx.88:80 46.61.38.113:3838 > ? ? ? ? tcp4 xx.xx.xx.91:80 95.154.76.11:2874 [...] > Кто-нибудь сталкивался? Перепробовал все. Аналогично настроенная машинка на > FreeBSD 8.2 и em не имеет таких глюков. Таки посмотрите на эти сокеты через netstat, и придёт вам понимание. А в 8.2 sockstat их, вероятно, просто показывать не умел. -- Maxim Dounin http://nginx.org/en/donation.html From marck at rinet.ru Sat Apr 13 16:41:05 2013 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sat, 13 Apr 2013 20:41:05 +0400 (MSK) Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L7QstC6?= =?UTF-8?B?0LAg0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= In-Reply-To: References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> Message-ID: On Sat, 13 Apr 2013, Алексей Сундуков wrote: > Проблем с клиентами с динамическими адреса разве не возникает? Много ли вы встречили клиентов, у которых адрес меняется в течение одной http сессии? Ваш, К.О. ;-P -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From public-mail at alekciy.ru Sat Apr 13 18:50:56 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Sat, 13 Apr 2013 22:50:56 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L7QstC6?= =?UTF-8?B?0LAg0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= In-Reply-To: References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> Message-ID: Много ли вы встречали клиентов на статических адресах? Пользователь зашел на сайт, прошел процедуру аутентификации, у него один адрес. Сегодня ему интернет больше не нужен и он завершил свою PPPoE сессию (или вообще это мобильный интернет). Завтра снова выходит в интернет, но провайдер выдал ему уже другой IP. Гарантии того, что он попадет на туже бэкэнд ноду что и вчера в случае распределения сессиий по IP клиента совершенно нет. На сколько часто... Мой смартофон в течении дня, судя по IP геобазе, бывает в самых разных места нашей страны, начиная от самых западных до самых восточных берегов. Поэтому я бы сказал, что статический клиент это больше исключение, чем правило. 13 апреля 2013 г., 20:41 пользователь Dmitry Morozovsky написал: > On Sat, 13 Apr 2013, Алексей Сундуков wrote: > >> Проблем с клиентами с динамическими адреса разве не возникает? > > Много ли вы встречили клиентов, у которых адрес меняется в течение одной http > сессии? > > > Ваш, > К.О. ;-P > > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck at FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** > ------------------------------------------------------------------------ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sat Apr 13 21:40:03 2013 From: nginx-forum at nginx.us (ast) Date: Sat, 13 Apr 2013 17:40:03 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L7QstC6?= =?UTF-8?B?0LAg0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= In-Reply-To: References: Message-ID: <632a36abe5f78c559ad302581229bce8.NginxMailingListRussian@forum.nginx.org> Алексей Сундуков Wrote: ------------------------------------------------------- > Много ли вы встречали клиентов на статических адресах? > > Пользователь зашел на сайт, прошел процедуру аутентификации, у него > один адрес. Сегодня ему интернет больше не нужен и он завершил свою > PPPoE сессию (или вообще это мобильный интернет). Завтра снова > выходит > в интернет, но провайдер выдал ему уже другой IP. Гарантии того, что > он попадет на туже бэкэнд ноду что и вчера в случае распределения > сессиий по IP клиента совершенно нет. > > На сколько часто... Мой смартофон в течении дня, судя по IP геобазе, > бывает в самых разных места нашей страны, начиная от самых западных > до > самых восточных берегов. Поэтому я бы сказал, что статический клиент > это больше исключение, чем правило. Для этого есть куки, как минимум. По нормальному общее хранилище сессий. На моей практике таких клиентов было два, у которых прямо в логах можно бло увидеть, как меняется IP , от запроса к запросу. Но это ненормальная ситуация, отправили к провайдеру, иначе никак. > 13 апреля 2013 г., 20:41 пользователь Dmitry Morozovsky > написал: > > On Sat, 13 Apr 2013, Алексей Сундуков wrote: > > > >> Проблем с клиентами с динамическими адреса разве не возникает? > > > > Много ли вы встречили клиентов, у которых адрес меняется в течение > одной http > > сессии? > > > > > > Ваш, > > К.О. ;-P > > > > > > -- > > Sincerely, > > D.Marck [DM5020, MCK-RIPE, > DM3-RIPN] > > [ FreeBSD committer: > marck at FreeBSD.org ] > > > ---------------------------------------------------------------------- > -- > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru > *** > > > ---------------------------------------------------------------------- > -- > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238286,238347#msg-238347 From n.g.i.n.x.e.r at gmail.com Sat Apr 13 21:45:04 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Sun, 14 Apr 2013 01:45:04 +0400 Subject: =?UTF-8?B?0J/QvtC00LzQtdC90LAg0YPRgNC70LAg0YEg0L7RgtC00LDRh9C10Lkg0YTQsNC5?= =?UTF-8?B?0LvQsA==?= Message-ID: Есть задачка скрыть реальное нахождение файла и отдавать его по короткой ссылке. Например: заходим по ссылке http://site.com/03209393/file.tgz, скачивание идет по ссылке http://site.com/03209393/file.tgz, а на самом деле файл находится тут http://site.com/arhive/file.tgz Задача довольно простая на первый взгляд, если бы не одно но. Можно ли читать реальную ссылку не скриптом, а например из мемкеша? Тогда бы nginx считывал ссылку и от давал файл без какого либо скрипта в бекенде. Вся задача сводится к убиранию бекенда. From anatoly at sonru.com Sat Apr 13 22:49:59 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Sat, 13 Apr 2013 23:49:59 +0100 Subject: =?UTF-8?B?UmU6INCf0L7QtNC80LXQvdCwINGD0YDQu9CwINGBINC+0YLQtNCw0YfQtdC5INGE?= =?UTF-8?B?0LDQudC70LA=?= In-Reply-To: References: Message-ID: <393F6BB5-84C8-4C57-84B8-1548A280D829@sonru.com> On Apr 13, 2013, at 10:45 PM, Роман wrote: > Есть задачка скрыть реальное нахождение файла и отдавать его по > короткой ссылке. Например: заходим по ссылке > http://site.com/03209393/file.tgz, скачивание идет по ссылке > http://site.com/03209393/file.tgz, а на самом деле файл находится тут > http://site.com/arhive/file.tgz > > Задача довольно простая на первый взгляд, если бы не одно но. > > Можно ли читать реальную ссылку не скриптом, а например из мемкеша? > Тогда бы nginx считывал ссылку и от давал файл без какого либо скрипта > в бекенде. > > Вся задача сводится к убиранию бекенда. можно даже без мемкэша обойтись, просто соберите nginx с опцией --with-http_secure_link_module location /download/ { rewrite /download/([a-zA-Z0-9_\-]*)/([0-9]*)/(.*)\.tgz$ /archive/$3.tgz?st=$1&e=$2; } location /archive/ { internal; secure_link $arg_st,$arg_e; secure_link_md5 YOUR_SECRET_PASSWORD_HERE$arg_e$uri; if ($secure_link = "") { return 403; } if ($secure_link = "0") { return 403; } } YOUR_SECRET_PASSWORD_HERE - пароль, с помощью которого вы делаете шифр, $arg_e - timestamp пример того, как генерить урлы на Ruby здесь https://gist.github.com/mikhailov/3174601 > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sun Apr 14 03:57:41 2013 From: nginx-forum at nginx.us (gvozd) Date: Sat, 13 Apr 2013 23:57:41 -0400 Subject: =?UTF-8?B?0KHQu9C40LIg0YLRgNCw0YTQuNC60LA=?= Message-ID: <5c25514c95f211105fd1bca4c9c78494.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Помогите решить проблему, происходит очень большой слив исходящего трафика, tcpdump'ом удалось выяснить, что nginx получает запрос: HTTP/1.1 302 OK Connection: Keep-Alive Location: http://affiliationpartner.it/tutorial/adesionecampagne.mov?COLLCC=1830002745&COLLCC=3039517559& redirect... После чего происходит загрузка этого файла и накрутка трафика. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238351,238351#msg-238351 From pavel2000 at ngs.ru Sun Apr 14 05:03:26 2013 From: pavel2000 at ngs.ru (Pavel V.) Date: Sun, 14 Apr 2013 12:03:26 +0700 Subject: =?UTF-8?B?UmU6INCh0LvQuNCyINGC0YDQsNGE0LjQutCw?= In-Reply-To: <5c25514c95f211105fd1bca4c9c78494.NginxMailingListRussian@forum.nginx.org> References: <5c25514c95f211105fd1bca4c9c78494.NginxMailingListRussian@forum.nginx.org> Message-ID: <1837199979.20130414120326@ngs.ru> Здравствуйте, gvozd. Вы писали 14 апреля 2013 г., 10:57:41: > Здравствуйте! > Помогите решить проблему, происходит очень большой слив исходящего трафика, > tcpdump'ом удалось выяснить, что nginx получает запрос: > HTTP/1.1 302 OK > Connection: Keep-Alive > Location: > http://affiliationpartner.it/tutorial/adesionecampagne.mov?COLLCC=1830002745&COLLCC=3039517559& > redirect... Это не HTTP-запрос, это HTTP-ответ. > После чего происходит загрузка этого файла и накрутка трафика. Я так понимаю, что указанный файл отдается не с вашего сервера, соответственно накрутки нет. Разберитесь сами в том, как работает HTTP, либо наймите компетентного специалиста. Из вами вышенаписанного проблемы не видно ни в настройках Nginx, ни в самой описанной ситуации. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From nginx-forum at nginx.us Sun Apr 14 06:01:43 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Sun, 14 Apr 2013 02:01:43 -0400 Subject: nginx/freebsd and broken sockets In-Reply-To: <20130413125907.GS62550@mdounin.ru> References: <20130413125907.GS62550@mdounin.ru> Message-ID: <4281526c5ce5c9e3dc4e3f468c21be4a.NginxMailingListRussian@forum.nginx.org> То есть, это просто TIME_WAIT так отображается? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238337,238353#msg-238353 From marck at rinet.ru Sun Apr 14 07:21:23 2013 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun, 14 Apr 2013 11:21:23 +0400 (MSK) Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L7QstC6?= =?UTF-8?B?0LAg0L3QsNCz0YDRg9C30LrQuCDQv9GA0LggaXAgaGFzaCA/?= In-Reply-To: References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> Message-ID: On Sat, 13 Apr 2013, Алексей Сундуков wrote: > > Много ли вы встречили клиентов, у которых адрес меняется в течение одной http > > сессии? > Много ли вы встречали клиентов на статических адресах? при чём здесь это? пока сессия длится, адрес один. между сессиями данные клиента всё равно нужно сохранять хотя бы потому, что их нужно сохранять *внутри* сессии, независимо от адреса (его можно применять разве что в целях некоторого ужесточения безопасности) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From postmaster at softsearch.ru Sun Apr 14 14:00:29 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 14 Apr 2013 18:00:29 +0400 Subject: =?UTF-8?B?UmVbMl06INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L4=?= =?UTF-8?B?0LLQutCwINC90LDQs9GA0YPQt9C60Lgg0L/RgNC4IGlwIGhhc2ggPw==?= In-Reply-To: References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> Message-ID: <1613593459.20130414180029@softsearch.ru> Здравствуйте, Dmitry. >> Проблем с клиентами с динамическими адреса разве не возникает? > Много ли вы встречили клиентов, у которых адрес меняется в течение > одной http сессии? Я такой, например. Могу напрямую в сеть выходить, потом через vpn подключиться, потом отключить его. -- С уважением, Михаил mailto:postmaster at softsearch.ru From marck at rinet.ru Sun Apr 14 14:09:54 2013 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun, 14 Apr 2013 18:09:54 +0400 (MSK) Subject: =?UTF-8?B?UmVbMl06INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L4=?= =?UTF-8?B?0LLQutCwINC90LDQs9GA0YPQt9C60Lgg0L/RgNC4IGlwIGhhc2ggPw==?= In-Reply-To: <1613593459.20130414180029@softsearch.ru> References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> <1613593459.20130414180029@softsearch.ru> Message-ID: On Sun, 14 Apr 2013, Михаил Монашёв wrote: > >> Проблем с клиентами с динамическими адреса разве не возникает? > > > Много ли вы встречили клиентов, у которых адрес меняется в течение > > одной http сессии? > > Я такой, например. Могу напрямую в сеть выходить, потом через vpn > подключиться, потом отключить его. Хм, ну я б в такой ситуации (aka включить/выключить WiFi на 3g-enabled устройстве, скажем) был бы готов к тому, что меня попросят перелогиниться... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From postmaster at softsearch.ru Sun Apr 14 16:10:42 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 14 Apr 2013 20:10:42 +0400 Subject: =?UTF-8?B?UmVbM106INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L4=?= =?UTF-8?B?0LLQutCwINC90LDQs9GA0YPQt9C60Lgg0L/RgNC4IGlwIGhhc2ggPw==?= In-Reply-To: References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> <1613593459.20130414180029@softsearch.ru> Message-ID: <910715695.20130414201042@softsearch.ru> Здравствуйте, Dmitry. >> >> Проблем с клиентами с динамическими адреса разве не возникает? >> >> > Много ли вы встречили клиентов, у которых адрес меняется в течение >> > одной http сессии? >> >> Я такой, например. Могу напрямую в сеть выходить, потом через vpn >> подключиться, потом отключить его. > Хм, ну я б в такой ситуации (aka включить/выключить WiFi на 3g-enabled > устройстве, скажем) был бы готов к тому, что меня попросят перелогиниться... ИМХО, релогин нужен при смене подсети, а не ip. Смена ip бывает, когда инет пропадает и человек снова к нему подключается. -- С уважением, Михаил mailto:postmaster at softsearch.ru From marck at rinet.ru Sun Apr 14 16:34:54 2013 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun, 14 Apr 2013 20:34:54 +0400 (MSK) Subject: =?UTF-8?B?UmVbM106INCS0L7Qt9C80L7QttC90LAg0LvQuCDQsdCw0LvQsNC90YHQuNGA0L4=?= =?UTF-8?B?0LLQutCwINC90LDQs9GA0YPQt9C60Lgg0L/RgNC4IGlwIGhhc2ggPw==?= In-Reply-To: <910715695.20130414201042@softsearch.ru> References: <20130411110919.GK62550@mdounin.ru> <338eaf32474fd28daf53478770294934.NginxMailingListRussian@forum.nginx.org> <1613593459.20130414180029@softsearch.ru> <910715695.20130414201042@softsearch.ru> Message-ID: On Sun, 14 Apr 2013, Михаил Монашёв wrote: > >> >> Проблем с клиентами с динамическими адреса разве не возникает? > >> > >> > Много ли вы встречили клиентов, у которых адрес меняется в течение > >> > одной http сессии? > >> > >> Я такой, например. Могу напрямую в сеть выходить, потом через vpn > >> подключиться, потом отключить его. > > > Хм, ну я б в такой ситуации (aka включить/выключить WiFi на 3g-enabled > > устройстве, скажем) был бы готов к тому, что меня попросят перелогиниться... > > ИМХО, релогин нужен при смене подсети, а не ip. Смена ip бывает, когда > инет пропадает и человек снова к нему подключается. не вижу противоречий. но, кстати, и с эвристикой смены адреса внутри подсети тоже все сильно неочевидно -- оно /29 или /21? ;) (у нас на сети в эксплуатации, если что, и те и другие, другое дело что /21 не у клиентов) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From mdounin at mdounin.ru Sun Apr 14 17:16:47 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 14 Apr 2013 21:16:47 +0400 Subject: nginx/freebsd and broken sockets In-Reply-To: <4281526c5ce5c9e3dc4e3f468c21be4a.NginxMailingListRussian@forum.nginx.org> References: <20130413125907.GS62550@mdounin.ru> <4281526c5ce5c9e3dc4e3f468c21be4a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130414171647.GB92338@mdounin.ru> Hello! On Sun, Apr 14, 2013 at 02:01:43AM -0400, Gaidamak wrote: > То есть, это просто TIME_WAIT так отображается? В частности. Нет повода для паники. -- Maxim Dounin http://nginx.org/en/donation.html From n.g.i.n.x.e.r at gmail.com Sun Apr 14 17:32:06 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Sun, 14 Apr 2013 21:32:06 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC80LXQvdCwINGD0YDQu9CwINGBINC+0YLQtNCw0YfQtdC5INGE?= =?UTF-8?B?0LDQudC70LA=?= In-Reply-To: <393F6BB5-84C8-4C57-84B8-1548A280D829@sonru.com> References: <393F6BB5-84C8-4C57-84B8-1548A280D829@sonru.com> Message-ID: Дело в том, что ссылки не постоянные. Короткая и настоящая лежат в базе. 14 апреля 2013 г., 2:49 пользователь Anatoly Mikhailov написал: > > On Apr 13, 2013, at 10:45 PM, Роман wrote: > > Есть задачка скрыть реальное нахождение файла и отдавать его по > короткой ссылке. Например: заходим по ссылке > http://site.com/03209393/file.tgz, скачивание идет по ссылке > http://site.com/03209393/file.tgz, а на самом деле файл находится тут > http://site.com/arhive/file.tgz > > Задача довольно простая на первый взгляд, если бы не одно но. > > Можно ли читать реальную ссылку не скриптом, а например из мемкеша? > Тогда бы nginx считывал ссылку и от давал файл без какого либо скрипта > в бекенде. > > Вся задача сводится к убиранию бекенда. > > > можно даже без мемкэша обойтись, просто соберите nginx с опцией > --with-http_secure_link_module > > location /download/ { > rewrite /download/([a-zA-Z0-9_\-]*)/([0-9]*)/(.*)\.tgz$ /archive/$3.tgz?st=$1&e=$2; > } > > > location /archive/ { > internal; > secure_link $arg_st,$arg_e; > secure_link_md5 YOUR_SECRET_PASSWORD_HERE$arg_e$uri; > > if ($secure_link = "") { return 403; } > if ($secure_link = "0") { return 403; } > > > } > > YOUR_SECRET_PASSWORD_HERE - пароль, с помощью которого вы делаете шифр, > $arg_e - timestamp > пример того, как генерить урлы на Ruby здесь > https://gist.github.com/mikhailov/3174601 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Sun Apr 14 18:11:56 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Sun, 14 Apr 2013 19:11:56 +0100 Subject: =?UTF-8?B?UmU6INCf0L7QtNC80LXQvdCwINGD0YDQu9CwINGBINC+0YLQtNCw0YfQtdC5INGE?= =?UTF-8?B?0LDQudC70LA=?= In-Reply-To: References: <393F6BB5-84C8-4C57-84B8-1548A280D829@sonru.com> Message-ID: <0634474A-FDE6-4CE6-9B1D-B040AB42C80D@sonru.com> On Apr 14, 2013, at 6:32 PM, Роман wrote: > Дело в том, что ссылки не постоянные. > Короткая и настоящая лежат в базе. > определитесь что вам, все таки, нужно: - "без какого либо скрипта в бекенде" - "ссылки непостоянные, короткая и настоящая лежат в базе." Анатолий > > > 14 апреля 2013 г., 2:49 пользователь Anatoly Mikhailov написал: > > On Apr 13, 2013, at 10:45 PM, Роман wrote: > >> Есть задачка скрыть реальное нахождение файла и отдавать его по >> короткой ссылке. Например: заходим по ссылке >> http://site.com/03209393/file.tgz, скачивание идет по ссылке >> http://site.com/03209393/file.tgz, а на самом деле файл находится тут >> http://site.com/arhive/file.tgz >> >> Задача довольно простая на первый взгляд, если бы не одно но. >> >> Можно ли читать реальную ссылку не скриптом, а например из мемкеша? >> Тогда бы nginx считывал ссылку и от давал файл без какого либо скрипта >> в бекенде. >> >> Вся задача сводится к убиранию бекенда. > > можно даже без мемкэша обойтись, просто соберите nginx с опцией --with-http_secure_link_module > > location /download/ { > > rewrite /download/([a-zA-Z0-9_\-]*)/([0-9]*)/(.*)\.tgz$ /archive/$3.tgz?st=$1&e=$2; > } > > location /archive/ { > internal; > secure_link $arg_st,$arg_e; > secure_link_md5 YOUR_SECRET_PASSWORD_HERE$arg_e$uri; > > > if ($secure_link = "") { return 403; } > if ($secure_link = "0") { return 403; } > > } > > YOUR_SECRET_PASSWORD_HERE - пароль, с помощью которого вы делаете шифр, $arg_e - timestamp > пример того, как генерить урлы на Ruby здесь https://gist.github.com/mikhailov/3174601 > >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.g.i.n.x.e.r at gmail.com Sun Apr 14 18:28:13 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Sun, 14 Apr 2013 22:28:13 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC80LXQvdCwINGD0YDQu9CwINGBINC+0YLQtNCw0YfQtdC5INGE?= =?UTF-8?B?0LDQudC70LA=?= In-Reply-To: <0634474A-FDE6-4CE6-9B1D-B040AB42C80D@sonru.com> References: <393F6BB5-84C8-4C57-84B8-1548A280D829@sonru.com> <0634474A-FDE6-4CE6-9B1D-B040AB42C80D@sonru.com> Message-ID: При генерации файла инфа о нем кладется в бд и мемкеш а при отдаче всего то надо взять одно значение из мемкеша вот и думаю как бы это сделать с минимальными потерями. 14 апреля 2013 г., 22:11 пользователь Anatoly Mikhailov написал: > > On Apr 14, 2013, at 6:32 PM, Роман wrote: > > Дело в том, что ссылки не постоянные. > Короткая и настоящая лежат в базе. > > > определитесь что вам, все таки, нужно: > - "без какого либо скрипта в бекенде" > - "ссылки непостоянные, короткая и настоящая лежат в базе." > > Анатолий > > > > 14 апреля 2013 г., 2:49 пользователь Anatoly Mikhailov написал: > >> >> On Apr 13, 2013, at 10:45 PM, Роман wrote: >> >> Есть задачка скрыть реальное нахождение файла и отдавать его по >> короткой ссылке. Например: заходим по ссылке >> http://site.com/03209393/file.tgz, скачивание идет по ссылке >> http://site.com/03209393/file.tgz, а на самом деле файл находится тут >> http://site.com/arhive/file.tgz >> >> Задача довольно простая на первый взгляд, если бы не одно но. >> >> Можно ли читать реальную ссылку не скриптом, а например из мемкеша? >> Тогда бы nginx считывал ссылку и от давал файл без какого либо скрипта >> в бекенде. >> >> Вся задача сводится к убиранию бекенда. >> >> >> можно даже без мемкэша обойтись, просто соберите nginx с опцией >> --with-http_secure_link_module >> >> location /download/ { >> rewrite /download/([a-zA-Z0-9_\-]*)/([0-9]*)/(.*)\.tgz$ /archive/$3.tgz?st=$1&e=$2; >> } >> >> >> location /archive/ { >> internal; >> secure_link $arg_st,$arg_e; >> secure_link_md5 YOUR_SECRET_PASSWORD_HERE$arg_e$uri; >> >> >> if ($secure_link = "") { return 403; } >> if ($secure_link = "0") { return 403; } >> >> >> } >> >> YOUR_SECRET_PASSWORD_HERE - пароль, с помощью которого вы делаете шифр, >> $arg_e - timestamp >> пример того, как генерить урлы на Ruby здесь >> https://gist.github.com/mikhailov/3174601 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Apr 15 00:21:59 2013 From: nginx-forum at nginx.us (mj_nooker) Date: Sun, 14 Apr 2013 20:21:59 -0400 Subject: nginx + phpPgAdmin Message-ID: <4eba20f5e2a73a0f0d0dea08401d735e.NginxMailingListRussian@forum.nginx.org> Привет! FreeBsd + nginx + php-fpm + phpPgAdmin. Есть сайт site.com Он лежит в /var/www/sites/site.com/public Надо к нему прикрутить phpPgAdmin. Он лежит в /usr/local/www/phpPgAdmin Начитался документации и примеров nginx + phpMyAdmin. Настроил nginx.conf Сайт работает (blitz, php) phpPgAdmin - нет. Если набираю site.com/pgadmin - пишет No input file specified. Если набираю site.com/pgadmin/index.html (тестовый статический /usr/local/www/phpPgAdmin/index.html) - все ок, html отображается. Конфиг nginx: user www www; worker_processes 2; error_log /var/log/nginx/nginx-error.log; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; server_names_hash_bucket_size 64; access_log /var/log/nginx/access.log; sendfile on; client_max_body_size 2000m; keepalive_timeout 60; include /usr/local/etc/nginx/Include/site.com.conf; } Конфиг Include/site.com.conf : server { listen 91.203.31.184:80; server_name site.com www.site.com; sendfile on; client_max_body_size 2000m; keepalive_timeout 60; location / { root /var/www/sites/site.com/public; try_files $uri $uri/ /index.php?route=$uri&$args; index index.html index.php; add_header Last-Modified ""; } location /pgadmin/ { alias /usr/local/www/phpPgAdmin/; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include /usr/local/etc/nginx/fastcgi_params; } server_name_in_redirect off; location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/sites/site.com/public$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param REDIRECT_STATUS 200; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; fastcgi_connect_timeout 60; fastcgi_ignore_client_abort on; fastcgi_intercept_errors on; fastcgi_read_timeout 60; fastcgi_send_timeout 60; charset utf-8; fastcgi_cache_valid 200 301 302 304 1m; fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; fastcgi_ignore_headers "Cache-Control" "Expires"; fastcgi_hide_header "Cache-Control"; add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"; fastcgi_hide_header "Pragma"; add_header Pragma "no-cache"; expires -1; add_header Last-Modified $sent_http_Expires; fastcgi_buffer_size 512k; fastcgi_buffers 4 512k; fastcgi_busy_buffers_size 512k; fastcgi_temp_file_write_size 512k; } } Пожалуйста, подскажите, где может быть ошибка? Два дня промучился, глаза красные, а толку нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238367,238367#msg-238367 From dedukhin at mail.ru Mon Apr 15 03:09:12 2013 From: dedukhin at mail.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JTQtdC00Y7RhdC40L0=?=) Date: Mon, 15 Apr 2013 07:09:12 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0L7QtNC80LXQvdCwINGD0YDQu9CwINGBINC+0YLQtNCw0YfQtdC5?= =?UTF-8?B?INGE0LDQudC70LA=?= In-Reply-To: References: <0634474A-FDE6-4CE6-9B1D-B040AB42C80D@sonru.com> Message-ID: <1365995352.785989104@f286.mail.ru> Воскресенье, 14 апреля 2013, 22:28 +04:00 от Роман : > > При генерации файла инфа о нем кладется в бд и мемкеш > а при отдаче всего то надо взять одно значение из мемкеша > вот и думаю как бы это сделать с минимальными потерями. > > > 14 апреля 2013 г., 22:11 пользователь Anatoly Mikhailov < anatoly at sonru.com > написал: > > > >On Apr 14, 2013, at 6:32 PM, Роман < n.g.i.n.x.e.r at gmail.com > wrote: > >>Дело в том, что ссылки не постоянные. > >>Короткая и настоящая лежат в базе. > >> > > > >определитесь что вам, все таки, нужно: > >- "без какого либо скрипта в бекенде" > >- "ссылки непостоянные, короткая и настоящая лежат в базе." > > > >Анатолий > > > >> > >> > >>14 апреля 2013 г., 2:49 пользователь Anatoly Mikhailov < anatoly at sonru.com > написал: > >>> > >>>On Apr 13, 2013, at 10:45 PM, Роман < n.g.i.n.x.e.r at gmail.com > wrote: > >>>>Есть задачка скрыть реальное нахождение файла и отдавать его по > >>>>короткой ссылке. Например: заходим по ссылке > >>>>http://site.com/03209393/file.tgz , скачивание идет по ссылке > >>>>http://site.com/03209393/file.tgz , а на самом деле файл находится тут > >>>>http://site.com/arhive/file.tgz > >>>> > >>>>Задача довольно простая на первый взгляд, если бы не одно но. > >>>> > >>>>Можно ли читать реальную ссылку не скриптом, а например из мемкеша? > >>>>Тогда бы nginx считывал ссылку и от давал файл без какого либо скрипта > >>>>в бекенде. > >>>> > >>>>Вся задача сводится к убиранию бекенда. > >>> > >>>можно даже без мемкэша обойтись, просто соберите nginx с опцией  --with-http_secure_link_module > >>> > >>> location /download/ { > > > > >>> rewrite /download/([a-zA-Z0-9_\-]*)/([0-9]*)/(.*)\.tgz$ /archive/$3.tgz?st=$1&e=$2; > >>> } > >>> > >>> > > >>> location /archive/ { > >>> internal; > >>> secure_link $arg_st,$arg_e; > >>> secure_link_md5 YOUR_SECRET_PASSWORD_HERE$arg_e$uri; > >>>  > >>> > > if ($secure_link = "") { return 403; } > >>> if ($secure_link = "0") { return 403; } > >>>  > >>>             } > >>> > >>>YOUR_SECRET_PASSWORD_HERE - пароль, с помощью которого вы делаете шифр, $arg_e - timestamp > >>>пример того, как генерить урлы на Ruby здесь  https://gist.github.com/mikhailov/3174601 > >>> > >>>>_______________________________________________ > >>>>nginx-ru mailing list > >>>>nginx-ru at nginx.org > >>>>http://mailman.nginx.org/mailman/listinfo/nginx-ru > >>> > >>>_______________________________________________ > >>>nginx-ru mailing list > >>>nginx-ru at nginx.org > >>>http://mailman.nginx.org/mailman/listinfo/nginx-ru > >> > >>_______________________________________________ > >>nginx-ru mailing list > >>nginx-ru at nginx.org > >>http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > >_______________________________________________ > >nginx-ru mailing list > >nginx-ru at nginx.org > >http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Посмотрите на eval-модуль, это именно то, что нужно вам. From nginx-forum at nginx.us Mon Apr 15 13:46:29 2013 From: nginx-forum at nginx.us (skeletor) Date: Mon, 15 Apr 2013 09:46:29 -0400 Subject: nginx/freebsd and broken sockets In-Reply-To: <20130414171647.GB92338@mdounin.ru> References: <20130414171647.GB92338@mdounin.ru> Message-ID: <439fbfe65bdfeda843bd7426ea3fc46e.NginxMailingListRussian@forum.nginx.org> Просто теперь расширили функционал sockstat, который показывает соединения, которые не принадлежат никаким файловым декстрипторам. Раньше именно это и отличало sockstat от netstat (он их показывал). Вот выдержка из оригинального сообщения: The change between 8.2 and 8.3 is that sockstat now also shows sockets that are not associated with a file descriptor. Formerly, these were not shown, causing a discrepancy between sockstat and netstat -a because netstat has always shown them. In your case, the sockets on port 2049 are associated with the kernel NFS client and server. The other TCP sockets are likely in TIME_WAIT or a similar state. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238337,238373#msg-238373 From corochoone at gmail.com Mon Apr 15 19:56:12 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Mon, 15 Apr 2013 23:56:12 +0400 Subject: =?UTF-8?B?0J7RgtGA0LDQsdC+0YLQutCwINC70LjQvNC40YLQvtCyLCDQstC+0L/RgNC+0YE=?= Message-ID: Сегодня столкнулся со странной вещью Стоит nginx 1.2.7 В нём сделаны ограничения по виртуалхостам с помощью limit_conn_zone и limit_conn Всё работало идеально до сегодняшнего вечера. Случилась атака на сайт и смотрю в apache /server-status что куча коннектов к тому виртуалхосту, к которому их быть не должно согласно limit_conn больше 5. Полез разбираться в логи. В логах я вижу сработавшие limit_conn 2013/04/16 01:52:21 [error] 11652#0: *248356 limiting connections by zone "from_all_limit", client: 196.205.118.51, server: XXXXXX.net, request: "GET / HTTP/1.1", host: "XXXXXX.net", referrer: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" всё бы классно, но почему тогда столько коннектов висит на апачах? Посмотрел ещё лог nginx, много 400-х Тогда возникла мысль, а не происходит ли следующее: 1. Клиент запрашивает у nginx страницу, но не дожидаясь её обрывает соединение 2. nginx передаёт запрос апачу и ждёт от него ответа, но поскольку клиент соединение закрыл из limit_conn оно удаляется. 3. вот и получается картина, что у апача есть куча запросов, которые он обрабатывает, но которые уже не нужны ни nginx'У ни клиенту Поскольку я не разбираюсь в тонкостях реализации, написал сюда. Я прав, так всё и просиходит? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Apr 15 20:04:34 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2013 00:04:34 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: References: Message-ID: <20130415200434.GK92338@mdounin.ru> Hello! On Mon, Apr 15, 2013 at 11:56:12PM +0400, Виктор Вислобоков wrote: > Сегодня столкнулся со странной вещью > Стоит nginx 1.2.7 > В нём сделаны ограничения по виртуалхостам с помощью limit_conn_zone и > limit_conn > Всё работало идеально до сегодняшнего вечера. > Случилась атака на сайт и смотрю в apache /server-status что куча коннектов > к тому виртуалхосту, к которому их быть не должно согласно limit_conn > больше 5. > Полез разбираться в логи. > В логах я вижу сработавшие limit_conn > > > 2013/04/16 01:52:21 [error] 11652#0: *248356 limiting connections by zone > "from_all_limit", client: 196.205.118.51, server: XXXXXX.net, request: "GET > / HTTP/1.1", host: "XXXXXX.net", referrer: > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" > > всё бы классно, но почему тогда столько коннектов висит на апачах? > Посмотрел ещё лог nginx, много 400-х > Тогда возникла мысль, а не происходит ли следующее: > > 1. Клиент запрашивает у nginx страницу, но не дожидаясь её обрывает > соединение > 2. nginx передаёт запрос апачу и ждёт от него ответа, но поскольку клиент > соединение закрыл из limit_conn оно удаляется. > 3. вот и получается картина, что у апача есть куча запросов, которые он > обрабатывает, но которые уже не нужны ни nginx'У ни клиенту > > Поскольку я не разбираюсь в тонкостях реализации, написал сюда. Я прав, так > всё и просиходит? Да, так вполне может происходить. На всякий случай отмечу, что поведением nginx'а в подобной ситуации можно управлять с помощью директивы proxy_ignore_client_abort (http://nginx.org/r/proxy_ignore_client_abort), но для большинства задач поведение по умолчанию наиболее разумно. -- Maxim Dounin http://nginx.org/en/donation.html From corochoone at gmail.com Mon Apr 15 20:08:37 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Tue, 16 Apr 2013 00:08:37 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <20130415200434.GK92338@mdounin.ru> References: <20130415200434.GK92338@mdounin.ru> Message-ID: Огромное спасибо за подсказку. После активации данной директивы всё стало работать так, как мне надо! 16 апреля 2013 г., 0:04 пользователь Maxim Dounin написал: > Hello! > > On Mon, Apr 15, 2013 at 11:56:12PM +0400, Виктор Вислобоков wrote: > > > Сегодня столкнулся со странной вещью > > Стоит nginx 1.2.7 > > В нём сделаны ограничения по виртуалхостам с помощью limit_conn_zone и > > limit_conn > > Всё работало идеально до сегодняшнего вечера. > > Случилась атака на сайт и смотрю в apache /server-status что куча > коннектов > > к тому виртуалхосту, к которому их быть не должно согласно limit_conn > > больше 5. > > Полез разбираться в логи. > > В логах я вижу сработавшие limit_conn > > > > > > 2013/04/16 01:52:21 [error] 11652#0: *248356 limiting connections by zone > > "from_all_limit", client: 196.205.118.51, server: XXXXXX.net, request: > "GET > > / HTTP/1.1", host: "XXXXXX.net", referrer: > > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" > > > > всё бы классно, но почему тогда столько коннектов висит на апачах? > > Посмотрел ещё лог nginx, много 400-х > > Тогда возникла мысль, а не происходит ли следующее: > > > > 1. Клиент запрашивает у nginx страницу, но не дожидаясь её обрывает > > соединение > > 2. nginx передаёт запрос апачу и ждёт от него ответа, но поскольку клиент > > соединение закрыл из limit_conn оно удаляется. > > 3. вот и получается картина, что у апача есть куча запросов, которые он > > обрабатывает, но которые уже не нужны ни nginx'У ни клиенту > > > > Поскольку я не разбираюсь в тонкостях реализации, написал сюда. Я прав, > так > > всё и просиходит? > > Да, так вполне может происходить. > > На всякий случай отмечу, что поведением nginx'а в подобной > ситуации можно управлять с помощью директивы > proxy_ignore_client_abort (http://nginx.org/r/proxy_ignore_client_abort), > но для большинства задач поведение по умолчанию наиболее разумно. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Mon Apr 15 20:09:09 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 16 Apr 2013 00:09:09 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: References: Message-ID: <201304160009.09730.vbart@nginx.com> On Monday 15 April 2013 23:56:12 Виктор Вислобоков wrote: > Сегодня столкнулся со странной вещью > Стоит nginx 1.2.7 > В нём сделаны ограничения по виртуалхостам с помощью limit_conn_zone и > limit_conn > Всё работало идеально до сегодняшнего вечера. > Случилась атака на сайт и смотрю в apache /server-status что куча коннектов > к тому виртуалхосту, к которому их быть не должно согласно limit_conn > больше 5. > Полез разбираться в логи. > В логах я вижу сработавшие limit_conn > > > 2013/04/16 01:52:21 [error] 11652#0: *248356 limiting connections by zone > "from_all_limit", client: 196.205.118.51, server: XXXXXX.net, request: "GET > / HTTP/1.1", host: "XXXXXX.net", referrer: > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" > > всё бы классно, но почему тогда столько коннектов висит на апачах? > Посмотрел ещё лог nginx, много 400-х > Тогда возникла мысль, а не происходит ли следующее: > > 1. Клиент запрашивает у nginx страницу, но не дожидаясь её обрывает > соединение > 2. nginx передаёт запрос апачу и ждёт от него ответа, но поскольку клиент > соединение закрыл из limit_conn оно удаляется. Не удаляется. Счетчик в модуле limit_conn никак не связан с клиентским соединением. > 3. вот и получается картина, что у апача есть куча запросов, которые он > обрабатывает, но которые уже не нужны ни nginx'У ни клиенту > > Поскольку я не разбираюсь в тонкостях реализации, написал сюда. Я прав, так > всё и просиходит? Нет, не так. -- Валентин Бартенев http://nginx.org/en/donation.html From mdounin at mdounin.ru Mon Apr 15 22:00:54 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2013 02:00:54 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <201304160009.09730.vbart@nginx.com> References: <201304160009.09730.vbart@nginx.com> Message-ID: <20130415220054.GM92338@mdounin.ru> Hello! On Tue, Apr 16, 2013 at 12:09:09AM +0400, Валентин Бартенев wrote: > On Monday 15 April 2013 23:56:12 Виктор Вислобоков wrote: > > Сегодня столкнулся со странной вещью > > Стоит nginx 1.2.7 > > В нём сделаны ограничения по виртуалхостам с помощью limit_conn_zone и > > limit_conn > > Всё работало идеально до сегодняшнего вечера. > > Случилась атака на сайт и смотрю в apache /server-status что куча коннектов > > к тому виртуалхосту, к которому их быть не должно согласно limit_conn > > больше 5. > > Полез разбираться в логи. > > В логах я вижу сработавшие limit_conn > > > > > > 2013/04/16 01:52:21 [error] 11652#0: *248356 limiting connections by zone > > "from_all_limit", client: 196.205.118.51, server: XXXXXX.net, request: "GET > > / HTTP/1.1", host: "XXXXXX.net", referrer: > > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" > > > > всё бы классно, но почему тогда столько коннектов висит на апачах? > > Посмотрел ещё лог nginx, много 400-х > > Тогда возникла мысль, а не происходит ли следующее: > > > > 1. Клиент запрашивает у nginx страницу, но не дожидаясь её обрывает > > соединение > > 2. nginx передаёт запрос апачу и ждёт от него ответа, но поскольку клиент > > соединение закрыл из limit_conn оно удаляется. > > Не удаляется. Счетчик в модуле limit_conn никак не связан с клиентским > соединением. Счётчик limit_conn связан с запросом, который завершается, когда клиент закрывает соединение. > > 3. вот и получается картина, что у апача есть куча запросов, которые он > > обрабатывает, но которые уже не нужны ни nginx'У ни клиенту > > > > Поскольку я не разбираюсь в тонкостях реализации, написал сюда. Я прав, так > > всё и просиходит? > > Нет, не так. Так, так. -- Maxim Dounin http://nginx.org/en/donation.html From denis at webmaster.spb.ru Tue Apr 16 00:43:29 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 16 Apr 2013 04:43:29 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <20130415200434.GK92338@mdounin.ru> References: <20130415200434.GK92338@mdounin.ru> Message-ID: <516C9EB1.1040100@webmaster.spb.ru> 16.04.2013 0:04, Maxim Dounin пишет: > но для большинства задач поведение по умолчанию наиболее разумно. > А почему? Ведь получается, что это потенциальный вектор для атаки. From mdounin at mdounin.ru Tue Apr 16 11:41:28 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2013 15:41:28 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <516C9EB1.1040100@webmaster.spb.ru> References: <20130415200434.GK92338@mdounin.ru> <516C9EB1.1040100@webmaster.spb.ru> Message-ID: <20130416114128.GR92338@mdounin.ru> Hello! On Tue, Apr 16, 2013 at 04:43:29AM +0400, denis wrote: > 16.04.2013 0:04, Maxim Dounin пишет: > >но для большинства задач поведение по умолчанию наиболее разумно. > > > А почему? Ведь получается, что это потенциальный вектор для атаки. Поведение по умолчанию - закрыть соединение с бекендом, если клиент закрыл соединение с nginx'ом. И это позволяет, при грамотном программировании на бекенде, не тратить ресурсы на дальнейшую обработку таких запросов. Ну и в любом случае - экономит ресурсы на nginx'е. Противоположный вариант работы - дожидаться ответа от бекенда, даже если клиент закрыл соединение - редко когда имеет смысл сам по себе. В конкретном обсуждаемом случае - его применимость является следствием того факта, что лимитируется количество соединений в nginx'е, в то время как на самом деле - предполагается лимитировать количество занятых процессов бекенда. -- Maxim Dounin http://nginx.org/en/donation.html From denis at webmaster.spb.ru Tue Apr 16 11:52:22 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 16 Apr 2013 15:52:22 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <20130416114128.GR92338@mdounin.ru> References: <20130415200434.GK92338@mdounin.ru> <516C9EB1.1040100@webmaster.spb.ru> <20130416114128.GR92338@mdounin.ru> Message-ID: <516D3B76.3050503@webmaster.spb.ru> 16.04.2013 15:41, Maxim Dounin пишет: > Hello! > > On Tue, Apr 16, 2013 at 04:43:29AM +0400, denis wrote: > >> 16.04.2013 0:04, Maxim Dounin пишет: >>> но для большинства задач поведение по умолчанию наиболее разумно. >>> >> А почему? Ведь получается, что это потенциальный вектор для атаки. > Поведение по умолчанию - закрыть соединение с бекендом, если > клиент закрыл соединение с nginx'ом. И это позволяет, при > грамотном программировании на бекенде, не тратить ресурсы на > дальнейшую обработку таких запросов. Ну и в любом случае - > экономит ресурсы на nginx'е. Оффтопик, но интересно как такое вообще можно сделать. Ну закрыл соединение nginx (забудем про свежие версии нгинха, которые умеют http 1.1 и keep-alive соединения с апачем), но теперь надо это понять апачу, прибить запросы к базе и выполнение запрошенного скрипта.. и чтобы это всё было корректно. From universite at ukr.net Tue Apr 16 11:56:47 2013 From: universite at ukr.net (Vladislav Prodan) Date: Tue, 16 Apr 2013 14:56:47 +0300 Subject: =?UTF-8?B?UmVbMl06INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/?= =?UTF-8?B?0YDQvtGB?= In-Reply-To: <516D3B76.3050503@webmaster.spb.ru> References: <20130415200434.GK92338@mdounin.ru> <516C9EB1.1040100@webmaster.spb.ru> <20130416114128.GR92338@mdounin.ru> <516D3B76.3050503@webmaster.spb.ru> Message-ID: <28205.1366113407.16054880555363336192@ffe6.ukr.net> --- Исходное сообщение --- От кого: "denis" Дата: 16 апреля 2013, 14:52:34 > Оффтопик, но интересно как такое вообще можно сделать. Ну закрыл > соединение nginx (забудем про свежие версии нгинха, которые умеют http > 1.1 и keep-alive соединения с апачем), но теперь надо это понять апачу, > прибить запросы к базе и выполнение запрошенного скрипта.. и чтобы это > всё было корректно. +1 А то Апач как попка-дурак делает ненужную работу... Увеличивает энтропию... -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From mdounin at mdounin.ru Tue Apr 16 12:09:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2013 16:09:07 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <516D3B76.3050503@webmaster.spb.ru> References: <20130415200434.GK92338@mdounin.ru> <516C9EB1.1040100@webmaster.spb.ru> <20130416114128.GR92338@mdounin.ru> <516D3B76.3050503@webmaster.spb.ru> Message-ID: <20130416120906.GU92338@mdounin.ru> Hello! On Tue, Apr 16, 2013 at 03:52:22PM +0400, denis wrote: > 16.04.2013 15:41, Maxim Dounin пишет: > >Hello! > > > >On Tue, Apr 16, 2013 at 04:43:29AM +0400, denis wrote: > > > >>16.04.2013 0:04, Maxim Dounin пишет: > >>>но для большинства задач поведение по умолчанию наиболее разумно. > >>> > >>А почему? Ведь получается, что это потенциальный вектор для атаки. > >Поведение по умолчанию - закрыть соединение с бекендом, если > >клиент закрыл соединение с nginx'ом. И это позволяет, при > >грамотном программировании на бекенде, не тратить ресурсы на > >дальнейшую обработку таких запросов. Ну и в любом случае - > >экономит ресурсы на nginx'е. > Оффтопик, но интересно как такое вообще можно сделать. Ну закрыл > соединение nginx (забудем про свежие версии нгинха, которые умеют > http 1.1 и keep-alive соединения с апачем), но теперь надо это > понять апачу, прибить запросы к базе и выполнение запрошенного > скрипта.. и чтобы это всё было корректно. В теории, в каком-нибудь php это даже должно быть поведением по умолчанию: http://www.php.net/manual/en/features.connection-handling.php http://www.php.net/manual/en/function.ignore-user-abort.php В mod_perl, если мне не изменяет память, можно было периодически делать соответствующую проверку из своего кода: http://perl.apache.org/docs/2.0/api/Apache2/Connection.html#C_aborted_ -- Maxim Dounin http://nginx.org/en/donation.html From gmm at csdoc.com Tue Apr 16 12:09:52 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 16 Apr 2013 15:09:52 +0300 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <20130416114128.GR92338@mdounin.ru> References: <20130415200434.GK92338@mdounin.ru> <516C9EB1.1040100@webmaster.spb.ru> <20130416114128.GR92338@mdounin.ru> Message-ID: <516D3F90.5020604@csdoc.com> On 16.04.2013 14:41, Maxim Dounin wrote: > ...лимитируется количество > соединений в nginx'е, в то время как на самом деле - > предполагается лимитировать количество занятых процессов бекенда. а разве можно как-то другим способом лимитировать количество занятых процессов бекенда в nginx, кроме установки haproxy между nginx и apache? -- Best regards, Gena From mdounin at mdounin.ru Tue Apr 16 12:15:05 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2013 16:15:05 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgNCw0LHQvtGC0LrQsCDQu9C40LzQuNGC0L7Qsiwg0LLQvtC/0YA=?= =?UTF-8?B?0L7RgQ==?= In-Reply-To: <516D3F90.5020604@csdoc.com> References: <20130415200434.GK92338@mdounin.ru> <516C9EB1.1040100@webmaster.spb.ru> <20130416114128.GR92338@mdounin.ru> <516D3F90.5020604@csdoc.com> Message-ID: <20130416121504.GV92338@mdounin.ru> Hello! On Tue, Apr 16, 2013 at 03:09:52PM +0300, Gena Makhomed wrote: > On 16.04.2013 14:41, Maxim Dounin wrote: > > >...лимитируется количество > >соединений в nginx'е, в то время как на самом деле - > >предполагается лимитировать количество занятых процессов бекенда. > > а разве можно как-то другим способом лимитировать количество занятых > процессов бекенда в nginx, кроме установки haproxy между nginx и apache? С теоретической точки зрения - лимитировать количество занятых процессов бекенда можно только на бекенде, во всех других местах - информация будет лишь приблизительной. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue Apr 16 14:21:30 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Apr 2013 18:21:30 +0400 Subject: nginx-1.3.16 Message-ID: <20130416142130.GA92338@mdounin.ru> Изменения в nginx 1.3.16 16.04.2013 *) Исправление: в рабочем процессе мог произойти segmentation fault, если использовались подзапросы; ошибка появилась в 1.3.9. *) Исправление: директива tcp_nodelay вызывала ошибку при проксировании WebSocket-соединений в unix domain сокет. *) Исправление: переменная $upstream_response_length возвращала значение "0", если не использовалась буферизация. Спасибо Piotr Sikora. *) Исправление: в методах обработки соединений eventport и /dev/poll. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Apr 17 04:25:30 2013 From: nginx-forum at nginx.us (INF[SZ]) Date: Wed, 17 Apr 2013 00:25:30 -0400 Subject: nginx-1.3.16 In-Reply-To: <20130416142130.GA92338@mdounin.ru> References: <20130416142130.GA92338@mdounin.ru> Message-ID: <1e36883d0ef38aa7eb637c1386d373dc.NginxMailingListRussian@forum.nginx.org> В 1.3.16 появилась ошибка сборки с параметром --without-http ошибка при компиляции nginx.xs:12:22: error: ngx_http.h: Нет такого файла или каталога nginx.xs:13:34: error: ngx_http_perl_module.h: Нет такого файла или каталога nginx.xs:30: ошибка: expected ?)? before ?ngx_http_request_t? nginx.xs:67: ошибка: expected ?)? before ?*? token nginx.c:109: ошибка: expected ?)? before ?CV? nginx.c:110: ошибка: expected ?)? before ?CV? nginx.c:133: ошибка: expected ?)? before ?CV? nginx.c:134: ошибка: expected ?)? before ?CV? nginx.c:174: ошибка: expected ?)? before ?CV? nginx.c:175: ошибка: expected ?)? before ?CV? nginx.c:197: ошибка: expected ?)? before ?CV? nginx.c:198: ошибка: expected ?)? before ?CV? nginx.c:218: ошибка: expected ?)? before ?CV? nginx.c:219: ошибка: expected ?)? before ?CV? nginx.c:239: ошибка: expected ?)? before ?CV? nginx.c:240: ошибка: expected ?)? before ?CV? nginx.c:260: ошибка: expected ?)? before ?CV? nginx.c:261: ошибка: expected ?)? before ?CV? nginx.c:282: ошибка: expected ?)? before ?CV? nginx.c:283: ошибка: expected ?)? before ?CV? nginx.c:422: ошибка: expected ?)? before ?CV? nginx.c:423: ошибка: expected ?)? before ?CV? nginx.c:463: ошибка: expected ?)? before ?CV? nginx.c:464: ошибка: expected ?)? before ?CV? nginx.c:499: ошибка: expected ?)? before ?CV? nginx.c:500: ошибка: expected ?)? before ?CV? nginx.c:526: ошибка: expected ?)? before ?CV? nginx.c:527: ошибка: expected ?)? before ?CV? nginx.c:545: ошибка: expected ?)? before ?CV? nginx.c:546: ошибка: expected ?)? before ?CV? nginx.c:598: ошибка: expected ?)? before ?CV? nginx.c:599: ошибка: expected ?)? before ?CV? nginx.c:636: ошибка: expected ?)? before ?CV? nginx.c:637: ошибка: expected ?)? before ?CV? nginx.c:740: ошибка: expected ?)? before ?CV? nginx.c:741: ошибка: expected ?)? before ?CV? nginx.c:838: ошибка: expected ?)? before ?CV? nginx.c:839: ошибка: expected ?)? before ?CV? nginx.c:869: ошибка: expected ?)? before ?CV? nginx.c:870: ошибка: expected ?)? before ?CV? nginx.c:908: ошибка: expected ?)? before ?CV? nginx.c:909: ошибка: expected ?)? before ?CV? nginx.c:927: ошибка: expected ?)? before ?CV? nginx.c:928: ошибка: expected ?)? before ?CV? nginx.c:969: ошибка: expected ?)? before ?CV? nginx.c:970: ошибка: expected ?)? before ?CV? nginx.c:1111: ошибка: expected ?)? before ?CV? nginx.c:1112: ошибка: expected ?)? before ?CV? nginx.c:1144: ошибка: expected ?)? before ?CV? nginx.c:1145: ошибка: expected ?)? before ?CV? nginx.c:1185: ошибка: expected ?)? before ?CV? nginx.c:1186: ошибка: expected ?)? before ?CV? make[2]: *** [nginx.o] Ошибка 1 Версия 1.3.15 собирается нормально Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238411,238421#msg-238421 From mdounin at mdounin.ru Wed Apr 17 11:39:18 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 17 Apr 2013 15:39:18 +0400 Subject: nginx-1.3.16 In-Reply-To: <1e36883d0ef38aa7eb637c1386d373dc.NginxMailingListRussian@forum.nginx.org> References: <20130416142130.GA92338@mdounin.ru> <1e36883d0ef38aa7eb637c1386d373dc.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130417113918.GE92338@mdounin.ru> Hello! On Wed, Apr 17, 2013 at 12:25:30AM -0400, INF[SZ] wrote: > В 1.3.16 появилась ошибка сборки с параметром --without-http > > ошибка при компиляции > > nginx.xs:12:22: error: ngx_http.h: Нет такого файла или каталога > nginx.xs:13:34: error: ngx_http_perl_module.h: Нет такого файла или > каталога [...] Гхм, --without-http, но при этом --with-http_perl_module? Как выглядят параметры ./configure полностью? Ну то есть можно, конечно, и такое обрабатывать, но как по мне, то сломаться при сборке в случае подобного противоречия флагов ./configure - вполне допустимое поведение. -- Maxim Dounin http://nginx.org/en/donation.html From alex.barut at gmail.com Wed Apr 17 12:14:08 2013 From: alex.barut at gmail.com (Alex Belyansky) Date: Wed, 17 Apr 2013 16:14:08 +0400 Subject: =?UTF-8?B?0J7QsdGA0LDQsdC+0YLQutCwIDUwMiDQvtGI0LjQsdC60Lgg0LIg0LjQvNC10L0=?= =?UTF-8?B?0L7QstCw0L3QvdC+0Lwg0LvQvtC60LXQudGI0LXQvdC1?= Message-ID: <516E9210.1020906@gmail.com> Добрый день! Имею вот такое в конфигурации: error_page 500 501 502 503 504 /500.html; location / { try_files $uri $uri/ @upstream; error_page 404 = @upstream; error_page 403 = @upstream; } location @upstream { proxy_pass http://backend; } Когда нет связи с бекендом и при этом запрашивается несуществующая страница (404), то nginx нормально отображает мою 500.html А вот когда запрашивается страница с ошибкой по правам доступа (403), то nginx отображает свою дефолтовую страницу, вместо моей 500.html Что делаю не так? Где что прописать, чтобы нормально отображалась моя 500.html для ситуации с 403-ей ? From nginx-forum at nginx.us Wed Apr 17 12:59:53 2013 From: nginx-forum at nginx.us (FireFenix) Date: Wed, 17 Apr 2013 08:59:53 -0400 Subject: =?UTF-8?B?W1dpbmRvd3MgKyBmYXN0Y2dpICsgcGhwXSDQktCw0LvQuNGC0YHRjyDQuNC70Lgg?= =?UTF-8?B?0L/QtdGA0LXRgdGC0LDRkdGCINC+0YLQstC10YfQsNGC0Yw=?= Message-ID: <5327f9d9d1a46d9772b9423528d15faf.NginxMailingListRussian@forum.nginx.org> Здраствуйте %user_name%. Я новичёк ине давно начал знакомство с nginx, и прошу помощи: Имеется относительно старенький дедик Dual Core AMD Opteron 2.2Ghz и 2 Gb RAM На котором: * Windows Server 2003 Standart Edition SP2 * nginx 1.3.16 * php 5.4.13 На котором получился конфиг worker_processes 2; worker_rlimit_nofile 163840; events { worker_connections 81920; } http { include mime.types; default_type application/octet-stream; sendfile on; tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 600s 600s; gzip on; server { listen 8080; server_name localhost; access_log off; #rewrite_log on; merge_slashes on; rewrite ^/path/(.*)$ /path/index.php; location / { root D:/Site; index index.html index.htm index.php; } location ~ \.php$ { root D:/Site; fastcgi_read_timeout 600s; fastcgi_send_timeout 600s; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } } Конфиг выше результирующий, вначале был дефолтный конфиг с прописанным fastcgi И при стандартном конфиге php-cgi.exe прибивалось на некотором запросе Использую программку ab из Апача для теста C:\>ab.exe -n 1000 -c 100 http://localhost:8080/index.php This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests apr_pollset_poll: The timeout specified has expired (70007) Total of 598 requests completed После этого php-cgi.exe улетало в космос. Поискал в доках, и начал увеличивать worker_rlimit_nofile = 163840 и worker_connections = 81920 Теперь картина другая, php-cgi не падает, но * При C:\>ab.exe -n 10 -c 10 http://localhost:8080/index.php спокойно проходит тест или при одиночных запросах из браузера * При C:\>ab.exe -n 1000 -c 100 http://localhost:8080/index.php ложиться и перестаёт отвечать, аналогичная картина если Ф5 зажать в браузере. Подумал, что проблема в таймаутах, и попробовал fastcgi_read_timeout = 600 и fastcgi_send_timeout = 600, но картина ничерта не изменилась. Причём кроме последнего случая в лог c параметром error ничего не выпадает, но в если включить лог debug, то в логе начинает спамить 2013/04/17 15:52:57 [debug] 3088#3300: select ready 0 2013/04/17 15:52:57 [debug] 3088#3300: timer delta: 500 2013/04/17 15:52:57 [debug] 3088#3300: posted events 00000000 2013/04/17 15:52:57 [debug] 3088#3300: worker cycle 2013/04/17 15:52:57 [debug] 3088#3300: accept mutex locked 2013/04/17 15:52:57 [debug] 3088#3300: select event: fd:156 wr:0 2013/04/17 15:52:57 [debug] 3088#3300: select timer: 500 2013/04/17 15:52:58 [debug] 212#2372: select ready 0 2013/04/17 15:52:58 [debug] 212#2372: timer delta: 500 2013/04/17 15:52:58 [debug] 212#2372: posted events 00000000 2013/04/17 15:52:58 [debug] 212#2372: worker cycle 2013/04/17 15:52:58 [debug] 212#2372: accept mutex lock failed: 0 2013/04/17 15:52:58 [debug] 212#2372: select timer: 500 даже при том, когда клиент закрыл соединение, ещё некоторое время идёт спам лога Так вот, товарищи знатоки, подскажите: * Почему конфиг выше перестаёт отдавать контент? * И как правильно настроить конфиг для ~500 юзеров работающих одновременно, при это которые могут слать запросы один за дргуим (т.е. не постоянно, а некоторым блоками запросов до ~100 запросов в секунду). Хотелось бы, чтобы контент отдавался в любом случае вне зависимости, от скорости выполнения, но в порядке очереди запросов. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238429,238429#msg-238429 From vbart at nginx.com Wed Apr 17 13:27:47 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 17 Apr 2013 17:27:47 +0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0gINCS0LDQu9C40YLRgdGPINC4?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <5327f9d9d1a46d9772b9423528d15faf.NginxMailingListRussian@forum.nginx.org> References: <5327f9d9d1a46d9772b9423528d15faf.NginxMailingListRussian@forum.nginx.org> Message-ID: <201304171727.47069.vbart@nginx.com> On Wednesday 17 April 2013 16:59:53 FireFenix wrote: > Здраствуйте %user_name%. Я новичёк ине давно начал знакомство с nginx, и > прошу помощи: > > Имеется относительно старенький дедик Dual Core AMD Opteron 2.2Ghz и 2 Gb > RAM > > На котором: > * Windows Server 2003 Standart Edition SP2 > * nginx 1.3.16 > * php 5.4.13 > > На котором получился конфиг > > worker_processes 2; > worker_rlimit_nofile 163840; > > events > { > worker_connections 81920; > } > > http > { > include mime.types; > default_type application/octet-stream; > > sendfile on; > tcp_nopush on; > > #keepalive_timeout 0; > keepalive_timeout 600s 600s; > > gzip on; > > server > { > listen 8080; > server_name localhost; > > access_log off; > #rewrite_log on; > > merge_slashes on; > > rewrite ^/path/(.*)$ /path/index.php; > > location / > { > root D:/Site; > index index.html index.htm index.php; > } > > location ~ \.php$ > { > root D:/Site; > > fastcgi_read_timeout 600s; > fastcgi_send_timeout 600s; > > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > include fastcgi_params; > } > > } > } > > Конфиг выше результирующий, вначале был дефолтный конфиг с прописанным > fastcgi > > И при стандартном конфиге php-cgi.exe прибивалось на некотором запросе > > Использую программку ab из Апача для теста > C:\>ab.exe -n 1000 -c 100 http://localhost:8080/index.php > This is ApacheBench, Version 2.3 <$Revision: 1430300 $> > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > Licensed to The Apache Software Foundation, http://www.apache.org/ > > Benchmarking localhost (be patient) > Completed 100 requests > Completed 200 requests > Completed 300 requests > Completed 400 requests > Completed 500 requests > apr_pollset_poll: The timeout specified has expired (70007) > Total of 598 requests completed > > После этого php-cgi.exe улетало в космос. > Поискал в доках, и начал увеличивать worker_rlimit_nofile = 163840 и > worker_connections = 81920 > > Теперь картина другая, php-cgi не падает, но > * При C:\>ab.exe -n 10 -c 10 http://localhost:8080/index.php спокойно > проходит тест или при одиночных запросах из браузера > * При C:\>ab.exe -n 1000 -c 100 http://localhost:8080/index.php ложиться и > перестаёт отвечать, аналогичная картина если Ф5 зажать в браузере. > > Подумал, что проблема в таймаутах, и попробовал fastcgi_read_timeout = 600 > и fastcgi_send_timeout = 600, но картина ничерта не изменилась. > > Причём кроме последнего случая в лог c параметром error ничего не выпадает, > но в если включить лог debug, то в логе начинает спамить > 2013/04/17 15:52:57 [debug] 3088#3300: select ready 0 > 2013/04/17 15:52:57 [debug] 3088#3300: timer delta: 500 > 2013/04/17 15:52:57 [debug] 3088#3300: posted events 00000000 > 2013/04/17 15:52:57 [debug] 3088#3300: worker cycle > 2013/04/17 15:52:57 [debug] 3088#3300: accept mutex locked > 2013/04/17 15:52:57 [debug] 3088#3300: select event: fd:156 wr:0 > 2013/04/17 15:52:57 [debug] 3088#3300: select timer: 500 > 2013/04/17 15:52:58 [debug] 212#2372: select ready 0 > 2013/04/17 15:52:58 [debug] 212#2372: timer delta: 500 > 2013/04/17 15:52:58 [debug] 212#2372: posted events 00000000 > 2013/04/17 15:52:58 [debug] 212#2372: worker cycle > 2013/04/17 15:52:58 [debug] 212#2372: accept mutex lock failed: 0 > 2013/04/17 15:52:58 [debug] 212#2372: select timer: 500 > даже при том, когда клиент закрыл соединение, ещё некоторое время идёт спам > лога > > Так вот, товарищи знатоки, подскажите: > * Почему конфиг выше перестаёт отдавать контент? На windows системах поддерживается не более 1024 соединений, смотрите: http://nginx.org/ru/docs/windows.html#known_issues -- Валентин Бартенев http://nginx.org/en/donation.html > * И как правильно настроить конфиг для ~500 юзеров работающих одновременно, > при это которые могут слать запросы один за дргуим (т.е. не постоянно, а > некоторым блоками запросов до ~100 запросов в секунду). > > Хотелось бы, чтобы контент отдавался в любом случае вне зависимости, от > скорости выполнения, но в порядке очереди запросов. > > Спасибо. From mdounin at mdounin.ru Wed Apr 17 13:43:22 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 17 Apr 2013 17:43:22 +0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0gINCS0LDQu9C40YLRgdGPINC4?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <201304171727.47069.vbart@nginx.com> References: <5327f9d9d1a46d9772b9423528d15faf.NginxMailingListRussian@forum.nginx.org> <201304171727.47069.vbart@nginx.com> Message-ID: <20130417134322.GG92338@mdounin.ru> Hello! On Wed, Apr 17, 2013 at 05:27:47PM +0400, Валентин Бартенев wrote: > On Wednesday 17 April 2013 16:59:53 FireFenix wrote: [...] > > worker_processes 2; Вот тут надо поставить 1. [...] > > Так вот, товарищи знатоки, подскажите: > > * Почему конфиг выше перестаёт отдавать контент? > > На windows системах поддерживается не более 1024 соединений, смотрите: > http://nginx.org/ru/docs/windows.html#known_issues "Перестаёт отдавать" - скорее всего следствие двух рабочих процессов. > > * И как правильно настроить конфиг для ~500 юзеров работающих одновременно, > > при это которые могут слать запросы один за дргуим (т.е. не постоянно, а > > некоторым блоками запросов до ~100 запросов в секунду). Ну и на всякий случай явно замечу, что "правильно настроить для ~500 юзеров" включает в себя заменить Windows на что-нибудь более другое. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Apr 17 14:53:21 2013 From: nginx-forum at nginx.us (INF[SZ]) Date: Wed, 17 Apr 2013 10:53:21 -0400 Subject: nginx-1.3.16 In-Reply-To: <20130417113918.GE92338@mdounin.ru> References: <20130417113918.GE92338@mdounin.ru> Message-ID: <9c7f9819a4bfa1059390ef87b02b3e6e.NginxMailingListRussian@forum.nginx.org> Максим приветствую. Отвлеку на 2 минуты чтобы была понятна суть проблемы. Я уже третий год веду репозиторий пакетов для RHEL/CentOS под названием CentALT в котором, помимо прочего, есть пакеты nginx-stable и nginx (количество инсталляций до 500 в день) в личку и на почту мне постоянно приходят просьбы добавить какую-либо опцию в пакет Nginx или добавить сторонний модуль, или же наоборот выкинуть все ?лишнее? и оставить минимальный набор опций. У Вас есть собственный официальный репозиторий и я думаю, что к Вам тоже обращаются с подобными просьбами в огромных количествах. Выполнить обе просьбы одновременно не представляется возможным, поэтому мы решили сделать проект, который позволит любому пользователю создать свою сборку Nginx с нужными ему параметрами. Пользователь выбирает ОС, архитектуру и задает параметры сборки пакета, после этого получает ссылку на репозиторий в котором лежит пакет собранный с необходимыми опциями, пакеты в репозиториях обновляются автоматически по выходу новых версий, т. е. пользователь самостоятельно может создать сборку которая идеально подходит для решения его задачи, поделиться ссылкой на репозиторий с коллегами которые решают аналогичные задачи и пр . Адрес проекта http://repobuild.com Сегодня в процессе тестирования обновления Nginx 1.3.16 некоторые тестовые репозитории не обновили пакет и сообщили о проблеме в сборке, на предыдущей версии nginx все собиралось. Если Вам не сложно, то для предотвращения ошибок при сборке с взаимоисключающими параметрами, можно ли фиксировать такие вещи на этапе configure, и предотвращать такие конфликты. Например чтобы --without-http гасило --with-http_perl_module. Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238411,238433#msg-238433 From nginx-ru at sadok.spb.ru Wed Apr 17 17:25:22 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 17 Apr 2013 21:25:22 +0400 Subject: nginx-1.3.16 In-Reply-To: <9c7f9819a4bfa1059390ef87b02b3e6e.NginxMailingListRussian@forum.nginx.org> References: <20130417113918.GE92338@mdounin.ru> <9c7f9819a4bfa1059390ef87b02b3e6e.NginxMailingListRussian@forum.nginx.org> Message-ID: <42592924.20130417212522@sadok.spb.ru> Здравствуйте, INF[SZ]. Вы писали 17 апреля 2013 г., 18:53:21: > Сегодня в процессе тестирования обновления Nginx 1.3.16 некоторые тестовые > репозитории не обновили пакет и сообщили о проблеме в сборке, на предыдущей > версии nginx все собиралось. Собиралось и работало в конечном итоге? -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From valintinr at tangramltd.com Wed Apr 17 18:48:01 2013 From: valintinr at tangramltd.com (=?UTF-8?B?0JLQsNC70LXQvdGC0LjQvSDQoNC+0YHQsNCy0LjRhtC60LjQuQ==?=) Date: Wed, 17 Apr 2013 21:48:01 +0300 Subject: =?UTF-8?B?bmdpbngg0LrQtdGI0LjRgNC+0LLQsNC90LjQtQ==?= Message-ID: <516EEE61.1080401@tangramltd.com> Здравствуйте. Имеется следующая конфигурация : nginx + php-fpm + drupal. Сайт с включенным модулем boost (кеширование для анонимов). После сброса кеша появляется 502 ошибка, в этот момент модуль активно пишет в базу, грузит диск вплотную. Сам сервер по конфигурации неплох, зеркало на сас дисках, 32Г памяти, 2 х E5645 (для одного сайта с 100-200 онлайна) но в этот момент просто вешает диски, думаю это не исправить (да и не мне это делать). Интересует возможность отдавать с кеша (не boost) страницу. Раньше сайт вертелся на nginx+apache и это решалось через proxy_cache_use_stale для fastcgi так не пройдет. Таймауты для nginx и php стоят большие. Немного конфигов: # serve imagecache files directly or redirect to drupal if they do not exist location ^~ /sites/default/files/imagecache/ { access_log off; expires 30d; try_files $uri @rewrite; } location ~ \.php$ { try_files $uri @cache; fastcgi_pass php5-fpm; .....} location / { try_files $uri @cache; } location @cache { if ($query_string ~ ".+") { return 405; } if ($cookie_DRUPAL_UID) { return 405; } if ($request_method !~ ^(GET|HEAD)$) { return 405; } error_page 405 = @rewrite; add_header Expires "Sun, 19 Nov 1978 05:00:00 GMT"; add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"; try_files /cache/normal/$host/${uri}_.html /cache/perm/$host/${uri}_.css /cache/perm/$host/${uri}_.js /cache/$host/0$uri.html /cache/$host/0${uri}/index.html @rewrite; } location @rewrite { rewrite ^/(.*)$ /index.php?q=$1 last; } error_page 502 =301 @cache; From mdounin at mdounin.ru Wed Apr 17 22:53:31 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 02:53:31 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <516EEE61.1080401@tangramltd.com> References: <516EEE61.1080401@tangramltd.com> Message-ID: <20130417225330.GJ92338@mdounin.ru> Hello! On Wed, Apr 17, 2013 at 09:48:01PM +0300, Валентин Росавицкий wrote: > Здравствуйте. > Имеется следующая конфигурация : nginx + php-fpm + drupal. > Сайт с включенным модулем boost (кеширование для анонимов). После > сброса кеша появляется 502 ошибка, > в этот момент модуль активно пишет в базу, грузит диск вплотную. Сам > сервер по конфигурации неплох, > зеркало на сас дисках, 32Г памяти, 2 х E5645 (для одного сайта с > 100-200 онлайна) но в этот момент просто > вешает диски, думаю это не исправить (да и не мне это делать). > Интересует возможность отдавать с кеша (не boost) страницу. > Раньше сайт вертелся на nginx+apache и это решалось через > proxy_cache_use_stale для fastcgi так не пройдет. А в чём проблема, кроме необходимости слегка изменить название директивы? http://nginx.org/r/fastcgi_cache_use_stale -- Maxim Dounin http://nginx.org/en/donation.html From valintinr at tangramltd.com Wed Apr 17 23:03:30 2013 From: valintinr at tangramltd.com (=?KOI8-R?Q?=F7=C1=CC=C5=CE=D4=C9=CE_=F2=CF=D3=C1=D7=C9=C3=CB=C9=CA?=) Date: Thu, 18 Apr 2013 02:03:30 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <20130417225330.GJ92338@mdounin.ru> References: <516EEE61.1080401@tangramltd.com> <20130417225330.GJ92338@mdounin.ru> Message-ID: <516F2A42.2080703@tangramltd.com> 18.04.2013 1:53, Maxim Dounin пишет: > Hello! > > > А в чём проблема, кроме необходимости слегка изменить название > директивы? > > http://nginx.org/r/fastcgi_cache_use_stale > В том что 502 ошибку не поддерживает. From nginx-forum at nginx.us Thu Apr 18 01:56:20 2013 From: nginx-forum at nginx.us (INF[SZ]) Date: Wed, 17 Apr 2013 21:56:20 -0400 Subject: nginx-1.3.16 In-Reply-To: <42592924.20130417212522@sadok.spb.ru> References: <42592924.20130417212522@sadok.spb.ru> Message-ID: <717e26566228f5e77a04e1ace7b0fef8.NginxMailingListRussian@forum.nginx.org> Он собирался и запускался. О практической пользе такой сборки судить сложно, но сборка с любыми комбинациями ключей не приводила к ошибкам при сборке. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238411,238440#msg-238440 From mdounin at mdounin.ru Thu Apr 18 07:50:29 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 11:50:29 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <516F2A42.2080703@tangramltd.com> References: <516EEE61.1080401@tangramltd.com> <20130417225330.GJ92338@mdounin.ru> <516F2A42.2080703@tangramltd.com> Message-ID: <20130418075029.GK92338@mdounin.ru> Hello! On Thu, Apr 18, 2013 at 02:03:30AM +0300, Валентин Росавицкий wrote: > 18.04.2013 1:53, Maxim Dounin пишет: > >Hello! > > > > > >А в чём проблема, кроме необходимости слегка изменить название > >директивы? > > > >http://nginx.org/r/fastcgi_cache_use_stale > > > В том что 502 ошибку не поддерживает. Если вы про http_502, то на самом деле - поддерживает, это просто документация по fastcgi_cache_use_stale слегка устарела. Но, вообще говоря, оно вам не нужно. Параметры http_* нужны для обработки полноценных ответов, возвращённых бекендом (бывает нужно при многоуровневом проксировании). Ошибки же, которые обнаруживаются при общении с бекендом непосредственно в самом nginx'е, в *_cache_use_stale следует указывать именно как ошибки - error, timeout, invalid_header. -- Maxim Dounin http://nginx.org/en/donation.html From valintinr at tangramltd.com Thu Apr 18 08:03:34 2013 From: valintinr at tangramltd.com (Rosavitskiy Valintin) Date: Thu, 18 Apr 2013 11:03:34 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <20130418075029.GK92338@mdounin.ru> References: <516EEE61.1080401@tangramltd.com> <20130417225330.GJ92338@mdounin.ru> <516F2A42.2080703@tangramltd.com> <20130418075029.GK92338@mdounin.ru> Message-ID: <516FA8D6.20705@tangramltd.com> On 18.04.2013 10:50, Maxim Dounin wrote: > Hello! > > On Thu, Apr 18, 2013 at 02:03:30AM +0300, Валентин Росавицкий wrote: > >> 18.04.2013 1:53, Maxim Dounin пишет: >>> Hello! >>> >>> >>> А в чём проблема, кроме необходимости слегка изменить название >>> директивы? >>> >>> http://nginx.org/r/fastcgi_cache_use_stale >>> >> В том что 502 ошибку не поддерживает. > Если вы про http_502, то на самом деле - поддерживает, это просто > документация по fastcgi_cache_use_stale слегка устарела. > > Но, вообще говоря, оно вам не нужно. Параметры http_* нужны для > обработки полноценных ответов, возвращённых бекендом (бывает нужно > при многоуровневом проксировании). Ошибки же, которые обнаруживаются > при общении с бекендом непосредственно в самом nginx'е, в > *_cache_use_stale следует указывать именно как ошибки - error, > timeout, invalid_header. > Вот так сейчас выглядит. fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503; На сервере стоит nginx/1.2.8 Когда добавляем http_502 то на нее ругается. -- С уважением, Валентин Росавицкий From nginx-forum at nginx.us Thu Apr 18 08:54:53 2013 From: nginx-forum at nginx.us (FireFenix) Date: Thu, 18 Apr 2013 04:54:53 -0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <201304171727.47069.vbart@nginx.com> References: <201304171727.47069.vbart@nginx.com> Message-ID: <0b37e409b08547e8ea930e96cbe4c857.NginxMailingListRussian@forum.nginx.org> Спасибо за ответы, но это сильно погоды не изменяет =( ведь это как дефолтный конфиг. Вот с таким конфигом: worker_processes 1; error_log logs/error.log info; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 600s 600s; gzip on; server { listen 8080; server_name localhost; access_log off; merge_slashes on; rewrite ^/panorama/(.*)$ /panorama/index.php; location / { root D:/Site; index index.html index.htm index.php; } location ~ \.php$ { root D:/Site; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } } При: C:\>ab.exe -n 1000 -c 100 http://10.10.1.1:8080/index.php This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 10.10.1.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests apr_pollset_poll: The timeout specified has expired (70007) Total of 593 requests completed В лог валится кучу флуда, строк вида: 2013/04/18 11:44:27 [error] 3920#3716: *1089 WSARecv() failed (10054: Удаленный хост принудительно разорвал существующее подключение) while reading response header from upstream, client: 10.0.0.4, server: localhost, request: "GET /index.php HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "10.10.1.1:8080" 2013/04/18 11:44:27 [error] 3920#3716: *1165 WSARecv() failed (10054: Удаленный хост принудительно разорвал существующее подключение) while reading response header from upstream, client: 10.0.0.4, server: localhost, request: "GET /index.php HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "10.10.1.1:8080" 2013/04/18 11:45:00 [info] 3920#3716: *1373 client prematurely closed connection, so upstream connection is closed too while connecting to upstream, client: 10.0.0.4, server: localhost, request: "GET /index.php HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "10.10.1.1:8080" 2013/04/18 11:45:00 [info] 3920#3716: *1387 client prematurely closed connection, so upstream connection is closed too while connecting to upstream, client: 10.0.0.4, server: localhost, request: "GET /index.php HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "10.10.1.1:8080" 2013/04/18 11:45:00 [info] 3920#3716: *1390 client prematurely closed connection, so upstream connection is closed too И прибивается процесс php-cgi. Подскажите, как быть? >Ну и на всякий случай явно замечу, что "правильно настроить для >~500 юзеров" включает в себя заменить Windows на что-нибудь более >другое. Ну и железо понменять тоже бы не помешало, но мне сейчас важно, чтобы просто все запросы уходили в пул и выдавали результат как выполняться, а не так чтобы всё падало и с концами =( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238430,238452#msg-238452 From mdounin at mdounin.ru Thu Apr 18 09:18:35 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 13:18:35 +0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <0b37e409b08547e8ea930e96cbe4c857.NginxMailingListRussian@forum.nginx.org> References: <201304171727.47069.vbart@nginx.com> <0b37e409b08547e8ea930e96cbe4c857.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130418091835.GM92338@mdounin.ru> Hello! On Thu, Apr 18, 2013 at 04:54:53AM -0400, FireFenix wrote: [...] > При: > > C:\>ab.exe -n 1000 -c 100 http://10.10.1.1:8080/index.php > This is ApacheBench, Version 2.3 <$Revision: 1430300 $> > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > Licensed to The Apache Software Foundation, http://www.apache.org/ > > Benchmarking 10.10.1.1 (be patient) > Completed 100 requests > Completed 200 requests > Completed 300 requests > Completed 400 requests > Completed 500 requests > apr_pollset_poll: The timeout specified has expired (70007) > Total of 593 requests completed > > > > В лог валится кучу флуда, строк вида: > > 2013/04/18 11:44:27 [error] 3920#3716: *1089 WSARecv() failed (10054: > Удаленный хост принудительно разорвал существующее подключение) while > reading response header from upstream, client: 10.0.0.4, server: localhost, > request: "GET /index.php HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", > host: "10.10.1.1:8080" > 2013/04/18 11:44:27 [error] 3920#3716: *1165 WSARecv() failed (10054: > Удаленный хост принудительно разорвал существующее подключение) while > reading response header from upstream, client: 10.0.0.4, server: localhost, > request: "GET /index.php HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", > host: "10.10.1.1:8080" > 2013/04/18 11:45:00 [info] 3920#3716: *1373 client prematurely closed > connection, so upstream connection is closed too while connecting to > upstream, client: 10.0.0.4, server: localhost, request: "GET /index.php > HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "10.10.1.1:8080" > 2013/04/18 11:45:00 [info] 3920#3716: *1387 client prematurely closed > connection, so upstream connection is closed too while connecting to > upstream, client: 10.0.0.4, server: localhost, request: "GET /index.php > HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "10.10.1.1:8080" > 2013/04/18 11:45:00 [info] 3920#3716: *1390 client prematurely closed > connection, so upstream connection is closed too > > > И прибивается процесс php-cgi. > > Подскажите, как быть? Судя по логам - ab просто не дождался ответа. Это может быть банально нормально, если время ответа тестируемого index.php достаточно большое, а php-процессов - мало. Хотя я не совсем понимаю, что понимается под словами "и прибивается процесс php-cgi", если он действительно умирает - то наверное надо разбираться, что именно там происходит. Тут, впрочем, nginx ни при чём - он не занимается запуском и контролем php-cgi. > >Ну и на всякий случай явно замечу, что "правильно настроить для > >~500 юзеров" включает в себя заменить Windows на что-нибудь более > >другое. > Ну и железо понменять тоже бы не помешало, но мне сейчас важно, чтобы просто > все запросы уходили в пул и выдавали результат как выполняться, а не так > чтобы всё падало и с концами =( Тут неоднократно высказывалось мнение, что поднять на той же машине linux/freebsd в виртуалке - более надёжное решение. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Apr 18 09:25:19 2013 From: nginx-forum at nginx.us (FireFenix) Date: Thu, 18 Apr 2013 05:25:19 -0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <20130418091835.GM92338@mdounin.ru> References: <20130418091835.GM92338@mdounin.ru> Message-ID: > Судя по логам - ab просто не дождался ответа. Это может быть > банально нормально, если время ответа тестируемого index.php > достаточно большое, а php-процессов - мало. > Хотя я не совсем понимаю, что понимается под словами "и > прибивается процесс php-cgi", если он действительно умирает - то > наверное надо разбираться, что именно там происходит. Тут, > впрочем, nginx ни при чём - он не занимается запуском и контролем > php-cgi. Да, это понятно, что вышел таймаут и ab перестал кидать запросы дальше Но ведь причина в том, что сервер перстал отвечать, а точнее процесс php-cgi.exe умер или закрылся, т.е. просто исчез из задач. Конечно, я не виню nginx или php, но хотелось бы найти рабочее решение. Много тем на форуме где советуют использовать отдельный менеджер fcgi, но ни одного не нашёл живого под Win =( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238430,238460#msg-238460 From mdounin at mdounin.ru Thu Apr 18 09:26:46 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 13:26:46 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <516FA8D6.20705@tangramltd.com> References: <516EEE61.1080401@tangramltd.com> <20130417225330.GJ92338@mdounin.ru> <516F2A42.2080703@tangramltd.com> <20130418075029.GK92338@mdounin.ru> <516FA8D6.20705@tangramltd.com> Message-ID: <20130418092646.GN92338@mdounin.ru> Hello! On Thu, Apr 18, 2013 at 11:03:34AM +0300, Rosavitskiy Valintin wrote: > On 18.04.2013 10:50, Maxim Dounin wrote: > >Hello! > > > >On Thu, Apr 18, 2013 at 02:03:30AM +0300, Валентин Росавицкий wrote: > > > >>18.04.2013 1:53, Maxim Dounin пишет: > >>>Hello! > >>> > >>> > >>>А в чём проблема, кроме необходимости слегка изменить название > >>>директивы? > >>> > >>>http://nginx.org/r/fastcgi_cache_use_stale > >>> > >>В том что 502 ошибку не поддерживает. > >Если вы про http_502, то на самом деле - поддерживает, это просто > >документация по fastcgi_cache_use_stale слегка устарела. > > > >Но, вообще говоря, оно вам не нужно. Параметры http_* нужны для > >обработки полноценных ответов, возвращённых бекендом (бывает нужно > >при многоуровневом проксировании). Ошибки же, которые обнаруживаются > >при общении с бекендом непосредственно в самом nginx'е, в > >*_cache_use_stale следует указывать именно как ошибки - error, > >timeout, invalid_header. > > > Вот так сейчас выглядит. > > fastcgi_cache_use_stale error timeout invalid_header updating > http_500 http_503; > > На сервере стоит nginx/1.2.8 > Когда добавляем http_502 то на нее ругается. Да, действительно, до fastcgi в этом месте ещё нужно константу дотащить. Но, повторяю, - оно вам не нужно. Параметры http_* имеют смысл только в том случае, если бекенд возвращает честный ответ, и в этом ответе написано "случилась ошибка 5xx". Такая обработка имеет смысл в основном при многоуровневом проксировании (за исключением разве что http_500). -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Thu Apr 18 09:31:46 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 13:31:46 +0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: References: <20130418091835.GM92338@mdounin.ru> Message-ID: <20130418093146.GO92338@mdounin.ru> Hello! On Thu, Apr 18, 2013 at 05:25:19AM -0400, FireFenix wrote: > > Судя по логам - ab просто не дождался ответа. Это может быть > > банально нормально, если время ответа тестируемого index.php > > достаточно большое, а php-процессов - мало. > > Хотя я не совсем понимаю, что понимается под словами "и > > прибивается процесс php-cgi", если он действительно умирает - то > > наверное надо разбираться, что именно там происходит. Тут, > > впрочем, nginx ни при чём - он не занимается запуском и контролем > > php-cgi. > Да, это понятно, что вышел таймаут и ab перестал кидать запросы дальше > Но ведь причина в том, что сервер перстал отвечать, а точнее процесс > php-cgi.exe умер или закрылся, т.е. просто исчез из задач. Вы в этом уверены? Если бы он умер - то nginx бы ругался, что не может к нему подключиться. > Конечно, я не виню nginx или php, но хотелось бы найти рабочее решение. > Много тем на форуме где советуют использовать отдельный менеджер fcgi, но ни > одного не нашёл живого под Win =( Правильное решение вам уже было предложено. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Apr 18 09:54:22 2013 From: nginx-forum at nginx.us (FireFenix) Date: Thu, 18 Apr 2013 05:54:22 -0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <20130418093146.GO92338@mdounin.ru> References: <20130418093146.GO92338@mdounin.ru> Message-ID: <0af6a724c9c7b3c88cb4cc354124c2bf.NginxMailingListRussian@forum.nginx.org> >Вы в этом уверены? Если бы он умер - то nginx бы ругался, что не >может к нему подключиться. php-cgi.exe пропадает из диспетчера задач и tasklist, я почти уверен что он умер. Когда ab отключается по таймауту, то в логе только флуд сообщений 2х типов, что я писалвыше. При последующих обращениях получаю лог вида: 2013/04/18 12:50:33 [error] 2496#456: *1399 upstream timed out (10060: Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера) while connecting to upstream, client: 10.0.0.4, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "10.10.1.1:8080" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238430,238468#msg-238468 From valintinr at tangramltd.com Thu Apr 18 09:59:56 2013 From: valintinr at tangramltd.com (Rosavitskiy Valintin) Date: Thu, 18 Apr 2013 12:59:56 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <20130418092646.GN92338@mdounin.ru> References: <516EEE61.1080401@tangramltd.com> <20130417225330.GJ92338@mdounin.ru> <516F2A42.2080703@tangramltd.com> <20130418075029.GK92338@mdounin.ru> <516FA8D6.20705@tangramltd.com> <20130418092646.GN92338@mdounin.ru> Message-ID: <516FC41C.6000900@tangramltd.com> On 18.04.2013 12:26, Maxim Dounin wrote: > Hello! > > On Thu, Apr 18, 2013 at 11:03:34AM +0300, Rosavitskiy Valintin wrote: > >> On 18.04.2013 10:50, Maxim Dounin wrote: >>> Hello! >>> >>> On Thu, Apr 18, 2013 at 02:03:30AM +0300, Валентин Росавицкий wrote: >>> >>>> 18.04.2013 1:53, Maxim Dounin пишет: >>>>> Hello! >>>>> >>>>> >>>>> А в чём проблема, кроме необходимости слегка изменить название >>>>> директивы? >>>>> >>>>> http://nginx.org/r/fastcgi_cache_use_stale >>>>> >>>> В том что 502 ошибку не поддерживает. >>> Если вы про http_502, то на самом деле - поддерживает, это просто >>> документация по fastcgi_cache_use_stale слегка устарела. >>> >>> Но, вообще говоря, оно вам не нужно. Параметры http_* нужны для >>> обработки полноценных ответов, возвращённых бекендом (бывает нужно >>> при многоуровневом проксировании). Ошибки же, которые обнаруживаются >>> при общении с бекендом непосредственно в самом nginx'е, в >>> *_cache_use_stale следует указывать именно как ошибки - error, >>> timeout, invalid_header. >>> >> Вот так сейчас выглядит. >> >> fastcgi_cache_use_stale error timeout invalid_header updating >> http_500 http_503; >> >> На сервере стоит nginx/1.2.8 >> Когда добавляем http_502 то на нее ругается. > Да, действительно, до fastcgi в этом месте ещё нужно константу > дотащить. Но, повторяю, - оно вам не нужно. Параметры http_* имеют > смысл только в том случае, если бекенд возвращает честный ответ, и > в этом ответе написано "случилась ошибка 5xx". Такая обработка > имеет смысл в основном при многоуровневом проксировании (за > исключением разве что http_500). > Понял. Есть ли у кого идеии как средствами nginx скрыть ошибку? Узкое место - mysql при сбросе кеша но пока это не справить. -- С уважением, Валентин Росавицкий From alex.barut at gmail.com Thu Apr 18 10:31:04 2013 From: alex.barut at gmail.com (Alex Belyansky) Date: Thu, 18 Apr 2013 14:31:04 +0400 Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCA1MDIg0L7RiNC40LHQutC4INCyINC40Lw=?= =?UTF-8?B?0LXQvdC+0LLQsNC90L3QvtC8INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <516E9210.1020906@gmail.com> References: <516E9210.1020906@gmail.com> Message-ID: <516FCB68.3090400@gmail.com> Добрый день! Своими силами проблему никак решить не могу. В дополнение прикладываю часть debug.log из которого видно, что идет внутренний редирект к странице 500.html, когда имеет место 404-ая ошибка и апстрим на нее не ответил. А вот в случае 403-ей ошибки, когда апстрим не отвечает, то такого редиректа для отдачи 500.html не срабатывает и Nginx отдает свою собственную 502-ую. ====================================================== 2013/04/18 14:07:30 [error] 17044#0: *124 connect() failed (113: No route to host) while connecting to upstream, client: 192.168.10.128, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "http://192.168.56.101:8000/info.php", host: "192.168.10.128" 2013/04/18 14:07:30 [debug] 17044#0: *124 http next upstream, 2 2013/04/18 14:07:30 [debug] 17044#0: *124 free rr peer 1 4 2013/04/18 14:07:30 [debug] 17044#0: *124 finalize http upstream request: 502 2013/04/18 14:07:30 [debug] 17044#0: *124 finalize http proxy request 2013/04/18 14:07:30 [debug] 17044#0: *124 free rr peer 0 0 2013/04/18 14:07:30 [debug] 17044#0: *124 close http upstream connection: 6 2013/04/18 14:07:30 [debug] 17044#0: *124 free: 0902A4F0, unused: 88 2013/04/18 14:07:30 [debug] 17044#0: *124 event timer del: 6: 480106897 2013/04/18 14:07:30 [debug] 17044#0: *124 delete posted event 0904B688 2013/04/18 14:07:30 [debug] 17044#0: *124 reusable connection: 0 2013/04/18 14:07:30 [debug] 17044#0: *124 http finalize request: 502, "/info.php?" a:1, c:1 2013/04/18 14:07:30 [debug] 17044#0: *124 http special response: 502, "/info.php?" 2013/04/18 14:07:30 [debug] 17044#0: *124 internal redirect: "/500.html?" 2013/04/18 14:07:30 [debug] 17044#0: *124 rewrite phase: 1 2013/04/18 14:07:30 [debug] 17044#0: *124 http script var 2013/04/18 14:07:30 [debug] 17044#0: *124 http script var: "" 2013/04/18 14:07:30 [debug] 17044#0: *124 http script value: "on" ======================================================= 2013/04/18 14:11:46 [error] 17044#0: *127 connect() failed (113: No route to host) while connecting to upstream, client: 192.168.10.128, server: localhost, request: "GET /pool/ HTTP/1.1", upstream: "http://192.168.56.101:8000/pool/", host: "192.168.10.128" 2013/04/18 14:11:46 [debug] 17044#0: *127 http next upstream, 2 2013/04/18 14:11:46 [debug] 17044#0: *127 free rr peer 1 4 2013/04/18 14:11:46 [debug] 17044#0: *127 finalize http upstream request: 502 2013/04/18 14:11:46 [debug] 17044#0: *127 finalize http proxy request 2013/04/18 14:11:46 [debug] 17044#0: *127 free rr peer 0 0 2013/04/18 14:11:46 [debug] 17044#0: *127 close http upstream connection: 6 2013/04/18 14:11:46 [debug] 17044#0: *127 free: 0903AE20, unused: 88 2013/04/18 14:11:46 [debug] 17044#0: *127 event timer del: 6: 480363426 2013/04/18 14:11:46 [debug] 17044#0: *127 delete posted event 0904B688 2013/04/18 14:11:46 [debug] 17044#0: *127 reusable connection: 0 2013/04/18 14:11:46 [debug] 17044#0: *127 http finalize request: 502, "/pool/?" a:1, c:1 2013/04/18 14:11:46 [debug] 17044#0: *127 http special response: 502, "/pool/?" 2013/04/18 14:11:46 [debug] 17044#0: *127 http set discard body 2013/04/18 14:11:46 [debug] 17044#0: *127 xslt filter header 2013/04/18 14:11:46 [debug] 17044#0: *127 HTTP/1.1 502 Bad Gateway Server: nginx/1.1.19 Date: Thu, 18 Apr 2013 10:11:46 GMT Content-Type: text/html Content-Length: 173 Connection: keep-alive On 17.04.2013 16:14, Alex Belyansky wrote: > Добрый день! > > Имею вот такое в конфигурации: > > error_page 500 501 502 503 504 /500.html; > > > location / { > try_files $uri $uri/ @upstream; > error_page 404 = @upstream; > error_page 403 = @upstream; > } > > location @upstream { > proxy_pass http://backend; > } > > > Когда нет связи с бекендом и при этом запрашивается несуществующая > страница (404), то nginx нормально отображает мою 500.html > А вот когда запрашивается страница с ошибкой по правам доступа (403), > то nginx отображает свою дефолтовую страницу, вместо моей 500.html > > Что делаю не так? Где что прописать, чтобы нормально отображалась моя > 500.html для ситуации с 403-ей ? From mdounin at mdounin.ru Thu Apr 18 13:10:39 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 17:10:39 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <516FC41C.6000900@tangramltd.com> References: <516EEE61.1080401@tangramltd.com> <20130417225330.GJ92338@mdounin.ru> <516F2A42.2080703@tangramltd.com> <20130418075029.GK92338@mdounin.ru> <516FA8D6.20705@tangramltd.com> <20130418092646.GN92338@mdounin.ru> <516FC41C.6000900@tangramltd.com> Message-ID: <20130418131039.GT92338@mdounin.ru> Hello! On Thu, Apr 18, 2013 at 12:59:56PM +0300, Rosavitskiy Valintin wrote: > On 18.04.2013 12:26, Maxim Dounin wrote: > >Hello! > > > >On Thu, Apr 18, 2013 at 11:03:34AM +0300, Rosavitskiy Valintin wrote: > > > >>On 18.04.2013 10:50, Maxim Dounin wrote: > >>>Hello! > >>> > >>>On Thu, Apr 18, 2013 at 02:03:30AM +0300, Валентин Росавицкий wrote: > >>> > >>>>18.04.2013 1:53, Maxim Dounin пишет: > >>>>>Hello! > >>>>> > >>>>> > >>>>>А в чём проблема, кроме необходимости слегка изменить название > >>>>>директивы? > >>>>> > >>>>>http://nginx.org/r/fastcgi_cache_use_stale > >>>>> > >>>>В том что 502 ошибку не поддерживает. > >>>Если вы про http_502, то на самом деле - поддерживает, это просто > >>>документация по fastcgi_cache_use_stale слегка устарела. > >>> > >>>Но, вообще говоря, оно вам не нужно. Параметры http_* нужны для > >>>обработки полноценных ответов, возвращённых бекендом (бывает нужно > >>>при многоуровневом проксировании). Ошибки же, которые обнаруживаются > >>>при общении с бекендом непосредственно в самом nginx'е, в > >>>*_cache_use_stale следует указывать именно как ошибки - error, > >>>timeout, invalid_header. > >>> > >>Вот так сейчас выглядит. > >> > >>fastcgi_cache_use_stale error timeout invalid_header updating > >>http_500 http_503; > >> > >>На сервере стоит nginx/1.2.8 > >>Когда добавляем http_502 то на нее ругается. > >Да, действительно, до fastcgi в этом месте ещё нужно константу > >дотащить. Но, повторяю, - оно вам не нужно. Параметры http_* имеют > >смысл только в том случае, если бекенд возвращает честный ответ, и > >в этом ответе написано "случилась ошибка 5xx". Такая обработка > >имеет смысл в основном при многоуровневом проксировании (за > >исключением разве что http_500). > > > Понял. > Есть ли у кого идеии как средствами nginx скрыть ошибку? > Узкое место - mysql при сбросе кеша но пока это не справить. Так и попробуйте для начала так же, как раньше делали - fastcgi_cache + fastcgi_cache_use_stale, всё должно получиться. С учётом наличия ещё одного кеша - я бы рекомендовал конфигурить что-то нибудь неоченьдолгоживующее, и видимо только для востребованных ресурсов (fastcgi_cache_min_uses). Это, впрочем, частности. -- Maxim Dounin http://nginx.org/en/donation.html From valintinr at tangramltd.com Thu Apr 18 13:39:16 2013 From: valintinr at tangramltd.com (Rosavitskiy Valintin) Date: Thu, 18 Apr 2013 16:39:16 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <20130418131039.GT92338@mdounin.ru> References: <516EEE61.1080401@tangramltd.com> <20130417225330.GJ92338@mdounin.ru> <516F2A42.2080703@tangramltd.com> <20130418075029.GK92338@mdounin.ru> <516FA8D6.20705@tangramltd.com> <20130418092646.GN92338@mdounin.ru> <516FC41C.6000900@tangramltd.com> <20130418131039.GT92338@mdounin.ru> Message-ID: <516FF784.4090305@tangramltd.com> > Так и попробуйте для начала так же, как раньше делали - > fastcgi_cache + fastcgi_cache_use_stale, всё должно получиться. > > С учётом наличия ещё одного кеша - я бы рекомендовал конфигурить > что-то нибудь неоченьдолгоживующее, и видимо только для > востребованных ресурсов (fastcgi_cache_min_uses). Это, впрочем, > частности. > Понял, спасибо, буду пробовать. К fastcgi_cache как то не дошло. -- С уважением, Валентин Росавицкий From mdounin at mdounin.ru Thu Apr 18 13:50:01 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 17:50:01 +0400 Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCA1MDIg0L7RiNC40LHQutC4INCyINC40Lw=?= =?UTF-8?B?0LXQvdC+0LLQsNC90L3QvtC8INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <516FCB68.3090400@gmail.com> References: <516E9210.1020906@gmail.com> <516FCB68.3090400@gmail.com> Message-ID: <20130418135001.GU92338@mdounin.ru> Hello! On Thu, Apr 18, 2013 at 02:31:04PM +0400, Alex Belyansky wrote: > Добрый день! > > Своими силами проблему никак решить не могу. В дополнение > прикладываю часть debug.log из которого видно, что идет внутренний > редирект к странице 500.html, > когда имеет место 404-ая ошибка и апстрим на нее не ответил. > А вот в случае 403-ей ошибки, когда апстрим не отвечает, то такого > редиректа для отдачи 500.html не срабатывает и Nginx отдает свою > собственную 502-ую. [...] > On 17.04.2013 16:14, Alex Belyansky wrote: > >Добрый день! > > > >Имею вот такое в конфигурации: > > > >error_page 500 501 502 503 504 /500.html; > > > > > >location / { > > try_files $uri $uri/ @upstream; > > error_page 404 = @upstream; > > error_page 403 = @upstream; Надо сделать так: recursive_error_pages on; > >} > > > >location @upstream { > > proxy_pass http://backend; > >} > > > > > >Когда нет связи с бекендом и при этом запрашивается несуществующая > >страница (404), то nginx нормально отображает мою 500.html > >А вот когда запрашивается страница с ошибкой по правам доступа > >(403), то nginx отображает свою дефолтовую страницу, вместо моей > >500.html > > > >Что делаю не так? Где что прописать, чтобы нормально отображалась > >моя 500.html для ситуации с 403-ей ? На самом деле 404-х ошибок у вас просто не бывает - перенаправление в @upstream для несуществующих файлов делается директивой try_files. Для того, чтобы можно было делать более одного перенаправления с помощью директивы error_page - нужно включить recursive_error_pages, см. тут: http://nginx.org/r/recursive_error_pages -- Maxim Dounin http://nginx.org/en/donation.html From alex.barut at gmail.com Thu Apr 18 14:18:48 2013 From: alex.barut at gmail.com (Alex Belyansky) Date: Thu, 18 Apr 2013 18:18:48 +0400 Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCA1MDIg0L7RiNC40LHQutC4INCyINC40Lw=?= =?UTF-8?B?0LXQvdC+0LLQsNC90L3QvtC8INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <20130418135001.GU92338@mdounin.ru> References: <516E9210.1020906@gmail.com> <516FCB68.3090400@gmail.com> <20130418135001.GU92338@mdounin.ru> Message-ID: <517000C8.5050301@gmail.com> Спасибо, Максим! Теперь все встало на свои места. Буду внимательней к документации. On 18.04.2013 17:50, Maxim Dounin wrote: > Hello! > > On Thu, Apr 18, 2013 at 02:31:04PM +0400, Alex Belyansky wrote: > >> Добрый день! >> >> Своими силами проблему никак решить не могу. В дополнение >> прикладываю часть debug.log из которого видно, что идет внутренний >> редирект к странице 500.html, >> когда имеет место 404-ая ошибка и апстрим на нее не ответил. >> А вот в случае 403-ей ошибки, когда апстрим не отвечает, то такого >> редиректа для отдачи 500.html не срабатывает и Nginx отдает свою >> собственную 502-ую. > [...] > >> On 17.04.2013 16:14, Alex Belyansky wrote: >>> Добрый день! >>> >>> Имею вот такое в конфигурации: >>> >>> error_page 500 501 502 503 504 /500.html; >>> >>> >>> location / { >>> try_files $uri $uri/ @upstream; >>> error_page 404 = @upstream; >>> error_page 403 = @upstream; > Надо сделать так: > > recursive_error_pages on; > >>> } >>> >>> location @upstream { >>> proxy_pass http://backend; >>> } >>> >>> >>> Когда нет связи с бекендом и при этом запрашивается несуществующая >>> страница (404), то nginx нормально отображает мою 500.html >>> А вот когда запрашивается страница с ошибкой по правам доступа >>> (403), то nginx отображает свою дефолтовую страницу, вместо моей >>> 500.html >>> >>> Что делаю не так? Где что прописать, чтобы нормально отображалась >>> моя 500.html для ситуации с 403-ей ? > На самом деле 404-х ошибок у вас просто не бывает - > перенаправление в @upstream для несуществующих файлов делается > директивой try_files. > > Для того, чтобы можно было делать более одного перенаправления с > помощью директивы error_page - нужно включить > recursive_error_pages, см. тут: > > http://nginx.org/r/recursive_error_pages > From mdounin at mdounin.ru Thu Apr 18 14:26:58 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Apr 2013 18:26:58 +0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <0af6a724c9c7b3c88cb4cc354124c2bf.NginxMailingListRussian@forum.nginx.org> References: <20130418093146.GO92338@mdounin.ru> <0af6a724c9c7b3c88cb4cc354124c2bf.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130418142657.GV92338@mdounin.ru> Hello! On Thu, Apr 18, 2013 at 05:54:22AM -0400, FireFenix wrote: > >Вы в этом уверены? Если бы он умер - то nginx бы ругался, что не > >может к нему подключиться. > php-cgi.exe пропадает из диспетчера задач и tasklist, я почти уверен что он > умер. Я не большой специалист по php, особенно под windows, но может проблема - из области тривиальных? Вот тут пишут, что php-cgi самоубивается после 500 запросов: http://stackoverflow.com/questions/12487147/php-cgi-exe-quits-after-exactly-500-hits И, видимо, не может родить новый процесс под win32. Лечится, как утверждается, банальным "set PHP_FCGI_MAX_REQUESTS=0". -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Apr 18 14:59:22 2013 From: nginx-forum at nginx.us (mp12390) Date: Thu, 18 Apr 2013 10:59:22 -0400 Subject: =?UTF-8?B?0LrQsNC6INGB0L/RgNGP0YLQsNGC0YwgaW5kZXgucGhw?= Message-ID: <46c22e9d0ac0411ca8983a27bb2b9eeb.NginxMailingListRussian@forum.nginx.org> Здравствуйте, Есть контент сайта вся логика которого реализуется средствами index.php. Поэтому хочется спрятать все "внутренности" и не показать в строке браузера что сайт написан на php. Пришла в голову такая конфигурация: location / { index index.php; try_files $uri $uri/ /index.php?$args; } location ~* \.php$ { rewrite ^ http://site.local; } location = /index.php { fastcgi_pass unix:/tmp/php.sock; ... } Все бы хорошо, но если в строке браузера вбить http://site.local/index.php, то так и останется висеть index.php, а хочется сделать редирект на http://site.local чтобы не "палить" php. Собственно и возникает вопрос как спрятать его? Немного поразмыслив пришло такое изменение: location = /index.php { internal; fastcgi_pass unix:/tmp/php.sock; ... error_page 404 http://site.local; } По тестам работает, но может будут более оптимизированные методы? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238484,238484#msg-238484 From nginx-forum at nginx.us Fri Apr 19 08:03:27 2013 From: nginx-forum at nginx.us (FireFenix) Date: Fri, 19 Apr 2013 04:03:27 -0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <20130418142657.GV92338@mdounin.ru> References: <20130418142657.GV92338@mdounin.ru> Message-ID: <676249f057426e9ae51e213d6da49b1a.NginxMailingListRussian@forum.nginx.org> > И, видимо, не может родить новый процесс под win32. Лечится, как > утверждается, банальным "set PHP_FCGI_MAX_REQUESTS=0". Вначале думал,что максимальное количетсво запросов, можно указать в конфиге nginx'a fastcgi_param PHP_FCGI_MAX_REQUESTS 0; Но результат был одинаковый... И вчера методом попробовал через батник, устанавливать переменные окружения и запускать php-cgi.exe Тогда всё заработало =) Так же ещё внутри сервиса http://winginx.ru/ нашёл spawn-cgi под Win, не знаю какой свежести, но главное рабочий =) Спасибо за помощь. И ещё подскажите пожалуйста. Где-то на форуме видел топик, что при fast_cgi серевер ставит запросы в пул и передаёт на обработку последующие запросы, только после выполнения предидущих. Так ли это? Т.е. стоит ли завести ещё upstream'ы fast_cgi для параллельной обработки? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238430,238496#msg-238496 From mdounin at mdounin.ru Fri Apr 19 11:08:13 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 19 Apr 2013 15:08:13 +0400 Subject: =?UTF-8?B?UmU6IFtXaW5kb3dzICsgZmFzdGNnaSArIHBocF0g0JLQsNC70LjRgtGB0Y8g0Lg=?= =?UTF-8?B?0LvQuCDQv9C10YDQtdGB0YLQsNGR0YIg0L7RgtCy0LXRh9Cw0YLRjA==?= In-Reply-To: <676249f057426e9ae51e213d6da49b1a.NginxMailingListRussian@forum.nginx.org> References: <20130418142657.GV92338@mdounin.ru> <676249f057426e9ae51e213d6da49b1a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130419110813.GA92338@mdounin.ru> Hello! On Fri, Apr 19, 2013 at 04:03:27AM -0400, FireFenix wrote: > > И, видимо, не может родить новый процесс под win32. Лечится, как > > утверждается, банальным "set PHP_FCGI_MAX_REQUESTS=0". > > Вначале думал,что максимальное количетсво запросов, можно указать в конфиге > nginx'a > fastcgi_param PHP_FCGI_MAX_REQUESTS 0; > Но результат был одинаковый... > > И вчера методом попробовал через батник, устанавливать переменные окружения > и запускать php-cgi.exe > Тогда всё заработало =) > > Так же ещё внутри сервиса http://winginx.ru/ нашёл spawn-cgi под Win, не > знаю какой свежести, но главное рабочий =) > > Спасибо за помощь. Пожалуйста. В числовом выражении спасибо можно сказать тут: http://nginx.org/en/donation.html :) > И ещё подскажите пожалуйста. Где-то на форуме видел топик, что при fast_cgi > серевер ставит запросы в пул и передаёт на обработку последующие запросы, > только после выполнения предидущих. Так ли это? > Т.е. стоит ли завести ещё upstream'ы fast_cgi для параллельной обработки? FastCGI - это лишь протокол, и с точки зрения nginx'а он мало отличается от других протоколов: когда приходит новый запрос, nginx открывает новое соединение на бекенд и отправляет туда запрос. Соответственно вопрос состоит в том, что будет дальше с вашим запросом - т.е. как его обработает бекенд. В случае php-cgi в режиме fastcgi - это обычная process-based модель, process per connection, prefork, т.е. одновременно может обрабатываться столько запросов, сколько запущено процессов php-cgi. Сколько запускать процессов - управляется переменной окружения PHP_FCGI_CHILDREN. -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Fri Apr 19 18:21:45 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 19 Apr 2013 22:21:45 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDRgdC/0YDRj9GC0LDRgtGMIGluZGV4LnBocA==?= In-Reply-To: <46c22e9d0ac0411ca8983a27bb2b9eeb.NginxMailingListRussian@forum.nginx.org> References: <46c22e9d0ac0411ca8983a27bb2b9eeb.NginxMailingListRussian@forum.nginx.org> Message-ID: <201304192221.45120.vbart@nginx.com> On Thursday 18 April 2013 18:59:22 mp12390 wrote: > Здравствуйте, > > Есть контент сайта вся логика которого реализуется средствами index.php. > Поэтому хочется спрятать все "внутренности" и не показать в строке браузера > что сайт написан на php. Пришла в голову такая конфигурация: > > location / { > index index.php; > try_files $uri $uri/ /index.php?$args; > } > > location ~* \.php$ { rewrite ^ http://site.local; } > > location = /index.php { fastcgi_pass unix:/tmp/php.sock; ... } > > Все бы хорошо, но если в строке браузера вбить http://site.local/index.php, > то так и останется висеть index.php, а хочется сделать редирект на > http://site.local чтобы не "палить" php. > > Собственно и возникает вопрос как спрятать его? > Убрать из root-а nginx-а. Вы пытаетесь решить проблему, которую сами сперва создали - положили index.php в document root веб-сервера. -- Валентин Бартенев http://nginx.org/en/donation.html > Немного поразмыслив пришло такое изменение: > > location = /index.php { > internal; > fastcgi_pass unix:/tmp/php.sock; > ... > error_page 404 http://site.local; > } > > По тестам работает, но может будут более оптимизированные методы? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238484,238484#msg-238484 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Apr 19 21:25:28 2013 From: nginx-forum at nginx.us (kermit32dll) Date: Fri, 19 Apr 2013 17:25:28 -0400 Subject: =?UTF-8?B?bmdpbnggKyBzcG9vZmVkIHN5biDRhNC70YPQtA==?= Message-ID: <089ce8c6563f406b5ab2ae36c1d715a7.NginxMailingListRussian@forum.nginx.org> Всем доброго времени суток! Возник следующий вопрос. Есть сервер (2 х E2620, 32 GB RAM, 10G оптическая карточка Intel). На сервере установлен nginx 1.2.6 в качестве прокси к другому физически отдельному серверу с Апачем. Если в сервер утыкается spoofed syn флуд на 80й порт, примерно 300kpps, то у сервера 98% времени начинают потреблять si. В чём может быть дело? Такое ощущение, что соединения хоть и висят в полуоткрытом состоянии, но всёравно как-то частично внутрь проходят. Заранее спасибо за любые идеи! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238505,238505#msg-238505 From postmaster at softsearch.ru Sat Apr 20 16:01:38 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 20 Apr 2013 20:01:38 +0400 Subject: =?UTF-8?B?UmU6IG5naW54ICsgc3Bvb2ZlZCBzeW4g0YTQu9GD0LQ=?= In-Reply-To: <089ce8c6563f406b5ab2ae36c1d715a7.NginxMailingListRussian@forum.nginx.org> References: <089ce8c6563f406b5ab2ae36c1d715a7.NginxMailingListRussian@forum.nginx.org> Message-ID: <473992834.20130420200138@softsearch.ru> Здравствуйте, kermit32dll. Какая операционка? -- С уважением, Михаил mailto:postmaster at softsearch.ru From mail at knutov.com Sun Apr 21 22:36:30 2013 From: mail at knutov.com (Nick Knutov) Date: Mon, 22 Apr 2013 04:36:30 +0600 Subject: =?UTF-8?Q?sendfile__=D0=B8_aio?= Message-ID: <517469EE.3000105@knutov.com> Если я правильно понимаю, что для отдачи больших файлов с локальных дисков лучше делать sendfile off и aio on, то можно ли сделать так, чтобы это происходило автоматически для файлов размером больше, например, 1 мегабайта (или любого другого рекомендуемого? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From mail at knutov.com Sun Apr 21 22:37:42 2013 From: mail at knutov.com (Nick Knutov) Date: Mon, 22 Apr 2013 04:37:42 +0600 Subject: =?UTF-8?Q?Re=3A_sendfile__=D0=B8_aio?= In-Reply-To: <517469EE.3000105@knutov.com> References: <517469EE.3000105@knutov.com> Message-ID: <51746A36.9040304@knutov.com> Наверное, важно: Linux 2.6.32, OpenVZ. 22.04.2013 4:36, Nick Knutov пишет: > Если я правильно понимаю, что для отдачи больших файлов с локальных > дисков лучше делать sendfile off и aio on, то можно ли сделать так, > чтобы это происходило автоматически для файлов размером больше, > например, 1 мегабайта (или любого другого рекомендуемого? > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From vbart at nginx.com Mon Apr 22 02:57:22 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 22 Apr 2013 06:57:22 +0400 Subject: =?UTF-8?Q?Re=3A_sendfile__=D0=B8_aio?= In-Reply-To: <517469EE.3000105@knutov.com> References: <517469EE.3000105@knutov.com> Message-ID: <201304220657.22489.vbart@nginx.com> On Monday 22 April 2013 02:36:30 Nick Knutov wrote: > Если я правильно понимаю, что для отдачи больших файлов с локальных > дисков лучше делать sendfile off и aio on, Когда используется aio на линуксе, то sendfile() и так не используется. Выключать его явно при использовании aio - нет необходимости. > то можно ли сделать так, чтобы это происходило автоматически для > файлов размером больше, например, 1 мегабайта (или любого другого > рекомендуемого? На линуксе aio включается только при использовании O_DIRECT. Директива directio и задает размер начиная с которого будет использоваться O_DIRECT. -- Валентин Бартенев http://nginx.org/en/donation.html From bener.beer at gmail.com Mon Apr 22 09:37:22 2013 From: bener.beer at gmail.com (Eric Benjamin) Date: Mon, 22 Apr 2013 13:37:22 +0400 Subject: =?UTF-8?B?0LzQvtC00YPQu9GMIG1wNDogc3RhcnQgdGltZSBpcyBvdXQgbXA0IHN0c2MgY2h1?= =?UTF-8?B?bmtz?= Message-ID: Приветствую! Вопрос по модулю mp4. Пытаюсь разобраться. При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc chunks" Время начала данной ошибки (при запросе ?start=XXX) разнится в зависимости от параметров конвертации одного итого же файла. Но после возникновения, при увеличении значения секунд, остается. Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в модуле mp4? Для конвертировании используется ffmpeg 1.2 # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec libfaac -ar 44100 -b:a 64k -y "" # qt-faststart "" "" ffmpeg configuration: --enable-gpl --enable-libfdk_aac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-nonfree # uname -a Linux localhost 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11 07:06:34 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux конфиг nginx: server { listen 8800; server_name videofarme; error_log logs/error.vf.log debug; access_log logs/access.vf.log main; root /opt/site/htdocs; location / { mp4_buffer_size 1m; mp4_max_buffer_size 5m; mp4; } } # sbin/nginx -V nginx version: nginx/1.2.7 built by gcc 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) configure arguments: --prefix=/opt/proxy --with-http_image_filter_module --with-http_dav_module --with-http_mp4_module --with-debug -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ?Общее Кол-во : 284 Кол-во потоков такого типа : 1 Тип потока : General Тип потока : Общее Идентификатор типа потока : 0 Inform : MPEG-4 (Base Media): 1,35 Мбайт, 24 с. Кол-во видеопотоков : 1 Video_Format_List : AVC Video_Format_WithHint_List : AVC Видеокодеки : AVC Полное имя : C:\177.high.mp4 Имя папки : C:\ Имя файла : 177.high Расширение : mp4 Формат : MPEG-4 Формат : MPEG-4 Формат/Используется в : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v Коммерческое название : MPEG-4 Профиль формата : Base Media Интернет-тип носителя : video/mp4 Идентификатор кодека : isom Идентификатор кодека/Ссылка : http://www.apple.com/quicktime/download/standalone.html Кодек : MPEG-4 Кодек : MPEG-4 Кодек/Используется в : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v Размер файла : 1415073 Размер файла : 1,35 Мбайт Размер файла : 1 Мбайт Размер файла : 1,3 Мбайт Размер файла : 1,35 Мбайт Размер файла : 1,350 Мбайт Продолжительность : 24360 Продолжительность : 24 с. Продолжительность : 24 с. 360 мс. Продолжительность : 24 с. Продолжительность : 00:00:24.360 Общий поток : 464720 Общий поток : 465 Кбит/сек Размер потока : 3904 Размер потока : 3,81 Кбайт (0%) Размер потока : 4 Кбайт Размер потока : 3,8 Кбайт Размер потока : 3,81 Кбайт Размер потока : 3,813 Кбайт Размер потока : 3,81 Кбайт (0%) Пропорции потока : 0.00276 HeaderSize : 3896 DataSize : 1411177 FooterSize : 0 IsStreamable : Yes Дата файла : UTC 2013-04-22 00:56:50.111 Дата файла (местная) : 2013-04-22 04:56:50.111 Дата изменения файла : UTC 2013-04-22 00:56:51.174 Дата изменения файла (местная) : 2013-04-22 04:56:51.174 Программа кодирования : Lavf54.63.104 Видео Кол-во : 263 Кол-во потоков такого типа : 1 Тип потока : Video Тип потока : Видео Идентификатор типа потока : 0 StreamOrder : 0 Inform : 463 Кбит/сек, 480*270 (16:9), в 25,000 кадров/сек, AVC (High at L2.1) (CABAC / 4 Ref Frames) Идентификатор : 1 Идентификатор : 1 Формат : AVC Формат/Информация : Advanced Video Codec Формат/Ссылка : http://developers.videolan.org/x264.html Коммерческое название : AVC Профиль формата : High at L2.1 Настройки формата : CABAC / 4 Ref Frames Параметр CABAC формата : Yes Параметр CABAC формата : Да Параметр ReFrames формата : 4 Параметр ReFrames формата : 4 кадра Интернет-тип носителя : video/H264 Идентификатор кодека : avc1 Идентификатор кодека/Информация : Advanced Video Coding Идентификатор кодека/Ссылка : http://www.apple.com/quicktime/download/standalone.html Кодек : AVC Кодек : AVC Кодек/Семейство : AVC Кодек/Информация : Advanced Video Codec Кодек/Ссылка : http://developers.videolan.org/x264.html Кодек/CC : avc1 Профиль кодека : High at L2.1 Настройки кодека : CABAC / 4 Ref Frames Параметр CABAC кодека : Yes Codec_Settings_RefFrames : 4 Продолжительность : 24360 Продолжительность : 24 с. Продолжительность : 24 с. 360 мс. Продолжительность : 24 с. Продолжительность : 00:00:24.360 Битрейт : 463438 Битрейт : 463 Кбит/сек Ширина : 480 Ширина : 480 пикселей Высота : 270 Высота : 270 пикселей Пропорции пикселя : 1.000 Соотношение сторон : 1.778 Соотношение сторон : 16:9 Rotation : 0.000 Режим частоты кадров : CFR Режим частоты кадров : Постоянный FrameRate_Mode_Original : VFR Частота кадров : 25.000 Частота кадров : 25,000 кадров/сек Счётчик кадров : 609 Разрешение : 8 Разрешение : 8 бит Колориметрия : 4:2:0 Цветовое пространство : YUV Субдискретизация насыщенности : 4:2:0 Битовая глубина : 8 Битовая глубина : 8 бит Тип развёртки : Progressive Тип развёртки : Прогрессивная Переплетение : PPF Переплетение : Прогрессивная Бит/(Пиксели*Кадры) : 0.143 Задержка : -80 Задержка : -80 мс. Задержка : -80 мс. Задержка : -80 мс. Задержка : -00:00:00.080 Задержка в оригинале : Container Задержка в оригинале : Контейнер Размер потока : 1411169 Размер потока : 1,35 Мбайт (100%) Размер потока : 1 Мбайт Размер потока : 1,3 Мбайт Размер потока : 1,35 Мбайт Размер потока : 1,346 Мбайт Размер потока : 1,35 Мбайт (100%) Пропорции потока : 0.99724 Библиотека кодирования : x264 - core 130 r2274 c832fe9 Библиотека кодирования : x264 core 130 r2274 c832fe9 Библиотека кодирования/Имя : x264 Библиотека кодирования/Version : core 130 r2274 c832fe9 Настройки программы : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=25 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=25 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.log Type: application/octet-stream Size: 14392 bytes Desc: not available URL: From nginx-forum at nginx.us Mon Apr 22 09:45:55 2013 From: nginx-forum at nginx.us (kermit32dll) Date: Mon, 22 Apr 2013 05:45:55 -0400 Subject: =?UTF-8?B?UmU6IG5naW54ICsgc3Bvb2ZlZCBzeW4g0YTQu9GD0LQ=?= In-Reply-To: <473992834.20130420200138@softsearch.ru> References: <473992834.20130420200138@softsearch.ru> Message-ID: Debian 6, ядро 2.6.32 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238505,238533#msg-238533 From pr1 at pr1.ru Mon Apr 22 14:32:06 2013 From: pr1 at pr1.ru (Andrey Feldman) Date: Mon, 22 Apr 2013 18:32:06 +0400 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: References: Message-ID: А без qt-faststart как? тожсамое? 2013/4/22 Eric Benjamin > Приветствую! > > Вопрос по модулю mp4. Пытаюсь разобраться. > При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc chunks" > > Время начала данной ошибки (при запросе ?start=XXX) разнится в зависимости > от > параметров конвертации одного итого же файла. > Но после возникновения, при увеличении значения секунд, остается. > > Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в модуле > mp4? > > Для конвертировании используется ffmpeg 1.2 > > # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec > libfaac -ar 44100 -b:a 64k -y "" > # qt-faststart "" "" > ffmpeg configuration: --enable-gpl --enable-libfdk_aac > --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx > --enable-libx264 --enable-nonfree > > # uname -a > Linux localhost 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11 07:06:34 > UTC 2010 x86_64 x86_64 x86_64 GNU/Linux > > конфиг nginx: > > server { > listen 8800; > server_name videofarme; > error_log logs/error.vf.log debug; > access_log logs/access.vf.log main; > > root /opt/site/htdocs; > location / { > mp4_buffer_size 1m; > mp4_max_buffer_size 5m; > mp4; > } > } > > > # sbin/nginx -V > nginx version: nginx/1.2.7 > built by gcc 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) > configure arguments: --prefix=/opt/proxy --with-http_image_filter_module > --with-http_dav_module --with-http_mp4_module --with-debug > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- -- Andrey Feldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From a4irkin at gmail.com Mon Apr 22 19:21:00 2013 From: a4irkin at gmail.com (Aleksey Chirkin) Date: Mon, 22 Apr 2013 23:21:00 +0400 Subject: proxy_next_upstream http_403 code Message-ID: Здравствуйте! В моей конфигурации nginx раздает файлы и балансирует нагрузку между серверами. Я использую rsync для синхронизации данных между машинами. Во время синхронизации rsync назначает chmod 600 на синхронизируемые директории. Nginx отвечает кодом 403 т.к. ресурс не достижим из-за ограниченных привилегий. Я хотел бы перехватить код 403 и перенаправить запрос на другой сервер. Не могли бы вы добавить поддержку кода 403 в proxy_next_upstream директиве? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marck at rinet.ru Mon Apr 22 19:33:53 2013 From: marck at rinet.ru (Dmitry Morozovsky) Date: Mon, 22 Apr 2013 23:33:53 +0400 (MSK) Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: On Mon, 22 Apr 2013, Aleksey Chirkin wrote: > В моей конфигурации nginx раздает файлы и балансирует нагрузку между > серверами. > Я использую rsync для синхронизации данных между машинами. > Во время синхронизации rsync назначает chmod 600 на синхронизируемые > директории. Nginx отвечает кодом 403 т.к. ресурс не достижим из-за > ограниченных привилегий. > Я хотел бы перехватить код 403 и перенаправить запрос на другой сервер. > > Не могли бы вы добавить поддержку кода 403 в proxy_next_upstream директиве? Простите за нескромный вопрос, а *зачем* вы так делаете? Если не предпринимать специальных усилий, то новые файлы в процессе rsync появляются на месте атомарно -- всё должно работать и так. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From mdounin at mdounin.ru Mon Apr 22 20:10:05 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 23 Apr 2013 00:10:05 +0400 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: References: Message-ID: <20130422201004.GO92338@mdounin.ru> Hello! On Mon, Apr 22, 2013 at 01:37:22PM +0400, Eric Benjamin wrote: > Приветствую! > > Вопрос по модулю mp4. Пытаюсь разобраться. > При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc chunks" > > Время начала данной ошибки (при запросе ?start=XXX) разнится в зависимости > от > параметров конвертации одного итого же файла. > Но после возникновения, при увеличении значения секунд, остается. > > Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в модуле > mp4? Судя по debug log'у - сообщение вполне верное, и в stsc атоме - некорректная информация: 2013/04/22 04:54:10 [debug] 11101#0: *1456 mp4 stsc atom update 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:450, chunk:1, chunks:1, samples:426, id:1 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:24, chunk:2, chunks:0, samples:183 2013/04/22 04:54:10 [error] 11101#0: *1456 start time is out mp4 stsc chunks in "/opt/site/htdocs/177.high.mp4", client: 127.0.0.1, server: videofarm, request: "GET /177.high.mp4?start=18 HTTP/1.0", host: "videofarmext" Во второй строке - интересна часть "chunks:0", т.е. в этой записи таблицы sample-to-chunk вроде как вообще нет chunk'ом. Что выглядит как откровенная неправда. Имеет смысл смотреть внимательно на mp4-файл и процесс его создания. -- Maxim Dounin http://nginx.org/en/donation.html From bener.beer at gmail.com Mon Apr 22 22:36:29 2013 From: bener.beer at gmail.com (Eric Benjamin) Date: Tue, 23 Apr 2013 02:36:29 +0400 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: References: Message-ID: Без qt-faststart тоже самое. На самом деле, пришлось прибегнуть к qt-faststart как раз в связи с данной проблемой. Т.к. закралась мысль о том, что все таки нужен что то наподобие metadata injector для mp4 как для flv, 22 апреля 2013 г., 18:32 пользователь Andrey Feldman написал: > А без qt-faststart как? тожсамое? > > > 2013/4/22 Eric Benjamin > >> Приветствую! >> >> Вопрос по модулю mp4. Пытаюсь разобраться. >> При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc >> chunks" >> >> Время начала данной ошибки (при запросе ?start=XXX) разнится в >> зависимости от >> параметров конвертации одного итого же файла. >> Но после возникновения, при увеличении значения секунд, остается. >> >> Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в >> модуле mp4? >> >> Для конвертировании используется ffmpeg 1.2 >> >> # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec >> libfaac -ar 44100 -b:a 64k -y "" >> # qt-faststart "" "" >> ffmpeg configuration: --enable-gpl --enable-libfdk_aac >> --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx >> --enable-libx264 --enable-nonfree >> >> # uname -a >> Linux localhost 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11 07:06:34 >> UTC 2010 x86_64 x86_64 x86_64 GNU/Linux >> >> конфиг nginx: >> >> server { >> listen 8800; >> server_name videofarme; >> error_log logs/error.vf.log debug; >> access_log logs/access.vf.log main; >> >> root /opt/site/htdocs; >> location / { >> mp4_buffer_size 1m; >> mp4_max_buffer_size 5m; >> mp4; >> } >> } >> >> >> # sbin/nginx -V >> nginx version: nginx/1.2.7 >> built by gcc 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) >> configure arguments: --prefix=/opt/proxy --with-http_image_filter_module >> --with-http_dav_module --with-http_mp4_module --with-debug >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > -- > Andrey Feldman > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bener.beer at gmail.com Mon Apr 22 23:05:05 2013 From: bener.beer at gmail.com (Eric Benjamin) Date: Tue, 23 Apr 2013 03:05:05 +0400 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: <20130422201004.GO92338@mdounin.ru> References: <20130422201004.GO92338@mdounin.ru> Message-ID: Команда для ffmpeg для конвертации (как писал) # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec libfaac -ar 44100 -b:a 64k -y "" исходный файл: http://yadi.sk/d/xp1lY9Rg4Gj4V итоговый файл: в аттаче. 23 апреля 2013 г., 0:10 пользователь Maxim Dounin написал: > Hello! > > On Mon, Apr 22, 2013 at 01:37:22PM +0400, Eric Benjamin wrote: > > > Приветствую! > > > > Вопрос по модулю mp4. Пытаюсь разобраться. > > При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc > chunks" > > > > Время начала данной ошибки (при запросе ?start=XXX) разнится в > зависимости > > от > > параметров конвертации одного итого же файла. > > Но после возникновения, при увеличении значения секунд, остается. > > > > Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в > модуле > > mp4? > > Судя по debug log'у - сообщение вполне верное, и в stsc атоме - > некорректная информация: > > 2013/04/22 04:54:10 [debug] 11101#0: *1456 mp4 stsc atom update > 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:450, chunk:1, > chunks:1, samples:426, id:1 > 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:24, chunk:2, > chunks:0, samples:183 > 2013/04/22 04:54:10 [error] 11101#0: *1456 start time is out mp4 stsc > chunks in "/opt/site/htdocs/177.high.mp4", client: 127.0.0.1, server: > videofarm, request: "GET /177.high.mp4?start=18 HTTP/1.0", host: > "videofarmext" > > Во второй строке - интересна часть "chunks:0", т.е. в этой записи > таблицы sample-to-chunk вроде как вообще нет chunk'ом. Что > выглядит как откровенная неправда. > > Имеет смысл смотреть внимательно на mp4-файл и процесс его > создания. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 177.high.mp4 Type: video/mp4 Size: 1415073 bytes Desc: not available URL: From a4irkin at gmail.com Tue Apr 23 05:30:35 2013 From: a4irkin at gmail.com (Aleksey Chirkin) Date: Tue, 23 Apr 2013 09:30:35 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: Я наблюдал за тем как работает rsync и заметил что на время копирования он блокирует доступ к директории устанавливая ей chmod 600, после выполнения синхронизации он устанавливает правильные права доступа. Вот в этот промежуток копирования и нужно перехватывать 403. Может я не понял вопроса? Вроде все делаю правильно. 22 апреля 2013 г., 23:33 пользователь Dmitry Morozovsky написал: > On Mon, 22 Apr 2013, Aleksey Chirkin wrote: > > > В моей конфигурации nginx раздает файлы и балансирует нагрузку между > > серверами. > > Я использую rsync для синхронизации данных между машинами. > > Во время синхронизации rsync назначает chmod 600 на синхронизируемые > > директории. Nginx отвечает кодом 403 т.к. ресурс не достижим из-за > > ограниченных привилегий. > > Я хотел бы перехватить код 403 и перенаправить запрос на другой сервер. > > > > Не могли бы вы добавить поддержку кода 403 в proxy_next_upstream > директиве? > > Простите за нескромный вопрос, а *зачем* вы так делаете? > > Если не предпринимать специальных усилий, то новые файлы в процессе rsync > появляются на месте атомарно -- всё должно работать и так. > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck at FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** > ------------------------------------------------------------------------ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.barut at gmail.com Tue Apr 23 06:27:45 2013 From: alex.barut at gmail.com (Alex Belyansky) Date: Tue, 23 Apr 2013 10:27:45 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: <517629E1.2020408@gmail.com> А чем не устраивает recursive_error_pages on; error_page 403 = @upstream; location @upstream { proxy_pass http://upstream; } Насколько я понял документацию, то при возникновении 403-ей от сервера в апстриме nginx снова передаст ее туда же, но уже скорее всего на другой из бекендов. Поправьте если я ошибаюсь. On 23.04.2013 09:30, Aleksey Chirkin wrote: > Я наблюдал за тем как работает rsync и заметил что на время > копирования он блокирует доступ к директории устанавливая ей chmod > 600, после выполнения синхронизации он устанавливает правильные права > доступа. Вот в этот промежуток копирования и нужно перехватывать 403. > Может я не понял вопроса? Вроде все делаю правильно. > > > 22 апреля 2013 г., 23:33 пользователь Dmitry Morozovsky > > написал: > > On Mon, 22 Apr 2013, Aleksey Chirkin wrote: > > > В моей конфигурации nginx раздает файлы и балансирует нагрузку между > > серверами. > > Я использую rsync для синхронизации данных между машинами. > > Во время синхронизации rsync назначает chmod 600 на синхронизируемые > > директории. Nginx отвечает кодом 403 т.к. ресурс не достижим из-за > > ограниченных привилегий. > > Я хотел бы перехватить код 403 и перенаправить запрос на другой > сервер. > > > > Не могли бы вы добавить поддержку кода 403 в proxy_next_upstream > директиве? > > Простите за нескромный вопрос, а *зачем* вы так делаете? > > Если не предпринимать специальных усилий, то новые файлы в > процессе rsync > появляются на месте атомарно -- всё должно работать и так. > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, > DM3-RIPN] > [ FreeBSD committer: marck at FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- > marck at rinet.ru *** > ------------------------------------------------------------------------ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From a4irkin at gmail.com Tue Apr 23 07:03:15 2013 From: a4irkin at gmail.com (Aleksey Chirkin) Date: Tue, 23 Apr 2013 11:03:15 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: <517629E1.2020408@gmail.com> References: <517629E1.2020408@gmail.com> Message-ID: При возникновении 403-ей ошибки запрос не будет передан на следующий сервер, т.к. директива proxy_next_upstream не поддерживает этот код. Я указал на пример где перехват этого кода действительно нужен в случае когда по для синхронизации блокирует доступ к синхронизируемым файлам путем снятия прав доступа. Alex Belyansky, спасибо, вы указали на один из возможных вариантов решения проблемы, он работает но использование его не совсем удобно, т.к. http://upstream должен указывать на отличный апстрим от того который перенаправил запрос на текущий сервер, иначе запрос вернется обратно, к тому же это это вряд ли будет работать в конфигурации апстримов с резервными серверами. Директива proxy_next_upstream в данном случае намного удобнее. 23 апреля 2013 г., 10:27 пользователь Alex Belyansky написал: > А чем не устраивает > > recursive_error_pages on; > error_page 403 = @upstream; > > location @upstream { > proxy_pass http://upstream; > } > > Насколько я понял документацию, то при возникновении 403-ей от сервера в > апстриме nginx снова передаст ее туда же, но уже скорее всего на другой из > бекендов. > > Поправьте если я ошибаюсь. > > > On 23.04.2013 09:30, Aleksey Chirkin wrote: > > Я наблюдал за тем как работает rsync и заметил что на время копирования он > блокирует доступ к директории устанавливая ей chmod 600, после выполнения > синхронизации он устанавливает правильные права доступа. Вот в этот > промежуток копирования и нужно перехватывать 403. Может я не понял вопроса? > Вроде все делаю правильно. > > > 22 апреля 2013 г., 23:33 пользователь Dmitry Morozovsky написал: > >> On Mon, 22 Apr 2013, Aleksey Chirkin wrote: >> >> > В моей конфигурации nginx раздает файлы и балансирует нагрузку между >> > серверами. >> > Я использую rsync для синхронизации данных между машинами. >> > Во время синхронизации rsync назначает chmod 600 на синхронизируемые >> > директории. Nginx отвечает кодом 403 т.к. ресурс не достижим из-за >> > ограниченных привилегий. >> > Я хотел бы перехватить код 403 и перенаправить запрос на другой сервер. >> > >> > Не могли бы вы добавить поддержку кода 403 в proxy_next_upstream >> директиве? >> >> Простите за нескромный вопрос, а *зачем* вы так делаете? >> >> Если не предпринимать специальных усилий, то новые файлы в процессе rsync >> появляются на месте атомарно -- всё должно работать и так. >> >> -- >> Sincerely, >> D.Marck [DM5020, MCK-RIPE, DM3-RIPN] >> [ FreeBSD committer: marck at FreeBSD.org ] >> ------------------------------------------------------------------------ >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing listnginx-ru at nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Tue Apr 23 10:05:56 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 23 Apr 2013 14:05:56 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: <201304231405.56884.vbart@nginx.com> On Monday 22 April 2013 23:21:00 Aleksey Chirkin wrote: > Здравствуйте! > > В моей конфигурации nginx раздает файлы и балансирует нагрузку между > серверами. > Я использую rsync для синхронизации данных между машинами. > Во время синхронизации rsync назначает chmod 600 на синхронизируемые > директории. Nginx отвечает кодом 403 т.к. ресурс не достижим из-за > ограниченных привилегий. Как одно из решений - можно с помощью директивы error_page изменить код ответа на один из поддерживаемых в proxy_next_upstream. -- Валентин Бартенев http://nginx.org/en/donation.html > Я хотел бы перехватить код 403 и перенаправить запрос на другой сервер. > > Не могли бы вы добавить поддержку кода 403 в proxy_next_upstream директиве? From a4irkin at gmail.com Tue Apr 23 10:28:50 2013 From: a4irkin at gmail.com (Aleksey Chirkin) Date: Tue, 23 Apr 2013 14:28:50 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: <201304231405.56884.vbart@nginx.com> References: <201304231405.56884.vbart@nginx.com> Message-ID: Валентин, спасибо! Я об этом воркэраунде не подумал, воспользуюсь пока. Но все же как на счет http_403? 23 апреля 2013 г., 14:05 пользователь Валентин Бартенев написал: > On Monday 22 April 2013 23:21:00 Aleksey Chirkin wrote: > > Здравствуйте! > > > > В моей конфигурации nginx раздает файлы и балансирует нагрузку между > > серверами. > > Я использую rsync для синхронизации данных между машинами. > > Во время синхронизации rsync назначает chmod 600 на синхронизируемые > > директории. Nginx отвечает кодом 403 т.к. ресурс не достижим из-за > > ограниченных привилегий. > > Как одно из решений - можно с помощью директивы error_page изменить код > ответа > на один из поддерживаемых в proxy_next_upstream. > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > > > Я хотел бы перехватить код 403 и перенаправить запрос на другой сервер. > > > > Не могли бы вы добавить поддержку кода 403 в proxy_next_upstream > директиве? > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marck at rinet.ru Tue Apr 23 10:56:46 2013 From: marck at rinet.ru (Dmitry Morozovsky) Date: Tue, 23 Apr 2013 14:56:46 +0400 (MSK) Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: On Tue, 23 Apr 2013, Aleksey Chirkin wrote: > Я наблюдал за тем как работает rsync и заметил что на время копирования он > блокирует доступ к директории устанавливая ей chmod 600, после выполнения > синхронизации он устанавливает правильные права доступа. А, вы про новосоздаваемые каталоги -- тогда да. А часто ли у вас меняется структура каталогов бэкенда? Потому что если она стабильна, то указанное будет только при первой синхронизации; разумно её делать до введения бэкенда в список апстримов -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From a4irkin at gmail.com Tue Apr 23 11:01:11 2013 From: a4irkin at gmail.com (Aleksey Chirkin) Date: Tue, 23 Apr 2013 15:01:11 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: Каждый день на основной сервер добавляется директория с кучей файлов объемом несколько гигабайт. И пока она синхронизируется на другие сервера, попытка доступа к файлам этой директории на синхронизируемых серверах приводит к ошибке 403. upstream заканчивает попытки перебора серверов не обработав этот код в proxy_next_upstream. 23 апреля 2013 г., 14:56 пользователь Dmitry Morozovsky написал: > On Tue, 23 Apr 2013, Aleksey Chirkin wrote: > > > Я наблюдал за тем как работает rsync и заметил что на время копирования > он > > блокирует доступ к директории устанавливая ей chmod 600, после выполнения > > синхронизации он устанавливает правильные права доступа. > > А, вы про новосоздаваемые каталоги -- тогда да. > > А часто ли у вас меняется структура каталогов бэкенда? Потому что если она > стабильна, то указанное будет только при первой синхронизации; разумно её > делать до введения бэкенда в список апстримов > > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck at FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** > ------------------------------------------------------------------------ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pr1 at pr1.ru Tue Apr 23 11:44:42 2013 From: pr1 at pr1.ru (Andrey Feldman) Date: Tue, 23 Apr 2013 15:44:42 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: А если сначало синхронизировать структуру директорий ? Типа rsync -av -f"+ */" -f"- *". Вторым шагам проходить по файлам. 2013/4/23 Aleksey Chirkin > Каждый день на основной сервер добавляется директория с кучей файлов > объемом несколько гигабайт. И пока она синхронизируется на другие сервера, > попытка доступа к файлам этой директории на синхронизируемых серверах > приводит к ошибке 403. upstream заканчивает попытки перебора серверов не > обработав этот код в proxy_next_upstream. > > > 23 апреля 2013 г., 14:56 пользователь Dmitry Morozovsky написал: > >> On Tue, 23 Apr 2013, Aleksey Chirkin wrote: >> >> > Я наблюдал за тем как работает rsync и заметил что на время копирования >> он >> > блокирует доступ к директории устанавливая ей chmod 600, после >> выполнения >> > синхронизации он устанавливает правильные права доступа. >> >> А, вы про новосоздаваемые каталоги -- тогда да. >> >> А часто ли у вас меняется структура каталогов бэкенда? Потому что если она >> стабильна, то указанное будет только при первой синхронизации; разумно её >> делать до введения бэкенда в список апстримов >> >> >> -- >> Sincerely, >> D.Marck [DM5020, MCK-RIPE, DM3-RIPN] >> [ FreeBSD committer: marck at FreeBSD.org ] >> ------------------------------------------------------------------------ >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- -- Andrey Feldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From a4irkin at gmail.com Tue Apr 23 11:48:37 2013 From: a4irkin at gmail.com (Aleksey Chirkin) Date: Tue, 23 Apr 2013 15:48:37 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: Есть много способов. Я так же могу в субд хранить информацию о синхронизированных файлах на всех серверах, но это не предмет разговора. 23 апреля 2013 г., 15:44 пользователь Andrey Feldman написал: > А если сначало синхронизировать структуру директорий ? Типа rsync -av > -f"+ */" -f"- *". > Вторым шагам проходить по файлам. > > > 2013/4/23 Aleksey Chirkin > >> Каждый день на основной сервер добавляется директория с кучей файлов >> объемом несколько гигабайт. И пока она синхронизируется на другие сервера, >> попытка доступа к файлам этой директории на синхронизируемых серверах >> приводит к ошибке 403. upstream заканчивает попытки перебора серверов не >> обработав этот код в proxy_next_upstream. >> >> >> 23 апреля 2013 г., 14:56 пользователь Dmitry Morozovsky написал: >> >>> On Tue, 23 Apr 2013, Aleksey Chirkin wrote: >>> >>> > Я наблюдал за тем как работает rsync и заметил что на время >>> копирования он >>> > блокирует доступ к директории устанавливая ей chmod 600, после >>> выполнения >>> > синхронизации он устанавливает правильные права доступа. >>> >>> А, вы про новосоздаваемые каталоги -- тогда да. >>> >>> А часто ли у вас меняется структура каталогов бэкенда? Потому что если >>> она >>> стабильна, то указанное будет только при первой синхронизации; разумно её >>> делать до введения бэкенда в список апстримов >>> >>> >>> -- >>> Sincerely, >>> D.Marck [DM5020, MCK-RIPE, DM3-RIPN] >>> [ FreeBSD committer: marck at FreeBSD.org ] >>> ------------------------------------------------------------------------ >>> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > -- > Andrey Feldman > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Apr 23 18:12:30 2013 From: nginx-forum at nginx.us (teo) Date: Tue, 23 Apr 2013 14:12:30 -0400 Subject: nginx as reverse proxy for weblogic In-Reply-To: <3eeba435c46c2909543810b9b27f0580.NginxMailingListRussian@forum.nginx.org> References: <3eeba435c46c2909543810b9b27f0580.NginxMailingListRussian@forum.nginx.org> Message-ID: Кстати нарисовалась еще одна проблема - как сделать так, чтобы nginx был терминатором SSL? Подключение сертификата и указание бекендом тех же серверов кончается циклическим редиректом - похоже что инстансы веблоджика считают что к ним пришли не по ssl и тупо возвращают редирект. Кто знает какой хедер надо подсунуть, чтобы веблоджик считал что это заход по SSL? В связке апач+плагин веблоджика такого поведения не наблюдается, хотя между плагином и инстансом связь без SSL. Не очень-то хочется прописывать https:// на бекенд. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235603,238588#msg-238588 From nginx-forum at nginx.us Tue Apr 23 22:19:08 2013 From: nginx-forum at nginx.us (Demontager) Date: Tue, 23 Apr 2013 18:19:08 -0400 Subject: upstream prematurely closed connection while reading response header Message-ID: <942f1a020e17c53d755b17a74cddc0b7.NginxMailingListRussian@forum.nginx.org> На FreeBSD 9.1 сервере используется связка nginx+phpFPM (1.2.8 и 5.4.13 (cli)). Проблема заключается в импорте дампов баз в phpMyadmin. zip файлы, примерно от 3 мб и выше не импортируются, выдает ошибку - 502 Bad Gateway В логе появляется такое - [error] 49927#0: *196 upstream prematurely closed connection while reading response header from upstream, client: 7X.XX.X.6X, server: domain.com, request: "POST /php3/import.php HTTP/1.1", upstream: "fastcgi://unix:/tmp/php5-fpm.sock2:", host: "domain.com", referrer: "http://domain.com/phpmyadmin/db_import.php?db=testdb&server=1&token=9ee45779dd53c45b7300545dd3113fed" Основной конфиг nginx.conf user www www; worker_processes 2; error_log /var/log/nginx-error.log error; pid /var/run/nginx.pid; events { worker_connections 2048; } http { upstream backend { server unix:/tmp/php5-fpm.sock; } include /usr/local/etc/nginx/mime.types; default_type application/octet-stream; access_log off; log_not_found off; server_tokens off; sendfile on; server_names_hash_bucket_size 128; client_max_body_size 200m; client_body_buffer_size 1m; keepalive_timeout 10; port_in_redirect off; gzip on; gzip_http_version 1.1; gzip_vary on; gzip_comp_level 6; gzip_min_length 0; gzip_proxied any; gzip_types text/plain text/css application/json application/x-javascript application/xml application/xml+rss text/javascript; gzip_buffers 16 8k; gzip_disable "MSIE [1-6].(?!.*SV1)"; include /usr/local/etc/nginx/Includes/*.conf; } Конфиг хоста server { listen 80; server_name www.domain.com; rewrite ^ http://domain.com$request_uri?; error_log /var/log/www/domain.com/nerror.log; } server { listen 80; server_name domain.com; server_name_in_redirect off; root /home/www/domain.com; index index.php index.html index.htm; location ~* ^.+\.(ico|js|gif|jpg|jpeg|png|bmp)$ { expires 30d; } location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { # fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_pass unix:/tmp/php5-fpm.sock2; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_intercept_errors on; fastcgi_ignore_client_abort on; fastcgi_connect_timeout 60s; fastcgi_send_timeout 200s; fastcgi_read_timeout 200s; fastcgi_buffer_size 128k; fastcgi_buffers 8 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } } Пробовал увеличивать таймауты, менять размер буферов - не помогло. Хамидулин рекомендует трогать параметры proxy_buffer_size large_client_header_buffers Но у меня таких даже нет, стоит их добавить и пробовать ? Вот https://gist.github.com/RuslanHamidullin/3894466 как раз вторая ошибка мой случай. Вдруг тут проблема - php.ini http://pastebin.com/vCZdNVSY и my.cnf http://pastebin.com/6XSE75XS Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238590,238590#msg-238590 From pr1 at pr1.ru Tue Apr 23 08:18:17 2013 From: pr1 at pr1.ru (Andrey Feldman) Date: Tue, 23 Apr 2013 12:18:17 +0400 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: References: <20130422201004.GO92338@mdounin.ru> Message-ID: Странно, при таких же параметрах ffmpeg у меня в stsc получилось: stsc size = 28 type = stsc entry_count = 1 first_chunk = 1, samples_per_chunk = 1, sample_description_index = 1 У тебя: stsc size = 40 type = stsc entry_count = 2 first_chunk = 1, samples_per_chunk = 426, sample_description_index = 1 first_chunk = 2, samples_per_chunk = 183, sample_description_index = 1 Попробуй файл в приложении. ffmpeg -i lys-20031106.avi -s 480x270 -vcodec libx264 -crf 23 -r 25 -g 25 -acodec libfaac -ar 44100 -b:a 64k -y test.mp4 ffmpeg -version ffmpeg version 0.8.6-6:0.8.6-0ubuntu0.12.10.1, Copyright (c) 2000-2013 the Libav developers built on Apr 2 2013 17:02:16 with gcc 4.7.2 *** THIS PROGRAM IS DEPRECATED *** This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. ffmpeg 0.8.6-6:0.8.6-0ubuntu0.12.10.1 libavutil 51. 22. 1 / 51. 22. 1 libavcodec 53. 35. 0 / 53. 35. 0 libavformat 53. 21. 1 / 53. 21. 1 libavdevice 53. 2. 0 / 53. 2. 0 libavfilter 2. 15. 0 / 2. 15. 0 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 52. 0. 0 / 52. 0. 0 2013/4/23 Eric Benjamin > Команда для ffmpeg для конвертации (как писал) > # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec > libfaac -ar 44100 -b:a 64k -y "" > > исходный файл: http://yadi.sk/d/xp1lY9Rg4Gj4V > итоговый файл: в аттаче. > > > > > 23 апреля 2013 г., 0:10 пользователь Maxim Dounin написал: > >> Hello! >> >> On Mon, Apr 22, 2013 at 01:37:22PM +0400, Eric Benjamin wrote: >> >> > Приветствую! >> > >> > Вопрос по модулю mp4. Пытаюсь разобраться. >> > При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc >> chunks" >> > >> > Время начала данной ошибки (при запросе ?start=XXX) разнится в >> зависимости >> > от >> > параметров конвертации одного итого же файла. >> > Но после возникновения, при увеличении значения секунд, остается. >> > >> > Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в >> модуле >> > mp4? >> >> Судя по debug log'у - сообщение вполне верное, и в stsc атоме - >> некорректная информация: >> >> 2013/04/22 04:54:10 [debug] 11101#0: *1456 mp4 stsc atom update >> 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:450, chunk:1, >> chunks:1, samples:426, id:1 >> 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:24, chunk:2, >> chunks:0, samples:183 >> 2013/04/22 04:54:10 [error] 11101#0: *1456 start time is out mp4 stsc >> chunks in "/opt/site/htdocs/177.high.mp4", client: 127.0.0.1, server: >> videofarm, request: "GET /177.high.mp4?start=18 HTTP/1.0", host: >> "videofarmext" >> >> Во второй строке - интересна часть "chunks:0", т.е. в этой записи >> таблицы sample-to-chunk вроде как вообще нет chunk'ом. Что >> выглядит как откровенная неправда. >> >> Имеет смысл смотреть внимательно на mp4-файл и процесс его >> создания. >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- -- Andrey Feldman -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.mp4 Type: video/mp4 Size: 1398811 bytes Desc: not available URL: From anatoly at sonru.com Wed Apr 24 08:49:38 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 24 Apr 2013 09:49:38 +0100 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: References: <20130422201004.GO92338@mdounin.ru> Message-ID: <6925B9A9-951C-45C0-AFB3-1D3BF7915696@sonru.com> On Apr 23, 2013, at 9:18 AM, Andrey Feldman wrote: > Странно, при таких же параметрах ffmpeg у меня в stsc получилось: > stsc > size = 28 > type = stsc > entry_count = 1 > first_chunk = 1, samples_per_chunk = 1, sample_description_index = 1 > > У тебя: > stsc > size = 40 > type = stsc > entry_count = 2 > first_chunk = 1, samples_per_chunk = 426, sample_description_index = 1 > first_chunk = 2, samples_per_chunk = 183, sample_description_index = 1 > > Попробуй файл в приложении. > ffmpeg -i lys-20031106.avi -s 480x270 -vcodec libx264 -crf 23 -r 25 -g 25 -acodec libfaac -ar 44100 -b:a 64k -y test.mp4 > > ffmpeg -version > ffmpeg version 0.8.6-6:0.8.6-0ubuntu0.12.10.1, Copyright (c) 2000-2013 the Libav developers > built on Apr 2 2013 17:02:16 with gcc 4.7.2 > *** THIS PROGRAM IS DEPRECATED *** > This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. > ffmpeg 0.8.6-6:0.8.6-0ubuntu0.12.10.1 > libavutil 51. 22. 1 / 51. 22. 1 > libavcodec 53. 35. 0 / 53. 35. 0 > libavformat 53. 21. 1 / 53. 21. 1 > libavdevice 53. 2. 0 / 53. 2. 0 > libavfilter 2. 15. 0 / 2. 15. 0 > libswscale 2. 1. 0 / 2. 1. 0 > libpostproc 52. 0. 0 / 52. 0. 0 > > попробуйте собрать все зависимости руками, чтобы исключить подобные проблемы, мы собираем так: cd /tmp && wget http://tortall.net/projects/yasm/releases/yasm-1.2.0.tar.gz tar xvzf yasm-1.2.0.tar.gz && cd yasm-1.2.0 ./configure && make && make install cd /tmp && wget http://sourceforge.net/projects/opencore-amr/files/vo-aacenc/vo-aacenc-0.1.2.tar.gz tar xvzf vo-aacenc-0.1.2.tar.gz && cd vo-aacenc-0.1.2 ./configure && make && make install cd /tmp && wget http://download.videolan.org/pub/videolan/x264/snapshots/x264-snapshot-20120812-2245-stable.tar.bz2 tar xvjf x264-snapshot-20120812-2245-stable.tar.bz2 && cd x264-snapshot-20120812-2245-stable ./configure --enable-shared && make && make install cd /tmp && wget http://ffmpeg.org/releases/ffmpeg-1.1.2.tar.gz tar xvzf ffmpeg-1.1.2.tar.gz && cd ffmpeg-1.1.2 ./configure --enable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-libvo-aacenc --enable-libx264 $ make && make install make tools/qt-faststart cp tools/qt-faststart /usr/local/bin/ ffmpeg -i YOUR_FILE -c:v libx264 -profile:v baseline -c:a libvo_aacenc -ab 96k -ac 1 OUTPUT.mp4 qt-faststar OUTPUT.mp4 READY.mp4 > > > 2013/4/23 Eric Benjamin > Команда для ffmpeg для конвертации (как писал) > # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec libfaac -ar 44100 -b:a 64k -y "" > > исходный файл: http://yadi.sk/d/xp1lY9Rg4Gj4V > итоговый файл: в аттаче. > > > > > 23 апреля 2013 г., 0:10 пользователь Maxim Dounin написал: > Hello! > > On Mon, Apr 22, 2013 at 01:37:22PM +0400, Eric Benjamin wrote: > > > Приветствую! > > > > Вопрос по модулю mp4. Пытаюсь разобраться. > > При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc chunks" > > > > Время начала данной ошибки (при запросе ?start=XXX) разнится в зависимости > > от > > параметров конвертации одного итого же файла. > > Но после возникновения, при увеличении значения секунд, остается. > > > > Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в модуле > > mp4? > > Судя по debug log'у - сообщение вполне верное, и в stsc атоме - > некорректная информация: > > 2013/04/22 04:54:10 [debug] 11101#0: *1456 mp4 stsc atom update > 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:450, chunk:1, chunks:1, samples:426, id:1 > 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:24, chunk:2, chunks:0, samples:183 > 2013/04/22 04:54:10 [error] 11101#0: *1456 start time is out mp4 stsc chunks in "/opt/site/htdocs/177.high.mp4", client: 127.0.0.1, server: videofarm, request: "GET /177.high.mp4?start=18 HTTP/1.0", host: "videofarmext" > > Во второй строке - интересна часть "chunks:0", т.е. в этой записи > таблицы sample-to-chunk вроде как вообще нет chunk'ом. Что > выглядит как откровенная неправда. > > Имеет смысл смотреть внимательно на mp4-файл и процесс его > создания. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > -- > Andrey Feldman > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Apr 24 13:37:43 2013 From: nginx-forum at nginx.us (Kubik129) Date: Wed, 24 Apr 2013 09:37:43 -0400 Subject: =?UTF-8?B?bmdpbngg0L3QtSDQvtCx0YDQsNCx0LDRgtGL0LLQsNC10YIg0L/QvtC00LTQvtC8?= =?UTF-8?B?0LXQvQ==?= Message-ID: Приветствую всех. ситуация следующая: есть сайт на nginx+php-fpm. Назовем его site.com. Есть два поддомена этого сайта - subdomen1.site.com и subdomen2.site.com. Все они сидят на одном ip. Конфиги: - базовый http { server { listen ip:80; server_name site.com www.site.com; access_log /var/log/nginx/site_access.log main; error_log /var/log/nginx/site_error.log error; root /home/site/data; ... } include subdomen1.conf; include subdomen2.conf; } - первый поддомен server { listen ip:80; server_name subdomen1.site.com; access_log /var/log/nginx/subdomen1_access.log main; error_log /var/log/nginx/subdomen1_error.log error; root /home/subdomen1/data; ... } - второй поддомен server { listen ip:80; server_name subdomen2.site.com; access_log /var/log/nginx/subdomen2_access.log main; error_log /var/log/nginx/subdomen2_error.log error; root /home/subdomen2/data; ... } Казалось бы все должно быть ОК. Но. Поведение всей этой конструкции вгоняет в ступор. Обращаемся на site.com - все ок, обращаемся на subdomen1.site.com - все ок, обращаемся на subdomen2.site.com - и получаем перенаправление на site.com. Фактически мы даже не получаем запись в subdomen2_access.log, обращение пишется сразу в site_access.log. Такое ощущение, что при пробеге по конфигу nginx не видит в упор запись про subdomen2. Пробовал ходить на разные порты, т.е. написал вот так - второй поддомен server { listen ip:8080; server_name subdomen2.site.com; access_log /var/log/nginx/subdomen2_access.log main; error_log /var/log/nginx/subdomen2_error.log error; root /home/subdomen2/data; ... } и заходить по адресу subdomen2.site.com:8080 - и чудо случилось, попадаю куда надо. Вопрос, а как так может быть? почему в первом случае с одинаковыми портами nginx не видит запись про subdomen2, а при разных портах все прекрасно? Понятно что мне нельзя оставлять порт 8080, все должно работать на стандартном 80. Но оно отказывается. Заранее всем спасибо за помощь и идеи. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238601,238601#msg-238601 From mdounin at mdounin.ru Wed Apr 24 14:19:57 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 24 Apr 2013 18:19:57 +0400 Subject: nginx-1.4.0 Message-ID: <20130424141957.GL10443@mdounin.ru> Изменения в nginx 1.4.0 24.04.2013 *) Исправление: nginx не собирался с модулем ngx_http_perl_module, если использовался параметр --with-openssl; ошибка появилась в 1.3.16. *) Исправление: в работе с телом запроса из модуля ngx_http_perl_module; ошибка появилась в 1.3.9. -- Maxim Dounin http://nginx.org/en/donation.html From a at gelun.ru Wed Apr 24 14:46:23 2013 From: a at gelun.ru (Gelun, Artem) Date: Wed, 24 Apr 2013 18:46:23 +0400 Subject: segfault nginx1.3.8 + http-push-stream-module Message-ID: День добрый всем. Столкнулся с проблемой в работе стороннего модуля nginx-http-push-stream-module. Периодически nginx сегфолтится (при том периоды, судя по всему, зависят от аптайма процесса и нагрузки на модуль) Вопроса два: 1) сталкивался ли кто? 2) определить где именно проблема. При поптыке разобрать причины падения возник вопрос по реализации rbtree. Сразу скажу, что я не большой спец в алгоритмах и прошу палками не бить )) Смысл вот в чём. nginx падает с таким бектрейсом: (gdb) bt #0 0x000000000040f6bc in ngx_rbtree_delete (tree=0x7f56ba655000, node=) at src/core/ngx_rbtree.c:300 #1 0x000000000047bb3f in ngx_http_push_stream_collect_expired_messages_and_empty_channels (data=0x7f56ba655000, shpool=0x7f56ba4d7000, force=) at /usr/src/redhat/SOURCES/nginx/nginx-push-stream-module/src/ngx_http_push_stream_module_utils.c:733 #2 0x000000000047bc34 in ngx_http_push_stream_memory_cleanup (ev=) at /usr/src/redhat/SOURCES/nginx/nginx-push-stream-module/src/ngx_http_push_stream_module_utils.c:810 #3 ngx_http_push_stream_memory_cleanup_timer_wake_handler (ev=) at /usr/src/redhat/SOURCES/nginx/nginx-push-stream-module/src/ngx_http_push_stream_module_utils.c:980 #4 0x000000000041cb8c in ngx_event_expire_timers () at src/event/ngx_event_timer.c:149 #5 0x000000000041c97f in ngx_process_events_and_timers (cycle=0xeeb330) at src/event/ngx_event.c:263 #6 0x0000000000422b58 in ngx_worker_process_cycle (cycle=0xeeb330, data=) at src/os/unix/ngx_process_cycle.c:810 #7 0x0000000000421147 in ngx_spawn_process (cycle=0xeeb330, proc=0x422a90 , data=0x0, name=0x47ffb9 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198 #8 0x0000000000422112 in ngx_start_worker_processes (cycle=0xeeb330, n=4, type=-4) at src/os/unix/ngx_process_cycle.c:365 #9 0x000000000042331d in ngx_master_process_cycle (cycle=0xeeb330) at src/os/unix/ngx_process_cycle.c:250 #10 0x000000000040787b in main (argc=, argv=) at src/core/nginx.c:412 (gdb) list 295 ngx_rbt_red(temp->parent); 296 ngx_rbtree_right_rotate(root, sentinel, temp->parent); 297 w = temp->parent->left; 298 } 299 300 if (ngx_rbt_is_black(w->left) && ngx_rbt_is_black(w->right)) { 301 ngx_rbt_red(w); 302 temp = temp->parent; 303 304 } else { В строке 300 ngx_rbt_is_black - в него нельзя передать "0": #define ngx_rbt_is_red(node) ((node)->color) #define ngx_rbt_is_black(node) (!ngx_rbt_is_red(node)) При этом, (gdb) p *w $1 = {key = 0, left = 0x0, right = 0x0, parent = 0x7f56bb2aa200, color = 0 '\000', data = 0 '\000'} (gdb) p *sentinel $5 = {key = 0, left = 0x0, right = 0x0, parent = 0x7f56bb2aa200, color = 0 '\000', data = 0 '\000'} *(gdb) p w==sentinel* *$27 = 1* Помогите разобраться, это особенность реализации rbtree в nginx'е и ошибка в модуле (где-то как-то неправильно заполняют структуру?) или же это недочёт реализации и проблема в самом nginx'е? )) Заранее спасибо. Артём. P.S. Могу, при необходимости, выложить куда-то coredump , бинарник с дебагсимволами и исходники, с которых компилировалось. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Apr 24 14:55:23 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 24 Apr 2013 18:55:23 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC90LUg0L7QsdGA0LDQsdCw0YLRi9Cy0LDQtdGCINC/0L7QtNC0?= =?UTF-8?B?0L7QvNC10L0=?= In-Reply-To: References: Message-ID: <20130424145523.GO10443@mdounin.ru> Hello! On Wed, Apr 24, 2013 at 09:37:43AM -0400, Kubik129 wrote: > Приветствую всех. > ситуация следующая: есть сайт на nginx+php-fpm. Назовем его site.com. Есть > два поддомена этого сайта - subdomen1.site.com и subdomen2.site.com. Все они > сидят на одном ip. Конфиги: > - базовый > http { > server { > listen ip:80; > server_name site.com www.site.com; > access_log /var/log/nginx/site_access.log main; > error_log /var/log/nginx/site_error.log error; > root /home/site/data; > ... > } > include subdomen1.conf; > include subdomen2.conf; > } > - первый поддомен > server { > listen ip:80; > server_name subdomen1.site.com; > access_log /var/log/nginx/subdomen1_access.log main; > error_log /var/log/nginx/subdomen1_error.log error; > root /home/subdomen1/data; > ... > } > - второй поддомен > server { > listen ip:80; > server_name subdomen2.site.com; > access_log /var/log/nginx/subdomen2_access.log main; > error_log /var/log/nginx/subdomen2_error.log error; > root /home/subdomen2/data; > ... > } > Казалось бы все должно быть ОК. > Но. Поведение всей этой конструкции вгоняет в ступор. Обращаемся на site.com > - все ок, обращаемся на subdomen1.site.com - все ок, обращаемся на > subdomen2.site.com - и получаем перенаправление на site.com. Фактически мы > даже не получаем запись в subdomen2_access.log, обращение пишется сразу в > site_access.log. Такое ощущение, что при пробеге по конфигу nginx не видит в > упор запись про subdomen2. > Пробовал ходить на разные порты, т.е. написал вот так > - второй поддомен > server { > listen ip:8080; > server_name subdomen2.site.com; > access_log /var/log/nginx/subdomen2_access.log main; > error_log /var/log/nginx/subdomen2_error.log error; > root /home/subdomen2/data; > ... > } > и заходить по адресу subdomen2.site.com:8080 - и чудо случилось, попадаю > куда надо. > > Вопрос, а как так может быть? почему в первом случае с одинаковыми портами > nginx не видит запись про subdomen2, а при разных портах все прекрасно? > Понятно что мне нельзя оставлять порт 8080, все должно работать на > стандартном 80. Но оно отказывается. > Заранее всем спасибо за помощь и идеи. Не имея полного конфига - можно только гадать, но я бы поставил на опечатку имени домена. При использовании отдельного порта - имя становится не важно, т.к. единственный сервер на данном порту становится заодно и сервером по умолчанию. -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Wed Apr 24 20:41:44 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 25 Apr 2013 00:41:44 +0400 Subject: upstream prematurely closed connection while reading response header In-Reply-To: <942f1a020e17c53d755b17a74cddc0b7.NginxMailingListRussian@forum.nginx.org> References: <942f1a020e17c53d755b17a74cddc0b7.NginxMailingListRussian@forum.nginx.org> Message-ID: <201304250041.44284.vbart@nginx.com> On Wednesday 24 April 2013 02:19:08 Demontager wrote: > На FreeBSD 9.1 сервере используется связка nginx+phpFPM (1.2.8 и 5.4.13 > (cli)). Проблема заключается в импорте дампов баз в phpMyadmin. zip файлы, > примерно от 3 мб и выше не импортируются, выдает ошибку - > > 502 Bad Gateway > > В логе появляется такое - > [error] 49927#0: *196 upstream prematurely closed connection while reading > response header from upstream, client: 7X.XX.X.6X, server: domain.com, > request: "POST /php3/import.php HTTP/1.1", upstream: > "fastcgi://unix:/tmp/php5-fpm.sock2:", host: "domain.com", referrer: > "http://domain.com/phpmyadmin/db_import.php?db=testdb&server=1&token=9ee457 > 79dd53c45b7300545dd3113fed" > В сообщение об ошибке четко указан виновник. Ваш php-fpm закрыл соединение и, видимо, убил скрипт до того, как отдать ответ. [...] > Пробовал увеличивать таймауты, менять размер буферов - не помогло. > Хамидулин рекомендует трогать параметры > proxy_buffer_size > large_client_header_buffers > large_client_header_buffers вообще не имеет отношения к чтению ответа от upstream-сервера. > Но у меня таких даже нет, стоит их добавить и пробовать ? > Вот https://gist.github.com/RuslanHamidullin/3894466 как раз вторая > ошибка мой случай. По ссылке написано много глупости, наверное даже больше, чем чего-то полезного. > Вдруг тут проблема - php.ini http://pastebin.com/vCZdNVSY и my.cnf > http://pastebin.com/6XSE75XS > Именно так, настраивайте php. Nginx тут не при чём. На лицо исчерпание каких-то таймаутов или лимитов на ресурсы в php или php-fpm. В лог последнего вы смотрели? -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Apr 24 21:22:10 2013 From: nginx-forum at nginx.us (Demontager) Date: Wed, 24 Apr 2013 17:22:10 -0400 Subject: upstream prematurely closed connection while reading response header In-Reply-To: <942f1a020e17c53d755b17a74cddc0b7.NginxMailingListRussian@forum.nginx.org> References: <942f1a020e17c53d755b17a74cddc0b7.NginxMailingListRussian@forum.nginx.org> Message-ID: <013d818ef46883cda5d8bf1ca98ec5a7.NginxMailingListRussian@forum.nginx.org> Да, это понимаю что проблема не в nginx, php-fpm закрывает соединение. По поводу логов, включил максимальное логирование в пуле, вплоть до notice ..... ;Resources include=/usr/local/etc/nginx/pm.conf ;Log errors catch_workers_output = yes php_flag[display_errors] = on ;Base dirs php_admin_value[error_reporting] = 8191 php_admin_value[error_log] = /var/log/www/domain.com/php-error.log .... Но после 502 Bad Gateway, там кроме notice и warning ничего такого, обьясняющее ошибку не появилось. В php.ini стоят довольно высокие лимиты, поэтому не знаю что еще можно крутить там. Проверил еще mysql лог, тоже не заметил ничего подозрительного. Единственное, что привлекло внимание, это лог php-fpm.log там часто повторяется, вот эта строчка - [23-Apr-2013 23:33:53] ERROR: unable to read what child say: Bad file descriptor (9 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238590,238624#msg-238624 From nginx-forum at nginx.us Thu Apr 25 07:35:52 2013 From: nginx-forum at nginx.us (shambler81) Date: Thu, 25 Apr 2013 03:35:52 -0400 Subject: =?UTF-8?B?0YDQsNC30L3Ri9C1IHJvYm90cy50eHQg0LTQu9GPINC00LLRg9GFINC00L7QvNC1?= =?UTF-8?B?0L3QvtCy?= Message-ID: <8abf1c901957886b61d59c72e05db077.NginxMailingListRussian@forum.nginx.org> Добрый день коллеги, достаточно простой вопрос.хоть на первый взгляд и немного странный. Требуется сослаться на одну и ту же папку с разных доменных имен. С разницей только в 1 файл который должен подменить nginx дабы у каждого домена свой robots.txt, все остальное по прежнему. (папка сайта обязательна таже, разница только конкретный файл) nginx version: nginx/0.7.67 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238630,238630#msg-238630 From nginx-forum at nginx.us Thu Apr 25 07:39:15 2013 From: nginx-forum at nginx.us (shambler81) Date: Thu, 25 Apr 2013 03:39:15 -0400 Subject: =?UTF-8?B?UmU6INGA0LDQt9C90YvQtSByb2JvdHMudHh0INC00LvRjyDQtNCy0YPRhSDQtNC+?= =?UTF-8?B?0LzQtdC90L7Qsg==?= In-Reply-To: <8abf1c901957886b61d59c72e05db077.NginxMailingListRussian@forum.nginx.org> References: <8abf1c901957886b61d59c72e05db077.NginxMailingListRussian@forum.nginx.org> Message-ID: пардон Nginx не на том сервере посмотрел на этом nginx version: nginx/1.2.4 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238630,238631#msg-238631 From a at gelun.ru Thu Apr 25 07:44:53 2013 From: a at gelun.ru (Gelun, Artem) Date: Thu, 25 Apr 2013 11:44:53 +0400 Subject: =?UTF-8?B?UmU6INGA0LDQt9C90YvQtSByb2JvdHMudHh0INC00LvRjyDQtNCy0YPRhSDQtNC+?= =?UTF-8?B?0LzQtdC90L7Qsg==?= In-Reply-To: References: <8abf1c901957886b61d59c72e05db077.NginxMailingListRussian@forum.nginx.org> Message-ID: 1) Отдельный location для robots.txt заведите на каждом домене (если серверы определены независимо несколько раз для каждого домена) 2) если server определён один раз со множеством server_name, то: location = /robots.txt { alias /path/to/robots/folder/$server_name/robots.txt ; } как-то так (писал по памяти, мог ошибиться) 25 апреля 2013 г., 11:39 пользователь shambler81 написал: > пардон Nginx не на том сервере посмотрел на этом nginx version: > nginx/1.2.4 > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238630,238631#msg-238631 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From samarinaleksandr at gmail.com Thu Apr 25 08:17:30 2013 From: samarinaleksandr at gmail.com (=?koi8-r?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Thu, 25 Apr 2013 11:17:30 +0300 Subject: =?UTF-8?B?UkU6INGA0LDQt9C90YvQtSByb2JvdHMudHh0INC00LvRjyDQtNCy0YPRhSDQtNC+?= =?UTF-8?B?0LzQtdC90L7Qsg==?= In-Reply-To: <8abf1c901957886b61d59c72e05db077.NginxMailingListRussian@forum.nginx.org> References: <8abf1c901957886b61d59c72e05db077.NginxMailingListRussian@forum.nginx.org> Message-ID: <006d01ce418d$558bc2e0$00a348a0$@gmail.com> Создайте отдельный локейшн для robots для другого vhosta location = /robots.txt { root /usr/local/www/robots/ expires 1d; } -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of shambler81 Sent: Thursday, April 25, 2013 10:36 AM To: nginx-ru at nginx.org Subject: разные robots.txt для двух доменов Добрый день коллеги, достаточно простой вопрос.хоть на первый взгляд и немного странный. Требуется сослаться на одну и ту же папку с разных доменных имен. С разницей только в 1 файл который должен подменить nginx дабы у каждого домена свой robots.txt, все остальное по прежнему. (папка сайта обязательна таже, разница только конкретный файл) nginx version: nginx/0.7.67 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238630,238630#msg-238630 _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Thu Apr 25 08:51:17 2013 From: nginx-forum at nginx.us (shambler81) Date: Thu, 25 Apr 2013 04:51:17 -0400 Subject: =?UTF-8?B?UmU6IFJFOiDRgNCw0LfQvdGL0LUgcm9ib3RzLnR4dCDQtNC70Y8g0LTQstGD0YUg?= =?UTF-8?B?0LTQvtC80LXQvdC+0LI=?= In-Reply-To: <006d01ce418d$558bc2e0$00a348a0$@gmail.com> References: <006d01ce418d$558bc2e0$00a348a0$@gmail.com> Message-ID: <0da6e9706a026d04c1ab254d2bd6fff7.NginxMailingListRussian@forum.nginx.org> ну тут трудность все саты ходят через default конфиг + к этому конфигов штук по 5 на каждый сайт поскольку Диниска из 1с-битрикса раскидал в своей виртуальной машине все по разным файлам, конечно я могу указать server { и в нем создать даный локейшен но при этом собственно и весь сайт перестанет работать ;( а отдаваться будет толко файл. В идиале было бы проще сделать конструкцию из " если урл содержит site.ru/robots.txt то /var/www/robots/site.txt site2.ru/robots.txt то /var/www/robots/site2.txt и это запихнуть в стандартный конфиг Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238630,238634#msg-238634 From nginx-forum at nginx.us Thu Apr 25 08:55:19 2013 From: nginx-forum at nginx.us (shambler81) Date: Thu, 25 Apr 2013 04:55:19 -0400 Subject: =?UTF-8?B?UmU6IFJFOiDRgNCw0LfQvdGL0LUgcm9ib3RzLnR4dCDQtNC70Y8g0LTQstGD0YUg?= =?UTF-8?B?0LTQvtC80LXQvdC+0LI=?= In-Reply-To: <0da6e9706a026d04c1ab254d2bd6fff7.NginxMailingListRussian@forum.nginx.org> References: <006d01ce418d$558bc2e0$00a348a0$@gmail.com> <0da6e9706a026d04c1ab254d2bd6fff7.NginxMailingListRussian@forum.nginx.org> Message-ID: <7799680e9d1afb834c7f986eb2be7174.NginxMailingListRussian@forum.nginx.org> аналог вот этого RewriteCond %{HTTP_HOST} ^pumprobots.farrock.ru [NC] RewriteRule ^temp.php?$ /temp2.php [QSA,L] Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238630,238635#msg-238635 From nginx-forum at nginx.us Thu Apr 25 09:05:04 2013 From: nginx-forum at nginx.us (shambler81) Date: Thu, 25 Apr 2013 05:05:04 -0400 Subject: =?UTF-8?B?UmU6IFJFOiDRgNCw0LfQvdGL0LUgcm9ib3RzLnR4dCDQtNC70Y8g0LTQstGD0YUg?= =?UTF-8?B?0LTQvtC80LXQvdC+0LI=?= In-Reply-To: <7799680e9d1afb834c7f986eb2be7174.NginxMailingListRussian@forum.nginx.org> References: <006d01ce418d$558bc2e0$00a348a0$@gmail.com> <0da6e9706a026d04c1ab254d2bd6fff7.NginxMailingListRussian@forum.nginx.org> <7799680e9d1afb834c7f986eb2be7174.NginxMailingListRussian@forum.nginx.org> Message-ID: Все решено: сам ответил на свой вопрос ;) location / { if ($http_host ~* "^pumprobots.farrock.ru"){ rewrite ^/robots.txt?$ /robots.txt break; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238630,238636#msg-238636 From nginx-forum at nginx.us Thu Apr 25 14:16:32 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Thu, 25 Apr 2013 10:16:32 -0400 Subject: opendir cache failed Message-ID: <21e9806b9755a9243094577c8cbc3b12.NginxMailingListRussian@forum.nginx.org> FreeBSD 9.1, user www. nginx запускается, создает папку кеша, но не может с ней работать. Чего только не делал, даже с правами на директорию 777 получается только это. Вообще не понимаю, что происходит. 2013/04/25 18:10:39 [crit] 6382#0: opendir() "/var/cache/nginx/" failed (13: Permission denied) 2013/04/25 18:10:39 [notice] 6382#0: http file cache: /var/cache/nginx 0.000M, bsize: 4096 2013/04/25 18:10:39 [notice] 6372#0: signal 20 (SIGCHLD) received 2013/04/25 18:10:39 [notice] 6372#0: cache loader process 6382 exited with code 0 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238639,238639#msg-238639 From sytar.alex at gmail.com Thu Apr 25 14:19:53 2013 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Thu, 25 Apr 2013 18:19:53 +0400 Subject: opendir cache failed In-Reply-To: <21e9806b9755a9243094577c8cbc3b12.NginxMailingListRussian@forum.nginx.org> References: <21e9806b9755a9243094577c8cbc3b12.NginxMailingListRussian@forum.nginx.org> Message-ID: 25 апреля 2013 г., 18:16 пользователь Gaidamak написал: > FreeBSD 9.1, user www. > > nginx запускается, создает папку кеша, но не может с ней работать. Чего > только не делал, даже с правами на директорию 777 получается только это. > Вообще не понимаю, что происходит. > > 2013/04/25 18:10:39 [crit] 6382#0: opendir() "/var/cache/nginx/" failed > (13: > Permission denied) > Какие права на: - /var - /var/cache -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Apr 25 14:33:20 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Thu, 25 Apr 2013 10:33:20 -0400 Subject: opendir cache failed In-Reply-To: References: Message-ID: <218689e610d6108e2f5c3dd152b59705.NginxMailingListRussian@forum.nginx.org> cd / drwxr-xr-x 24 root wheel 512 Apr 25 22:23 var cd /var drwxr-x--- 3 root wheel 512 Apr 25 17:38 cache cd cache drwxr-xr-x 4 www wheel 512 Apr 25 18:29 nginx Причем конфиг перенесен с другого, вполне себе рабочего сервера. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238639,238641#msg-238641 From alex.barut at gmail.com Thu Apr 25 14:35:17 2013 From: alex.barut at gmail.com (Alex Belyansky) Date: Thu, 25 Apr 2013 18:35:17 +0400 Subject: opendir cache failed In-Reply-To: <218689e610d6108e2f5c3dd152b59705.NginxMailingListRussian@forum.nginx.org> References: <218689e610d6108e2f5c3dd152b59705.NginxMailingListRussian@forum.nginx.org> Message-ID: <51793F25.5090302@gmail.com> chmod o+x /var/cache On 25.04.2013 18:33, Gaidamak wrote: > cd / > drwxr-xr-x 24 root wheel 512 Apr 25 22:23 var > cd /var > drwxr-x--- 3 root wheel 512 Apr 25 17:38 cache > cd cache > drwxr-xr-x 4 www wheel 512 Apr 25 18:29 nginx > > > Причем конфиг перенесен с другого, вполне себе рабочего сервера. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238639,238641#msg-238641 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From dmitriy at lyalyuev.info Thu Apr 25 14:36:09 2013 From: dmitriy at lyalyuev.info (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JvRj9C70Y7QtdCy?=) Date: Thu, 25 Apr 2013 17:36:09 +0300 Subject: opendir cache failed In-Reply-To: <218689e610d6108e2f5c3dd152b59705.NginxMailingListRussian@forum.nginx.org> References: <218689e610d6108e2f5c3dd152b59705.NginxMailingListRussian@forum.nginx.org> Message-ID: Прав на запись для группы wheel нет, а Вы Nginx тираните. Не при чем он. Добавьте права для группы. 25 апреля 2013 г., 17:33 пользователь Gaidamak написал: > cd / > drwxr-xr-x 24 root wheel 512 Apr 25 22:23 var > cd /var > drwxr-x--- 3 root wheel 512 Apr 25 17:38 cache > cd cache > drwxr-xr-x 4 www wheel 512 Apr 25 18:29 nginx > > > Причем конфиг перенесен с другого, вполне себе рабочего сервера. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238639,238641#msg-238641 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Дмитрий Лялюев тел. +380 (66) 532-29-62 Все контакты для связи на http://lyalyuev.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Apr 25 15:05:30 2013 From: nginx-forum at nginx.us (X-Thief) Date: Thu, 25 Apr 2013 11:05:30 -0400 Subject: =?UTF-8?B?0J3QtSDQt9Cw0L/QuNGB0YvQstCw0LXRgtGB0Y8gYWNjZXNzIGxvZw==?= Message-ID: <8b060f1d891f32330bf90719644aba46.NginxMailingListRussian@forum.nginx.org> Пытаюсь сделать чтоб 444 http ошибки записывались в другой лог файл. Делал так: error_page 444 = @log444; location @log444 { access_log log444.txt; } Файл создался, но ничего в него не записывается. Ошибки по прежнему пишутся в прежний стандартный лог-файл. Чуть ниже у меня условия, где выдаются такие ошибки. Эти условия находятся как и в location { так и просто в server { Вроде этого: if ($something) { return 444; } Может кто что посоветовать? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238644,238644#msg-238644 From nginx-forum at nginx.us Thu Apr 25 15:13:07 2013 From: nginx-forum at nginx.us (X-Thief) Date: Thu, 25 Apr 2013 11:13:07 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0LfQsNC/0LjRgdGL0LLQsNC10YLRgdGPIGFjY2VzcyBsb2c=?= In-Reply-To: <8b060f1d891f32330bf90719644aba46.NginxMailingListRussian@forum.nginx.org> References: <8b060f1d891f32330bf90719644aba46.NginxMailingListRussian@forum.nginx.org> Message-ID: <106b63b305ac31d64d70cd76b4b2c154.NginxMailingListRussian@forum.nginx.org> Права на запись в файл есть. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238644,238645#msg-238645 From mdounin at mdounin.ru Thu Apr 25 16:07:40 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 25 Apr 2013 20:07:40 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0LfQsNC/0LjRgdGL0LLQsNC10YLRgdGPIGFjY2VzcyBsb2c=?= In-Reply-To: <8b060f1d891f32330bf90719644aba46.NginxMailingListRussian@forum.nginx.org> References: <8b060f1d891f32330bf90719644aba46.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130425160740.GE10443@mdounin.ru> Hello! On Thu, Apr 25, 2013 at 11:05:30AM -0400, X-Thief wrote: > Пытаюсь сделать чтоб 444 http ошибки записывались в другой лог файл. > > Делал так: > > error_page 444 = @log444; > location @log444 { > access_log log444.txt; > } > > Файл создался, но ничего в него не записывается. Ошибки по прежнему пишутся > в прежний стандартный лог-файл. > > Чуть ниже у меня условия, где выдаются такие ошибки. Эти условия находятся > как и в location { так и просто в server { > > Вроде этого: > if ($something) { > return 444; > } > > Может кто что посоветовать? > Спасибо. Возврат 444 ошибки - это способ сказать nginx'у, что соединение надо закрыть. До директивы error_page в этом случае дело не доходит. Если хочется, чтобы nginx закрыл соединение, и при этом отдельно залогировал соответствующий запрос - то можно сделать это, перейдя в нужный location перед возвратом 444, как-то так: error_page 418 = @close; if ($something) { return 418; } location @close { access_log /path/to/444.log; return 444; } -- Maxim Dounin http://nginx.org/en/donation.html From bener.beer at gmail.com Thu Apr 25 16:27:55 2013 From: bener.beer at gmail.com (Eric Benjamin) Date: Thu, 25 Apr 2013 20:27:55 +0400 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: References: <20130422201004.GO92338@mdounin.ru> Message-ID: 2 Andrey Feldman Файл проигрывается отлично. Вижу разницу только в версии ffmpeg, установленная версия у меня - 1.2. 2 Anatoly Mikhailov: Спасибо. Собирал все руками используя http://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide Очевидно, что проблема в работе с ffmpeg Спасибо за ответы буду разбираться. 23 апреля 2013 г., 12:18 пользователь Andrey Feldman написал: > Странно, при таких же параметрах ffmpeg у меня в stsc получилось: > stsc > size = 28 > type = stsc > entry_count = 1 > first_chunk = 1, samples_per_chunk = 1, > sample_description_index = 1 > > У тебя: > stsc > size = 40 > type = stsc > entry_count = 2 > first_chunk = 1, samples_per_chunk = 426, > sample_description_index = 1 > first_chunk = 2, samples_per_chunk = 183, > sample_description_index = 1 > > Попробуй файл в приложении. > ffmpeg -i lys-20031106.avi -s 480x270 -vcodec libx264 -crf 23 -r 25 -g 25 > -acodec libfaac -ar 44100 -b:a 64k -y test.mp4 > > ffmpeg -version > ffmpeg version 0.8.6-6:0.8.6-0ubuntu0.12.10.1, Copyright (c) 2000-2013 the > Libav developers > built on Apr 2 2013 17:02:16 with gcc 4.7.2 > *** THIS PROGRAM IS DEPRECATED *** > This program is only provided for compatibility and will be removed in a > future release. Please use avconv instead. > ffmpeg 0.8.6-6:0.8.6-0ubuntu0.12.10.1 > libavutil 51. 22. 1 / 51. 22. 1 > libavcodec 53. 35. 0 / 53. 35. 0 > libavformat 53. 21. 1 / 53. 21. 1 > libavdevice 53. 2. 0 / 53. 2. 0 > libavfilter 2. 15. 0 / 2. 15. 0 > libswscale 2. 1. 0 / 2. 1. 0 > libpostproc 52. 0. 0 / 52. 0. 0 > > > > > 2013/4/23 Eric Benjamin > >> Команда для ffmpeg для конвертации (как писал) >> # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec >> libfaac -ar 44100 -b:a 64k -y "" >> >> исходный файл: http://yadi.sk/d/xp1lY9Rg4Gj4V >> итоговый файл: в аттаче. >> >> >> >> >> 23 апреля 2013 г., 0:10 пользователь Maxim Dounin написал: >> >>> Hello! >>> >>> On Mon, Apr 22, 2013 at 01:37:22PM +0400, Eric Benjamin wrote: >>> >>> > Приветствую! >>> > >>> > Вопрос по модулю mp4. Пытаюсь разобраться. >>> > При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc >>> chunks" >>> > >>> > Время начала данной ошибки (при запросе ?start=XXX) разнится в >>> зависимости >>> > от >>> > параметров конвертации одного итого же файла. >>> > Но после возникновения, при увеличении значения секунд, остается. >>> > >>> > Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в >>> модуле >>> > mp4? >>> >>> Судя по debug log'у - сообщение вполне верное, и в stsc атоме - >>> некорректная информация: >>> >>> 2013/04/22 04:54:10 [debug] 11101#0: *1456 mp4 stsc atom update >>> 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:450, chunk:1, >>> chunks:1, samples:426, id:1 >>> 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:24, chunk:2, >>> chunks:0, samples:183 >>> 2013/04/22 04:54:10 [error] 11101#0: *1456 start time is out mp4 stsc >>> chunks in "/opt/site/htdocs/177.high.mp4", client: 127.0.0.1, server: >>> videofarm, request: "GET /177.high.mp4?start=18 HTTP/1.0", host: >>> "videofarmext" >>> >>> Во второй строке - интересна часть "chunks:0", т.е. в этой записи >>> таблицы sample-to-chunk вроде как вообще нет chunk'ом. Что >>> выглядит как откровенная неправда. >>> >>> Имеет смысл смотреть внимательно на mp4-файл и процесс его >>> создания. >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/en/donation.html >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > -- > Andrey Feldman > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Thu Apr 25 18:56:25 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 25 Apr 2013 19:56:25 +0100 Subject: =?UTF-8?B?UmU6INC80L7QtNGD0LvRjCBtcDQ6IHN0YXJ0IHRpbWUgaXMgb3V0IG1wNCBzdHNj?= =?UTF-8?B?IGNodW5rcw==?= In-Reply-To: References: <20130422201004.GO92338@mdounin.ru> Message-ID: On Apr 25, 2013, at 5:27 PM, Eric Benjamin wrote: > 2 Andrey Feldman > > Файл проигрывается отлично. > Вижу разницу только в версии ffmpeg, установленная версия у меня - 1.2. > > 2 Anatoly Mikhailov: > > Спасибо. Собирал все руками используя > http://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide > > Очевидно, что проблема в работе с ffmpeg > Спасибо за ответы буду разбираться. у вас libfaac, но мы решили использовать aacenc, причину сейчас не назову, можете попробовать-сравнить > > > > 23 апреля 2013 г., 12:18 пользователь Andrey Feldman написал: > Странно, при таких же параметрах ffmpeg у меня в stsc получилось: > stsc > size = 28 > type = stsc > entry_count = 1 > first_chunk = 1, samples_per_chunk = 1, sample_description_index = 1 > > У тебя: > stsc > size = 40 > type = stsc > entry_count = 2 > first_chunk = 1, samples_per_chunk = 426, sample_description_index = 1 > first_chunk = 2, samples_per_chunk = 183, sample_description_index = 1 > > Попробуй файл в приложении. > ffmpeg -i lys-20031106.avi -s 480x270 -vcodec libx264 -crf 23 -r 25 -g 25 -acodec libfaac -ar 44100 -b:a 64k -y test.mp4 > > ffmpeg -version > ffmpeg version 0.8.6-6:0.8.6-0ubuntu0.12.10.1, Copyright (c) 2000-2013 the Libav developers > built on Apr 2 2013 17:02:16 with gcc 4.7.2 > *** THIS PROGRAM IS DEPRECATED *** > This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. > ffmpeg 0.8.6-6:0.8.6-0ubuntu0.12.10.1 > libavutil 51. 22. 1 / 51. 22. 1 > libavcodec 53. 35. 0 / 53. 35. 0 > libavformat 53. 21. 1 / 53. 21. 1 > libavdevice 53. 2. 0 / 53. 2. 0 > libavfilter 2. 15. 0 / 2. 15. 0 > libswscale 2. 1. 0 / 2. 1. 0 > libpostproc 52. 0. 0 / 52. 0. 0 > > > > > 2013/4/23 Eric Benjamin > Команда для ffmpeg для конвертации (как писал) > # ffmpeg -i "" -s 480x270 -c:v libx264 -crf 23 -r 25 -g 25 -acodec libfaac -ar 44100 -b:a 64k -y "" > > исходный файл: http://yadi.sk/d/xp1lY9Rg4Gj4V > итоговый файл: в аттаче. > > > > > 23 апреля 2013 г., 0:10 пользователь Maxim Dounin написал: > Hello! > > On Mon, Apr 22, 2013 at 01:37:22PM +0400, Eric Benjamin wrote: > > > Приветствую! > > > > Вопрос по модулю mp4. Пытаюсь разобраться. > > При псевдо-стримменге возникает ошибка: "start time is out mp4 stsc chunks" > > > > Время начала данной ошибки (при запросе ?start=XXX) разнится в зависимости > > от > > параметров конвертации одного итого же файла. > > Но после возникновения, при увеличении значения секунд, остается. > > > > Непонятно куда "копать", в настройки ffmpeg или все-таки проблема в модуле > > mp4? > > Судя по debug log'у - сообщение вполне верное, и в stsc атоме - > некорректная информация: > > 2013/04/22 04:54:10 [debug] 11101#0: *1456 mp4 stsc atom update > 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:450, chunk:1, chunks:1, samples:426, id:1 > 2013/04/22 04:54:10 [debug] 11101#0: *1456 start_sample:24, chunk:2, chunks:0, samples:183 > 2013/04/22 04:54:10 [error] 11101#0: *1456 start time is out mp4 stsc chunks in "/opt/site/htdocs/177.high.mp4", client: 127.0.0.1, server: videofarm, request: "GET /177.high.mp4?start=18 HTTP/1.0", host: "videofarmext" > > Во второй строке - интересна часть "chunks:0", т.е. в этой записи > таблицы sample-to-chunk вроде как вообще нет chunk'ом. Что > выглядит как откровенная неправда. > > Имеет смысл смотреть внимательно на mp4-файл и процесс его > создания. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > -- > Andrey Feldman > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From universite at ukr.net Thu Apr 25 21:03:37 2013 From: universite at ukr.net (Vladislav Prodan) Date: Fri, 26 Apr 2013 00:03:37 +0300 Subject: =?UTF-8?B?0JrQsNC6INC+0L/QuNGB0LDRgtGMINGB0L7QsdGL0YLQuNC1INGBINC00LvRjyA=?= =?UTF-8?B?0LTQstGD0YUg0L7QtNC90L7QstGA0LXQvNC10L3QvdC+INCy0YvQv9C+0Ls=?= =?UTF-8?B?0Y/RjtGJ0LjRhdGB0Y8g0YPRgdC70L7QstC40Lk/?= Message-ID: <86099.1366923817.10687909452817956864@ffe8.ukr.net> Например: if ( $http_referer = (""|"-") ) { return 403; } if ( $http_user_agent = ("spybot"| "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)") ) { return 403; } Заранее благодарю. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From sargaskn at gmail.com Thu Apr 25 21:17:25 2013 From: sargaskn at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCb0YvRgdC10L3QutC+?=) Date: Fri, 26 Apr 2013 00:17:25 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtC/0LjRgdCw0YLRjCDRgdC+0LHRi9GC0LjQtSDRgSDQtNC7?= =?UTF-8?B?0Y8g0LTQstGD0YUg0L7QtNC90L7QstGA0LXQvNC10L3QvdC+INCy0YvQv9C+?= =?UTF-8?B?0LvRj9GO0YnQuNGF0YHRjyDRg9GB0LvQvtCy0LjQuT8=?= In-Reply-To: <86099.1366923817.10687909452817956864@ffe8.ukr.net> References: <86099.1366923817.10687909452817956864@ffe8.ukr.net> Message-ID: Приветствую. Как-то так if ( $http_referer = (""|"-") ) { set $lock1 1; } if ( $http_user_agent = ("spybot"| "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)") ) { set $lock2 1; } set $lock3 "$lock1$lock2"; if ( $lock3 = "11" ) { return 403; } 2013/4/26 Vladislav Prodan > > Например: > > if ( $http_referer = (""|"-") ) { return 403; } > if ( $http_user_agent = ("spybot"| "Mozilla/5.0 (compatible; > Googlebot/2.1; +http://www.google.com/bot.html)") ) { return 403; } > > > Заранее благодарю. > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim at nginx.com Fri Apr 26 08:31:54 2013 From: maxim at nginx.com (Maxim Konovalov) Date: Fri, 26 Apr 2013 12:31:54 +0400 Subject: recent nginx security issue announce In-Reply-To: <517A3AB9.70807@nginx.com> References: <517A3AB9.70807@nginx.com> Message-ID: <517A3B7A.3000102@nginx.com> Приветствую! По поводу вчерашнего сообщения о потенциальной уязвимости в nginx[*]: мы знаем об этом анонсе и работаем над анализом проблемы. Результаты этого анализа сообщим отдельно. * http://www.securityfocus.com/archive/1/526439/30/0/threaded -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/services.html From nginx-forum at nginx.us Fri Apr 26 11:58:56 2013 From: nginx-forum at nginx.us (Kubik129) Date: Fri, 26 Apr 2013 07:58:56 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC90LUg0L7QsdGA0LDQsdCw0YLRi9Cy0LDQtdGCINC/0L7QtNC0?= =?UTF-8?B?0L7QvNC10L0=?= In-Reply-To: <20130424145523.GO10443@mdounin.ru> References: <20130424145523.GO10443@mdounin.ru> Message-ID: <54946390a76086c64304cfb5bb0e2f39.NginxMailingListRussian@forum.nginx.org> Максим, спасибо за ответ. Вы оказались близки к правде. На самом деле имя subdomen2 было зарезервировано для дочернего неймсервера site.com и перенаправление происходило на уровне браузера, не доходя до собственно nginx'a. Так что мораль, проверяйте и еще раз проверяйте, даже если доверяете :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238601,238663#msg-238663 From nginx-forum at nginx.us Sat Apr 27 12:58:54 2013 From: nginx-forum at nginx.us (Sovigod) Date: Sat, 27 Apr 2013 08:58:54 -0400 Subject: =?UTF-8?B?0LLRgNC10LzQtdC90L3Ri9C1INGE0LDQudC70Ysg0L/QvtGB0LvQtSDRg9C00L4=?= =?UTF-8?B?0LvQtdC90LjRjyDQvdC1INC+0YHQstC+0LHQvtC20LTQsNGO0YIg0LzQtdGB?= =?UTF-8?B?0YLQvg==?= Message-ID: <54af4b9010b7c7cd9297d5dd29be4c2b.NginxMailingListRussian@forum.nginx.org> Используется >proxy_store on; >root /storage/store; >proxy_temp_path /storage/tmp1; /storage/tmp1 - это отдельная точка монтирования, знаю что при этом перенос занимает время, но это сделанно осознанно. Проблемма в том что со временем на этом винте копятся открытые файлы которые нджинкс уже использовал и перернес на другой раздел. Копится много( около 40-50 Гб в сутки). fstat показывает что там нджинкс что-то открыл на чтение и не закрыл. Сейчал лечится регулярными рестартами нджинкса. Если более правильно решение?? #fstat -f /storage/tmp1/ USER CMD PID FD MOUNT INUM MODE SZ|DV R/W www nginx 94555 36 - 3451216 -rw------- 206102172 r www nginx 94555 46 /storage/tmp1 3451095 -rw------- 509117897 r www nginx 94555 50 /storage/tmp1 3451356 -rw------- 181898742 r www nginx 94555 62 - 3451298 -rw------- 836798835 r #df -h Filesystem Size Used Avail Capacity Mounted on /dev/mfid0p2 535G 4.3G 488G 1% / devfs 1.0k 1.0k 0B 100% /dev /dev/mfid1p1 3.7T 2.2T 1.2T 66% /storage /dev/mfid2p1 176G 158G 3.8G 98% /storage/tmp1 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238679,238679#msg-238679 From nginx-forum at nginx.us Sun Apr 28 15:59:37 2013 From: nginx-forum at nginx.us (excentro) Date: Sun, 28 Apr 2013 11:59:37 -0400 Subject: =?UTF-8?B?0JHQu9C+0LrQuNGA0L7QstCw0YLRjCDQv9C+INC60YPQutC1?= Message-ID: Добрый день. Подскажите пож-ста как блокировать посетителя по куке? Если можно с примером конфига :) Заранее благодарю. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238687,238687#msg-238687 From nginx-forum at nginx.us Mon Apr 29 07:17:28 2013 From: nginx-forum at nginx.us (Sylvia) Date: Mon, 29 Apr 2013 03:17:28 -0400 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNGC0Ywg0L/QviDQutGD0LrQtQ==?= In-Reply-To: References: Message-ID: hi. if ($http_cookie ~* "cookie1_|cookie2" ) { блокируете ... } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238687,238697#msg-238697 From nginx-forum at nginx.us Mon Apr 29 07:23:27 2013 From: nginx-forum at nginx.us (excentro) Date: Mon, 29 Apr 2013 03:23:27 -0400 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNGC0Ywg0L/QviDQutGD0LrQtQ==?= In-Reply-To: References: Message-ID: <788ba12ffeb6c4c9b6f1f043addef964.NginxMailingListRussian@forum.nginx.org> Премного благодарен. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238687,238699#msg-238699 From self at alaz.me Mon Apr 29 10:53:19 2013 From: self at alaz.me (Azarov Alexander) Date: Mon, 29 Apr 2013 14:53:19 +0400 Subject: upstream keepalive + Host override : problem? Message-ID: Добрый день, Конфиг у меня выглядит вот так: upstream playapp { server ?:9000; keepalive 16; } server { listen ... ssl; server_name ?; proxy_set_header Host $server_name; location / { limit_conn byConn 14; limit_req zone=byReq burst=50; proxy_pass http://playapp; proxy_http_version 1.1; proxy_set_header Connection ""; } } Проблема: 2013/04/29 14:19:02 [debug] 21900#0: *1013606439 http proxy header: "GET /pic/2034583 HTTP/1.1 Host: playapp Cache-Control: max-age=0 Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 Т.е. на бэкенд уходит "Host: playapp" вместо "Host: $server_name". Если убрать proxy_http_version и proxy_set_header Connection, все нормализуется, бэкенд видит "Host: $server_name" # nginx -V nginx version: nginx/1.2.6 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/cache/nginx/body --http-fastcgi-temp-path=/var/cache/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/cache/nginx/proxy --http-scgi-temp-path=/var/cache/nginx/scgi --http-uwsgi-temp-path=/var/cache/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --add-module=/usr/src/nginx-1.2.6/debian/modules/nginx-echo --add-module=/usr/src/nginx-1.2.6/debian/modules/nginx-upstream-fair --add-module=/usr/src/nginx-1.2.6/debian/modules/nginx-cache-purge С уважением, Александр From mdounin at mdounin.ru Mon Apr 29 10:59:50 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 29 Apr 2013 14:59:50 +0400 Subject: upstream keepalive + Host override : problem? In-Reply-To: References: Message-ID: <20130429105950.GT10443@mdounin.ru> Hello! On Mon, Apr 29, 2013 at 02:53:19PM +0400, Azarov Alexander wrote: > Добрый день, > > Конфиг у меня выглядит вот так: > > upstream playapp { > server ?:9000; > keepalive 16; > } > > server { > listen ... ssl; > server_name ?; > > proxy_set_header Host $server_name; > > location / { > limit_conn byConn 14; > limit_req zone=byReq burst=50; > > proxy_pass http://playapp; > proxy_http_version 1.1; > proxy_set_header Connection ""; > } > } > > Проблема: > > 2013/04/29 14:19:02 [debug] 21900#0: *1013606439 http proxy header: > "GET /pic/2034583 HTTP/1.1 > Host: playapp > Cache-Control: max-age=0 > Pragma: no-cache > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 > > Т.е. на бэкенд уходит "Host: playapp" вместо "Host: > $server_name". Если убрать proxy_http_version и proxy_set_header > Connection, все нормализуется, бэкенд видит "Host: $server_name" http://nginx.org/r/proxy_set_header/ru: : Директивы наследуются с предыдущего уровня при условии, что на : данном уровне не описаны свои директивы proxy_set_header. Т.е. правильно будет написать так: server { ... proxy_set_header Host $server_name; location / { ... proxy_set_header Host $server_name; proxy_set_header Connection ""; } } или так: server { ... proxy_set_header Host $server_name; proxy_set_header Connection ""; location / { ... } } -- Maxim Dounin http://nginx.org/en/donation.html From self at alaz.me Mon Apr 29 11:04:49 2013 From: self at alaz.me (Azarov Alexander) Date: Mon, 29 Apr 2013 15:04:49 +0400 Subject: upstream keepalive + Host override : problem? In-Reply-To: <20130429105950.GT10443@mdounin.ru> References: <20130429105950.GT10443@mdounin.ru> Message-ID: On 29.04.2013, at 14:59, Maxim Dounin wrote: > Hello! > > On Mon, Apr 29, 2013 at 02:53:19PM +0400, Azarov Alexander wrote: > >> Добрый день, >> >> Конфиг у меня выглядит вот так: >> >> [?] >> >> Т.е. на бэкенд уходит "Host: playapp" вместо "Host: >> $server_name". Если убрать proxy_http_version и proxy_set_header >> Connection, все нормализуется, бэкенд видит "Host: $server_name" > > http://nginx.org/r/proxy_set_header/ru: > > : Директивы наследуются с предыдущего уровня при условии, что на > : данном уровне не описаны свои директивы proxy_set_header. О, да, я это держал в памяти, но вот сейчас, когда было нужно, оно выпало. Спасибо! > Т.е. правильно будет написать так: > > server { > ... > proxy_set_header Host $server_name; > > location / { > ... > proxy_set_header Host $server_name; > proxy_set_header Connection ""; > } > } > > или так: > > server { > ... > proxy_set_header Host $server_name; > proxy_set_header Connection ""; > > location / { > ... > } > } > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Mon Apr 29 12:32:08 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 29 Apr 2013 16:32:08 +0400 Subject: =?UTF-8?B?0L/RgNC+INGP0LrQvtCx0Ysg0YPRj9C30LLQuNC80L7RgdGC0Yw=?= Message-ID: <20130429123208.GW10443@mdounin.ru> Hello! Недавно в сети появилось сообщение о якобы имеющейся в nginx'е уязвимости, и утверждающее возможность удалённого выполнения произвольного кода. Мы таки тщательно изучили вопрос, и не подтверждаем наличия указанной уязвимости. Пользуясь случаем, хочу напомнить, что если вы считаете, что нашли уязвимость в nginx, - хорошей идеей будет сообщить подробности по адресу security-alert at nginx.org, как указано на странице "nginx security advisories" тут: http://nginx.org/en/security_advisories.html -- Maxim Dounin http://nginx.org/en/donation.html From alexey.bondar at gmail.com Mon Apr 29 13:14:02 2013 From: alexey.bondar at gmail.com (Bondar Alexey) Date: Mon, 29 Apr 2013 15:14:02 +0200 Subject: =?UTF-8?B?UmU6INC/0YDQviDRj9C60L7QsdGLINGD0Y/Qt9Cy0LjQvNC+0YHRgtGM?= In-Reply-To: <20130429123208.GW10443@mdounin.ru> References: <20130429123208.GW10443@mdounin.ru> Message-ID: Это про вот это? http://www.securityfocus.com/archive/1/526439/30/0/threaded On 29 Apr 2013, at 14:32, Maxim Dounin wrote: > Hello! > > Недавно в сети появилось сообщение о якобы имеющейся в nginx'е > уязвимости, и утверждающее возможность удалённого выполнения > произвольного кода. Мы таки тщательно изучили вопрос, и не > подтверждаем наличия указанной уязвимости. > > Пользуясь случаем, хочу напомнить, что если вы считаете, что нашли > уязвимость в nginx, - хорошей идеей будет сообщить подробности по > адресу security-alert at nginx.org, как указано на странице "nginx > security advisories" тут: > > http://nginx.org/en/security_advisories.html > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4151 bytes Desc: not available URL: From mdounin at mdounin.ru Mon Apr 29 13:40:39 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 29 Apr 2013 17:40:39 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQviDRj9C60L7QsdGLINGD0Y/Qt9Cy0LjQvNC+0YHRgtGM?= In-Reply-To: References: <20130429123208.GW10443@mdounin.ru> Message-ID: <20130429134039.GA10443@mdounin.ru> Hello! On Mon, Apr 29, 2013 at 03:14:02PM +0200, Bondar Alexey wrote: > Это про вот это? http://www.securityfocus.com/archive/1/526439/30/0/threaded Да. > > On 29 Apr 2013, at 14:32, Maxim Dounin wrote: > > > Hello! > > > > Недавно в сети появилось сообщение о якобы имеющейся в nginx'е > > уязвимости, и утверждающее возможность удалённого выполнения > > произвольного кода. Мы таки тщательно изучили вопрос, и не > > подтверждаем наличия указанной уязвимости. > > > > Пользуясь случаем, хочу напомнить, что если вы считаете, что нашли > > уязвимость в nginx, - хорошей идеей будет сообщить подробности по > > адресу security-alert at nginx.org, как указано на странице "nginx > > security advisories" тут: > > > > http://nginx.org/en/security_advisories.html > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon Apr 29 16:44:52 2013 From: nginx-forum at nginx.us (Rickey) Date: Mon, 29 Apr 2013 12:44:52 -0400 Subject: Online Jobs and Entertainment Message-ID: http://kholyar.blogspot.com/ Open It And Enjoy:) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238721,238721#msg-238721 From scroitor at gmail.com Mon Apr 29 22:06:47 2013 From: scroitor at gmail.com (Sergey Croitor) Date: Tue, 30 Apr 2013 01:06:47 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQviDRj9C60L7QsdGLINGD0Y/Qt9Cy0LjQvNC+0YHRgtGM?= In-Reply-To: <20130429134039.GA10443@mdounin.ru> References: <20130429123208.GW10443@mdounin.ru> <20130429134039.GA10443@mdounin.ru> Message-ID: А китайсы с вами поделились fully functional remote code execution exploit, который available through the safe3q? Или таят? 2013/4/29 Maxim Dounin > Hello! > > On Mon, Apr 29, 2013 at 03:14:02PM +0200, Bondar Alexey wrote: > > > Это про вот это? > http://www.securityfocus.com/archive/1/526439/30/0/threaded > > Да. > > > > > On 29 Apr 2013, at 14:32, Maxim Dounin wrote: > > > > > Hello! > > > > > > Недавно в сети появилось сообщение о якобы имеющейся в nginx'е > > > уязвимости, и утверждающее возможность удалённого выполнения > > > произвольного кода. Мы таки тщательно изучили вопрос, и не > > > подтверждаем наличия указанной уязвимости. > > > > > > Пользуясь случаем, хочу напомнить, что если вы считаете, что нашли > > > уязвимость в nginx, - хорошей идеей будет сообщить подробности по > > > адресу security-alert at nginx.org, как указано на странице "nginx > > > security advisories" тут: > > > > > > http://nginx.org/en/security_advisories.html > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/en/donation.html > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Apr 30 08:54:45 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 30 Apr 2013 12:54:45 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQviDRj9C60L7QsdGLINGD0Y/Qt9Cy0LjQvNC+0YHRgtGM?= In-Reply-To: References: <20130429123208.GW10443@mdounin.ru> <20130429134039.GA10443@mdounin.ru> Message-ID: <20130430085445.GG10443@mdounin.ru> Hello! On Tue, Apr 30, 2013 at 01:06:47AM +0300, Sergey Croitor wrote: > А китайсы с вами поделились fully functional remote code execution exploit, > который available through the safe3q? > Или таят? Не поделились. Судя по всему - оного эксплоита нет и никогда не было. > > > 2013/4/29 Maxim Dounin > > > Hello! > > > > On Mon, Apr 29, 2013 at 03:14:02PM +0200, Bondar Alexey wrote: > > > > > Это про вот это? > > http://www.securityfocus.com/archive/1/526439/30/0/threaded > > > > Да. > > > > > > > > On 29 Apr 2013, at 14:32, Maxim Dounin wrote: > > > > > > > Hello! > > > > > > > > Недавно в сети появилось сообщение о якобы имеющейся в nginx'е > > > > уязвимости, и утверждающее возможность удалённого выполнения > > > > произвольного кода. Мы таки тщательно изучили вопрос, и не > > > > подтверждаем наличия указанной уязвимости. > > > > > > > > Пользуясь случаем, хочу напомнить, что если вы считаете, что нашли > > > > уязвимость в nginx, - хорошей идеей будет сообщить подробности по > > > > адресу security-alert at nginx.org, как указано на странице "nginx > > > > security advisories" тут: > > > > > > > > http://nginx.org/en/security_advisories.html > > > > > > > > -- > > > > Maxim Dounin > > > > http://nginx.org/en/donation.html > > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Apr 30 09:43:39 2013 From: nginx-forum at nginx.us (sergowech) Date: Tue, 30 Apr 2013 05:43:39 -0400 Subject: woff mime type In-Reply-To: <20130214163218.GH40751@mdounin.ru> References: <20130214163218.GH40751@mdounin.ru> Message-ID: <25945c8acfca84e98239ae039521e733.NginxMailingListRussian@forum.nginx.org> Мне тоже такой mime тип нужен.... Сейчас браузеры ругаются - хром говорит: "Resource interpreted as Font but transferred with MIME type application/octet-stream: "http://mysite/data/fonts/tpl/Helios.woff". " Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236224,238734#msg-238734 From mva at mva.name Tue Apr 30 11:59:25 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 30 Apr 2013 18:59:25 +0700 Subject: =?UTF-8?B?UmU6INCd0LUg0LfQsNC/0LjRgdGL0LLQsNC10YLRgdGPIGFjY2VzcyBsb2c=?= In-Reply-To: <20130425160740.GE10443@mdounin.ru> References: <8b060f1d891f32330bf90719644aba46.NginxMailingListRussian@forum.nginx.org> <20130425160740.GE10443@mdounin.ru> Message-ID: <517FB21D.6060209@mva.name> У меня после обновления до 1.4.0 per-server'ные access_log'и не пишутся вообще ни в каком случае. Если указать в http{} ? все обращения на все хосты будут писаться туда. Если не указать ? в дефолтный nginx'овый. При этом указанные в server{} аццесс-логи ? игнорируются... 25.04.2013 23:07, Maxim Dounin пишет: > Hello! > > On Thu, Apr 25, 2013 at 11:05:30AM -0400, X-Thief wrote: > >> Пытаюсь сделать чтоб 444 http ошибки записывались в другой лог файл. >> >> Делал так: >> >> error_page 444 = @log444; >> location @log444 { >> access_log log444.txt; >> } >> >> Файл создался, но ничего в него не записывается. Ошибки по прежнему пишутся >> в прежний стандартный лог-файл. >> >> Чуть ниже у меня условия, где выдаются такие ошибки. Эти условия находятся >> как и в location { так и просто в server { >> >> Вроде этого: >> if ($something) { >> return 444; >> } >> >> Может кто что посоветовать? >> Спасибо. > > Возврат 444 ошибки - это способ сказать nginx'у, что соединение > надо закрыть. До директивы error_page в этом случае дело не > доходит. > > Если хочется, чтобы nginx закрыл соединение, и при этом отдельно > залогировал соответствующий запрос - то можно сделать это, перейдя > в нужный location перед возвратом 444, как-то так: > > error_page 418 = @close; > > if ($something) { > return 418; > } > > location @close { > access_log /path/to/444.log; > return 444; > } > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From mva at mva.name Tue Apr 30 12:01:30 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 30 Apr 2013 19:01:30 +0700 Subject: nginx-1.4.0 In-Reply-To: <20130424141957.GL10443@mdounin.ru> References: <20130424141957.GL10443@mdounin.ru> Message-ID: <517FB29A.6090205@mva.name> Появилась какая-то странная ошибка, из-за которой не работают индивидуальные access_log'и для каждого server{}. Всё пишется либо в тот, что указан в http{}, либо, если не указано ? в дефолтный NginX'овый... 24.04.2013 21:19, Maxim Dounin пишет: > Изменения в nginx 1.4.0 24.04.2013 > > *) Исправление: nginx не собирался с модулем ngx_http_perl_module, если > использовался параметр --with-openssl; ошибка появилась в 1.3.16. > > *) Исправление: в работе с телом запроса из модуля ngx_http_perl_module; > ошибка появилась в 1.3.9. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From chipitsine at gmail.com Tue Apr 30 12:31:33 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 30 Apr 2013 18:31:33 +0600 Subject: =?UTF-8?B?UmU6INC/0YDQviDRj9C60L7QsdGLINGD0Y/Qt9Cy0LjQvNC+0YHRgtGM?= In-Reply-To: <20130430085445.GG10443@mdounin.ru> References: <20130429123208.GW10443@mdounin.ru> <20130429134039.GA10443@mdounin.ru> <20130430085445.GG10443@mdounin.ru> Message-ID: open source сканер уязвимостей, который состоит из одного скриншота - тоже ведь их ? http://code.google.com/p/safe3si/ 30 апреля 2013 г., 14:54 пользователь Maxim Dounin написал: > Hello! > > On Tue, Apr 30, 2013 at 01:06:47AM +0300, Sergey Croitor wrote: > >> А китайсы с вами поделились fully functional remote code execution exploit, >> который available through the safe3q? >> Или таят? > > Не поделились. Судя по всему - оного эксплоита нет и никогда не > было. > >> >> >> 2013/4/29 Maxim Dounin >> >> > Hello! >> > >> > On Mon, Apr 29, 2013 at 03:14:02PM +0200, Bondar Alexey wrote: >> > >> > > Это про вот это? >> > http://www.securityfocus.com/archive/1/526439/30/0/threaded >> > >> > Да. >> > >> > > >> > > On 29 Apr 2013, at 14:32, Maxim Dounin wrote: >> > > >> > > > Hello! >> > > > >> > > > Недавно в сети появилось сообщение о якобы имеющейся в nginx'е >> > > > уязвимости, и утверждающее возможность удалённого выполнения >> > > > произвольного кода. Мы таки тщательно изучили вопрос, и не >> > > > подтверждаем наличия указанной уязвимости. >> > > > >> > > > Пользуясь случаем, хочу напомнить, что если вы считаете, что нашли >> > > > уязвимость в nginx, - хорошей идеей будет сообщить подробности по >> > > > адресу security-alert at nginx.org, как указано на странице "nginx >> > > > security advisories" тут: >> > > > >> > > > http://nginx.org/en/security_advisories.html >> > > > >> > > > -- >> > > > Maxim Dounin >> > > > http://nginx.org/en/donation.html >> > > > >> > > > _______________________________________________ >> > > > nginx-ru mailing list >> > > > nginx-ru at nginx.org >> > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > >> > >> > >> > >> > > _______________________________________________ >> > > nginx-ru mailing list >> > > nginx-ru at nginx.org >> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > >> > >> > -- >> > Maxim Dounin >> > http://nginx.org/en/donation.html >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mva at mva.name Tue Apr 30 12:32:55 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 30 Apr 2013 19:32:55 +0700 Subject: nginx-1.4.0 In-Reply-To: <517FB29A.6090205@mva.name> References: <20130424141957.GL10443@mdounin.ru> <517FB29A.6090205@mva.name> Message-ID: <517FB9F7.404@mva.name> Более точный юз-кейс: Не работает, как показало тестирование, access_log только в двух server{}, оба из которых используют root /path/to/site; index index.; #в этом месте подразумевается index.bash в одном и index.lua в другом и в конце блока: location = /index. { include backends.d/configs/paste; fastcgi_intercept_errors off; } В инклуде при этом (но дело не в нём, ибо с почти идентичным инклудом, отличающимся только на одну переменную, работают другие хосты): fastcgi_pass unix:/var/run/fcgi/wrap.sock; fastcgi_param NG_VERSION $nginx_version; fastcgi_param LANG ru_RU.UTF-8; fastcgi_param LC_ALL ru_RU.UTF-8; include fastcgi.conf; При всём этьом, если access_log указать внутри location ={}, то всё работает. Но странно, что не цепляется оный уровнем выше, в самом server{}. 30.04.2013 19:01, Vadim A. Misbakh-Soloviov пишет: > Появилась какая-то странная ошибка, из-за которой не работают > индивидуальные access_log'и для каждого server{}. Всё пишется либо в > тот, что указан в http{}, либо, если не указано ? в дефолтный NginX'овый... > > 24.04.2013 21:19, Maxim Dounin пишет: >> Изменения в nginx 1.4.0 24.04.2013 >> >> *) Исправление: nginx не собирался с модулем ngx_http_perl_module, если >> использовался параметр --with-openssl; ошибка появилась в 1.3.16. >> >> *) Исправление: в работе с телом запроса из модуля ngx_http_perl_module; >> ошибка появилась в 1.3.9. >> >> > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From mdounin at mdounin.ru Tue Apr 30 13:49:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 30 Apr 2013 17:49:59 +0400 Subject: nginx-1.4.0 In-Reply-To: <517FB9F7.404@mva.name> References: <20130424141957.GL10443@mdounin.ru> <517FB29A.6090205@mva.name> <517FB9F7.404@mva.name> Message-ID: <20130430134959.GP10443@mdounin.ru> Hello! On Tue, Apr 30, 2013 at 07:32:55PM +0700, Vadim A. Misbakh-Soloviov wrote: > Более точный юз-кейс: > > Не работает, как показало тестирование, access_log только в двух > server{}, оба из которых используют > root /path/to/site; > index index.; #в этом месте подразумевается index.bash в одном и > index.lua в другом Точка с запятой после директивы index - не забыта? Вообще в подобных ситуациях имеет смысл показывать конфиг полностью и как есть. > > и в конце блока: > location = /index. { > include backends.d/configs/paste; > fastcgi_intercept_errors off; > } > > В инклуде при этом (но дело не в нём, ибо с почти идентичным инклудом, > отличающимся только на одну переменную, работают другие хосты): > > fastcgi_pass unix:/var/run/fcgi/wrap.sock; > fastcgi_param NG_VERSION $nginx_version; > fastcgi_param LANG ru_RU.UTF-8; > fastcgi_param LC_ALL ru_RU.UTF-8; > include fastcgi.conf; > > > При всём этьом, если access_log указать внутри location ={}, то всё > работает. Но странно, что не цепляется оный уровнем выше, в самом server{}. > > > 30.04.2013 19:01, Vadim A. Misbakh-Soloviov пишет: > > Появилась какая-то странная ошибка, из-за которой не работают > > индивидуальные access_log'и для каждого server{}. Всё пишется либо в > > тот, что указан в http{}, либо, если не указано ? в дефолтный NginX'овый... > > > > 24.04.2013 21:19, Maxim Dounin пишет: > >> Изменения в nginx 1.4.0 24.04.2013 > >> > >> *) Исправление: nginx не собирался с модулем ngx_http_perl_module, если > >> использовался параметр --with-openssl; ошибка появилась в 1.3.16. > >> > >> *) Исправление: в работе с телом запроса из модуля ngx_http_perl_module; > >> ошибка появилась в 1.3.9. > >> > >> > > > > > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From mva at mva.name Tue Apr 30 17:16:06 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 01 May 2013 00:16:06 +0700 Subject: nginx-1.4.0 In-Reply-To: <20130430134959.GP10443@mdounin.ru> References: <20130424141957.GL10443@mdounin.ru> <517FB29A.6090205@mva.name> <517FB9F7.404@mva.name> <20130430134959.GP10443@mdounin.ru> Message-ID: <517FFC56.7000607@mva.name> > Точка с запятой после директивы index - не забыта? Воистину! :) // Было решено в IRC; отписался на случай "может поможет кому" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: