Re: upstart conf for managing nginx
Thanks for your reply.. and pointing out the typo. nginx doesnt comes up, and upstart command hangs, I have to kill it to come out of it. Changing path did not helped and neither does expect fork (but I do agree I need fork and not daemon) . It turned out that I named my conf file as nginx.conf, and it was causing the problem. I guess because it is also trying to start a binary with same name (but not sure). Changing the name of config file fixed the issue.. and I am able to use upstart conf to manage nginx. On Sat, Jul 25, 2015 at 12:00 AM, Francis Daly fran...@daoine.org wrote: On Fri, Jul 24, 2015 at 04:09:02PM -0700, vikrant singh wrote: Hi there, I wrote a small upstart script to stop/start nginx through upstart. This is how it looks I do not have an upstart system to test on, but: * comparing with http://wiki.nginx.org/Upstart, you have expect daemon and that has expect fork. * the binary you run is /usr/local/nginx/nginx; I think it is more common for it to be /usr/local/nginx/sbin/nginx. Does checking and changing either of those make a difference? Does hangs mean things run fine eventually, but there is a delay; or things never run correctly? (Is there anything in the nginx or upstart logs which might indicate the problem?) f -- Francis Dalyfran...@daoine.org ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Добавление заголовка после upstream
On Wed, Jul 29, 2015 at 05:56:40AM -0400, Budulianin wrote: Т.е. в блоке в котором выполняется proxy_pass на запрос повлиять можно, а в блоке upstream уже нет? Именно так. http://forum.nginx.org/read.php?21,260591,260611#msg-260611 Скажите, пожалуйста, а какое поведение ожидается от nginx в случае недоступности одной из нод? Должны ли запросы, ранее маршрутизируемые на нее, быть переданы другой ноде (на время или постоянно), либо допустимо ответить клиенту, что Сервис временно недоступен? -- Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 403 errors with standard browser, pages work with GUI browser
On Wed, Jul 29, 2015 at 05:00:40PM +0200, Thorsten Glaser wrote: Hi there, I’ve run across several websites where I get a 403 error when I connect to them with my standard webbrowser (lynx), yet the very same URIs work with the GUI browser fallback (Firef*x). All of these sites is common that they have an nginx error message, so this must be connected to your software somehow. That suggests that they run nginx as their web server. There is unlikely to be any other connection. To add insult to injury, this appears to be dependent on the User-Agent HTTP header: “Mozilla/5.0 (compatible)” works, “Lynx/2.8.9dev.6” works, “Lynx/2.8.9dev.6 libwww-FM/2.14” doesn’t, nor “Mozilla/5.0 (compatible) libwww-FM/2.14”. It appears that there is some blacklist on some component of my webbrowser. Please kindly remove it. I suspect that they have configured their instance of their web server to deny access to user agents which include the string libwww. I suspect that your best option for accessing the content is to change your web browser user agent string to omit libwww (and whatever other parts the server owner has chosen to block); at least until you contact the owner and convince them to change their configuration. Good luck with it, f -- Francis Dalyfran...@daoine.org ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
[PATCH] Add log variables $http_all and $sent_http_all
src/http/ngx_http_header_filter_module.c | 5 +
src/http/ngx_http_request.h | 2 +
src/http/ngx_http_variables.c| 92
3 files changed, 99 insertions(+), 0 deletions(-)
# HG changeset patch
# User Jonh Wendell jonh.wend...@gmail.com
# Date 1438199955 10800
# Wed Jul 29 16:59:15 2015 -0300
# Node ID 2412f965360cdbf9d15280e8ee9fa1a28a3c86ca
# Parent 341e4303d25be159d4773b819d0ec055ba711afb
Add log variables $http_all and $sent_http_all
These are meant to log the entire request and response
headers, respectively.
There are cases when we want to log the whole request (or response)
headers, for example, when we don't know in advance the
field the client sends. Currently we must know exactly the
header fields we want to log.
This patch adds these two variables that contains
$http_all: all request headers as received from client
$sent_http_all: all response headers as sent to the client
Closes #426.
diff -r 341e4303d25b -r 2412f965360c src/http/ngx_http_header_filter_module.c
--- a/src/http/ngx_http_header_filter_module.c Thu Jul 16 14:20:48 2015 +0300
+++ b/src/http/ngx_http_header_filter_module.c Wed Jul 29 16:59:15 2015 -0300
@@ -608,6 +608,11 @@
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, c-log, 0,
%*s, (size_t) (b-last - b-pos), b-pos);
+/* prepare the complete headers for eventual logging - strip out the last
\r\n */
+r-headers_out.final_response.len = b-last - b-pos - (sizeof(CRLF) - 1);
+r-headers_out.final_response.data = ngx_palloc(r-pool,
r-headers_out.final_response.len);
+ngx_memcpy(r-headers_out.final_response.data, b-pos,
r-headers_out.final_response.len);
+
/* the end of HTTP header */
*b-last++ = CR; *b-last++ = LF;
diff -r 341e4303d25b -r 2412f965360c src/http/ngx_http_request.h
--- a/src/http/ngx_http_request.h Thu Jul 16 14:20:48 2015 +0300
+++ b/src/http/ngx_http_request.h Wed Jul 29 16:59:15 2015 -0300
@@ -272,6 +272,8 @@
off_t content_length_n;
time_tdate_time;
time_tlast_modified_time;
+
+ngx_str_t final_response;
} ngx_http_headers_out_t;
diff -r 341e4303d25b -r 2412f965360c src/http/ngx_http_variables.c
--- a/src/http/ngx_http_variables.c Thu Jul 16 14:20:48 2015 +0300
+++ b/src/http/ngx_http_variables.c Wed Jul 29 16:59:15 2015 -0300
@@ -100,6 +100,10 @@
ngx_http_variable_value_t *v, uintptr_t data);
static ngx_int_t ngx_http_variable_status(ngx_http_request_t *r,
ngx_http_variable_value_t *v, uintptr_t data);
+static ngx_int_t ngx_http_variable_http_all(ngx_http_request_t *r,
+ngx_http_variable_value_t *v, uintptr_t data);
+static ngx_int_t ngx_http_variable_sent_http_all(ngx_http_request_t *r,
+ngx_http_variable_value_t *v, uintptr_t data);
static ngx_int_t ngx_http_variable_sent_content_type(ngx_http_request_t *r,
ngx_http_variable_value_t *v, uintptr_t data);
@@ -174,6 +178,9 @@
{ ngx_string(http_cookie), NULL, ngx_http_variable_cookies,
offsetof(ngx_http_request_t, headers_in.cookies), 0, 0 },
+{ ngx_string(http_all), NULL, ngx_http_variable_http_all, 0, 0, 0 },
+{ ngx_string(sent_http_all), NULL, ngx_http_variable_sent_http_all, 0,
0, 0 },
+
{ ngx_string(content_length), NULL, ngx_http_variable_content_length,
0, 0, 0 },
@@ -1712,6 +1719,91 @@
static ngx_int_t
+ngx_http_variable_sent_http_all(ngx_http_request_t *r,
+ngx_http_variable_value_t *v, uintptr_t data)
+{
+v-len = r-headers_out.final_response.len;
+v-data = r-headers_out.final_response.data;
+v-valid = 1;
+v-no_cacheable = 0;
+v-not_found = 0;
+
+return NGX_OK;
+}
+
+
+static ngx_int_t
+ngx_http_variable_http_all(ngx_http_request_t *r,
+ngx_http_variable_value_t *v, uintptr_t data)
+{
+ngx_uint_ti;
+ngx_list_part_t *part;
+ngx_table_elt_t *header;
+u_char *buf;
+
+v-len = 0;
+
+part = r-headers_in.headers.part;
+header = part-elts;
+for (i = 0; /* void */ ; i++) {
+
+if (i = part-nelts) {
+if (part-next == NULL) {
+break;
+}
+
+part = part-next;
+header = part-elts;
+i = 0;
+}
+
+if (header[i].hash == 0) {
+continue;
+}
+
+v-len += header[i].key.len + header[i].value.len + sizeof(: \r\n) -
1;
+}
+
+buf = ngx_pnalloc(r-pool, v-len);
+if (buf == NULL) {
+return NGX_ERROR;
+}
+v-data = buf;
+
+part = r-headers_in.headers.part;
+header = part-elts;
+for (i = 0; /* void */ ; i++) {
+
+if (i = part-nelts) {
+if (part-next == NULL) {
+break;
+}
+
+part = part-next;
+header = part-elts;
+i = 0;
+}
+
+if (header[i].hash == 0) {
+
[PATCH] Workaround for configuration file test failed under OpenVZ
# HG changeset patch
# User Gena Makhomed g...@csdoc.com
# Date 1437674403 14400
# Thu Jul 23 14:00:03 2015 -0400
# Node ID 57ac65580b5bba0cb4bb61dca9d63daec0ceb14c
# Parent 341e4303d25be159d4773b819d0ec055ba711afb
Workaround for configuration file test failed under OpenVZ.
nginx configuration test failed:
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] listen() to 0.0.0.0:80, backlog 511 failed (98: Address
already in use)
nginx: configuration file /etc/nginx/nginx.conf test failed
...if nginx used under OpenVZ and container with nginx was suspended and
resumed.
After this patch - nginx configuration test works fine under same
environment:
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
PS More details about OpenVZ suspend/resume bug:
https://bugzilla.openvz.org/show_bug.cgi?id=2470
diff -r 341e4303d25b -r 57ac65580b5b src/core/ngx_connection.c
--- a/src/core/ngx_connection.c Thu Jul 16 14:20:48 2015 +0300
+++ b/src/core/ngx_connection.c Thu Jul 23 14:00:03 2015 -0400
@@ -567,9 +567,13 @@
#endif
if (listen(s, ls[i].backlog) == -1) {
-ngx_log_error(NGX_LOG_EMERG, log, ngx_socket_errno,
- listen() to %V, backlog %d failed,
- ls[i].addr_text, ls[i].backlog);
+err = ngx_socket_errno;
+
+if (err != NGX_EADDRINUSE || !ngx_test_config) {
+ngx_log_error(NGX_LOG_EMERG, log, err,
+ listen() to %V, backlog %d failed,
+ ls[i].addr_text, ls[i].backlog);
+}
if (ngx_close_socket(s) == -1) {
ngx_log_error(NGX_LOG_EMERG, log, ngx_socket_errno,
@@ -577,7 +581,15 @@
ls[i].addr_text);
}
-return NGX_ERROR;
+if (err != NGX_EADDRINUSE) {
+return NGX_ERROR;
+}
+
+if (!ngx_test_config) {
+failed = 1;
+}
+
+continue;
}
ls[i].listen = 1;
# HG changeset patch
# User Gena Makhomed g...@csdoc.com
# Date 1437674403 14400
# Thu Jul 23 14:00:03 2015 -0400
# Node ID 57ac65580b5bba0cb4bb61dca9d63daec0ceb14c
# Parent 341e4303d25be159d4773b819d0ec055ba711afb
Workaround for configuration file test failed under OpenVZ.
nginx configuration test failed:
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] listen() to 0.0.0.0:80, backlog 511 failed (98: Address already
in use)
nginx: configuration file /etc/nginx/nginx.conf test failed
...if nginx used under OpenVZ and container with nginx was suspended and
resumed.
After this patch - nginx configuration test works fine under same environment:
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
PS More details about OpenVZ suspend/resume bug:
https://bugzilla.openvz.org/show_bug.cgi?id=2470
diff -r 341e4303d25b -r 57ac65580b5b src/core/ngx_connection.c
--- a/src/core/ngx_connection.c Thu Jul 16 14:20:48 2015 +0300
+++ b/src/core/ngx_connection.c Thu Jul 23 14:00:03 2015 -0400
@@ -567,9 +567,13 @@
#endif
if (listen(s, ls[i].backlog) == -1) {
-ngx_log_error(NGX_LOG_EMERG, log, ngx_socket_errno,
- listen() to %V, backlog %d failed,
- ls[i].addr_text, ls[i].backlog);
+err = ngx_socket_errno;
+
+if (err != NGX_EADDRINUSE || !ngx_test_config) {
+ngx_log_error(NGX_LOG_EMERG, log, err,
+ listen() to %V, backlog %d failed,
+ ls[i].addr_text, ls[i].backlog);
+}
if (ngx_close_socket(s) == -1) {
ngx_log_error(NGX_LOG_EMERG, log, ngx_socket_errno,
@@ -577,7 +581,15 @@
ls[i].addr_text);
}
-return NGX_ERROR;
+if (err != NGX_EADDRINUSE) {
+return NGX_ERROR;
+}
+
+if (!ngx_test_config) {
+failed = 1;
+}
+
+continue;
}
ls[i].listen = 1;
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: nginx без причины перестал запускаться
А зачем, будучи рутом, запускать команду с помощью sudo? Судя по всему ваш init-скрипт пытается найти pid файл и не находит его, поэтому директива stop/restart и не работает. Права на папку c pid, ну или самой папки нет, проверьте. 29 июля 2015 г., 23:48 пользователь Alexey Malov scukon...@gmail.com написал: 29 июля 2015 г., 14:56 пользователь tfox nginx-fo...@nginx.us написал: Всем привет. Вот такая ситуация. root@maxserver:/# sudo service nginx start root@maxserver:/# sudo service nginx stop root@maxserver:/# sudo service nginx restart * Restarting nginx nginx [fail] root@maxserver:/# Получается говоришь nginx старт он молчит. Говоришь стоп он тоже молчит. Говоришь рестарт он отвечает fail root@maxserver:/# sudo service nginx status * nginx is not running root@maxserver:/# grep -h '[n]ginx' (ps aux) (service --status-all 21) www-data 11700 0.0 0.3 3465836 31896 ? SJul28 0:14 nginx: worker process www-data 11701 0.0 0.4 3465836 32364 ? SJul28 0:13 nginx: worker process www-data 11702 0.0 0.3 3465836 31940 ? SJul28 0:14 nginx: worker process www-data 11703 0.0 0.3 3465836 31916 ? SJul28 0:15 nginx: worker process www-data 11704 0.0 0.3 3465836 25504 ? SJul28 0:00 nginx: cache manager process [ - ] nginx root@maxserver:/# Насколько я понимаю. Первая команда сообщает, что nginx не запущен. Но сайты при этом работают. Вторая команда сообщает, что какие то процессы nginx работают. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260631,260631#msg-260631 Попробуйте: sudo killall -9 nginx sudo service nginx start ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx без причины перестал запускаться
29 июля 2015 г., 14:56 пользователь tfox nginx-fo...@nginx.us написал: Всем привет. Вот такая ситуация. root@maxserver:/# sudo service nginx start root@maxserver:/# sudo service nginx stop root@maxserver:/# sudo service nginx restart * Restarting nginx nginx [fail] root@maxserver:/# Получается говоришь nginx старт он молчит. Говоришь стоп он тоже молчит. Говоришь рестарт он отвечает fail root@maxserver:/# sudo service nginx status * nginx is not running root@maxserver:/# grep -h '[n]ginx' (ps aux) (service --status-all 21) www-data 11700 0.0 0.3 3465836 31896 ? SJul28 0:14 nginx: worker process www-data 11701 0.0 0.4 3465836 32364 ? SJul28 0:13 nginx: worker process www-data 11702 0.0 0.3 3465836 31940 ? SJul28 0:14 nginx: worker process www-data 11703 0.0 0.3 3465836 31916 ? SJul28 0:15 nginx: worker process www-data 11704 0.0 0.3 3465836 25504 ? SJul28 0:00 nginx: cache manager process [ - ] nginx root@maxserver:/# Насколько я понимаю. Первая команда сообщает, что nginx не запущен. Но сайты при этом работают. Вторая команда сообщает, что какие то процессы nginx работают. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260631,260631#msg-260631 Попробуйте: sudo killall -9 nginx sudo service nginx start ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Tweak fastcgi_buffer
Hello! On Wed, Jul 29, 2015 at 04:45:31PM -0400, Karl Johnson wrote: On Thu, Jul 23, 2015 at 3:21 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Wed, Jul 22, 2015 at 05:50:12PM -0400, Karl Johnson wrote: Hello, I need to tweak fastcgi_buffer to 1m on a website that has heavy requests to avoid buffer. If I use a distro with 4096 pagesize, is it better to do 256x 4k or 4x 256k? [root@web ~]# getconf PAGESIZE 4096 [root@web ~]# fastcgi_buffer_size 4k; fastcgi_buffers 256 4k; OR fastcgi_buffer_size 256k; fastcgi_buffers 4 256k; I would recommend the latter. Or, alternatively, something like fastcgi_buffers 8 128k; Too many small buffers will result in extra processing overhead, and it's unlikely to be a good solution. Thanks for the recommendation Maxim. There's no issue setting the buffer to 128k when the pagesize is 4k? No issues, though large buffers imply some memory waste when last buffer isn't fully used. So usually you should consider some balance between number of buffers and their size. -- Maxim Dounin http://nginx.org/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Tweak fastcgi_buffer
On Thu, Jul 23, 2015 at 3:21 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Wed, Jul 22, 2015 at 05:50:12PM -0400, Karl Johnson wrote: Hello, I need to tweak fastcgi_buffer to 1m on a website that has heavy requests to avoid buffer. If I use a distro with 4096 pagesize, is it better to do 256x 4k or 4x 256k? [root@web ~]# getconf PAGESIZE 4096 [root@web ~]# fastcgi_buffer_size 4k; fastcgi_buffers 256 4k; OR fastcgi_buffer_size 256k; fastcgi_buffers 4 256k; I would recommend the latter. Or, alternatively, something like fastcgi_buffers 8 128k; Too many small buffers will result in extra processing overhead, and it's unlikely to be a good solution. Thanks for the recommendation Maxim. There's no issue setting the buffer to 128k when the pagesize is 4k? Karl ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Default access_log buffering
Hello! On Wed, Jul 29, 2015 at 02:55:54PM -0400, doolli_doug wrote: I was reading an article on performance on the Nginx site: https://www.nginx.com/blog/tuning-nginx/ One thing mentioned was enabling buffering on the access_log. However, the directive reference (http://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) says that the default buffer size is 64 KB. Does this mean that buffering is enabled by default, with a size of 64 KB, or that if the buffer is enabled without a specified size, it will be 64 KB? The default buffer size the documentation talks about is one used if you enable the gzip parameter, but don't specify buffer size explicitly. -- Maxim Dounin http://nginx.org/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
nginx без причины перестал запускаться
Всем привет. Вот такая ситуация. root@maxserver:/# sudo service nginx start root@maxserver:/# sudo service nginx stop root@maxserver:/# sudo service nginx restart * Restarting nginx nginx [fail] root@maxserver:/# Получается говоришь nginx старт он молчит. Говоришь стоп он тоже молчит. Говоришь рестарт он отвечает fail root@maxserver:/# sudo service nginx status * nginx is not running root@maxserver:/# grep -h '[n]ginx' (ps aux) (service --status-all 21) www-data 11700 0.0 0.3 3465836 31896 ? SJul28 0:14 nginx: worker process www-data 11701 0.0 0.4 3465836 32364 ? SJul28 0:13 nginx: worker process www-data 11702 0.0 0.3 3465836 31940 ? SJul28 0:14 nginx: worker process www-data 11703 0.0 0.3 3465836 31916 ? SJul28 0:15 nginx: worker process www-data 11704 0.0 0.3 3465836 25504 ? SJul28 0:00 nginx: cache manager process [ - ] nginx root@maxserver:/# Насколько я понимаю. Первая команда сообщает, что nginx не запущен. Но сайты при этом работают. Вторая команда сообщает, что какие то процессы nginx работают. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260631,260631#msg-260631 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
Скажите, пожалуйста, а какое поведение ожидается от nginx в случае недоступности одной из нод? Должны ли запросы, ранее маршрутизируемые на нее, быть переданы другой ноде (на время или постоянно), либо допустимо ответить клиенту, что Сервис временно недоступен? Отвечать нужно всегда, это одна из целей, которую мы преследуем при наращивании нод. Я озвучил плохое решение, когда сказал про жёсткую привязку пользователя к конкретной ноде. Сейчас решил просто сохранять имя хоста(где произошло соединение) в БД, и когда нужен конкретный пользователь, доставать имя хоста и идти именно туда, за конкретным пользователем. Только вот это будет напрямую к ноде, а хотелось бы через Nginx сначала. Как мне в таком случае лучше передать в запросе для Nginx имя хоста, на который он должен перенаправить запрос? в заголовке? В таком случае, если мы будем обращаться к конкретной ноде, а она не отвечает, то соединение ноды с клиентом(websocket) будет оборвано, и клиент подцепится к другой ноде, а мы просто повторим запрос уже по новому адресу. По моему неплохое решение, вот только хотелось бы через Nginx ходить к ноде. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260596,260628#msg-260628 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Default access_log buffering
I was reading an article on performance on the Nginx site: https://www.nginx.com/blog/tuning-nginx/ One thing mentioned was enabling buffering on the access_log. However, the directive reference (http://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) says that the default buffer size is 64 KB. Does this mean that buffering is enabled by default, with a size of 64 KB, or that if the buffer is enabled without a specified size, it will be 64 KB? Posted at Nginx Forum: http://forum.nginx.org/read.php?2,260630,260630#msg-260630 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re:Re: [RFC] event/openssl: Add dynamic record size support for serving ssl trafic
Hi wmark I have read your post in nginx forum, I think the getsockopt(2) call at connection init process will cause cpu spike if for example 100K clients try to connect to the server at the same time. But what you will get from the mss return from the kernel are exactly the same 99.9 percent of th e time. I have already take that into account when I design that patch, so I make it hard-coded. And BTW what did you mean by sending two result s in better catching parts? Regard YM At 2015-06-03 02:14:45, W-Mark Kubacki wmark+ng...@hurrikane.de wrote: 2015-06-02 3:04 GMT+02:00 SplitIce mat...@gmail.com: From memory SSL_CIPHER_is_AES is a BoringSSL addition isnt it? I did a quick look over the OpenSSL source and it does not seem like its been added either. I havent had a chance to compile this yet to confirm it, but if correct then this is not compatible with OpenSSL and possibly other SSL libraries. My bad. It's a draft and, as you've found out, can be trivially fixed. https://github.com/openssl/openssl/blob/c3d734701cd57575856bf9b542446811518dd28c/ssl/ssl_ciph.c#L596-L615 https://boringssl.googlesource.com/boringssl/+/4d4bff89bb8ec345d289412f0f7f135c6e51b1a6%5E!/ -- Mark ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Маршрутизация запросов
29 июля 2015 г., 0:43 пользователь Budulianin nginx-fo...@nginx.us написал: Но hash же не гарантирует равномерного распределения запросов по бэкендам, он как раз гарантирует, что запросы с одинаковым id будут идти на одну и ту же ноду. А где-то описывается алгоритм работы hash? Вообще вот тут вот:-) http://hg.nginx.org/nginx/file/341e4303d25b/src/http/modules/ngx_http_upstream_hash_module.c Чтобы можно было понять наверняка, всегда ли с одним id на одну и туже ноду или нет. Можно в debug-логах посмотреть, какой хеш получается у какого клиента и у какого id, и посмотреть на какую ноду он уходит. Я конечно проверю, но ещё хотелось бы что-то в документации прочитать по этому поводу. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260591,260602#msg-260602 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Маршрутизация запросов
Большое спасибо за развёрнутый ответ.
Hash (как и другие алгоритмы баллансировки) учитывает состояние апстрима.
И если апстрим не доступен, то для маршрутизации запроса будет выбран один
из оставшихся.
Я хочу задать жёсткую маршрутизацию для каждого пользователя(по сути сама
балансировка мне тут не нужна
просто я пытался через неё задать жёсткий маршрут), для организации
websocket.
Дело в том, что планируется несколько instance приложения, с которым
соединяется клиент.
И чтобы общаться с пользователем, нужно знать, с каким именно instance он
установил соединение, чтобы работать именно с ним.
Поэтому мне каким-то образом нужно либо жёстко задать маршрут для каждого
пользователя либо отслеживать путь по которому
прошёл запрос пользователя(желательна такая схема(на будущее), req - Nginx
- {node1, node2, ...},
но пока планирую сделать напрямую req - {node1, node2, ...} таким образом,
мне нужно будет только запомнить адрес конкретной ноды(простой вариант)
Но хотелось бы req - Nginx - {node1, node2, ...}. Для этого мне нужно
делать запрос на Nginx и он каким-то образом должен отправлять этот запрос
в нужную ноду. Может передавать в адрес ноды в заголовке или параметре и
Nginx будет его использовать для правильного перенаправления?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,260591,260611#msg-260611
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
Привет.
On Wed, Jul 29, 2015 at 01:34:59AM -0400, Budulianin wrote:
В ответ клиенту добавить?
Добавить в запрос, который перенаправится какой-то ноде, после того, как она
будет выбрана в upstream.
Т.е. upstream уже выбран, мы его только теперь знаем(адрес ноды) и тогда мы
добавляем его в header и он отправляется в ноду.
Запрос для передачи на апстрим формируется один раз и после этого не
меняется. И в этом неизменном виде передается на выбранный апстрим. Если
выбранный не отвечает, тот же самый запрос, сформированный ранее, может
передаваться на другой апстрим (в зависимости от настроек
proxy_next_upstream). Таким образом, эта переменная может содержать не
только IP адрес, но и список IP адресов всех потыканных серверов.
Вообще, использование upstream предполагает и требует использование
идентично настроенных бэкэндов. Если они у вас различаются, то надо
разносить их по разным группам и проксировать на разные группы в разных
локейшенах.
Есть несолько решений, которые позволяют добиться желаемого.
1. Для каждого бэкэнда определить отдельный виртуальный сервер и повесить
его на какой-нибудь 127.0.0.1:9995 и т.д. В нем можно указать желаемые
заголовки, специфичные для данного сервера. И в upstream определять не сами
бэкэнды, а эти виртуальные сервера. (Но не забудьте сохранить все кастомные
заголовки)
2. Отказываться от алгоритмов баллансировки nginx и мутить свой лунапарк,
например, через map задавать используемый апстрим для группы ипользуемых
key. Все key перечислять не надо, можно воспоользоваться регулярными
выражениями. И после этого в proxy_pass указывать значение полученное в
map. В этом случае на бэкэнды будет прилеть хидер Host, в котором будет
указан желаемый IP адрес.
Но, увы, это полностью убьет все плюшки upstream (такие как, next_upstream,
weight и т.д)
Но зачем все это?
Если ставить proxy_set_header рядом с proxy_pass, то заголовок не
добавляется, я так понимаю, что переменная ещё пустая, поэтому
заголовок не ставится. Но где уже известна эта переменная? Только в блоке
upstream? Но там нельзя устанавливать заголовок.
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream tornado {
hash $arg_key;
server 127.0.0.1:9995;
server 127.0.0.1:9996;
server 127.0.0.1:9997;
server 127.0.0.1:9998;
server 127.0.0.1:;
}
server {
listen 8080 default_server;
access_log /var/log/nginx/prototypes-nginx-access.log;
error_log /var/log/nginx/prototypes-nginx-error.log;
location /ws/ {
proxy_pass http://tornado;
proxy_set_header Test-Header1 123;
proxy_set_header Test-Header2 $upstream_addr;
proxy_set_header Test-Header3 $host;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
--
Ekaterina Kukushkina
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
29 июля 2015 г., 0:34 пользователь Budulianin nginx-fo...@nginx.us
написал:
В ответ клиенту добавить?
Добавить в запрос, который перенаправится какой-то ноде, после того, как
она
будет выбрана в upstream.
Т.е. upstream уже выбран, мы его только теперь знаем(адрес ноды) и тогда мы
добавляем его в header и он отправляется в ноду.
Если ставить proxy_set_header рядом с proxy_pass, то заголовок не
добавляется, я так понимаю, что переменная ещё пустая, поэтому
заголовок не ставится. Но где уже известна эта переменная? Только в блоке
upstream? Но там нельзя устанавливать заголовок.
Она известна уже после получения конечного ответа от бэкендов.
А разве ноды бэкенда сами свои адреса не знают? Зачем им этот заголовок
посылать?
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream tornado {
hash $arg_key;
server 127.0.0.1:9995;
server 127.0.0.1:9996;
server 127.0.0.1:9997;
server 127.0.0.1:9998;
server 127.0.0.1:;
}
server {
listen 8080 default_server;
access_log /var/log/nginx/prototypes-nginx-access.log;
error_log /var/log/nginx/prototypes-nginx-error.log;
location /ws/ {
proxy_pass http://tornado;
proxy_set_header Test-Header1 123;
proxy_set_header Test-Header2 $upstream_addr;
proxy_set_header Test-Header3 $host;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,260596,260601#msg-260601
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Маршрутизация запросов
Привет. On Wed, Jul 29, 2015 at 01:43:11AM -0400, Budulianin wrote: Но hash же не гарантирует равномерного распределения запросов по бэкендам, он как раз гарантирует, что запросы с одинаковым id будут идти на одну и ту же ноду. А где-то описывается алгоритм работы hash? Чтобы можно было понять наверняка, всегда ли с одним id на одну и туже ноду или нет. Я конечно проверю, но ещё хотелось бы что-то в документации прочитать по этому поводу. Hash (как и другие алгоритмы баллансировки) учитывает состояние апстрима. И если апстрим не доступен, то для маршрутизации запроса будет выбран один из оставшихся. Недоступным апстрим может считаться по нескольким причинам: не ответил в течение заданного таймаута, ответил, но nginx оценил его ответ как невалидный. Это конфигурируется с помощью директивы proxy_next_upstream. Также обратите внимание на директиву max_fails. Хоть она и не фигурирует в вашей конструкции, но тем не менее присутствует в виде 'max_fails=1'. При каждом неуспешном ответе (или неответе в установленное время) nginx будет помечать указанный сервер как недоступный (на 10 секунд по умолчанию). И в этом случае nginx заново выберет актуальный апстрим для указанного хэша и будет использовать его до тех пор пока он жив. Для того чтобы это подтвердить, рекомендую посмотреть error_log на предмет таймаутов от апстрима (они видны на уровне error). Также можно в access_log добавить пременные $upstream_status и $upstream_addr. В этом случае в access_log'е будут видны переходы с следующему апстриму. -- Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx и сетевые папки
1, Сетевой диск доступен до запуска Nginx в проводнике Windows как
\\192.168.xxx.xx\video_serial\video\sf
2. Конфиг:
location /video/sf/ {
root //192.168.xxx.xx/video_serial/video/sf/;
index index.html index.htm;
3. На удаленную папку video_serial (подпапки video и sf) установлен Полный
доступ для Все.
(по рекомендации itpp2012 на удаленном ПК завел пользователя user1 с паролем
pass1 и дал ему Полный доступ к этой папке)
4. Аудит включил для Все и для user1 (тишина)
При попытке открыть http://www.site.com/video/sf/ получаю ошибку 403
Forbidden
лог:
2015/07/29 14:36:46 [error] 2904#7608: *9
//192.168.xxx.xx/video_serial/video/sf/video/sf/index.html is forbidden
(5: Access is denied), client: xxx.xxx.xxx.xxx, server: localhost, request:
GET /video/sf/ HTTP/1.1, host: www.site.com
в логе почему-то 2 раза идет /video/sf
(//192.168.xxx.xx/video_serial/video/sf/video/sf/index.html)
Что не так? Благодарен за ответы.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,257586,260616#msg-260616
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
Спасибо за объяснение. Запрос для передачи на апстрим формируется один раз и после этого не меняется. Т.е. в блоке в котором выполняется proxy_pass на запрос повлиять можно, а в блоке upstream уже нет? Вообще, использование upstream предполагает и требует использование идентично настроенных бэкэндов. Они идентично настроены, это экземпляры одного приложения, разнесены в целях масштабируемости. Но зачем все это? http://forum.nginx.org/read.php?21,260591,260611#msg-260611 Может знаете какие-то книги/форумы/статьи на тему маршрутизации и правильных подходов/принципов? Интересно почитать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260596,260613#msg-260613 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
mp4 streaming/seeking works from firefox (fedora) and not from firefox (windows) (nginx 1.9.3)
greetings! i am seeing an unexplained malfunction here with nginx when serving videos. flv and mp4 files have different symptoms. mp4 streams correctly when i view the file in firefox 39 in fedora 22, but in windows 7 (firefox 39) the file cannot be 'seeked' and must be played linearly. after speaking with the coders of video.js (the player i use), it was determined that nginx is not returning byte range data appropriately (or at all) - so seeking would not work. however, this does not explain why firefox 39 in fedora works perfectly and does not provide a solution as to how to get nginx to serve correctly. the only advice i have seen is to change the value of the 'max_ranges' directive - but doing that has made no difference. i have left it as 'unset' - which i understand to mean 'unlimited'. an example video from the server is here: src=https://www.ureka.org/file/play/17924/censored%20on%20google%202.mp4; any tips welcomed! thanks Posted at Nginx Forum: http://forum.nginx.org/read.php?2,260615,260615#msg-260615 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
problem with images after refresh website
Hi i run directadmin+nginx1.8+php5.4 php-fpm when i do refresh to website the images not refresh good, sometime after refresh it put images in wrong place or double the images you can look on this website rhost(dot)biz, you can try refresh few times and look on the images and you will see the problem. what can be the problem? Posted at Nginx Forum: http://forum.nginx.org/read.php?2,260621,260621#msg-260621 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Добавление заголовка после upstream
On 2015-07-29 12:56, Budulianin wrote:
Может знаете какие-то книги/форумы/статьи на тему маршрутизации и
правильных
подходов/принципов?
Интересно почитать.
Правильно так:
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#sticky
Но если купить коммерческую подписку по тем или иным причинам
невозможно, придётся внешним монтажом:
или ставить за nginx'ом haproxy и писать в нём нечто эдакое:
listen fe 127.0.0.1:9876
balance leastconn
appsession JSESSIONID len 52 timeout 1h
server be1 192.168.169.170:8989 check
server be2 192.168.169.171:8989 check
или самим nginx'ом сделать то же самое:
# случайный выбор бакенда
upstream rndbackend {
server 192.168.169.170;
server 192.168.169.171;
}
# выбор бакенда на основании куки backend
map $cookie_backend $sticky_backend {
default BAD_GATEWAY;
~(?IP[0-9.]+$)$IP;
}
server {
listen 80;
# если приехала кука, выбираем бакенд согласно её значению
location / {
proxy_pass http://$sticky_backend;
error_page 502 = @random_backend;
}
# если куки нет, выбираем бакенд случайно и выставляем куку
location @random_backend (
proxy_pass http://rndbackend;
add_header Set-Cookie backend=$upstream_addr; path=/;
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
403 errors with standard browser, pages work with GUI browser
Hi, I’ve run across several websites where I get a 403 error when I connect to them with my standard webbrowser (lynx), yet the very same URIs work with the GUI browser fallback (Firef*x). Example link: http://blog.streamingmedia.com/2015/07/new-patent-pool-wants-share-of-revenue-from-content-owners.html Output from webbrowser: ←←← 403 Forbidden 403 Forbidden __ nginx All of these sites is common that they have an nginx error message, so this must be connected to your software somehow. To add insult to injury, this appears to be dependent on the User-Agent HTTP header: “Mozilla/5.0 (compatible)” works, “Lynx/2.8.9dev.6” works, “Lynx/2.8.9dev.6 libwww-FM/2.14” doesn’t, nor “Mozilla/5.0 (compatible) libwww-FM/2.14”. It appears that there is some blacklist on some component of my webbrowser. Please kindly remove it. Thanks, //mirabilos -- Why don't you use JavaScript? I also don't like enabling JavaScript in Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: log files as non root user
Hello, If you start your nginx process with root (login), your master process will start with root but the worker process and cache manager with usradmin:mwgroup (you can test with this command ps aux | grep nginx) you can try to start nginx with usradmin account : su - usradmin ; /etc/init.d/nginx start, this will solve the rights issue Posted at Nginx Forum: http://forum.nginx.org/read.php?2,260593,260622#msg-260622 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: nginx и сетевые папки
изменил конфиг:
location /video/sf/ {
root //192.168.xxx.xx/;
index index.html index.htm;
теперь в логе правильный путь
2015/07/29 15:31:56 [error] 11096#10252: *21
//192.168.xxx.xx/video/sf/index.html is forbidden (5: Access is denied),
client: 93.126.68.47, server: localhost, request: GET /video/sf/ HTTP/1.1,
host: www.site.com
но не работает
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,257586,260618#msg-260618
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
