Custom Query (2296 matches)

# nginx -V nginx version: nginx/1.4.6 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-cc-opt='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

# uname -a Linux lb01.host.tld 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

# service nginx configtest nginx: [emerg] Unable to create curve "secp521r1" (SSL: error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group) nginx: configuration file /etc/nginx/nginx.conf test failed

Whereas the previous version, 1.4.5, does support it:

# nginx -V nginx version: nginx/1.4.5 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-cc-opt='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

# service nginx configtest nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

This breaks upgrades for configs that try to use better/safer SSL implementations.

Hi!

There is a lot of crashes on Debian Jessie after upgrade from 1.6.x to 1.8.0:

stack trace:

Thread 1 (Thread 0x7f260fe21740 (LWP 6616)):
#0  ngx_ssl_new_session (ssl_conn=0x25429f0, sess=0x2543760) at src/event/ngx_event_openssl.c:2310
#1  0x00007f260ef01fb0 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#2  0x00000000025429f0 in ?? ()
#3  0x0000000000000003 in ?? ()
#4  0x0000000000000003 in ?? ()
#5  0x000000000042da50 in ?? () at src/event/ngx_event_openssl.c:508
#6  0x00007f260eedfcc1 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#7  0x000000000042f789 in ngx_ssl_handshake (c=c@entry=0x2358eb0) at src/event/ngx_event_openssl.c:1093
#8  0x000000000042fb13 in ngx_ssl_handshake_handler (ev=0x23c3020) at src/event/ngx_event_openssl.c:1245
#9  0x0000000000423d53 in ngx_event_process_posted (cycle=cycle@entry=0x2147410, posted=0x6e6a50 <ngx_posted_events>) at src/event/ngx_event_posted.c:33
#10 0x000000000042385b in ngx_process_events_and_timers (cycle=cycle@entry=0x2147410) at src/event/ngx_event.c:265
#11 0x000000000042a2bf in ngx_worker_process_cycle (cycle=cycle@entry=0x2147410, data=data@entry=0x2) at src/os/unix/ngx_process_cycle.c:767
#12 0x0000000000428c9a in ngx_spawn_process (cycle=0x2147410, proc=0x42a200 <ngx_worker_process_cycle>, data=0x2, name=0x4a3a36 "worker process", respawn=2)
    at src/os/unix/ngx_process.c:198
#13 0x000000000042b73e in ngx_reap_children (cycle=<optimized out>) at src/os/unix/ngx_process_cycle.c:620
#14 ngx_master_process_cycle (cycle=0x2147410) at src/os/unix/ngx_process_cycle.c:173
#15 0x0000000000409173 in main (argc=<optimized out>, argv=<optimized out>) at src/core/nginx.c:419

Maybe there is the bug, already fixed in 1.9.6, because:

• there is ssl_session_cache parameter used in one of vhosts.
• upgrate to 1.9.9 solve problem

I am having a requirement where my grpc-servers are behind firewall. So all incoming connections to these servers are blocked.

I want to use grpc as tunnel, where these servers will initiate the tcp connection with a publicly exposed load balancer. I chose nginx as load balancer for POC. So my idea is :

a) Grpc servers will initiate a long-lived tcp connection with nginx by calling a RPC. Nginx will have all these servers defined under upstream group. This way each upstream server will have 1 connection with nginx. b) A Grpc client calls nginx, and nginx will forward the request to any of upstream server. In-doing so nginx should use the connection established in step-a than creating a new connection to upstream server. But when I tested with above set-up, I see that it is creating a new connection than using the already established connection with upstream server.

Can you please suggest if this is possible ? How differently should I run the grpc server / nginx conf. Can any other load-balancer server above purpose than nginx ?