From roberto at unbit.it Wed Jan 1 06:18:16 2014
From: roberto at unbit.it (Roberto De Ioris)
Date: Wed, 1 Jan 2014 07:18:16 +0100
Subject: Hiring a dev: nginx+interchange
In-Reply-To:
References:
Message-ID: <9ebbe61429e25362cd558914f3f8d604.squirrel@manage.unbit.it>
> Hello, I use a perl framework called interchange (icdevgroup.org) and
> I've been using a perl module called Interchange::Link to interface
> interchange to apache:
>
> https://github.com/interchange/interchange/blob/master/dist/src/mod_perl2/Interchange/Link.pm
>
> I'd like to switch from apache to nginx and I need to hire someone to
> help me interface interchange to nginx. I don't need the interface to
> include all of the features from Interchange::Link.
>
> - Grant
>
> _
Hi Grant, embedding blocking code in nginx is not allowed (or better: it
is terribly wrong as in any other non-blocking engine)
You should invest on writing a PSGI adapter so you can use a full
application server (like Starman or uWSGI) behind nginx.
--
Roberto De Ioris
http://unbit.it
From nginx-forum at nginx.us Wed Jan 1 15:54:13 2014
From: nginx-forum at nginx.us (linuxr00lz2013)
Date: Wed, 01 Jan 2014 10:54:13 -0500
Subject: How do I disable DNS Caching and DNS Reverse Lookup in Nginx ?
In-Reply-To: <20131230231545.GZ95113@mdounin.ru>
References: <20131230231545.GZ95113@mdounin.ru>
Message-ID: <6b5ef756829d64f63c050cd264857f52.NginxMailingListEnglish@forum.nginx.org>
Hello Happy New year and thank you for the reply!
I dont think thats the cause, because I tried clearing the cache and it was
still stlow! Is there a special directive that I have to use to get it to
stop caching?
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245904,245945#msg-245945
From m.herrmann at ibumedia.de Wed Jan 1 16:43:19 2014
From: m.herrmann at ibumedia.de (Moritz Herrmann)
Date: Wed, 01 Jan 2014 17:43:19 +0100
Subject: Rewriteing awstats to base path
Message-ID: <52C445A7.2090307@ibumedia.de>
Hi,
I like to beautify my urls used for awstats.
Currently I have to use the following path for awstats
> /cgi-bin/awstats.pl?config=www.example.com
that works as expected.
For easier handling for our users I like to shorten the url to /www.example.com
I tried a simple rewrite like
> rewrite ^/www.example.com$ /cgi-bin/awstats.pl?config=www.example.com;
but I'll get the following error
> 2013/12/31 23:43:20 [error] 23736#0: *1 open() "/srv/awstats/dist/wwwroot/awstats.pl" failed (2: No such file or directory), client: ::ff:123.123.123.123, server: awstats.example.com, request: "GET /awstats.pl?config=www.example.com&framename=mainleft HTTP/1.1", host: "awstats.example.com", referrer: "http://awstats.example.com/www.example.com"
here is the full server block
> server {
> listen [::]:80;
> server_name awstats.example.com awstats7.example.com;
>
> root /srv/awstats/dist/wwwroot;
>
> auth_basic "Restricted";
> auth_basic_user_file /srv/awstats/.htpasswd;
>
> location ~ ^/cgi-bin/awstats\.pl {
> include fastcgi_params;
> fastcgi_pass unix:/var/run/php5-fpm.sock;
> fastcgi_param SCRIPT_FILENAME /srv/awstats/dist/tools/nginx/awstats-fcgi.php;
> fastcgi_param X_SCRIPT_FILENAME $document_root$fastcgi_script_name;
> fastcgi_param X_SCRIPT_NAME $fastcgi_script_name;
> }
>
> rewrite ^/awstats/(.*)$ /cgi-bin/$1;
> rewrite ^/www.example.com$ /cgi-bin/awstats.pl?config=www.example.com;
>
> location = /robots.txt { return 200 "User-agent: *\nDisallow: /\n"; }
> }
Desired url http://awstats.example.com/www.example.com
Probably I didn't fully understand the rewrite rules.
Hopefully you can help!
Best regards
moe
From mdounin at mdounin.ru Thu Jan 2 02:07:01 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 2 Jan 2014 06:07:01 +0400
Subject: How do I disable DNS Caching and DNS Reverse Lookup in Nginx ?
In-Reply-To: <6b5ef756829d64f63c050cd264857f52.NginxMailingListEnglish@forum.nginx.org>
References: <20131230231545.GZ95113@mdounin.ru>
<6b5ef756829d64f63c050cd264857f52.NginxMailingListEnglish@forum.nginx.org>
Message-ID: <20140102020701.GB95113@mdounin.ru>
Hello!
On Wed, Jan 01, 2014 at 10:54:13AM -0500, linuxr00lz2013 wrote:
> Hello Happy New year and thank you for the reply!
>
> I dont think thats the cause, because I tried clearing the cache and it was
> still stlow! Is there a special directive that I have to use to get it to
> stop caching?
Unfortunately, there is no magic directive "do it all right".
There is no DNS caching in nginx which survives configuration
reload, and there are no reverse DNS lookups in http module at
all.
Unfortunately, you don't show us real configuration and real logs,
so basically nobody here can help with debugging, but general tips
are:
1) Make sure you are testing it right. This basically means
you'll have to forget about browsers as they are too complex to be
usable as testing tools and use telnet or curl for basic tests.
And make sure to watch logs while doing tests.
2) Make sure you've configured it right. Make sure to understand
what you write in your configuration, make sure to test what you
wrote ("nginx -t" is your friend, as well as error log), and avoid
stupid mistakes like infinite loops. See above for recommended
testing tools.
3) Avoid descriptive terms like "really", "painfully", "awfully" -
measure instead. If a request takes 60 milliseconds - it may be
either really fast or really slow, depeding on use case.
Moreover, exact numbers are usually help a lot with debugging. If
something takes 60 seconds - it usually means that there is 60
second timeout somewhere (one of configure upstream servers can't
be reached?).
Happy New Year and happy debugging!
--
Maxim Dounin
http://nginx.org/
From nginx-forum at nginx.us Thu Jan 2 04:44:24 2014
From: nginx-forum at nginx.us (humank)
Date: Wed, 01 Jan 2014 23:44:24 -0500
Subject: How do i get the request body ?
Message-ID:
Hello guys,
I'm developing a nginx module, the intent is to get the request
body, then write some response depends on what request body is.
I've called the method ngx_http_read_client_request_body (r,
ngx_http_myModule_handler);
Since this code, i want to get the real request body in
ngx_http_myModule_handler()
Here are my codes ...
void ngx_http_myModule_handler(ngx_http_request_t *r)
{
ngx_http_finalize_request(r, NGX_DONE);
if(!(r->request_body->bufs == NULL)){
ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "request is not
empty.");
}
}
the questions is , how can i get the r->request_body->bufs to char * ?
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245952,245952#msg-245952
From nginx-forum at nginx.us Thu Jan 2 14:29:01 2014
From: nginx-forum at nginx.us (goversation)
Date: Thu, 02 Jan 2014 09:29:01 -0500
Subject: nginx rewrite configuration
Message-ID: <778b42cccec552ecc399e481296ac27c.NginxMailingListEnglish@forum.nginx.org>
hi! i'm newbie so having a hard time!
I have a question about rewrite configure in nginx!
RULE is http://URL/[option]/http://URL .
I mean...
for example,
if request is http://aaa.net/25X25/http://bbb.net/ccc.jpg ,
rewrite is /25X25/bbb.net.jpg
should i use regular expression?
please help me!
thank you :D
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245954,245954#msg-245954
From s.wiese at trabia.net Thu Jan 2 16:59:40 2014
From: s.wiese at trabia.net (Sven Wiese)
Date: Thu, 02 Jan 2014 18:59:40 +0200
Subject: Nginx not starting with named pipe (fifo) for access_log
Message-ID: <52C59AFC.3050404@trabia.net>
Heya,
there seems to be a issue with Nginx and named pipes (fifo).
Tested nginx versions:
- 1.1.19 (Ubuntu 12.04.3 LTS amd64)
- 1.4.4 (Ubuntu 12.04.3 LTS amd64 with PPA
https://launchpad.net/~nginx/+archive/stable )
- 1.4.4 (CentOS 6.5 amd64 with repo
http://nginx.org/packages/centos/$releasever/$basearch/ )
Issue description:
As soon as a named pipe is defined as access_log, nginx refuses to
start. It just stales during the start and that's it. The only you can
do is kill the process.
The named pipe has been created with: mkfifo -m 0666 /var/log/test.log
I have tested 2 versions of Nginx (1.1.19, 1.4.4) using Ubuntus
repository. Different locations and different permissions of the named
pipe have been tried, didn't help.
Other programs work just fine with the named pipe, only Nginx seems to
refuse it.
Configuration:
--snip--
http {
[...]
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
access_log /var/log/test.log;
[...]
}
--snap--
strace output:
--snip--
[...]
open("/var/log/nginx/access.log", O_WRONLY|O_CREAT|O_APPEND, 0644) = 5
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
open("/var/log/nginx/error.log", O_WRONLY|O_CREAT|O_APPEND, 0644) = 6
fcntl(6, F_SETFD, FD_CLOEXEC) = 0
open("/var/log/test.log", O_WRONLY|O_CREAT|O_APPEND, 0644
[ CTRL+C ]
--snap--
Did anyone else experience such behavior? I tried searching for it but
couldn't find anything, only people seeming to successfully use named
pipes (eg. in conjunction with syslog-ng).
Cheers,
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3872 bytes
Desc: S/MIME Cryptographic Signature
URL:
From appa at perusio.net Thu Jan 2 19:18:47 2014
From: appa at perusio.net (=?ISO-8859-1?Q?Ant=F3nio_P=2E_P=2E_Almeida?=)
Date: Thu, 2 Jan 2014 20:18:47 +0100
Subject: How to delete cache based on expires headers?
In-Reply-To: <1388377677.36102.YahooMailNeo@web140402.mail.bf1.yahoo.com>
References: <1387426860.9588.YahooMailNeo@web142305.mail.bf1.yahoo.com>
<1387853867.39367.YahooMailNeo@web140403.mail.bf1.yahoo.com>
<1388377677.36102.YahooMailNeo@web140402.mail.bf1.yahoo.com>
Message-ID:
Yes.
Nginx will obey the Cache-Control/Expire headers. It won't delete, but it
will refresh the files so that the served content is fresh.
So it is as if the files were deleted. AFAIK deletion happens more often
when the file is not accessed for given time specified through the inactive
parameter of the proxy_cache_path/fastcgi_cache_path directives.
----appa
On Mon, Dec 30, 2013 at 5:27 AM, Indo Php wrote:
> Hi
>
> Is that means that nginx will put the files based on the upstream expire
> headers? After that nginx will delete the cache files?
>
>
>
>
> On Tuesday, December 24, 2013 10:28 PM, Ant?nio P. P. Almeida <
> appa at perusio.net> wrote:
> Why you want to do this? nginx can manage expiration/cache-control
> headers all by itself.
>
> As soon as the defined max-age is set it returns a upstream status of
> EXPIRED until it fetches a fresh
> page from upstream.
>
> Deleting won't buy you anything in terms of content freshness.
>
>
>
>
>
> ----appa
>
>
>
> On Tue, Dec 24, 2013 at 3:57 AM, Indo Php wrote:
>
> Hello..
>
> Can somebody help me on this?
>
> Thank you before
>
>
> On Thursday, December 19, 2013 11:21 AM, Indo Php
> wrote:
> Hi
>
> I'm using proxy_cache to mirror my files with the configuration below
>
> proxy_cache_path /var/cache/nginx/image levels=1:2 keys_zone=one:10m
> inactive=7d max_size=100g;
>
> Our backend server has the expires header set to 600secs
>
> Is that posibble for us to also delete the cache files located at /var/cache/nginx/image
> depends on the backend expire header?
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nginx-forum at nginx.us Thu Jan 2 20:54:48 2014
From: nginx-forum at nginx.us (theotow)
Date: Thu, 02 Jan 2014 15:54:48 -0500
Subject: dynamic rate limiting per ip
Message-ID:
Hello Folks,
i have some setup with multiple server and i offer downloads for the users,
in the case my servers bandwidth is overloaded i want the people to be able
to start the download but with limited rate so the don't have to wait in
some kind of queue till the get there downloadlink. As soon as some slots
frees the person highest in the queue download rate should increase to the
max.
Any Ideas if this is possible with the limit_rate of the http core module
and lua?
If it would be possible to make 2 zone dicts where the ips of the the slow
and fast connections are in. And if someone ratelimit is dropped his ip gets
removed from the slow dict and added to the fast dict.
https://github.com/chaoslawful/lua-nginx-module#ngxshareddict
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245957,245957#msg-245957
From nginx-forum at nginx.us Thu Jan 2 22:03:36 2014
From: nginx-forum at nginx.us (nginx_developer)
Date: Thu, 02 Jan 2014 17:03:36 -0500
Subject: OCSP validation of client certificates
Message-ID: <806156b9262dfcabe5614b4363523683.NginxMailingListEnglish@forum.nginx.org>
Hi Forum,
I see that nGinx supports configuration to perform OCSP validation of
server side certificates and staple the validation response to the client.
My question is whether nGinx supports OCSP validation of client presented
certificates.
I seem to hit a dead end with documentation for that question. Would be
helpful if someone could answer this.
Thanks in advance for your time.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245958,245958#msg-245958
From electronixtar at gmail.com Fri Jan 3 00:49:20 2014
From: electronixtar at gmail.com (est)
Date: Fri, 3 Jan 2014 08:49:20 +0800
Subject: How would nginx record client IP address under TCP Multipath?
Message-ID:
Hello,
Since iOS7 supports TCP Multipath now, I think more and more devices will
start support it.
But TCP Multipath allows many client IPs connected to the same server,
suppose Nginx in this case, how would access_log record all of the IPs?
Just curious question :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From luky-37 at hotmail.com Fri Jan 3 01:43:10 2014
From: luky-37 at hotmail.com (Lukas Tribus)
Date: Fri, 3 Jan 2014 02:43:10 +0100
Subject: How would nginx record client IP address under TCP Multipath?
In-Reply-To:
References:
Message-ID:
Hi,
> Since iOS7 supports TCP Multipath now, I think more and more devices
> will start support it.
Not if the servers don't support it.
Apple pushed for a specific reason:
To avoid having a broken TCP session when the IP address of the handheld
changes, which would interrupt Apple's Siri.
But TCP multipath is still not supported by linux mainline and I don't
see efforts on linux-netdev to include it anytime soon. I understand there
is a maintained and uptodate patchset available, but that doesn't mean
it will be included in the kernel soon.
> But TCP Multipath allows many client IPs connected to the same server,
> suppose Nginx in this case, how would access_log record all of the IPs?
The application will always see the first IP, which connected to the server,
as per:
http://lwn.net/Articles/545862/
Regards,
Lukas
From mdounin at mdounin.ru Fri Jan 3 03:17:27 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 3 Jan 2014 07:17:27 +0400
Subject: OCSP validation of client certificates
In-Reply-To: <806156b9262dfcabe5614b4363523683.NginxMailingListEnglish@forum.nginx.org>
References: <806156b9262dfcabe5614b4363523683.NginxMailingListEnglish@forum.nginx.org>
Message-ID: <20140103031727.GD95113@mdounin.ru>
Hello!
On Thu, Jan 02, 2014 at 05:03:36PM -0500, nginx_developer wrote:
> Hi Forum,
> I see that nGinx supports configuration to perform OCSP validation of
> server side certificates and staple the validation response to the client.
> My question is whether nGinx supports OCSP validation of client presented
> certificates.
>
> I seem to hit a dead end with documentation for that question. Would be
> helpful if someone could answer this.
No. Only explicitly loaded CRLs are supported, see
http://nginx.org/r/ssl_crl.
--
Maxim Dounin
http://nginx.org/
From mdounin at mdounin.ru Fri Jan 3 03:40:34 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 3 Jan 2014 07:40:34 +0400
Subject: How do i get the request body ?
In-Reply-To:
References:
Message-ID: <20140103034033.GE95113@mdounin.ru>
Hello!
On Wed, Jan 01, 2014 at 11:44:24PM -0500, humank wrote:
> Hello guys,
>
> I'm developing a nginx module, the intent is to get the request
> body, then write some response depends on what request body is.
> I've called the method ngx_http_read_client_request_body (r,
> ngx_http_myModule_handler);
>
> Since this code, i want to get the real request body in
> ngx_http_myModule_handler()
> Here are my codes ...
>
> void ngx_http_myModule_handler(ngx_http_request_t *r)
> {
> ngx_http_finalize_request(r, NGX_DONE);
>
> if(!(r->request_body->bufs == NULL)){
> ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "request is not
> empty.");
>
> }
> }
>
> the questions is , how can i get the r->request_body->bufs to char * ?
A request body is available as a series of
buffers in r->request_body->bufs. To understand more about
buffers, try reading Evan Miller's guide as available from here:
http://www.evanmiller.org/nginx-modules-guide.html
Some example code which uses r->request_body->bufs to access
request body contents as available in memory can be found in
src/http/ngx_http_variables.c, in the
ngx_http_variable_request_body() function.
Note though, that depending on a configuration and a request, the
request body may not be available in memory at all (that is, it
will be in temporary file, and there will be a file buffer in
r->request_body->bufs).
--
Maxim Dounin
http://nginx.org/
From noloader at gmail.com Fri Jan 3 05:18:27 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 3 Jan 2014 00:18:27 -0500
Subject: -rpath linker option?
Message-ID:
I'm having trouble with dll hell on Debian and Ubuntu with OpenSSL.
Debian and Ubuntu insist on runtime linking with the copy in /usr/lib.
Fedora and Red Hat are OK because they don't use OpenSSL by default,
so they are not present in /usr/lib.
I've tried specifying a rpath in ld options:
--with-ld-opt="-rpath=$OPENSSL_LIB_DIR -ldl"
That results in:
checking for C compiler ... found
+ using GNU C compiler
checking for --with-ld-opt="-rpath=/usr/local/ssl/lib -ldl" ... not found
./auto/configure: error: the invalid value in
--with-ld-opt="-rpath=/usr/local/ssl/lib -ldl"
The path is valid:
$ ls /usr/local/ssl/lib
engines libcrypto.so libssl.a libssl.so.1.0.0
libcrypto.a libcrypto.so.1.0.0 libssl.so pkgconfig
LD_LIBRARY_PATH and LD_PRELOAD tricks don't work because they are
dropped when running as root.
Any ideas how to proceed?
From electronixtar at gmail.com Fri Jan 3 08:10:08 2014
From: electronixtar at gmail.com (est)
Date: Fri, 3 Jan 2014 16:10:08 +0800
Subject: How would nginx record client IP address under TCP Multipath?
In-Reply-To:
References:
Message-ID:
That's very helpful info. Thanks!
So getsockname() and getpeername() returns the initial subflow, what's the
API to get other subflows?
Edit: found my answer:
https://datatracker.ietf.org/doc/rfc6897/?include_text=1 by
using setsockopt() and getsockopt()
The functions getpeername() and getsockname() SHOULD also always
return the addresses of the first subflow if the socket is used by an
MPTCP-aware application, in order to be consistent with MPTCP-unaware
applications, and, e.g., also with the Stream Control Transmission
Protocol (SCTP). Instead of getpeername() or getsockname(),
MPTCP-aware applications can use new API calls, described in
Section 5.3, in order to retrieve the full list of address pairs for
the subflows in use.
On Fri, Jan 3, 2014 at 9:43 AM, Lukas Tribus wrote:
> Hi,
>
>
> > Since iOS7 supports TCP Multipath now, I think more and more devices
> > will start support it.
>
> Not if the servers don't support it.
>
> Apple pushed for a specific reason:
> To avoid having a broken TCP session when the IP address of the handheld
> changes, which would interrupt Apple's Siri.
>
> But TCP multipath is still not supported by linux mainline and I don't
> see efforts on linux-netdev to include it anytime soon. I understand there
> is a maintained and uptodate patchset available, but that doesn't mean
> it will be included in the kernel soon.
>
>
>
> > But TCP Multipath allows many client IPs connected to the same server,
> > suppose Nginx in this case, how would access_log record all of the IPs?
>
> The application will always see the first IP, which connected to the
> server,
> as per:
> http://lwn.net/Articles/545862/
>
>
>
>
> Regards,
>
> Lukas
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nginx-forum at nginx.us Fri Jan 3 09:35:06 2014
From: nginx-forum at nginx.us (flash008)
Date: Fri, 03 Jan 2014 04:35:06 -0500
Subject: SSL handshake fail between nginx and my tomcat with mutual
authentication
Message-ID:
Hi All,
I am using Nginx 1.4.4 as reverse proxy for my tomcat server. My problem is:
SSL handshake failed between Nginx and tomcat with mutual SSL
authentication. I have verified that Client to Nginx with mutual SSL is
working. But if my upstream backend is also using https:mutual port, the
path will fail with error:
[error] 1816#3436: *23 SSL_do_handshake() failed (SSL: error:14094412:SSL
routines:SSL3_READ_BYTES:sslv3 alert bad certificate:SSL alert number 42)
while SSL handshaking to upstream, client: xx.xx.xx.xx, server:
xx.xxx.xxx.xxx, request: "GET / HTTP/1.1", upstream:
"https://xx.xx.xx.xx:8082/", host: "xx.xx.xx.xx:8002"
My upstream server https://xx.xx.xx.xx:8082 is using mutual SSL and working
perfectly without Nginx.
the Nginx host https://xx.xx.xx.xx:8002 is using mutual SSL and also working
perfectly without the upstream mutual ssl or with only http port.
The problem is: when both Nginx and upstream require mutual SSL, and I would
like to pass the client certificate to Nginx then to my upstream server, the
SSL handshake error occurs.
I have tried to add client cert in headers, but no luck. Here is part of my
nginx config
####
server {
listen xx.xx.xx.xx:8002;
server_name xx.xx.xx.xx;
ssl on;
ssl_certificate C:/nginx-1.4.4/cert/MyServer.crt;
ssl_certificate_key C:/nginx-1.4.4/cert/MyServer.key;
ssl_client_certificate C:/nginx-1.4.4/cert/MyCA.pem;
ssl_trusted_certificate C:/nginx-1.4.4/cert/MyCA.pem;
ssl_prefer_server_ciphers on;
ssl_verify_client on;
ssl_verify_depth 3;
ssl_protocols SSLv2 SSLv3 TLSv1;
access_log C:/nginx-1.4.4/logs/access_8002.log;
error_log C:/nginx-1.4.4/logs/error_8002.log debug;
root html;
index index.html index.htm;
location / {
proxy_pass https://10.128.103.47:8082/;
proxy_redirect default;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Client-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
proxy_set_header X-SSL-Client-Serial $ssl_client_serial;
proxy_set_header X-SSL-Client-Verify $ssl_client_verify;
proxy_set_header X-SSL-Client-S-DN $ssl_client_s_dn;
}
}
Is this usage supported by Nginx?
I would be very grateful if someone can point me some clues or suggestions.
Thanks and Best Regards,
Flash008
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245971,245971#msg-245971
From mdounin at mdounin.ru Fri Jan 3 13:37:54 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 3 Jan 2014 17:37:54 +0400
Subject: -rpath linker option?
In-Reply-To:
References:
Message-ID: <20140103133754.GJ95113@mdounin.ru>
Hello!
On Fri, Jan 03, 2014 at 12:18:27AM -0500, Jeffrey Walton wrote:
> I'm having trouble with dll hell on Debian and Ubuntu with OpenSSL.
> Debian and Ubuntu insist on runtime linking with the copy in /usr/lib.
> Fedora and Red Hat are OK because they don't use OpenSSL by default,
> so they are not present in /usr/lib.
>
> I've tried specifying a rpath in ld options:
>
> --with-ld-opt="-rpath=$OPENSSL_LIB_DIR -ldl"
>
> That results in:
>
> checking for C compiler ... found
> + using GNU C compiler
> checking for --with-ld-opt="-rpath=/usr/local/ssl/lib -ldl" ... not found
> ./auto/configure: error: the invalid value in
> --with-ld-opt="-rpath=/usr/local/ssl/lib -ldl"
Try looking into objs/autoconf.err. Most likely, your cc want it
to be spelled like "-Wl,-rpath=...".
--
Maxim Dounin
http://nginx.org/
From richard at kearsley.me Fri Jan 3 14:46:09 2014
From: richard at kearsley.me (Richard Kearsley)
Date: Fri, 03 Jan 2014 14:46:09 +0000
Subject: nginx ssl handshake vs apache
Message-ID: <52C6CD31.3030908@kearsley.me>
Hi
I was watching this video by fastly ceo http://youtu.be/zrSvoQz1GOs?t=24m44s
he talks about the nginx ssl handshake versus apache and comes to the
conclusion that apache was more efficient at mass handshakes due to
nginx blocking while it calls back to openssl
I was hoping to get other people's opinion on this and find out if what
he says is accurate or not
Many thanks
Richard
From renenglish at gmail.com Fri Jan 3 15:03:26 2014
From: renenglish at gmail.com (=?GB2312?B?yM7Twsir?=)
Date: Fri, 3 Jan 2014 23:03:26 +0800
Subject: Does it possible to submit duplicated request with the
proxy_next_upstream on
Message-ID: <9B89B2DD-EB2A-4126-AB7D-9E86972866A0@gmail.com>
Hi all:
I am wondering if I set:
proxy_next_upstream error timeout;
Fox example , if the requested service is a counter , I issue the request use the interface http://example.com/incr . The request is failed on my first host A, then it is passed to the second host B , is the counter likely be added twice ?
thanks .
From nginx-forum at nginx.us Sat Jan 4 01:22:28 2014
From: nginx-forum at nginx.us (ura)
Date: Fri, 03 Jan 2014 20:22:28 -0500
Subject: mainline does not include gzip module?
Message-ID:
i just replaced a stable install with the mainline version (1.5.8) and
noticed that the outputted files are not being gzipped.
i ran nginx -V and do not see any arguments that enable gzip.
is there a reason why the stable version included gzip and this mainline
does not?
do i need to manually build nginx to include the gzip module?
if so, does that mean i need to rebuild nginx every time there is a new
update?
thanks
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245997,245997#msg-245997
From vbart at nginx.com Sat Jan 4 01:34:02 2014
From: vbart at nginx.com (Valentin V. Bartenev)
Date: Sat, 04 Jan 2014 05:34:02 +0400
Subject: mainline does not include gzip module?
In-Reply-To:
References:
Message-ID: <2131154.zFoeNsukc8@vbart-laptop>
On Friday 03 January 2014 20:22:28 ura wrote:
> i just replaced a stable install with the mainline version (1.5.8) and
> noticed that the outputted files are not being gzipped.
> i ran nginx -V and do not see any arguments that enable gzip.
> is there a reason why the stable version included gzip and this mainline
> does not?
The gzip module is compiled by default, unless explicitly disabled
using the --without-http_gzip_module argument.
> do i need to manually build nginx to include the gzip module?
No, you don't. It is included in both packages stable and mainline.
wbr, Valentin V. Bartenev
From nginx-forum at nginx.us Sat Jan 4 01:51:31 2014
From: nginx-forum at nginx.us (ura)
Date: Fri, 03 Jan 2014 20:51:31 -0500
Subject: mainline does not include gzip module?
In-Reply-To: <2131154.zFoeNsukc8@vbart-laptop>
References: <2131154.zFoeNsukc8@vbart-laptop>
Message-ID:
thanks for responding. :)
so... has a change been made in the way i would activate the gzip process
between the stable and mainline versions?
in nginx.conf?
this is the list of options i was successfully using in stable (built
through trial and error):
gzip on;
gzip_http_version 1.0;
gzip_comp_level 6;
gzip_proxied any;
gzip_min_length 100;
gzip_buffers 16 8k;
gzip_types text/plain text/css application/x-javascript application/json
text/xml application/xml application/xml+rss text/javascript;
gzip_disable "msie6";
gzip_vary on;
any other thoughts on why gzip would appear to not be functioning for me
here?
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245997,245999#msg-245999
From nginx-forum at nginx.us Sat Jan 4 01:53:32 2014
From: nginx-forum at nginx.us (ura)
Date: Fri, 03 Jan 2014 20:53:32 -0500
Subject: mainline does not include gzip module?
In-Reply-To:
References: <2131154.zFoeNsukc8@vbart-laptop>
Message-ID:
ah, i found the answer..
i needed to change the javascript mimetype to 'application/javascript'
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245997,246000#msg-246000
From nginx-forum at nginx.us Sat Jan 4 03:42:52 2014
From: nginx-forum at nginx.us (justin)
Date: Fri, 03 Jan 2014 22:42:52 -0500
Subject: Very slow dns lookup using proxy_pass
Message-ID: <5fd685a4bea5a8565474e049ed32969d.NginxMailingListEnglish@forum.nginx.org>
I am seeing very slow DNS lookup times ( > 2 seconds ) using proxy_pass,
even though dig response times on the server are quick. Here is the nginx
configuration block:
location ~ ^/v1/(?.*) {
resolver 8.8.4.4 4.4.4.4 valid=300s;
resolver_timeout 10s;
proxy_pass https://$remote_user.mydomain.com/api/;
proxy_hide_header Vary;
proxy_set_header X-Real-IP $remote_addr;
proxy_connect_timeout 10s;
proxy_read_timeout 60s;
proxy_ssl_session_reuse on;
}
I am using Google Public DNS. Here is a result from: dig demo.mydomain.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> demo.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<
References: <5fd685a4bea5a8565474e049ed32969d.NginxMailingListEnglish@forum.nginx.org>
Message-ID:
On 4 January 2014 03:42, justin wrote:
> I am seeing very slow DNS lookup times ( > 2 seconds ) using proxy_pass,
> even though dig response times on the server are quick
[snip]
> Any ideas why this is so slow, and solutions?
Please demonstrate a slow request, and show the data that leads you to
believe that DNS lookups from nginx are the problem.
Jonathan
From nginx-forum at nginx.us Sat Jan 4 04:11:02 2014
From: nginx-forum at nginx.us (justin)
Date: Fri, 03 Jan 2014 23:11:02 -0500
Subject: Very slow dns lookup using proxy_pass
In-Reply-To:
References:
Message-ID: <3c9913711c91dce5ec8fada3f5a037de.NginxMailingListEnglish@forum.nginx.org>
Hi Jonathan,
Using time is the only way I know how to demonstrate this:
FIRST TIME TOOK: 5.8 seconds
? ~ time curl -i -u demo: https://api.mydomain.com/v1/
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 04 Jan 2014 04:07:50 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31556926
Cache-Control: no-cache, no-store
Access-Control-Max-Age: 300
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
{"version":"v1"} curl -i -u demo: https://api.mydomain.com/v1/ 0.54s user
0.01s system 9% cpu 5.857 total
EXECUTED AGAIN, IMMEDIATELY AFTER. TOOK: 197ms
? ~ time curl -i -u demo: https://api.mydomain.com/v1/
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 04 Jan 2014 04:07:54 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31556926
Cache-Control: no-cache, no-store
Access-Control-Max-Age: 300
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
{"version":"v1"} curl -i -u demo: https://api.mydomain.com/v1/ 0.05s user
0.01s system 27% cpu 0.197 total
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246001,246003#msg-246003
From nginx-forum at nginx.us Sat Jan 4 06:18:12 2014
From: nginx-forum at nginx.us (ComfortVPS)
Date: Sat, 04 Jan 2014 01:18:12 -0500
Subject: CentOS Nginx Installer(include PHP-FTP,
MYSQL) add website no need restart Nginx
Message-ID: <02e742f31424674afd3f2dc62b2d567f.NginxMailingListEnglish@forum.nginx.org>
Some of our clients are not good at SSH command, they just want an easy way
to run their websites. Most of them are less then 1GB memory VPS and don't
want install control panel.
For this purpose, we wrote a CentOS Nginx Installer script for
"Nginx+PHP+MySql+phpMyAdmin"
What's you need to do is: Copy and post/run below single command line via
SSH root login. wait 5-15 minutes(depending on the software download speed
from your server), Everything is Done!
############ Automatically install command line ############
wget -O /tmp/npmp.sh
https://raw.github.com/ComfortVPS/Nginx-PHP-MySql-phpMyAdmin/master/install-nginx-php-mysql.sh;
sh /tmp/npmp.sh;
############ Installation Requirement ############
CentOS 5.x/6.x 32bit or 64bit ( We recommend you Reload OS before run the
installer )
Guarantee Memory >= 128MB
Free Disk space >=2GB
############ Fetures ############
You can add multiple websites directly via SFTP, no need to login SSH, no
need to restart Nginx
You can easily custom config each website domain's Nginx config file if you
need
Installed the newest stable version of Nginx, PHP-FPM, MySql by YUM
phpMyAdmin4.x installed and ready for use. Just login and manage mysql
database as you want
Work perfectly for low memory VPS with ram >= 128MB
Many tutorials for how to use
Get your password after everything installed
Your SSH console screen will show something like below after successfully
installed, Please record your password. The unique password was random
generated by openssl, no need to change.
############ Information you will get after installation (below is an
example) ############
====== Nginx + PHP-FPM + MYSQL Successfully installed
====== MySql root password is cft.KL7fvW2g
====== SFTP Username is myweb
====== SFTP Password is cft.KL7fvW2g
====== Website document root is /www/yourdomain
====== Add websites tutorials: http://goo.gl/sdDF9
====== Now you can visit http://your-ip-address/
====== Eg. http://50.3.62.173/
====== phpMyAdmin: http://50.3.62.173/phpMyAdmin4U/
====== More tutorials: http://goo.gl/tNFb0
############ How to add multiple websites via SFTP ? ############
Step 1, Create a domain name directory under /www via SFTP, eg,
yourdomain.com, subdomain.abc.com, domain-name.net
Step 2, Everything is Done, Config Nginx virtual host is finish, upload your
php/html files to that directory then test it.
############ More tutorials ############
http://goo.gl/tNFb0
We will continue to write more tutorials for how to use it.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246005,246005#msg-246005
From nginx at 2xlp.com Sat Jan 4 20:36:33 2014
From: nginx at 2xlp.com (Jonathan Vanasco)
Date: Sat, 4 Jan 2014 15:36:33 -0500
Subject: issue with `default_type` & `type` on 1.5.7
In-Reply-To: <36cb46b6f59688950730d92fbdb0a260.NginxMailingListEnglish@forum.nginx.org>
References: <36cb46b6f59688950730d92fbdb0a260.NginxMailingListEnglish@forum.nginx.org>
Message-ID: <663B722A-E6F3-40CD-B37D-4CD53FCD4956@2xlp.com>
I recently encountered an issue with a 1.5.7 branch on OSX. i did not check 1.5.8
The following code will set ALL css/js files as the default_type
include /usr/local/nginx/conf/mime.types;
default_type application/octet-stream;
The following code works as intended
default_type application/octet-stream;
include /usr/local/nginx/conf/mime.types;
I haven't had time to test on other versions.
This could be the intended behavior, but the docs don't suggest that. usually a default_type only applies when the real type can't be found.
From noloader at gmail.com Sun Jan 5 07:59:52 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 5 Jan 2014 02:59:52 -0500
Subject: agentzh's encrypted session module
Message-ID:
I've been studying agentzh's encrypted session module from
https://github.com/agentzh/encrypted-session-nginx-module/tree/master/src.
There are essentially two methods: one to encrypt values, and a second
to decrypt modules. The functions to do so are
ngx_http_set_encode_encrypted_session and
ngx_http_set_decode_encrypted_session. The functions call
ngx_http_encrypted_session_aes_mac_encrypt and
ngx_http_encrypted_session_aes_mac_decrypt respectively.
The problem I am having is: I cannot tell how this is plumbed into
nginx framework such that a value is encrypted going one way, and
decrypted going another. From the module, I clearly see the command:
Can anyone shed some light on the magic I am missing?
Thanks in advance.
From noloader at gmail.com Sun Jan 5 08:14:48 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 5 Jan 2014 03:14:48 -0500
Subject: OT: Crypto Hardening Guide (nginx has an entry)
Message-ID:
For administrators interested in SSL/TLS protocols and ciphers
settings, the following may be useful. It also looks like the
[possibly influenced] US stuff was removed.
https://bettercrypto.org/static/applied-crypto-hardening.pdf
From nick at thenile.com.au Mon Jan 6 03:56:23 2014
From: nick at thenile.com.au (Nick Jenkin)
Date: Mon, 6 Jan 2014 14:56:23 +1100
Subject: Centos 6.5 and ECDH ciphers in nginx.org Centos repo
Message-ID: <4828002A-2339-4CD2-A0F1-D44F7A51FBF9@thenile.com.au>
Hi
In Centos 6.5 (and RHEL 6.5) the ECDH ciphers were enabled. There appears to be an issue with the nginx.org 1.5.8 Centos binaries still not having support for ECDHE despite having updated openssl 1.01e with elliptic curves.
If I compile from source, ECDH works fine. Is there something wrong with the centos binaries?
Ciphers on Centos 6.5:
[nick at dev9145 conf.d]$ openssl ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:KRB5-IDEA-CBC-SHA:KRB5-IDEA-CBC-MD5:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:KRB5-DES-CBC-SHA:KRB5-DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-KRB5-RC4-MD5
ECDHE test:
openssl s_client -tls1_2 -cipher ECDH -connect 127.0.0.1:443
CONNECTED(00000003)
139798957754184:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40
139798957754184:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
?
Thanks
-Nick
From iptablez at yahoo.com Mon Jan 6 04:17:46 2014
From: iptablez at yahoo.com (Indo Php)
Date: Sun, 5 Jan 2014 20:17:46 -0800 (PST)
Subject: How to delete cache based on expires headers?
In-Reply-To:
References: <1387426860.9588.YahooMailNeo@web142305.mail.bf1.yahoo.com>
<1387853867.39367.YahooMailNeo@web140403.mail.bf1.yahoo.com>
<1388377677.36102.YahooMailNeo@web140402.mail.bf1.yahoo.com>
Message-ID: <1388981866.74009.YahooMailNeo@web142305.mail.bf1.yahoo.com>
Thanks that makes clear!
On Friday, January 3, 2014 2:19 AM, Ant?nio P. P. Almeida wrote:
Yes.?
Nginx will obey the Cache-Control/Expire headers. It won't delete, but it will refresh the files so that the served content is fresh.
So it is as if the files were deleted. AFAIK deletion happens more often when the file is not accessed for given time specified through the inactive
parameter of the proxy_cache_path/fastcgi_cache_path directives. ?
----appa
On Mon, Dec 30, 2013 at 5:27 AM, Indo Php wrote:
Hi
>
>
>Is that means that nginx will put the files based on the upstream expire headers? After that nginx will delete the cache files?
>
>
>
>
>
>
>
>On Tuesday, December 24, 2013 10:28 PM, Ant?nio P. P. Almeida wrote:
>
>Why you want to do this? nginx can manage expiration/cache-control headers all by itself.
>
>
>As soon as the defined max-age is set it returns a upstream status of EXPIRED until it fetches a fresh
>page from upstream.
>
>
>Deleting won't buy you anything in terms of content freshness.
>
>
>
>
>
>
>
>
>
>
>----appa
>
>
>
>
>On Tue, Dec 24, 2013 at 3:57 AM, Indo Php wrote:
>
>Hello..
>>
>>
>>Can somebody help me on this?
>>
>>
>>Thank you before
>>
>>
>>
>>On Thursday, December 19, 2013 11:21 AM, Indo Php wrote:
>>
>>Hi
>>
>>
>>I'm using proxy_cache to mirror my files with the configuration below
>>
>>
>>proxy_cache_path? /var/cache/nginx/image levels=1:2 keys_zone=one:10m inactive=7d ? ? max_size=100g;
>>
>>
>>Our backend server has the expires header set to 600secs
>>
>>
>>Is that posibble for us to also delete the cache files located at?/var/cache/nginx/image depends on the backend expire header?
>>
>>
>>_______________________________________________
>>nginx mailing list
>>nginx at nginx.org
>>http://mailman.nginx.org/mailman/listinfo/nginx
>>
>>
>>_______________________________________________
>>nginx mailing list
>>nginx at nginx.org
>>http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
>_______________________________________________
>nginx mailing list
>nginx at nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>_______________________________________________
>nginx mailing list
>nginx at nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nginx-forum at nginx.us Mon Jan 6 04:55:12 2014
From: nginx-forum at nginx.us (hoidulich)
Date: Sun, 05 Jan 2014 23:55:12 -0500
Subject: Problem trying to rewrite a URL
Message-ID:
Hi all,
I have a problem trying to rewrite a URL.
It should be pretty straightforward but it has been taking me hours
searching.
Google indexed urls containing ";", which gets escaped to %3b:
http://hoidulich.com/index.php?action=tagged%3bid=254715%3btag=vietholiday
(the original url that works is
http://hoidulich.com/index.php?action=tagged;id=254715;tag=vietholiday)
How can I fix it?
Thank you very much.
Cao Tri.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246052,246052#msg-246052
From noloader at gmail.com Mon Jan 6 10:07:09 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 6 Jan 2014 05:07:09 -0500
Subject: Centos 6.5 and ECDH ciphers in nginx.org Centos repo
In-Reply-To: <4828002A-2339-4CD2-A0F1-D44F7A51FBF9@thenile.com.au>
References: <4828002A-2339-4CD2-A0F1-D44F7A51FBF9@thenile.com.au>
Message-ID:
On Sun, Jan 5, 2014 at 10:56 PM, Nick Jenkin wrote:
> Hi
>
> In Centos 6.5 (and RHEL 6.5) the ECDH ciphers were enabled. There appears to be an issue with the nginx.org 1.5.8 Centos binaries still not having support for ECDHE despite having updated openssl 1.01e with elliptic curves.
>
> If I compile from source, ECDH works fine. Is there something wrong with the centos binaries?
>
http://unix.stackexchange.com/questions/84283/how-can-i-get-tlsv1-2-support-in-apache-on-rhel6-centos-sl6
Though the question is about Apache, it specifically calls out nginx
as needing a recompile on the platform after updating from OpenSSL
1.0.0 to OpenSSL 1.0.1 due to static linking.
Jeff
From nick at thenile.com.au Mon Jan 6 10:10:43 2014
From: nick at thenile.com.au (Nick Jenkin)
Date: Mon, 6 Jan 2014 21:10:43 +1100
Subject: Centos 6.5 and ECDH ciphers in nginx.org Centos repo
In-Reply-To:
References: <4828002A-2339-4CD2-A0F1-D44F7A51FBF9@thenile.com.au>
Message-ID:
RHEL used 1.0.0 in 6.4, however in 6.5 it was updated to OpenSSL 1.0.1e-fips 11 Feb 2013
See: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.5_Release_Notes/
Like I said, if I compile nginx myself it ECDH works fine. It?s the nginx.org binaries that do not work. So it would appear the nginx.org binaries are statically compiled against the older version, so I guess the question is when will the nginx.org builds be built on 6.5?
-Nick
On 6 Jan 2014, at 9:07 pm, Jeffrey Walton wrote:
> On Sun, Jan 5, 2014 at 10:56 PM, Nick Jenkin wrote:
>> Hi
>>
>> In Centos 6.5 (and RHEL 6.5) the ECDH ciphers were enabled. There appears to be an issue with the nginx.org 1.5.8 Centos binaries still not having support for ECDHE despite having updated openssl 1.01e with elliptic curves.
>>
>> If I compile from source, ECDH works fine. Is there something wrong with the centos binaries?
>>
> http://unix.stackexchange.com/questions/84283/how-can-i-get-tlsv1-2-support-in-apache-on-rhel6-centos-sl6
>
> Though the question is about Apache, it specifically calls out nginx
> as needing a recompile on the platform after updating from OpenSSL
> 1.0.0 to OpenSSL 1.0.1 due to static linking.
>
> Jeff
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
From noloader at gmail.com Mon Jan 6 10:21:41 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 6 Jan 2014 05:21:41 -0500
Subject: Centos 6.5 and ECDH ciphers in nginx.org Centos repo
In-Reply-To:
References: <4828002A-2339-4CD2-A0F1-D44F7A51FBF9@thenile.com.au>
Message-ID:
On Mon, Jan 6, 2014 at 5:10 AM, Nick Jenkin wrote:
> RHEL used 1.0.0 in 6.4, however in 6.5 it was updated to OpenSSL 1.0.1e-fips 11 Feb 2013
> See: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.5_Release_Notes/
>
> Like I said, if I compile nginx myself it ECDH works fine. It?s the nginx.org binaries that do not work. So it would appear the nginx.org binaries are statically compiled against the older version...
That's easy enought to check. Run ldd on it an look for an OpenSSL
dependency. If SSL/TLS is eanbled and the dependency is missing, then
nginx was statically linked against OpenSSL. Below, nginx was built
with a dependency on the shared object.
$ ldd objs/nginx
linux-vdso.so.1 => (0x00007fff85f96000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9f0345b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f9f0323f000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f9f03007000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f9f02dca000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x00007f9f02b6a000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x00007f9f02785000)
...
> so I guess the question is when will the nginx.org builds be built on 6.5?
Sorry, I can't help. I believe that's a question for the Red Hat or
CentOS folks.
Jeff
> On 6 Jan 2014, at 9:07 pm, Jeffrey Walton wrote:
>
>> On Sun, Jan 5, 2014 at 10:56 PM, Nick Jenkin wrote:
>>> Hi
>>>
>>> In Centos 6.5 (and RHEL 6.5) the ECDH ciphers were enabled. There appears to be an issue with the nginx.org 1.5.8 Centos binaries still not having support for ECDHE despite having updated openssl 1.01e with elliptic curves.
>>>
>>> If I compile from source, ECDH works fine. Is there something wrong with the centos binaries?
>>>
>> http://unix.stackexchange.com/questions/84283/how-can-i-get-tlsv1-2-support-in-apache-on-rhel6-centos-sl6
>>
>> Though the question is about Apache, it specifically calls out nginx
>> as needing a recompile on the platform after updating from OpenSSL
>> 1.0.0 to OpenSSL 1.0.1 due to static linking.
>>
From mdounin at mdounin.ru Mon Jan 6 12:54:57 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 6 Jan 2014 16:54:57 +0400
Subject: Centos 6.5 and ECDH ciphers in nginx.org Centos repo
In-Reply-To: <4828002A-2339-4CD2-A0F1-D44F7A51FBF9@thenile.com.au>
References: <4828002A-2339-4CD2-A0F1-D44F7A51FBF9@thenile.com.au>
Message-ID: <20140106125457.GR95113@mdounin.ru>
Hello!
On Mon, Jan 06, 2014 at 02:56:23PM +1100, Nick Jenkin wrote:
> Hi
>
> In Centos 6.5 (and RHEL 6.5) the ECDH ciphers were enabled.
> There appears to be an issue with the nginx.org 1.5.8 Centos
> binaries still not having support for ECDHE despite having
> updated openssl 1.01e with elliptic curves.
>
> If I compile from source, ECDH works fine. Is there something
> wrong with the centos binaries?
>
> Ciphers on Centos 6.5:
[...]
This is expected. Builds are done for CentOS 6, not just CentOS
6.5, so they are done with OpenSSL as available in previous
versions to ensure compatibility with previous versions of CentOS 6.
--
Maxim Dounin
http://nginx.org/
From nginx-forum at nginx.us Mon Jan 6 16:07:36 2014
From: nginx-forum at nginx.us (theotow)
Date: Mon, 06 Jan 2014 11:07:36 -0500
Subject: dynamic rate limiting per ip
In-Reply-To:
References:
Message-ID: <3618e65a4e5808716b4ab89fa4908147.NginxMailingListEnglish@forum.nginx.org>
nobody an idea?
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245957,246064#msg-246064
From nginx-forum at nginx.us Mon Jan 6 17:35:46 2014
From: nginx-forum at nginx.us (linuxr00lz2013)
Date: Mon, 06 Jan 2014 12:35:46 -0500
Subject: How do I disable DNS Caching and DNS Reverse Lookup in Nginx ?
In-Reply-To: <20140102020701.GB95113@mdounin.ru>
References: <20140102020701.GB95113@mdounin.ru>
Message-ID: <959b925f65dbdba2780e44913888a117.NginxMailingListEnglish@forum.nginx.org>
Hello thank you for your reply!
1) I have shown you the real configuration and logs. All I changed was the
FQDN's because I dont know if I am allowed by my company to post them
online.
2) Which tests do you recommend I run using telnet and curl? I am not too
familiar with using curl so any guidance will be greatly appreciated!
Thanks!
Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
>
> On Wed, Jan 01, 2014 at 10:54:13AM -0500, linuxr00lz2013 wrote:
>
> > Hello Happy New year and thank you for the reply!
> >
> > I dont think thats the cause, because I tried clearing the cache and
> it was
> > still stlow! Is there a special directive that I have to use to get
> it to
> > stop caching?
>
> Unfortunately, there is no magic directive "do it all right".
> There is no DNS caching in nginx which survives configuration
> reload, and there are no reverse DNS lookups in http module at
> all.
>
> Unfortunately, you don't show us real configuration and real logs,
> so basically nobody here can help with debugging, but general tips
> are:
>
> 1) Make sure you are testing it right. This basically means
> you'll have to forget about browsers as they are too complex to be
> usable as testing tools and use telnet or curl for basic tests.
> And make sure to watch logs while doing tests.
>
> 2) Make sure you've configured it right. Make sure to understand
> what you write in your configuration, make sure to test what you
> wrote ("nginx -t" is your friend, as well as error log), and avoid
> stupid mistakes like infinite loops. See above for recommended
> testing tools.
>
> 3) Avoid descriptive terms like "really", "painfully", "awfully" -
> measure instead. If a request takes 60 milliseconds - it may be
> either really fast or really slow, depeding on use case.
> Moreover, exact numbers are usually help a lot with debugging. If
> something takes 60 seconds - it usually means that there is 60
> second timeout somewhere (one of configure upstream servers can't
> be reached?).
>
> Happy New Year and happy debugging!
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245904,246065#msg-246065
From agentzh at gmail.com Mon Jan 6 19:33:23 2014
From: agentzh at gmail.com (Yichun Zhang (agentzh))
Date: Mon, 6 Jan 2014 11:33:23 -0800
Subject: dynamic rate limiting per ip
In-Reply-To:
References:
Message-ID:
Hello!
On Thu, Jan 2, 2014 at 12:54 PM, theotow wrote:
>
> Any Ideas if this is possible with the limit_rate of the http core module
> and lua?
>
You can use ngx_lua alone to do this.
> If it would be possible to make 2 zone dicts where the ips of the the slow
> and fast connections are in. And if someone ratelimit is dropped his ip gets
> removed from the slow dict and added to the fast dict.
>
> https://github.com/chaoslawful/lua-nginx-module#ngxshareddict
>
Yes, you can surely do that. You can use ngx.sleep() to hold back the
exceeding clients without blocking other requests served by the same
nginx worker.
Regards,
-agentzh
From agentzh at gmail.com Mon Jan 6 19:44:43 2014
From: agentzh at gmail.com (Yichun Zhang (agentzh))
Date: Mon, 6 Jan 2014 11:44:43 -0800
Subject: agentzh's encrypted session module
In-Reply-To:
References:
Message-ID:
Hello!
On Sat, Jan 4, 2014 at 11:59 PM, Jeffrey Walton wrote:
> I've been studying agentzh's encrypted session module from
> https://github.com/agentzh/encrypted-session-nginx-module/tree/master/src.
>
Thank you for checking it out! :)
>
> The problem I am having is: I cannot tell how this is plumbed into
> nginx framework such that a value is encrypted going one way, and
> decrypted going another. From the module, I clearly see the command:
>
The callbacks are injected into the standard ngx_rewrite module's
command list by means of the ndk_set_var submodule in the
ngx_devel_kit (NDK) module:
https://github.com/simpl/ngx_devel_kit
The entry point of NDK called ngx_encrypted_session is
ndk_set_var_value. You can trace from there :)
The actual request-time caller of these configuration directives is
the standard ngx_rewrite module at the "rewrite" running phase.
Best regards,
-agentzh
From nginx-forum at nginx.us Mon Jan 6 20:34:39 2014
From: nginx-forum at nginx.us (justink101)
Date: Mon, 06 Jan 2014 15:34:39 -0500
Subject: Very slow dns lookup using proxy_pass
In-Reply-To: <5fd685a4bea5a8565474e049ed32969d.NginxMailingListEnglish@forum.nginx.org>
References: <5fd685a4bea5a8565474e049ed32969d.NginxMailingListEnglish@forum.nginx.org>
Message-ID: <6bf4973420f767174bd74e1a38cf8742.NginxMailingListEnglish@forum.nginx.org>
Anybody have any further insight on this? Consistently slow DNS lookups from
nginx, even though dig shows fast query times.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246001,246070#msg-246070
From noloader at gmail.com Mon Jan 6 20:40:05 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 6 Jan 2014 15:40:05 -0500
Subject: OT: OpenSSL 1.0.1f
Message-ID:
OpenSSL 1.0.1f was released today. It might be a good time to rebuild
all the versions of nginx using static versions of OpenSSL.
There are three CVE remediations included in the release:
CVE-2013-4353, CVE-2013-6449, CVE-2013-6450.
http://www.openssl.org/news/openssl-1.0.1-notes.html.
It does not look like 1.0.1f changed the default behavior of
ENGINE_rdrand (coderman's been following it).
1.0.1f added hostname and email verification routines so programs no
longer have to do it themselves.
There's also an Apple SecureTransport bug workaround. Apple's
SecrureTransport does not properly negotiate ECDHE-ECDSA cipher
suites. It affects Mac OS X and could affect iOS. It might be prudent
to add SSL_OP_SAFARI_ECDHE_ECDSA_BUG by default.
http://www.mail-archive.com/openssl-dev at openssl.org/msg32629.html.
From rob.stradling at comodo.com Mon Jan 6 21:02:36 2014
From: rob.stradling at comodo.com (Rob Stradling)
Date: Mon, 06 Jan 2014 21:02:36 +0000
Subject: OT: OpenSSL 1.0.1f
In-Reply-To:
References:
Message-ID: <52CB19EC.8040201@comodo.com>
On 06/01/14 20:40, Jeffrey Walton wrote:
> There's also an Apple SecureTransport bug workaround. Apple's
> SecrureTransport does not properly negotiate ECDHE-ECDSA cipher
> suites. It affects Mac OS X and could affect iOS. It might be prudent
> to add SSL_OP_SAFARI_ECDHE_ECDSA_BUG by default.
> http://www.mail-archive.com/openssl-dev at openssl.org/msg32629.html.
Nginx doesn't yet support multiple server certs per site (e.g. 1 RSA
cert and 1 ECC cert), so SSL_OP_SAFARI_ECDHE_ECDSA_BUG isn't yet useful.
(I was working on a patch for multiple server certs a few months ago; I
hope to find time to complete this very soon).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
From contact at jpluscplusm.com Mon Jan 6 21:06:46 2014
From: contact at jpluscplusm.com (Jonathan Matthews)
Date: Mon, 6 Jan 2014 21:06:46 +0000
Subject: Very slow dns lookup using proxy_pass
In-Reply-To: <6bf4973420f767174bd74e1a38cf8742.NginxMailingListEnglish@forum.nginx.org>
References: <5fd685a4bea5a8565474e049ed32969d.NginxMailingListEnglish@forum.nginx.org>
<6bf4973420f767174bd74e1a38cf8742.NginxMailingListEnglish@forum.nginx.org>
Message-ID:
On 6 January 2014 20:34, justink101 wrote:
> Consistently slow DNS lookups from
> nginx
I *really* don't think you've demonstrated anything that points to
that conclusion. Do some tcpdump'ing. Show the data. Show your
working. ;-)
J
From luky-37 at hotmail.com Mon Jan 6 22:04:58 2014
From: luky-37 at hotmail.com (Lukas Tribus)
Date: Mon, 6 Jan 2014 23:04:58 +0100
Subject: OT: OpenSSL 1.0.1f
In-Reply-To:
References:
Message-ID:
Hi,
> It does not look like 1.0.1f changed the default behavior of
> ENGINE_rdrand (coderman's been following it).
Yes it did, rdrand is no longer enabled by default. Here [1] is
the backport in the OpenSSL_1_0_1-stable head [2].
At least Debian [3] and Ubuntu backported this as well.
Regards,
Lukas
[1] http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1c2c5e402a757a63d690bd2390bd6b8b491ef184
[2] http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog;h=refs/heads/OpenSSL_1_0_1-stable
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732710
From mdounin at mdounin.ru Tue Jan 7 02:31:36 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 7 Jan 2014 06:31:36 +0400
Subject: How do I disable DNS Caching and DNS Reverse Lookup in Nginx ?
In-Reply-To: <959b925f65dbdba2780e44913888a117.NginxMailingListEnglish@forum.nginx.org>
References: <20140102020701.GB95113@mdounin.ru>
<959b925f65dbdba2780e44913888a117.NginxMailingListEnglish@forum.nginx.org>
Message-ID: <20140107023136.GW95113@mdounin.ru>
Hello!
On Mon, Jan 06, 2014 at 12:35:46PM -0500, linuxr00lz2013 wrote:
> Hello thank you for your reply!
>
> 1) I have shown you the real configuration and logs. All I changed was the
> FQDN's because I dont know if I am allowed by my company to post them
> online.
The problem is that it makes configs and logs unusable for the
purpose of tracing typos and dump misconfigurations like proxy
loops.
General recommendation for those who don't want to show names and
ips in public is to reporoduce a problem in some test environment
instead, and provide real configs and logs from this environment.
> 2) Which tests do you recommend I run using telnet and curl? I am not too
> familiar with using curl so any guidance will be greatly appreciated!
Most trivial test is to do something like:
$ time curl -o /dev/null http://example.com
to see if it show the problem (i.e., if it's slow, and how slow it
is).
--
Maxim Dounin
http://nginx.org/
From rob.stradling at comodo.com Tue Jan 7 09:59:03 2014
From: rob.stradling at comodo.com (Rob Stradling)
Date: Tue, 07 Jan 2014 09:59:03 +0000
Subject: OT: OpenSSL 1.0.1f
In-Reply-To: <52CB19EC.8040201@comodo.com>
References:
<52CB19EC.8040201@comodo.com>
Message-ID: <52CBCFE7.3030906@comodo.com>
On 06/01/14 21:02, Rob Stradling wrote:
> On 06/01/14 20:40, Jeffrey Walton wrote:
>
>> There's also an Apple SecureTransport bug workaround. Apple's
>> SecrureTransport does not properly negotiate ECDHE-ECDSA cipher
>> suites. It affects Mac OS X and could affect iOS. It might be prudent
>> to add SSL_OP_SAFARI_ECDHE_ECDSA_BUG by default.
>> http://www.mail-archive.com/openssl-dev at openssl.org/msg32629.html.
>
> Nginx doesn't yet support multiple server certs per site (e.g. 1 RSA
> cert and 1 ECC cert), so SSL_OP_SAFARI_ECDHE_ECDSA_BUG isn't yet useful.
Actually I suppose that's not strictly true. Setting
SSL_OP_SAFARI_ECDHE_ECDSA_BUG would be useful today on any Nginx server
with an ECC cert and both ECDHE-ECDSA cipher(s) and ECDH-ECDSA cipher(s)
enabled. (I don't suppose there are many such servers!)
> (I was working on a patch for multiple server certs a few months ago; I
> hope to find time to complete this very soon).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
From unixant at gmail.com Tue Jan 7 11:34:42 2014
From: unixant at gmail.com (SmallAnt)
Date: Tue, 7 Jan 2014 19:34:42 +0800
Subject: how to submit my open source nginx module to nginx thrid party modules
Message-ID:
i want to submit my open souce nginx module to
http://wiki.nginx.org/3rdPartyModules, how can i do ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nginx-forum at nginx.us Tue Jan 7 14:04:42 2014
From: nginx-forum at nginx.us (Ensiferous)
Date: Tue, 07 Jan 2014 09:04:42 -0500
Subject: how to submit my open source nginx module to nginx thrid party
modules
In-Reply-To:
References:
Message-ID:
Create an account and just edit the wiki page.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246089,246095#msg-246095
From nginx-forum at nginx.us Tue Jan 7 15:06:56 2014
From: nginx-forum at nginx.us (lodakai)
Date: Tue, 07 Jan 2014 10:06:56 -0500
Subject: Request body in a module
Message-ID: <6e3cdd7044c75bf17bd9837128024425.NginxMailingListEnglish@forum.nginx.org>
Hi, have been trying to read the request body in my module, using the
information I have gotten from this forum and some blogs and basically came
up with the following functions
as can be seen in this post http://forum.nginx.org/read.php?11,245953. The
problem is that the request_body.bufs seem to contain no data.
If I check the request body with the following conf:
log_format my_tracking $request_body;
location /dd {
access_log logs/postdata.log my_tracking;
proxy_pass http://127.0.0.1:8081/temp_service;
}
location /demo {
access_log logs/postdata.log my_tracking;
demo;
}
I get the request_boody logged in the first /dd post request but in the
second /demo I do not get anything logged if I post data
Use the following command the trying it out: curl -v --request POST -d
"a=b" http://localhost:8080/dd
Anyone that have an idea what can be wrong?
Best Regards
Christer
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246098,246098#msg-246098
From coderman at gmail.com Tue Jan 7 17:35:56 2014
From: coderman at gmail.com (coderman)
Date: Tue, 7 Jan 2014 09:35:56 -0800
Subject: OT: OpenSSL 1.0.1f
In-Reply-To:
References:
Message-ID:
On Mon, Jan 6, 2014 at 2:04 PM, Lukas Tribus wrote:
> Hi,
>
>
>> It does not look like 1.0.1f changed the default behavior of
>> ENGINE_rdrand (coderman's been following it).
>
> Yes it did, rdrand is no longer enabled by default. Here [1] is
> the backport in the OpenSSL_1_0_1-stable head [2].
>
> At least Debian [3] and Ubuntu backported this as well.
OpenSSL makes ZERO mention of this fix anywhere in the 1.0.1f release
itself, only the git history itself provides clue. Tor released an
update to intentionally work around this issue with notice to relay
and hidden service operators who may have been affected; Debian and
Ubuntu disabled via backport, and explicitly called this out in their
security errata (thank you all!).
however, debian and ubuntu neglected to mention packages that may have
been affected by generating long lived keys during a vulnerable
configuration (boo!).
in any case, end result: use 1.0.1f and be happy
best regards,
From coderman at gmail.com Tue Jan 7 17:41:19 2014
From: coderman at gmail.com (coderman)
Date: Tue, 7 Jan 2014 09:41:19 -0800
Subject: OT: OpenSSL 1.0.1f
In-Reply-To:
References:
Message-ID:
On Tue, Jan 7, 2014 at 9:35 AM, coderman wrote:
>...
> in any case, end result: use 1.0.1f and be happy
and if concerned that your OS distribution or upstream OpenSSL lacks this fix,
confirm yourself via openssl-1.0.1f/crypto/engine/eng_rdrand.c in patched src
if you see !ENGINE_set_flags(e, ENGINE_FLAGS_NO_REGISTER_ALL)
in the near bottom of file static int bind_helper(ENGINE *e){} definition,
then you are safe from accidental use.
c.f. good ver: openssl-1.0.1f/crypto/engine/eng_rdrand.c
static int bind_helper(ENGINE *e)
{
if (!ENGINE_set_id(e, engine_e_rdrand_id) ||
!ENGINE_set_name(e, engine_e_rdrand_name) ||
!ENGINE_set_flags(e, ENGINE_FLAGS_NO_REGISTER_ALL) ||
!ENGINE_set_init_function(e, rdrand_init) ||
!ENGINE_set_RAND(e, &rdrand_meth) )
return 0;
return 1;
}
From nginx-forum at nginx.us Tue Jan 7 19:43:19 2014
From: nginx-forum at nginx.us (itpp2012)
Date: Tue, 07 Jan 2014 14:43:19 -0500
Subject: OT: OpenSSL 1.0.1f
In-Reply-To:
References:
Message-ID: <512120c3cad216d4e8532c01fa7d95de.NginxMailingListEnglish@forum.nginx.org>
1.0.1f against 1.5.9 mainline (today);
ecp_nistputil.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
ecp_nistp521.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
ecp_nistp256.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
ecp_nistp224.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
fips_ers.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
.\ssl\s23_clnt.c(286) : warning C4244: 'initializing' : conversion from
'time_t' to 'unsigned long', possible loss of data
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246071,246108#msg-246108
From nginx-forum at nginx.us Tue Jan 7 23:02:38 2014
From: nginx-forum at nginx.us (justink101)
Date: Tue, 07 Jan 2014 18:02:38 -0500
Subject: proxy_pass check if 404, and return 404
Message-ID: <8d777d0738bdfd772d375cc2868004f4.NginxMailingListEnglish@forum.nginx.org>
I am using proxy_pass to a dynamic subdomain:
proxy_pass https://$remote_user.mydomain.io
Is it possible to have the proxy_pass check if the response of
https://$remote_user.mydomain.io is 404, if so, simply do:
return 404;
I.E. don't proxy, immediately return.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246112,246112#msg-246112
From contact at jpluscplusm.com Tue Jan 7 23:57:15 2014
From: contact at jpluscplusm.com (Jonathan Matthews)
Date: Tue, 7 Jan 2014 23:57:15 +0000
Subject: proxy_pass check if 404, and return 404
In-Reply-To: <8d777d0738bdfd772d375cc2868004f4.NginxMailingListEnglish@forum.nginx.org>
References: <8d777d0738bdfd772d375cc2868004f4.NginxMailingListEnglish@forum.nginx.org>
Message-ID:
The *only* context I can see this being even slightly useful is where
you are concerned about the unacceptably large size of the upstream
server's 404 page.
If this isn't your problem, I don't understand what you're trying to solve.
From contact at jpluscplusm.com Wed Jan 8 00:10:16 2014
From: contact at jpluscplusm.com (Jonathan Matthews)
Date: Wed, 8 Jan 2014 00:10:16 +0000
Subject: proxy_pass check if 404, and return 404
In-Reply-To:
References: <8d777d0738bdfd772d375cc2868004f4.NginxMailingListEnglish@forum.nginx.org>
Message-ID:
On 7 January 2014 23:57, Jonathan Matthews wrote:
> The *only* context I can see this being even slightly useful is where
> you are concerned about the unacceptably large size of the upstream
> server's 404 page.
>
> If this isn't your problem, I don't understand what you're trying to solve.
Either way, I should have said, look at the error_page directive.
HTH,
J
From vbart at nginx.com Wed Jan 8 04:21:15 2014
From: vbart at nginx.com (Valentin V. Bartenev)
Date: Wed, 08 Jan 2014 08:21:15 +0400
Subject: proxy_pass check if 404, and return 404
In-Reply-To:
References: <8d777d0738bdfd772d375cc2868004f4.NginxMailingListEnglish@forum.nginx.org>
Message-ID: <1862675.szrVqdqnOr@vbart-laptop>
On Wednesday 08 January 2014 00:10:16 Jonathan Matthews wrote:
> On 7 January 2014 23:57, Jonathan Matthews wrote:
> > The *only* context I can see this being even slightly useful is where
> > you are concerned about the unacceptably large size of the upstream
> > server's 404 page.
> >
> > If this isn't your problem, I don't understand what you're trying to
> > solve.
>
> Either way, I should have said, look at the error_page directive.
..and "proxy_intercept_errors".
http://nginx.org/r/proxy_intercept_errors
wbr, Valentin V. Bartenev
From appa at perusio.net Wed Jan 8 08:11:43 2014
From: appa at perusio.net (=?ISO-8859-1?Q?Ant=F3nio_P=2E_P=2E_Almeida?=)
Date: Wed, 8 Jan 2014 09:11:43 +0100
Subject: Problem trying to rewrite a URL
In-Reply-To:
References:
Message-ID:
AFAIK nginx has no directive for unescaping URLs. You could do it with Lua
or go down a messy path of map directives listing all arguments with
permutations.
Rather what you need to do is fix your application so that it accepts
escaped URLs. They're standard and there's no reason why it shouldn't IMO.
Le 6 janv. 2014 05:55, "hoidulich" a ?crit :
> Hi all,
>
> I have a problem trying to rewrite a URL.
>
> It should be pretty straightforward but it has been taking me hours
> searching.
>
> Google indexed urls containing ";", which gets escaped to %3b:
>
> http://hoidulich.com/index.php?action=tagged%3bid=254715%3btag=vietholiday
> (the original url that works is
> http://hoidulich.com/index.php?action=tagged;id=254715;tag=vietholiday)
>
> How can I fix it?
> Thank you very much.
> Cao Tri.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,246052,246052#msg-246052
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From chalx.chalx at gmail.com Wed Jan 8 09:07:50 2014
From: chalx.chalx at gmail.com (chAlx)
Date: Wed, 08 Jan 2014 13:07:50 +0400
Subject: Empty error log
Message-ID: <52CD1566.5050506@gmail.com>
I have installed Nginx for a small web server with static content. It works fine but the site error log file is always empty. All errors such as 404 are written to the access log only. File grants are the same for access and error logs.
I've tried to change error_log param from "error" to "warn" and that didn't help. But changing it to "debug" was successful: log was filled with debug info (but no error info).
My config files:
/etc/nginx/nginx.conf:
user www;
worker_processes 2;
pid /var/run/nginx.pid;
events {
worker_connections 768;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
server_tokens off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
gzip_disable "msie6";
gzip_min_length 200;
gzip_types text/plain text/css application/json
application/x-javascript text/xml application/xml application/xml+rss
text/javascript application/rdf+xml;
include/etc/nginx/conf.d/*.conf; # None
include/etc/nginx/sites-enabled/*; # One
}
/etc/nginx/sites-available/mysite.conf:
server {
listen 80;
root /var/www/mysite;
index index.html index.htm;
server_name mysite.org;
access_log /var/log/nginx/mysite_access.log combined;
error_log /var/log/nginx/mysite_error.log error;
log_subrequest on;
location / {
try_files $uri $uri/ =404;
autoindex off;
}
}
From vbart at nginx.com Wed Jan 8 09:19:15 2014
From: vbart at nginx.com (Valentin V. Bartenev)
Date: Wed, 08 Jan 2014 13:19:15 +0400
Subject: Empty error log
In-Reply-To: <52CD1566.5050506@gmail.com>
References: <52CD1566.5050506@gmail.com>
Message-ID: <6095750.regsHMoXXa@vbart-laptop>
On Wednesday 08 January 2014 13:07:50 chAlx wrote:
> I have installed Nginx for a small web server with static content. It works
> fine but the site error log file is always empty. All errors such as 404
> are written to the access log only. File grants are the same for access and
> error logs.
>
> I've tried to change error_log param from "error" to "warn" and that didn't
> help. But changing it to "debug" was successful: log was filled with debug
> info (but no error info).
>
> My config files:
[..]
> /etc/nginx/sites-available/mysite.conf:
>
> server {
> listen 80;
> root /var/www/mysite;
> index index.html index.htm;
> server_name mysite.org;
> access_log /var/log/nginx/mysite_access.log combined;
> error_log /var/log/nginx/mysite_error.log error;
> log_subrequest on;
> location / {
> try_files $uri $uri/ =404;
You should remove "try_files" directive if you want to see file access errors
in the error log.
wbr, Valentin V. Bartenev
From nginx-forum at nginx.us Wed Jan 8 09:22:40 2014
From: nginx-forum at nginx.us (rrrrcccc)
Date: Wed, 08 Jan 2014 04:22:40 -0500
Subject: How to combine try_files with multiple proxy destinations
Message-ID: <552e6b2529a268dc7b6ac5138e88128f.NginxMailingListEnglish@forum.nginx.org>
I have the folllowing requirement:
1. if /usr/share/nginx/html/maintenance.html exists, then always show this
file to browser.
2. if this is the static file which located in the sub-directories of
/usr/share/nginx/html/, then show this static file to browser.
3. if the URI begins with /testapp1/, then proxy to http://127.0.0.1:8080;
else proxy to http://127.0.0.1:8081
And I tried the following two configurations but both failed:
1. Config1
server {
...
root /usr/share/nginx/html/;
location / {
try_files /maintenance.html $uri @proxy;
}
location @proxy {
location /testapp/ {
proxy_pass http://127.0.0.1:8080;
}
location / {
proxy_pass http://127.0.0.1:8081
}
}
}
2. Config2
server {
...
root /usr/share/nginx/html/;
try_files /maintenance.html $uri @proxy;
location /testapp/ {
proxy_pass http://127.0.0.1:8080;
}
location / {
proxy_pass http://127.0.0.1:8081
}
}
For Config1, it throws the following error:
nginx: [emerg] location "/testapp/" cannot be inside the named location
"@proxy" in /etc/nginx/nginx.conf:41
For Config2, it does not work as expected: it seems that when try_files is
together with location directives, try_file has the lowerest priority and so
I can never get /maintenance.html shown.
So can anybody know how to config to meet my requirement ? Thanks in
advance!
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246125,246125#msg-246125
From artemrts at ukr.net Wed Jan 8 09:33:11 2014
From: artemrts at ukr.net (wishmaster)
Date: Wed, 08 Jan 2014 11:33:11 +0200
Subject: Empty error log
In-Reply-To: <52CD1566.5050506@gmail.com>
References: <52CD1566.5050506@gmail.com>
Message-ID: <1389173228.461303469.bne02fn8@frv34.ukr.net>
--- Original message ---
From: "chAlx"
Date: 8 January 2014, 11:08:35
> I have installed Nginx for a small web server with static content. It works fine but the site error log file is always empty. All errors such as 404 are written to the access log only. File grants are the same for access and error logs.
>
> I've tried to change error_log param from "error" to "warn" and that didn't help. But changing it to "debug" was successful: log was filled with debug info (but no error info).
>
> My config files:
>
>
> /etc/nginx/nginx.conf:
>
> user www;
> worker_processes 2;
> pid /var/run/nginx.pid;
>
> events {
> worker_connections 768;
> }
>
> http {
> sendfile on;
> tcp_nopush on;
> tcp_nodelay on;
> keepalive_timeout 65;
> types_hash_max_size 2048;
> server_tokens off;
> include /etc/nginx/mime.types;
> default_type application/octet-stream;
> access_log /var/log/nginx/access.log;
> error_log /var/log/nginx/error.log;
> gzip on;
> gzip_disable "msie6";
> gzip_min_length 200;
> gzip_types text/plain text/css application/json
> application/x-javascript text/xml application/xml application/xml+rss
> text/javascript application/rdf+xml;
>
> include/etc/nginx/conf.d/*.conf; # None
> include/etc/nginx/sites-enabled/*; # One
> }
>
>
> /etc/nginx/sites-available/mysite.conf:
>
> server {
> listen 80;
> root /var/www/mysite;
> index index.html index.htm;
> server_name mysite.org;
> access_log /var/log/nginx/mysite_access.log combined;
> error_log /var/log/nginx/mysite_error.log error;
> log_subrequest on;
> location / {
> try_files $uri $uri/ =404;
> autoindex off;
> }
Use try_files if you need rewriting rules.
E.g. http://myshop.com/goods/foo/bar need to be rewritten in /index.php?router=goods/foo/bar and passed to php-server.
From nginx-forum at nginx.us Wed Jan 8 10:08:22 2014
From: nginx-forum at nginx.us (itpp2012)
Date: Wed, 08 Jan 2014 05:08:22 -0500
Subject: OT: OpenSSL 1.0.1f
In-Reply-To: <512120c3cad216d4e8532c01fa7d95de.NginxMailingListEnglish@forum.nginx.org>
References:
<512120c3cad216d4e8532c01fa7d95de.NginxMailingListEnglish@forum.nginx.org>
Message-ID: <7d25f3c0d938f0110e6f367f80f881f4.NginxMailingListEnglish@forum.nginx.org>
itpp2012 Wrote:
-------------------------------------------------------
> 1.0.1f against 1.5.9 mainline (today);
>
> .\ssl\s23_clnt.c(286) : warning C4244: 'initializing' : conversion
> from 'time_t' to 'unsigned long', possible loss of data
Also found by http://rt.openssl.org/Ticket/Display.html?id=3220
and fixed in .\ssl\s23_clnt.c(line 286):
[...]
int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
len)
[...]
if (send_time)
{
// unsigned long Time = time(NULL);
unsigned long Time = (unsigned long)time(NULL);
unsigned char *p = result;
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246071,246128#msg-246128
From chencw1982 at gmail.com Wed Jan 8 14:49:33 2014
From: chencw1982 at gmail.com (Chuanwen Chen)
Date: Wed, 8 Jan 2014 22:49:33 +0800
Subject: [ANNOUNCE] Tengine-2.0.0 is released
Message-ID:
Hi folks,
We are glad to announce that Tengine-2.0.0 (development version) has been
released. You can either checkout the source code from GitHub:
https://github.com/alibaba/tengine or download the tarball directly:
http://tengine.taobao.org/download/tengine-2.0.0.tar.gz
The highlights of this release are support for SPDY v3 (flow control), and
enhanced DSO module.
Tengine is now based on Nginx-1.4.4.
The full changelog is as follows:
*) Feature: now DSO module does not need the original source code or
compiler options when compiling a new module. (monadbobo)
*) Feature: added support for SPDY v3, and SPDY/HTTP servers can listen on
the same port. (lilbedwin?chobits)
*) Feature: added support for setting retries for upstream servers (proxy,
memcached, fastcgi, scgi, uwsgi). (supertcy)
*) Feature: now tfs module can report access status to rcs while keepalive.
(zhcn381)
*) Feature: now the directive "if" supports ">", "=", "<=" operators
for numeric comparison. (flygoast)
*) Feature: now upstream health check module uses keep-alive connections.
(lilbedwin)
*) Feature: now trim module can handle SSI and ESI comments properly.
(taoyuanyuan)
*) Feature: now directive "expires_by_types" supports wildcard such as
"text/*". (zhcn381)
*) Feature: added variables starting with "$base64_decode_" to encode
variables in base64. (yzprofile)
*) Feature: added variables starting with "$md5_encode_" to encode
variables in md5. (yzprofile)
*) Feature: added a variable "$time_http" to get the current HTTP time.
(flygoast)
*) Feature: added a variable "$full_request" to get the original request
URL with scheme and host. (yzprofile)
*) Feature: added variables starting with "$escape_uri_" to escape
variables into formal URL syntax. (yzprofile)
*) Feature: added a variable "$raw_uri" to get the original URI without
arguments. (flygoast)
*) Feature: added support for logging subrequests in nanoseconds. (jinglong)
*) Feature: added a new API function to encode URL into base64. (lilbedwin)
*) Change: merged changes between nginx-1.2.9 and nginx-1.4.4. (cfsego)
*) Change: now stub_status module does not log subrequests. (jinglong)
*) Bugfix: fixed a bug in footer module when reading a response with a
"Content-Encoding" header. (yaoweibin)
*) Bugfix: fixed a bug when "client_body_postpone_size" is set to 0.
(yaoweibin)
*) Bugfix: fixed a compilation warning of Lua module. (diwayou)
For those who don't know Tengine, it is a free and open source distribution
of Nginx with some advanced features. See our website for more details:
http://tengine.taobao.org
Have fun!
Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From j at jonathanleighton.com Wed Jan 8 14:57:18 2014
From: j at jonathanleighton.com (Jon Leighton)
Date: Wed, 08 Jan 2014 14:57:18 +0000
Subject: proxy_cache incorrectly returning 304 Not Modified
Message-ID: <52CD674E.5080007@jonathanleighton.com>
Hi there,
I work on a site which has nginx in front of a Rails application, and we
use proxy_cache.
For the home page, our application returns a "max-age=600, public"
Cache-Control header, and we have nginx configured to cache the response
using proxy_cache.
This generally works fine, but last night nginx started to respond with
304 Not Modified to requests that *didn't* include any caching headers
(If-Modified-Since or ETag). Our Pingdom alerts showed this issue, and
here is the request/response captured:
GET / HTTP/1.0
User-Agent: Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)
Host: loco2.com
304 Not Modified
Cache-Control: max-age=600, public
Date: Tue, 07 Jan 2014 22:59:32 GMT
ETag: "900e1f11422519337c9ed25fad299ce0"
Server: nginx/1.4.4
Status: 304 Not Modified
Strict-Transport-Security: max-age=31536000
X-Cache-Status: HIT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: c7ee78ab-df49-4467-bced-753b2cc622ab
X-UA-Compatible: chrome=1
X-XSS-Protection: 1; mode=block
Connection: Close
Does this look like a bug? Or could it be a configuration issue? I can't
think of any reason why this should be the correct thing for the proxy
cache to do.
Many thanks,
Jon
--
http://jonathanleighton.com/
From denis.papathanasiou at gmail.com Thu Jan 9 01:15:47 2014
From: denis.papathanasiou at gmail.com (Denis Papathanasiou)
Date: Wed, 8 Jan 2014 20:15:47 -0500
Subject: Time out errors using uwsgi with ngnix on debian 7 (wheezy)
Message-ID:
I've installed nginx via apt, using the nginx stable pkg as described here:
http://nginx.org/en/linux_packages.html#stable
It works perfectly for serving static files using the default configuration.
Next, I installed uwsgi from source, as described here:
https://pypi.python.org/pypi/uWSGI/1.2.3
When I do the steps in the python quickstart guide --
http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html -- and open
my browser to localhost:9090, everything works as expected.
When I change the nginx config file to use uwsgi_pass to localhost:9090 as
described here --
http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html#putting-behind-a-full-webserver--
however, I get time out errors:
> upstream timed out (110: Connection timed out) while reading response
header from upstream
It is as though nginx is *not* passing those requests to the uwsgi process
(which is still running).
Here is the content of server{ } inside the nginx config file:
location / {
include uwsgi_params;
uwsgi_pass localhost:9090;
}
Any ideas on what the problem might be?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nanotek at bsdbox.co Thu Jan 9 04:57:43 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 15:57:43 +1100
Subject: "Primary script unknown" wp-login.php
Message-ID: <52CE2C47.8080905@bsdbox.co>
As subject says: I cannot access wp-admin due to above [error].
Otherwise, site functions as it should.
See error log:
2014/01/09 04:31:23 [error] 35759#0: *5254 FastCGI sent in stderr:
"Primary script unknown" while reading response header from upstream,
client: ipaddress, server: hostname, request: "GET
/wordpress/wp-login.php HTTP/1.1", upstream:
"fastcgi://unix:/var/run/php-fpm.sock:", host: "hostname", referrer:
"http://hostname/"
See access.log
[09/Jan/2014:04:31:23 +0000] "GET /wordpress/wp-login.php HTTP/1.1" 404
27 "hostname" "useragent" "-"
See nginx.conf
user www;
worker_processes 1;
error_log logs/error.log info;
pid /var/run/nginx.pid;
events {
worker_connections 768;
}
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 off;
keepalive_timeout 65;
gzip off;
server {
listen 80;
listen 443 ssl;
server_name hostname;
root /usr/local/www;
ssl_certificate /path/to/crt-chain.pem;
ssl_certificate_key /path/to/privatekey.pem;
ssl_dhparam /pth/to/dhparam4096.pem;
server_name hostname www.hostnam;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW
!3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
ssl_prefer_server_ciphers on;
access_log logs/access.log main;
charset utf-8;
location / {
root /usr/local/www/wordpress;
try_files $uri $uri/ /index.php?q=$uri&$args;
index index.php index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/www/nginx-dist;
}
location ~ \.(js|css|png|jpg|jpeg|gif|ico|html)$ {
expires max;
}
location ~ \.php$ {
root html;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
/usr/local/www/wordpress$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
}
}
See fastcgi_params:
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 SCRIPT_NAME $fastcgi_script_name;
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 HTTPS $https if_not_empty;
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_param REDIRECT_STATUS 200;
Please advise my mistake and how to fix. Thank you.
From aidan at aodhandigital.com Thu Jan 9 05:16:52 2014
From: aidan at aodhandigital.com (Aidan Scheller)
Date: Wed, 8 Jan 2014 23:16:52 -0600
Subject: OT: OpenSSL 1.0.1f
In-Reply-To: <7d25f3c0d938f0110e6f367f80f881f4.NginxMailingListEnglish@forum.nginx.org>
References:
<512120c3cad216d4e8532c01fa7d95de.NginxMailingListEnglish@forum.nginx.org>
<7d25f3c0d938f0110e6f367f80f881f4.NginxMailingListEnglish@forum.nginx.org>
Message-ID:
Does using the --with-openssl-opt="enable-ec_nistp_64_gcc_128"
configure parameter without the *--with-openssl *cause a static version of
OpenSSL to be created for Nginx? I'm unsure as the configuration summary
then lists that the system library is being used.
Thanks,
Aidan
On Wed, Jan 8, 2014 at 4:08 AM, itpp2012 wrote:
> itpp2012 Wrote:
> -------------------------------------------------------
> > 1.0.1f against 1.5.9 mainline (today);
> >
> > .\ssl\s23_clnt.c(286) : warning C4244: 'initializing' : conversion
> > from 'time_t' to 'unsigned long', possible loss of data
>
> Also found by http://rt.openssl.org/Ticket/Display.html?id=3220
> and fixed in .\ssl\s23_clnt.c(line 286):
>
> [...]
> int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
> len)
> [...]
> if (send_time)
> {
> // unsigned long Time = time(NULL);
> unsigned long Time = (unsigned long)time(NULL);
> unsigned char *p = result;
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,246071,246128#msg-246128
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nginx-forum at nginx.us Thu Jan 9 05:52:16 2014
From: nginx-forum at nginx.us (humank)
Date: Thu, 09 Jan 2014 00:52:16 -0500
Subject: How do i get the request body ?
In-Reply-To: <20140103034033.GE95113@mdounin.ru>
References: <20140103034033.GE95113@mdounin.ru>
Message-ID: <5e58bfc08ec754417e22eb054208bfe3.NginxMailingListEnglish@forum.nginx.org>
Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
>
> On Wed, Jan 01, 2014 at 11:44:24PM -0500, humank wrote:
>
> > Hello guys,
> >
> > I'm developing a nginx module, the intent is to get the
> request
> > body, then write some response depends on what request body is.
> > I've called the method ngx_http_read_client_request_body (r,
> > ngx_http_myModule_handler);
> >
> > Since this code, i want to get the real request body in
> > ngx_http_myModule_handler()
> > Here are my codes ...
> >
> > void ngx_http_myModule_handler(ngx_http_request_t *r)
> > {
> > ngx_http_finalize_request(r, NGX_DONE);
> >
> > if(!(r->request_body->bufs == NULL)){
> > ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "request
> is not
> > empty.");
> >
> > }
> > }
> >
> > the questions is , how can i get the r->request_body->bufs to
> char * ?
>
> A request body is available as a series of
> buffers in r->request_body->bufs. To understand more about
> buffers, try reading Evan Miller's guide as available from here:
>
> http://www.evanmiller.org/nginx-modules-guide.html
>
> Some example code which uses r->request_body->bufs to access
> request body contents as available in memory can be found in
> src/http/ngx_http_variables.c, in the
> ngx_http_variable_request_body() function.
>
> Note though, that depending on a configuration and a request, the
> request body may not be available in memory at all (that is, it
> will be in temporary file, and there will be a file buffer in
> r->request_body->bufs).
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
Hi Maxim,
Thanks for your reply, i have get the body from the sample code
src/http/ngx_http_variables.c.
Next time i will try to grep all the source code first while facing the
unknown problems :D
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245952,246137#msg-246137
From nginx-forum at nginx.us Thu Jan 9 08:51:26 2014
From: nginx-forum at nginx.us (itpp2012)
Date: Thu, 09 Jan 2014 03:51:26 -0500
Subject: OT: OpenSSL 1.0.1f
In-Reply-To:
References:
Message-ID:
Aidan Scheller Wrote:
-------------------------------------------------------
> Does using the --with-openssl-opt="enable-ec_nistp_64_gcc_128"
> configure parameter without the *--with-openssl *cause a static
> version of
> OpenSSL to be created for Nginx? I'm unsure as the configuration
> summary
> then lists that the system library is being used.
Who is reporting which lib is used? openssl is compiled independently as
part of the nginx build process where you can choose a static or dynamic
build. What options does openssl makefile have after configure?
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246071,246138#msg-246138
From Pekka.Panula at sofor.fi Thu Jan 9 09:29:11 2014
From: Pekka.Panula at sofor.fi (Pekka.Panula at sofor.fi)
Date: Thu, 9 Jan 2014 11:29:11 +0200
Subject: SSL ciphers, disable or not to disable RC4?
Message-ID:
Hi
My current values in my nginx configuration for ssl_protocols/ciphers what
i use is this:
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
What are todays recommendations for ssl_ciphers option for supporting all
current OSes and browsers, even Windows XP users with IE?
Can i disable RC4?
My nginx is compiled with OpenSSL v1.0.1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nanotek at bsdbox.co Thu Jan 9 09:42:04 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 20:42:04 +1100
Subject: SSL ciphers, disable or not to disable RC4?
In-Reply-To:
References:
Message-ID: <52CE6EEC.10609@bsdbox.co>
On 9/01/2014 8:29 PM, Pekka.Panula at sofor.fi wrote:
> Hi
>
> My current values in my nginx configuration for ssl_protocols/ciphers
> what i use is this:
>
> ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
> ssl_ciphers RC4:HIGH:!aNULL:!MD5;
> ssl_prefer_server_ciphers on;
>
> What are todays recommendations for ssl_ciphers option for supporting
> all current OSes and browsers, even Windows XP users with IE?
> Can i disable RC4?
>
> My nginx is compiled with OpenSSL v1.0.1.
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
The current consensus suggests that mitigating RC4 vulnerabilities is
more important than BEAST attack concerns, which are all but mitigated
client-side. If you want to deploy protocols to cater for a wide range
of browsers (including XP IE) implement the following (that will
fall-back to RC4 as a last resort):
ssl_ciphers EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS
+RC4 RC4
Otherwise, exclude RC4 with the following:
ssl_ciphers EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4
--
syn.bsdbox.co
From noloader at gmail.com Thu Jan 9 09:52:35 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 9 Jan 2014 04:52:35 -0500
Subject: SSL ciphers, disable or not to disable RC4?
In-Reply-To:
References:
Message-ID:
On Thu, Jan 9, 2014 at 4:29 AM, wrote:
> Hi
>
> My current values in my nginx configuration for ssl_protocols/ciphers what i
> use is this:
>
> ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
> ssl_ciphers RC4:HIGH:!aNULL:!MD5;
> ssl_prefer_server_ciphers on;
>
> What are todays recommendations for ssl_ciphers option for supporting all
> current OSes and browsers, even Windows XP users with IE?
> Can i disable RC4?
>
The paper of interest is from AlFardan, Bernstein, et al: "On the
Security of RC4 in TLS and WPA"
(http://cr.yp.to/streamciphers/rc4biases-20130708.pdf?). From the
paper:
... While the RC4 algorithm is known to have a
variety of cryptographic weaknesses (see [26]
for an excellent survey), it has not been previously
explored how these weaknesses can be exploited
in the context of TLS. Here we show that new and
recently discovered biases in the RC4 keystream
do create serious vulnerabilities in TLS when using
RC4 as its encryption algorithm.
I don't believe there's a need for SSLv3 anymore either. TLSv1.0 is
pretty much ubiquitous, and its at nearly 100% for modern browser,
clients and servers.
https://en.wikipedia.org/wiki/Transport_Layer_Security#Applications_and_adoption.
You also migth want to include "!eNULL:!ADH:!ECADH:!MEDIUM:!LOW:!EXP'.
eNULL is great for performance, but it has a few problems for privacy.
From luky-37 at hotmail.com Thu Jan 9 09:53:03 2014
From: luky-37 at hotmail.com (Lukas Tribus)
Date: Thu, 9 Jan 2014 10:53:03 +0100
Subject: SSL ciphers, disable or not to disable RC4?
In-Reply-To:
References:
Message-ID:
Hi,
> My current values in my nginx configuration for ssl_protocols/ciphers
> what i use is this:
>
> ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
> ssl_ciphers RC4:HIGH:!aNULL:!MD5;
> ssl_prefer_server_ciphers on;
>
> What are todays recommendations for ssl_ciphers option for supporting
> all current OSes and browsers, even Windows XP users with IE?
> Can i disable RC4?
Personally, I'm following Mozillas deployment recommendations:
https://wiki.mozilla.org/Security/Server_Side_TLS
Regards,
Lukas
From black.fledermaus at arcor.de Thu Jan 9 10:03:11 2014
From: black.fledermaus at arcor.de (basti)
Date: Thu, 09 Jan 2014 11:03:11 +0100
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
Message-ID: <52CE73DF.80200@arcor.de>
Hello,
I have a closed-source Webapp that run on an IIS-Webserver and send a
"X-Frame-Options: SAMEORIGIN" header.
I also have to implement this Webapp in my own, Frame based Application.
So I try to use nginx as a reverse Proxy, but the X-Frame-Options Header
is still send.
How can I remove his header?
I have try "proxy_hide_header X-Frame-Options;" without success.
Regards,
Basti
From noloader at gmail.com Thu Jan 9 10:04:29 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 9 Jan 2014 05:04:29 -0500
Subject: SSL ciphers, disable or not to disable RC4?
In-Reply-To:
References:
Message-ID:
On Thu, Jan 9, 2014 at 4:53 AM, Lukas Tribus wrote:
>> My current values in my nginx configuration for ssl_protocols/ciphers
>> what i use is this:
>>
>> ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>> ssl_ciphers RC4:HIGH:!aNULL:!MD5;
>> ssl_prefer_server_ciphers on;
>>
>> What are todays recommendations for ssl_ciphers option for supporting
>> all current OSes and browsers, even Windows XP users with IE?
>> Can i disable RC4?
>
> Personally, I'm following Mozillas deployment recommendations:
> https://wiki.mozilla.org/Security/Server_Side_TLS
Mozilla claims RC4 is "High Grade" encryption even though it has
serious vulnerabilities when used in TLS
(https://bugzilla.mozilla.org/show_bug.cgi?id=947149). They remove
3-key TDEA with 112-bits of security (which is currently approved by
ECRYPT, ISO/IEC, NIST, and NESSIE).
Related, their browser claim plain text HTTP is good (no user
warnings), and HTTPS with a self signed is bad (big red flags for
opportunistic encryption). When did plain text become better than
cipher text? And they also rewarded Trustwave's bad behavior way back
when (https://bugzilla.mozilla.org/show_bug.cgi?id=724929).
I'm not sure I would follow Mozilla's lead.
Jeff
From noloader at gmail.com Thu Jan 9 10:04:31 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 9 Jan 2014 05:04:31 -0500
Subject: SSL ciphers, disable or not to disable RC4?
In-Reply-To:
References:
Message-ID:
On Thu, Jan 9, 2014 at 4:53 AM, Lukas Tribus wrote:
>> My current values in my nginx configuration for ssl_protocols/ciphers
>> what i use is this:
>>
>> ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>> ssl_ciphers RC4:HIGH:!aNULL:!MD5;
>> ssl_prefer_server_ciphers on;
>>
>> What are todays recommendations for ssl_ciphers option for supporting
>> all current OSes and browsers, even Windows XP users with IE?
>> Can i disable RC4?
>
> Personally, I'm following Mozillas deployment recommendations:
> https://wiki.mozilla.org/Security/Server_Side_TLS
Mozilla claims RC4 is "High Grade" encryption even though it has
serious vulnerabilities when used in TLS
(https://bugzilla.mozilla.org/show_bug.cgi?id=947149). They remove
3-key TDEA with 112-bits of security (which is currently approved by
ECRYPT, ISO/IEC, NIST, and NESSIE).
Related, their browser claim plain text HTTP is good (no user
warnings), and HTTPS with a self signed is bad (big red flags for
opportunistic encryption). When did plain text become better than
cipher text? And they also rewarded Trustwave's bad behavior way back
when (https://bugzilla.mozilla.org/show_bug.cgi?id=724929).
I'm not sure I would follow Mozilla's lead.
Jeff
From contact at jpluscplusm.com Thu Jan 9 10:21:43 2014
From: contact at jpluscplusm.com (Jonathan Matthews)
Date: Thu, 9 Jan 2014 10:21:43 +0000
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <52CE73DF.80200@arcor.de>
References: <52CE73DF.80200@arcor.de>
Message-ID:
On 9 January 2014 10:03, basti wrote:
> Hello,
>
> I have a closed-source Webapp that run on an IIS-Webserver and send a
> "X-Frame-Options: SAMEORIGIN" header.
> I also have to implement this Webapp in my own, Frame based Application.
>
> So I try to use nginx as a reverse Proxy, but the X-Frame-Options Header
> is still send.
> How can I remove his header?
> I have try "proxy_hide_header X-Frame-Options;" without success.
You'll find the answer in the documentation:
http://wiki.nginx.org/NginxHttpProxyModule#proxy_set_header
J
From nanotek at bsdbox.co Thu Jan 9 10:23:56 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 21:23:56 +1100
Subject: PHP below server root not served
In-Reply-To:
References:
Message-ID: <52CE78BC.7050500@bsdbox.co>
I am having trouble configuring nginx to serve up PHP from outside of
the server document root. For example, this site's root is
/usr/local/www/site1/wordpress and phpMyAdmin is located in
/usr/local/www/phpMyAdmin. I cannot access servername.com/phpmyadmin.
nginx logs the following error:
====================================================================
2014/01/09 09:56:20 [error] 39387#0: *6160 FastCGI sent in stderr:
"Primary script unknown" while reading response header from upstream,
client: clientIP, server: serverhostname, request: "GET /phpmyadmin/
HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host:
"serverhostname"
====================================================================
The WordPress site, however, is served without error. Therefore, nginx
is refusing to serve PHP from outside of the server document root.
Please see the following configuration:
nginx.conf
====================================================================
user www www;
worker_processes 1;
pid /var/run/nginx.pid;
error_log logs/error.log info;
events {
worker_connections 768;
use kqueue;
}
http {
include mime.types;
default_type application/octet-stream;
access_log logs/access.log main;
sendfile on;
keepalive_timeout 65;
gzip on;
server {
listen 80;
listen 443 ssl;
server_name servername.com;
ssl_certificate crt-chain.pem;
ssl_certificate_key key.pem;
ssl_dhparam dhparam4096.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !a
NULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
ssl_prefer_server_ciphers on;
root /usr/local/www/site1/wordpress;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME
/usr/local/www/site1/wordpress$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}
#----------------------PROBLEM AREA----------------------#
location /phpmyadmin/ {
alias /usr/local/www/phpMyAdmin/;
index index.php index.html;
}
location ~ ^/phpmyadmin/(.*\.php)$ {
fastcgi_param PHP_ADMIN_VALUE
open_basedir=/usr/local/www/phpMyAdmin;
fastcgi_pass unix:/tmp/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
/usr/local/www/phpMyAdmin$fastcgi_script_name;
include fastcgi_params;
#----------------------PROBLEM AREA----------------------#
}
}
}
====================================================================
I am obviously lacking some required configuration. Perhaps in
nginx.conf, php-fpm.conf, or php.ini. Could someone please advise me of
my error and how to correct it? Thank you.
Strangely, in Apache, I simply required an alias entry, such as:
Alias /phpmyadmin "/usr/local/www/phpMyAdmin"
Options None
AllowOverride None
Require all granted
in my httpd.conf file even when the server root was above this location
and with the exact same PHP settings (php.ini) as I now have with nginx.
Server intel:
# uname -a
FreeBSD hostname 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26
22:50:31 UTC 2013
root at bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
# nginx -V
nginx version: nginx/1.5.7
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx-error.log --user=www --group=www
--with-ipv6 --with-google_perftools_module
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx-access.log --with-http_addition_module
--with-http_auth_request_module --with-http_dav_module
--with-http_flv_module --with-http_geoip_module
--with-http_gzip_static_module --with-http_gunzip_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_sub_module
--with-http_xslt_module --with-pcre --with-http_spdy_module --with-mail
--with-mail_ssl_module --with-http_ssl_module
--
syn.bsdbox.co
From r1ch+nginx at teamliquid.net Thu Jan 9 10:27:58 2014
From: r1ch+nginx at teamliquid.net (Richard Stanway)
Date: Thu, 9 Jan 2014 11:27:58 +0100
Subject: PHP below server root not served
In-Reply-To: <52CE78BC.7050500@bsdbox.co>
References:
<52CE78BC.7050500@bsdbox.co>
Message-ID:
> fastcgi_pass unix:/tmp/php-fpm.sock;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME
> /usr/local/www/phpMyAdmin$fastcgi_script_name;
> include fastcgi_params;
>
What's in your fastcgi_params? Is it overriding your SCRIPT_FILENAME perhaps?
From nanotek at bsdbox.co Thu Jan 9 10:32:12 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 21:32:12 +1100
Subject: PHP below server root not served
In-Reply-To:
References: <52CE78BC.7050500@bsdbox.co>
Message-ID: <52CE7AAC.7030205@bsdbox.co>
On 9/01/2014 9:27 PM, Richard Stanway wrote:
>> fastcgi_pass unix:/tmp/php-fpm.sock;
>> fastcgi_index index.php;
>> fastcgi_param SCRIPT_FILENAME
>> /usr/local/www/phpMyAdmin$fastcgi_script_name;
>> include fastcgi_params;
>>
>
> What's in your fastcgi_params? Is it overriding your SCRIPT_FILENAME perhaps?
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
Thanks for replying. Here is my fastcgi_params file:
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 SCRIPT_NAME $fastcgi_script_name;
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 HTTPS $https if_not_empty;
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;
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;
It is the default nginx file, unaltered.
--
syn.bsdbox.co
From francis at daoine.org Thu Jan 9 10:55:31 2014
From: francis at daoine.org (Francis Daly)
Date: Thu, 9 Jan 2014 10:55:31 +0000
Subject: PHP below server root not served
In-Reply-To: <52CE78BC.7050500@bsdbox.co>
References: <52CE78BC.7050500@bsdbox.co>
Message-ID: <20140109105531.GB19804@craic.sysops.org>
On Thu, Jan 09, 2014 at 09:23:56PM +1100, nano wrote:
Hi there,
> The WordPress site, however, is served without error. Therefore, nginx
> is refusing to serve PHP from outside of the server document root.
nginx doesn't serve php.
nginx tells the fastcgi server what you configure it to tell.
(That's an important difference from what Apache does.)
> Please see the following configuration:
One request is handled in one location.
For this request, the one location that you want to be used is not the
one that nginx actually uses.
> location / {
> location ~ \.php$ {
> location /phpmyadmin/ {
> location ~ ^/phpmyadmin/(.*\.php)$ {
> I am obviously lacking some required configuration. Perhaps in
> nginx.conf, php-fpm.conf, or php.ini. Could someone please advise me of
> my error and how to correct it? Thank you.
http://nginx.org/r/location
A request for /phpmyadmin/index.php will be handled in the second location
above, not the fourth.
Re-arrange the config file.
(I'd suggest using "location ^~ /phpmyadmin/", and inside that using
"location ~ \.php$"; but just re-ordering the regex blocks that you have
should cause the location that you want to be chosen.)
f
--
Francis Daly francis at daoine.org
From francis at daoine.org Thu Jan 9 11:01:24 2014
From: francis at daoine.org (Francis Daly)
Date: Thu, 9 Jan 2014 11:01:24 +0000
Subject: "Primary script unknown" wp-login.php
In-Reply-To: <52CE2C47.8080905@bsdbox.co>
References: <52CE2C47.8080905@bsdbox.co>
Message-ID: <20140109110124.GC19804@craic.sysops.org>
On Thu, Jan 09, 2014 at 03:57:43PM +1100, nano wrote:
Hi there,
> As subject says: I cannot access wp-admin due to above [error].
> Otherwise, site functions as it should.
> location ~ \.php$ {
> fastcgi_param SCRIPT_FILENAME
> /usr/local/www/wordpress$fastcgi_script_name;
> }
The request /wordpress/wp-login.php should be handled in your "location
~ \.php$" block, where you tell nginx to tell the fasctcgi server to
process the file /usr/local/www/wordpress/wordpress/wp-login.php.
Is that the file that you want the fastcgi server to process?
f
--
Francis Daly francis at daoine.org
From nanotek at bsdbox.co Thu Jan 9 11:44:35 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 22:44:35 +1100
Subject: PHP below server root not served
In-Reply-To: <20140109105531.GB19804@craic.sysops.org>
References: <52CE78BC.7050500@bsdbox.co>
<20140109105531.GB19804@craic.sysops.org>
Message-ID: <52CE8BA3.6070207@bsdbox.co>
On 9/01/2014 9:55 PM, Francis Daly wrote:
> On Thu, Jan 09, 2014 at 09:23:56PM +1100, nano wrote:
>
> Hi there,
>
> One request is handled in one location.
>
> For this request, the one location that you want to be used is not the
> one that nginx actually uses.
>
>> location / {
>> location ~ \.php$ {
>> location /phpmyadmin/ {
>> location ~ ^/phpmyadmin/(.*\.php)$ {
>
>
> http://nginx.org/r/location
>
> A request for /phpmyadmin/index.php will be handled in the second location
> above, not the fourth.
>
> Re-arrange the config file.
>
> (I'd suggest using "location ^~ /phpmyadmin/", and inside that using
> "location ~ \.php$"; but just re-ordering the regex blocks that you have
> should cause the location that you want to be chosen.)
>
>
Hi. Thank you for your response. I had previously read the documentation
you reference but I am afraid I am none the wiser, likely due to my own
failure to comprehend. Similarly, I am finding it difficult to implement
your suggestion. Would you please provide an example of this arrangement
I should have?
I attempted multiple variations of what I believed your instructions
suggested (nesting \.php$ location inside the /phpmyadmin location);
such as:
location ^~ /phpmyadmin {
alias /usr/local/www/phpMyAdmin/;
fastcgi_param DOCUEMNT_ROOT /usr/local/www/phpMyAdmin;
fastcgi_param PATH_INFO $fastcgi_script_name;
location ~ \.php$ {
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}
}
I implemented many varieties of this location nesting. All resulted in
the same inability to access the URI: sitename.com/phpmyadmin. But also
made the WordPress site (servername.com) unavailable. Instead, it
presented a dialog offering to download the 'application/octet-stream'.
Please provide the configuration you suggest. Thank you.
--
syn.bsdbox.co
From mdounin at mdounin.ru Thu Jan 9 11:44:57 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 9 Jan 2014 15:44:57 +0400
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <52CE73DF.80200@arcor.de>
References: <52CE73DF.80200@arcor.de>
Message-ID: <20140109114457.GA1835@mdounin.ru>
Hello!
On Thu, Jan 09, 2014 at 11:03:11AM +0100, basti wrote:
> Hello,
>
> I have a closed-source Webapp that run on an IIS-Webserver and send a
> "X-Frame-Options: SAMEORIGIN" header.
> I also have to implement this Webapp in my own, Frame based Application.
>
> So I try to use nginx as a reverse Proxy, but the X-Frame-Options Header
> is still send.
> How can I remove his header?
> I have try "proxy_hide_header X-Frame-Options;" without success.
The proxy_hide_header directive is expected to work (and works
here, just tested). If it doesn't work for you, you may want to
provide more details, see http://wiki.nginx.org/Debugging for some
hints.
--
Maxim Dounin
http://nginx.org/
From nanotek at bsdbox.co Thu Jan 9 11:46:32 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 22:46:32 +1100
Subject: "Primary script unknown" wp-login.php
In-Reply-To: <20140109110124.GC19804@craic.sysops.org>
References: <52CE2C47.8080905@bsdbox.co>
<20140109110124.GC19804@craic.sysops.org>
Message-ID: <52CE8C18.9040709@bsdbox.co>
On 9/01/2014 10:01 PM, Francis Daly wrote:
> On Thu, Jan 09, 2014 at 03:57:43PM +1100, nano wrote:
>
> Hi there,
>
>> As subject says: I cannot access wp-admin due to above [error].
>> Otherwise, site functions as it should.
>
>> location ~ \.php$ {
>> fastcgi_param SCRIPT_FILENAME
>> /usr/local/www/wordpress$fastcgi_script_name;
>> }
>
> The request /wordpress/wp-login.php should be handled in your "location
> ~ \.php$" block, where you tell nginx to tell the fasctcgi server to
> process the file /usr/local/www/wordpress/wordpress/wp-login.php.
>
> Is that the file that you want the fastcgi server to process?
>
> f
>
I resolved this problem by making the /wordpress directory the server
root. However, I now have the problem of /usr/local/www/phpMyAdmin being
inaccessible, due to the same error.
--
syn.bsdbox.co
From mdounin at mdounin.ru Thu Jan 9 11:57:32 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 9 Jan 2014 15:57:32 +0400
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To:
References: <52CE73DF.80200@arcor.de>
Message-ID: <20140109115732.GB1835@mdounin.ru>
Hello!
On Thu, Jan 09, 2014 at 10:21:43AM +0000, Jonathan Matthews wrote:
> On 9 January 2014 10:03, basti wrote:
> > Hello,
> >
> > I have a closed-source Webapp that run on an IIS-Webserver and send a
> > "X-Frame-Options: SAMEORIGIN" header.
> > I also have to implement this Webapp in my own, Frame based Application.
> >
> > So I try to use nginx as a reverse Proxy, but the X-Frame-Options Header
> > is still send.
> > How can I remove his header?
> > I have try "proxy_hide_header X-Frame-Options;" without success.
>
> You'll find the answer in the documentation:
> http://wiki.nginx.org/NginxHttpProxyModule#proxy_set_header
The X-Frame-Options header is returned by a server-side
application, hence the proxy_hide_header is correct solution,
while proxy_set_header isn't.
And, being pedantic, wiki != documentation. Here are
links to the documentation:
http://nginx.org/r/proxy_set_header
http://nginx.org/r/proxy_hide_header
--
Maxim Dounin
http://nginx.org/
From contact at jpluscplusm.com Thu Jan 9 12:12:09 2014
From: contact at jpluscplusm.com (Jonathan Matthews)
Date: Thu, 9 Jan 2014 12:12:09 +0000
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <20140109115732.GB1835@mdounin.ru>
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
Message-ID:
On 9 January 2014 11:57, Maxim Dounin wrote:
> Hello!
>
> On Thu, Jan 09, 2014 at 10:21:43AM +0000, Jonathan Matthews wrote:
>
>> On 9 January 2014 10:03, basti wrote:
>> > Hello,
>> >
>> > I have a closed-source Webapp that run on an IIS-Webserver and send a
>> > "X-Frame-Options: SAMEORIGIN" header.
>> > I also have to implement this Webapp in my own, Frame based Application.
>> >
>> > So I try to use nginx as a reverse Proxy, but the X-Frame-Options Header
>> > is still send.
>> > How can I remove his header?
>> > I have try "proxy_hide_header X-Frame-Options;" without success.
>>
>> You'll find the answer in the documentation:
>> http://wiki.nginx.org/NginxHttpProxyModule#proxy_set_header
>
> The X-Frame-Options header is returned by a server-side
> application, hence the proxy_hide_header is correct solution,
> while proxy_set_header isn't.
My bad. I was pretty sure I'd had success with 'set foo ""' where
'hide' hadn't worked in the past.
> And, being pedantic, wiki != documentation. Here are
> links to the documentation:
>
> http://nginx.org/r/proxy_set_header
> http://nginx.org/r/proxy_hide_header
Ack that. I'll personally keep linking to the wiki until the documentation
* is significantly better internally hyper-linked;
* has documentation targeted soley towards the open source nginx,
without having to skip to the end of each directive to check for "This
functionality is available as part of our commercial subscription
only";
* has useful pages such as IfIsEvil integrated into it.
I may be wrong about that third one still needing doing, but I
couldn't find IfIsEvil anywhere but the wiki. The presence of a
top-level pointer on each wiki page to http://nginx.org/en/docs/ is
pretty useless, too - it needs to point to the appropriate place in
the docs to get people to start using them.
Didn't you guys pick up several millions a while ago, which was
announced as being somewhat earmarked for improving documentation? :-)
From nanotek at bsdbox.co Thu Jan 9 12:24:03 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 23:24:03 +1100
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To:
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
Message-ID: <52CE94E3.5090608@bsdbox.co>
On 9/01/2014 11:12 PM, Jonathan Matthews wrote:
> On 9 January 2014 11:57, Maxim Dounin wrote:
>> Hello!
>>
>> On Thu, Jan 09, 2014 at 10:21:43AM +0000, Jonathan Matthews wrote:
>>
>>> On 9 January 2014 10:03, basti wrote:
>>>> Hello,
>>>>
>>>> I have a closed-source Webapp that run on an IIS-Webserver and send a
>>>> "X-Frame-Options: SAMEORIGIN" header.
>>>> I also have to implement this Webapp in my own, Frame based Application.
>>>>
>>>> So I try to use nginx as a reverse Proxy, but the X-Frame-Options Header
>>>> is still send.
>>>> How can I remove his header?
>>>> I have try "proxy_hide_header X-Frame-Options;" without success.
>>>
>>> You'll find the answer in the documentation:
>>> http://wiki.nginx.org/NginxHttpProxyModule#proxy_set_header
>>
>> The X-Frame-Options header is returned by a server-side
>> application, hence the proxy_hide_header is correct solution,
>> while proxy_set_header isn't.
>
> My bad. I was pretty sure I'd had success with 'set foo ""' where
> 'hide' hadn't worked in the past.
>
>> And, being pedantic, wiki != documentation. Here are
>> links to the documentation:
>>
>> http://nginx.org/r/proxy_set_header
>> http://nginx.org/r/proxy_hide_header
>
> Ack that. I'll personally keep linking to the wiki until the documentation
>
> * is significantly better internally hyper-linked;
> * has documentation targeted soley towards the open source nginx,
> without having to skip to the end of each directive to check for "This
> functionality is available as part of our commercial subscription
> only";
> * has useful pages such as IfIsEvil integrated into it.
>
> I may be wrong about that third one still needing doing, but I
> couldn't find IfIsEvil anywhere but the wiki. The presence of a
> top-level pointer on each wiki page to http://nginx.org/en/docs/ is
> pretty useless, too - it needs to point to the appropriate place in
> the docs to get people to start using them.
>
> Didn't you guys pick up several millions a while ago, which was
> announced as being somewhat earmarked for improving documentation? :-)
>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
I share your opinion regarding nginx documentation. It is woeful.
Particularly when compared to other exemplary open source projects, such
as Postfix and FreeBSD. My inability to easily transfer my webservers to
nginx from Apache, due to (my own shortcomings compounded by) terribly
inadequate documentation, nearly made the transition impossible. Insult
was only added to injury when, after transferring some sites to the
recommended nginx, I found very little performance enhancement.
Admittedly, I am most probably not properly utilizing the application
and will only see improvements when my own abilities allow it.
Nevertheless, the documentation needs work. It is prudent to accommodate
less technically aware users.
--
syn.bsdbox.co
From nanotek at bsdbox.co Thu Jan 9 12:41:32 2014
From: nanotek at bsdbox.co (nano)
Date: Thu, 09 Jan 2014 23:41:32 +1100
Subject: PHP below server root not served
In-Reply-To: <52CE78BC.7050500@bsdbox.co>
References: <52CE78BC.7050500@bsdbox.co>
Message-ID: <52CE98FC.8000405@bsdbox.co>
On 9/01/2014 9:23 PM, nano wrote:
> I am having trouble configuring nginx to serve up PHP from outside of
> the server document root. For example, this site's root is
> /usr/local/www/site1/wordpress and phpMyAdmin is located in
> /usr/local/www/phpMyAdmin. I cannot access servername.com/phpmyadmin.
> nginx logs the following error:
>
> ====================================================================
> 2014/01/09 09:56:20 [error] 39387#0: *6160 FastCGI sent in stderr:
> "Primary script unknown" while reading response header from upstream,
> client: clientIP, server: serverhostname, request: "GET /phpmyadmin/
> HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host:
> "serverhostname"
> ====================================================================
>
> The WordPress site, however, is served without error. Therefore, nginx
> is refusing to serve PHP from outside of the server document root.
> Please see the following configuration:
>
>
> nginx.conf
> ====================================================================
> user www www;
> worker_processes 1;
> pid /var/run/nginx.pid;
> error_log logs/error.log info;
>
> events {
> worker_connections 768;
> use kqueue;
> }
>
> http {
> include mime.types;
> default_type application/octet-stream;
>
> access_log logs/access.log main;
> sendfile on;
> keepalive_timeout 65;
> gzip on;
>
> server {
> listen 80;
> listen 443 ssl;
> server_name servername.com;
> ssl_certificate crt-chain.pem;
> ssl_certificate_key key.pem;
> ssl_dhparam dhparam4096.pem;
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM
> EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384
> EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !a
> NULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
> ssl_prefer_server_ciphers on;
>
> root /usr/local/www/site1/wordpress;
> index index.php;
>
> location / {
> try_files $uri $uri/ /index.php?$args;
> }
>
> location ~ \.php$ {
> fastcgi_pass unix:/var/run/php-fpm.sock;
> fastcgi_param SCRIPT_FILENAME
> /usr/local/www/site1/wordpress$fastcgi_script_name;
> fastcgi_param PATH_INFO $fastcgi_script_name;
> include fastcgi_params;
> }
>
> #----------------------PROBLEM AREA----------------------#
>
> location /phpmyadmin/ {
> alias /usr/local/www/phpMyAdmin/;
> index index.php index.html;
> }
>
> location ~ ^/phpmyadmin/(.*\.php)$ {
> fastcgi_param PHP_ADMIN_VALUE
> open_basedir=/usr/local/www/phpMyAdmin;
> fastcgi_pass unix:/tmp/php-fpm.sock;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME
> /usr/local/www/phpMyAdmin$fastcgi_script_name;
> include fastcgi_params;
>
> #----------------------PROBLEM AREA----------------------#
>
> }
> }
> }
> ====================================================================
>
>
> I am obviously lacking some required configuration. Perhaps in
> nginx.conf, php-fpm.conf, or php.ini. Could someone please advise me of
> my error and how to correct it? Thank you.
>
> Strangely, in Apache, I simply required an alias entry, such as:
>
> Alias /phpmyadmin "/usr/local/www/phpMyAdmin"
>
> Options None
> AllowOverride None
> Require all granted
>
>
> in my httpd.conf file even when the server root was above this location
> and with the exact same PHP settings (php.ini) as I now have with nginx.
>
> Server intel:
> # uname -a
> FreeBSD hostname 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26
> 22:50:31 UTC 2013
> root at bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
>
> # nginx -V
> nginx version: nginx/1.5.7
> TLS SNI support enabled
> configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
> /usr/local/include' --with-ld-opt='-L /usr/local/lib'
> --conf-path=/usr/local/etc/nginx/nginx.conf
> --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
> --error-log-path=/var/log/nginx-error.log --user=www --group=www
> --with-ipv6 --with-google_perftools_module
> --http-client-body-temp-path=/var/tmp/nginx/client_body_temp
> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
> --http-proxy-temp-path=/var/tmp/nginx/proxy_temp
> --http-scgi-temp-path=/var/tmp/nginx/scgi_temp
> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
> --http-log-path=/var/log/nginx-access.log --with-http_addition_module
> --with-http_auth_request_module --with-http_dav_module
> --with-http_flv_module --with-http_geoip_module
> --with-http_gzip_static_module --with-http_gunzip_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_sub_module
> --with-http_xslt_module --with-pcre --with-http_spdy_module --with-mail
> --with-mail_ssl_module --with-http_ssl_module
>
>
I seem to have fixed this problem.
Amended nginx.conf file:
====================================================================
user www www;
worker_processes 1;
pid /var/run/nginx.pid;
error_log logs/error.log info;
events {
worker_connections 768;
use kqueue;
}
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;
keepalive_timeout 65;
gzip on;
server {
listen 80;
listen 443 ssl;
server_name srvname.com www.srvname.com;
ssl_certificate crt-chain.pem;
ssl_certificate_key key.pem;
ssl_dhparam dhparam4096.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW
!3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
ssl_prefer_server_ciphers on;
root /usr/local/www/site1/wordpress;
index index.php;
location /phpmyadmin {
alias /usr/local/www/phpMyAdmin/;
index index.php index.html;
}
location ~ ^/phpmyadmin/(.*\.php)$ {
root /usr/local/www/phpMyAdmin/;
fastcgi_pass unix:/var/run/php-fpm.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME
/usr/local/www/site1/wordpress$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/www/nginx-dist;
}
}
}
====================================================================
Admittedly, I don't know *why* what I changed fixed the problem, but it
did. I relocated the phpMyAdmin entries to above the "location /" block
from beneath the "location /" block.
From:
http {
server {
root;
location / {
try_files; ... }
location ~ \.php$ {
fastcgi_pass ... }
location /phpmyadmin {
alias; ... }
location ~ ^/phpmyadmin/(.*\.php)$ {
root; ... }
location = /50x.html; {
root; ... }
}
}
}
to:
http {
server {
root;
location /phpmyadmin {
alias; ... }
location ~ ^/phpmyadmin/(.*\.php)$ {
root; ... }
location / {
try_files; ... }
location ~ \.php$ {
fastcgi_pass ... }
location = /50x.html; {
root; ... }
}
}
}
The syntax is identical, just those two location blocks are in a
different place. I would like to know why this works, but am just happy
that it does. I look forward to better understanding this great program.
Thank you, all, for your participation.
--
syn.bsdbox.co
From contact at jpluscplusm.com Thu Jan 9 12:47:39 2014
From: contact at jpluscplusm.com (Jonathan Matthews)
Date: Thu, 9 Jan 2014 12:47:39 +0000
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <52CE94E3.5090608@bsdbox.co>
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
<52CE94E3.5090608@bsdbox.co>
Message-ID:
On 9 January 2014 12:24, nano wrote:
> I share your opinion regarding nginx documentation. It is woeful.
Sorry chap - I didn't say that and I don't think that. There may well
be some specific target audiences not well served by the aggregate of
the current (psuedo-)documentation sources, but that doesn't mean they
themselves are /that/ bad. My problems with them are specific and
fixable, and not just "make it better!"
J
From mdounin at mdounin.ru Thu Jan 9 12:48:56 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 9 Jan 2014 16:48:56 +0400
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To:
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
Message-ID: <20140109124856.GE1835@mdounin.ru>
Hello!
On Thu, Jan 09, 2014 at 12:12:09PM +0000, Jonathan Matthews wrote:
> On 9 January 2014 11:57, Maxim Dounin wrote:
> > Hello!
> >
> > On Thu, Jan 09, 2014 at 10:21:43AM +0000, Jonathan Matthews wrote:
> >
> >> On 9 January 2014 10:03, basti wrote:
> >> > Hello,
> >> >
> >> > I have a closed-source Webapp that run on an IIS-Webserver and send a
> >> > "X-Frame-Options: SAMEORIGIN" header.
> >> > I also have to implement this Webapp in my own, Frame based Application.
> >> >
> >> > So I try to use nginx as a reverse Proxy, but the X-Frame-Options Header
> >> > is still send.
> >> > How can I remove his header?
> >> > I have try "proxy_hide_header X-Frame-Options;" without success.
> >>
> >> You'll find the answer in the documentation:
> >> http://wiki.nginx.org/NginxHttpProxyModule#proxy_set_header
> >
> > The X-Frame-Options header is returned by a server-side
> > application, hence the proxy_hide_header is correct solution,
> > while proxy_set_header isn't.
>
> My bad. I was pretty sure I'd had success with 'set foo ""' where
> 'hide' hadn't worked in the past.
>
> > And, being pedantic, wiki != documentation. Here are
> > links to the documentation:
> >
> > http://nginx.org/r/proxy_set_header
> > http://nginx.org/r/proxy_hide_header
>
> Ack that. I'll personally keep linking to the wiki until the documentation
>
> * is significantly better internally hyper-linked;
> * has documentation targeted soley towards the open source nginx,
> without having to skip to the end of each directive to check for "This
> functionality is available as part of our commercial subscription
> only";
> * has useful pages such as IfIsEvil integrated into it.
>
> I may be wrong about that third one still needing doing, but I
> couldn't find IfIsEvil anywhere but the wiki. The presence of a
> top-level pointer on each wiki page to http://nginx.org/en/docs/ is
> pretty useless, too - it needs to point to the appropriate place in
> the docs to get people to start using them.
>
> Didn't you guys pick up several millions a while ago, which was
> announced as being somewhat earmarked for improving documentation? :-)
And that's why we actually have the documentation in English. :)
Additionally, compared to what we have previously it is already
significantly imporoved.
As I already explained, the problem with wiki pages which
duplication documentation is a bit rot. There are lots of
improvements in the documentation which isn't in wiki, most
obviously - there are no new directives. And this bit rot confuse
people more and more.
The generic plan is to avoid the duplication altogether,
preserving wiki for useful additional content.
--
Maxim Dounin
http://nginx.org/
From reallfqq-nginx at yahoo.fr Thu Jan 9 12:57:32 2014
From: reallfqq-nginx at yahoo.fr (B.R.)
Date: Thu, 9 Jan 2014 13:57:32 +0100
Subject: PHP below server root not served
In-Reply-To: <52CE98FC.8000405@bsdbox.co>
References: <52CE78BC.7050500@bsdbox.co>
<52CE98FC.8000405@bsdbox.co>
Message-ID:
Try to understand what you are doing first.
One request is handled in one location.
>>
>> For this request, the one location that you want to be used is not the
>> one that nginx actually uses.
>>
>>
>>> ?1. ?
>>> location / {
>>>
>>> ?2. ?
>>> location ~ \.php$ {
>>>
>>> ?3. ?
>>> location /phpmyadmin/ {
>>>
>>> ?4. ?
>>> location ~ ^/phpmyadmin/(.*\.php)$ {
>>>
>>
>>
>> http://nginx.org/r/location
>>
>> A request for /phpmyadmin/index.php will be handled in the second location
>> above, not the fourth.
>>
>
?The docs say 'To find location matching a given request, nginx first
checks locations defined using the prefix strings (prefix locations). Among
them, the location with the longest matching prefix is selected and
remembered. Then regular expressions are checked, in the order of their
appearance in the configuration file. The search of regular expressions
terminates on the first match, and the corresponding configuration is used.
If no match with a regular expression is found then the configuration of
the prefix location remembered earlier is used.'
Thus, in your configuration, for a '/phpmyadmin/***.php' request, it does
the following:
* Start searching prefix location *
1. location /
3. location /phpmyadmin/
* End of prefix location search, longest prefix = 3. *
* Start searching regex expressions
2. location ~\.php$ // First regex found, stop of search
* End of prefix location search, regex found is being used * // Otherwise,
if no matching regex were to be found, a fallback to the longest prefix
location found before would have applied
Your problem is that the location 4. is *never* used, because the regex
being used is the first which matches. Your generic '\.php$' will catch'em
all!
?
?Francis provided 2 ways of fixing your problem:
I. Re-arranging your config file so 'location /phpmyadmin/(.*\.php)$' is
found *before* \.php$?
On Thu, Jan 9, 2014 at 1:41 PM, nano wrote:
> Admittedly, I don't know *why* what I changed fixed the problem, but it
> did. I relocated the phpMyAdmin entries to above the "location /" block
> from beneath the "location /" block.
>
> ?* snip *
>
> The syntax is identical, just those two location blocks are in a different
> place. I would like to know why this works, but am just happy that it does.
> I look forward to better understanding this great program.
?
You did just that...
II. Use a smarter (and more scalable, in light of future adds to the nginx
config) way, which is nesting the rules of 'location
/phpmyadmin/(.*\.php)$' in a 'location ~\.php$' block embedded in a
'location ^~ /phpmyadmin/' block.
Note the modification made to the prefix block for phpmyadmin. The docs say
'If the longest matching prefix location has the ?^~? modifier then regular
expressions are not checked.'
This way, longest prefix will be 'location /phpmyadmin/' *but the generic
'location \.php$' won't be used* since there will be no regex search.
Hope I helped,
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mdounin at mdounin.ru Thu Jan 9 13:18:09 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 9 Jan 2014 17:18:09 +0400
Subject: issue with `default_type` & `type` on 1.5.7
In-Reply-To: <663B722A-E6F3-40CD-B37D-4CD53FCD4956@2xlp.com>
References: <36cb46b6f59688950730d92fbdb0a260.NginxMailingListEnglish@forum.nginx.org>
<663B722A-E6F3-40CD-B37D-4CD53FCD4956@2xlp.com>
Message-ID: <20140109131808.GH1835@mdounin.ru>
Hello!
On Sat, Jan 04, 2014 at 03:36:33PM -0500, Jonathan Vanasco wrote:
> I recently encountered an issue with a 1.5.7 branch on OSX. i did not check 1.5.8
>
> The following code will set ALL css/js files as the default_type
>
> include /usr/local/nginx/conf/mime.types;
> default_type application/octet-stream;
>
>
> The following code works as intended
>
> default_type application/octet-stream;
> include /usr/local/nginx/conf/mime.types;
>
> I haven't had time to test on other versions.
>
> This could be the intended behavior, but the docs don't suggest
> that. usually a default_type only applies when the real type
> can't be found.
Most likely there is a directive with some non-strict syntax (like
"index") before they configuration you've quoted, and there is no
semicolon after it. E.g., something like this:
index index.html
include /usr/local/nginx/conf/mime.types;
default_type application/octet-stream;
While the configuration looks like correct one with mime.types
included, it's instead defines 3 index files ("index.html",
"include", "/usr/local/nginx/conf/mime.types"), and default_type -
but mime.types isn't included.
--
Maxim Dounin
http://nginx.org/
From nanotek at bsdbox.co Thu Jan 9 13:18:36 2014
From: nanotek at bsdbox.co (nano)
Date: Fri, 10 Jan 2014 00:18:36 +1100
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To:
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
<52CE94E3.5090608@bsdbox.co>
Message-ID: <52CEA1AC.1030704@bsdbox.co>
On 9/01/2014 11:47 PM, Jonathan Matthews wrote:
> On 9 January 2014 12:24, nano wrote:
>> I share your opinion regarding nginx documentation. It is woeful.
>
> Sorry chap - I didn't say that and I don't think that. There may well
> be some specific target audiences not well served by the aggregate of
> the current (psuedo-)documentation sources, but that doesn't mean they
> themselves are /that/ bad. My problems with them are specific and
> fixable, and not just "make it better!"
>
> J
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
Nonetheless, I find the official documentation lacking. It is good that
you do not. Fortunately, there are alternative resources that make
deployment of nginx servers achievable for users lacking technical
proficiency, like myself.
--
syn.bsdbox.co
From andre at digirati.com.br Thu Jan 9 13:35:17 2014
From: andre at digirati.com.br (Andre Nathan)
Date: Thu, 09 Jan 2014 11:35:17 -0200
Subject: Nginx, Lua and blocking libraries
Message-ID: <52CEA595.2040505@digirati.com.br>
Hello
I'm considering the possibility of implementing a project using Nginx
and the Lua module. One of the requirements of the project is that the
code must use an embedded database such as SQLite. However, as known,
using the lua-sqlite3 library directly is not optimal because it would
block the Nginx worker process.
My question is, is there a way to work around this in any way? For
example, creating a coroutine to run the lua-sqlite3 calls?
If not, does anyone know of some other embedded database that works well
with the Lua Nginx module?
Thank you in advance,
Andre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL:
From nanotek at bsdbox.co Thu Jan 9 13:51:24 2014
From: nanotek at bsdbox.co (nano)
Date: Fri, 10 Jan 2014 00:51:24 +1100
Subject: PHP below server root not served
In-Reply-To:
References: <52CE78BC.7050500@bsdbox.co>
<52CE98FC.8000405@bsdbox.co>
Message-ID: <52CEA95C.3020300@bsdbox.co>
On 9/01/2014 11:57 PM, B.R. wrote:
> Try to understand what you are doing first.
>
I really am trying.
> One request is handled in one location.
>
> For this request, the one location that you want to be used is
> not the
> one that nginx actually uses.
>
> ?1. ?
> location / {
> ?2. ?
> location ~ \.php$ {
> ?3. ?
> location /phpmyadmin/ {
> ?4. ?
> location ~ ^/phpmyadmin/(.*\.php)$ {
>
>
>
> http://nginx.org/r/location
>
> A request for /phpmyadmin/index.php will be handled in the
> second location
> above, not the fourth.
>
>
> ?The docs say 'To find location matching a given request, nginx first
> checks locations defined using the prefix strings (prefix locations).
> Among them, the location with the longest matching prefix is selected
> and remembered. Then regular expressions are checked, in the order of
> their appearance in the configuration file. The search of regular
> expressions terminates on the first match, and the corresponding
> configuration is used. If no match with a regular expression is found
> then the configuration of the prefix location remembered earlier is used.'
>
I did not (and still do not) understand it like you do. I had the
impression that each location block would adhere to its own assignments.
What defines a prefix string and a regular expression? Would " ~
^/phpmyadmin/(.*\.php)$ " not be the longest matching prefix to be
selected and remembered? And if so, despite it coming after the " ~
\.php$ " location, should it not be used?
> Thus, in your configuration, for a '/phpmyadmin/***.php' request, it
> does the following:
> * Start searching prefix location *
> 1. location /
> 3. location /phpmyadmin/
> * End of prefix location search, longest prefix = 3. *
>
> * Start searching regex expressions
> 2. location ~\.php$ // First regex found, stop of search
> * End of prefix location search, regex found is being used * //
> Otherwise, if no matching regex were to be found, a fallback to the
> longest prefix location found before would have applied
>
I think I am gradually understanding your explanation: despite location
3 being the longest prefix, regular expression in location 2 is found
and used. This found and used regex does not suit the requirements of
executing PHP instructions necessary to serve files from location 4? In
my example, nginx was instructing php-fpm to execute
/usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?
> Your problem is that the location 4. is *never* used, because the regex
> being used is the first which matches. Your generic '\.php$' will
> catch'em all!
> ?
>
> ?Francis provided 2 ways of fixing your problem:
> I. Re-arranging your config file so 'location /phpmyadmin/(.*\.php)$' is
> found /*before*/ \.php$?
>
I misunderstood Francis' advice. I thought he advised nesting my
/phpmyadmin location(s) inside the location ~ \.php$ block which further
broke my site.
> On Thu, Jan 9, 2014 at 1:41 PM, nano > wrote:
>
> Admittedly, I don't know *why* what I changed fixed the problem, but
> it did. I relocated the phpMyAdmin entries to above the "location /"
> block from beneath the "location /" block.
>
> ?* snip *
>
> The syntax is identical, just those two location blocks are in a
> different place. I would like to know why this works, but am just
> happy that it does. I look forward to better understanding this
> great program.
>
> ?
> You did just that...
>
> II. Use a smarter (and more scalable, in light of future adds to the
> nginx config) way, which is nesting the rules of 'location
> /phpmyadmin/(.*\.php)$' in a 'location ~\.php$' block embedded in a
> 'location ^~ /phpmyadmin/' block.
>
Please, would you provide a working example of this for me to use? I
have been trying to create this smarter way but am failing miserably.
Does location ~\.php$ coming before /phpmyadmin/(.*\.php)$ (as it does
if the latter is nested in the former) not emulate the same situation I
created in the first place, thus rendering servername.com/phpmyadmin
broken? An example would help immensely and be very much appreciated. If
not mistaken, I understand you are suggesting the following structure
but, due to my failures in implementing such advice, it appears I need
something precise:
location / { }
location /phpmyadmin {
location ~\.php$
location /phpmyadmin/(.*\.php)$
}
}
}
> Note the modification made to the prefix block for phpmyadmin. The docs
> say 'If the longest matching prefix location has the ?|^~|? modifier
> then regular expressions are not checked.'
> This way, longest prefix will be 'location /phpmyadmin/' /but the
> generic 'location \.php$' *won't be used*/ since there will be no regex
> search.
>
What exactly does this mean? Is this a proper assignment to avoid
phpMyAdmin scripts being affected by the generic php regex and *only*
using those assigned in the ~ ^/phpmyadmin/(.*\.php)$ location?
> Hope I helped,
>
I really appreciate your help. I am also very sorry that I do not have a
better understanding and lack the knowledge to fully benefit from your
assistance, but it is great you are helping. Thank you!
--
syn.bsdbox.co
From nanotek at bsdbox.co Thu Jan 9 14:42:41 2014
From: nanotek at bsdbox.co (nano)
Date: Fri, 10 Jan 2014 01:42:41 +1100
Subject: PHP below server root not served
In-Reply-To:
References: <52CE78BC.7050500@bsdbox.co>
<52CE98FC.8000405@bsdbox.co>
Message-ID: <52CEB561.8050305@bsdbox.co>
On 9/01/2014 11:57 PM, B.R. wrote:
>
> II. Use a smarter (and more scalable, in light of future adds to the
> nginx config) way, which is nesting the rules of 'location
> /phpmyadmin/(.*\.php)$' in a 'location ~\.php$' block embedded in a
> 'location ^~ /phpmyadmin/' block.
>
I have attempted several variations of this format[1] you recommend and
continue to produce a broken site; dialog to download
application/octet-stream from the main servername.com and a 'File not
found.' from https://servername.com/phpmyadmin.
[1]
location / {
try_files $uri $uri/ /index.php?$args;
}
location ^~ /phpmyadmin {
alias /usr/local/www/phpMyAdmin/;
index index.php index.html;
location ~ \.php$ {
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
fastcgi_param SCRIPT_FILENAME
/usr/local/www/site1/wordpress$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}
}
I eagerly anticipate a working example if and when you can provide one.
Thank you.
--
syn.bsdbox.co
From mdounin at mdounin.ru Thu Jan 9 14:46:50 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 9 Jan 2014 18:46:50 +0400
Subject: proxy_cache incorrectly returning 304 Not Modified
In-Reply-To: <52CD674E.5080007@jonathanleighton.com>
References: <52CD674E.5080007@jonathanleighton.com>
Message-ID: <20140109144650.GK1835@mdounin.ru>
Hello!
On Wed, Jan 08, 2014 at 02:57:18PM +0000, Jon Leighton wrote:
> Hi there,
>
> I work on a site which has nginx in front of a Rails application, and we
> use proxy_cache.
>
> For the home page, our application returns a "max-age=600, public"
> Cache-Control header, and we have nginx configured to cache the response
> using proxy_cache.
>
> This generally works fine, but last night nginx started to respond with
> 304 Not Modified to requests that *didn't* include any caching headers
> (If-Modified-Since or ETag). Our Pingdom alerts showed this issue, and
> here is the request/response captured:
>
> GET / HTTP/1.0
> User-Agent: Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)
> Host: loco2.com
>
> 304 Not Modified
> Cache-Control: max-age=600, public
> Date: Tue, 07 Jan 2014 22:59:32 GMT
> ETag: "900e1f11422519337c9ed25fad299ce0"
> Server: nginx/1.4.4
> Status: 304 Not Modified
> Strict-Transport-Security: max-age=31536000
> X-Cache-Status: HIT
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> X-Request-Id: c7ee78ab-df49-4467-bced-753b2cc622ab
> X-UA-Compatible: chrome=1
> X-XSS-Protection: 1; mode=block
> Connection: Close
>
> Does this look like a bug? Or could it be a configuration issue? I can't
> think of any reason why this should be the correct thing for the proxy
> cache to do.
This easily can be a result of a misconfiguration (e.g.,
proxy_set_header used incorrectly) and/or backend
problem.
Additionally, response headers looks very suspicious. There
shouldn't be "Status: 304 Not Modified" in nginx responses, and
"Connection: Close" capitalization doesn't match what nginx uses.
Unless it's something introduced by Pingdom interface, this may
indicate that it's checking something which isn't nginx.
--
Maxim Dounin
http://nginx.org/
From mdounin at mdounin.ru Thu Jan 9 15:03:09 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 9 Jan 2014 19:03:09 +0400
Subject: Time out errors using uwsgi with ngnix on debian 7 (wheezy)
In-Reply-To:
References:
Message-ID: <20140109150309.GL1835@mdounin.ru>
Hello!
On Wed, Jan 08, 2014 at 08:15:47PM -0500, Denis Papathanasiou wrote:
> I've installed nginx via apt, using the nginx stable pkg as described here:
> http://nginx.org/en/linux_packages.html#stable
>
> It works perfectly for serving static files using the default configuration.
>
> Next, I installed uwsgi from source, as described here:
> https://pypi.python.org/pypi/uWSGI/1.2.3
>
> When I do the steps in the python quickstart guide --
> http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html -- and open
> my browser to localhost:9090, everything works as expected.
>
> When I change the nginx config file to use uwsgi_pass to localhost:9090 as
> described here --
> http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html#putting-behind-a-full-webserver--
> however, I get time out errors:
>
> > upstream timed out (110: Connection timed out) while reading response
> header from upstream
>
> It is as though nginx is *not* passing those requests to the uwsgi process
> (which is still running).
>
> Here is the content of server{ } inside the nginx config file:
>
> location / {
> include uwsgi_params;
> uwsgi_pass localhost:9090;
> }
>
> Any ideas on what the problem might be?
If you are able to connect to localhost:9090 with your browser,
you are likely using native HTTP support in your uWSGI server.
The "uwsgi_pass" directive assumes uwsgi protocol though, which is
different.
You should either reconfigure uWSGI server to work via uwsgi, or
instruct nginx to talk via HTTP (i.e., use "proxy_pass" instead of
"uwsgi_pass").
--
Maxim Dounin
http://nginx.org/
From jim at ohlste.in Thu Jan 9 15:21:06 2014
From: jim at ohlste.in (Jim Ohlstein)
Date: Thu, 09 Jan 2014 10:21:06 -0500
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <52CE94E3.5090608@bsdbox.co>
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
<52CE94E3.5090608@bsdbox.co>
Message-ID: <52CEBE62.4090402@ohlste.in>
Hello,
On 1/9/14, 7:24 AM, nano wrote:
[snip]
>
> I share your opinion regarding nginx documentation. It is woeful.
> Particularly when compared to other exemplary open source projects, such
> as Postfix and FreeBSD. My inability to easily transfer my webservers to
> nginx from Apache, due to (my own shortcomings compounded by) terribly
> inadequate documentation, nearly made the transition impossible. Insult
> was only added to injury when, after transferring some sites to the
> recommended nginx, I found very little performance enhancement.
> Admittedly, I am most probably not properly utilizing the application
> and will only see improvements when my own abilities allow it.
> Nevertheless, the documentation needs work. It is prudent to accommodate
> less technically aware users.
>
You may not see much "performance enhancement" if your server was not
heavily loaded or if it is using PHP to serve static content, such as
WordPress used to do up until version 3.4 and continues to do on some
sites that were upgraded from older versions to the current version.
Also, if you are running a PHP daemon and a MySQL server on the same
server as you run nginx, they may contribute more to server load than
does nginx. Optimizing them, especially MySQL, may give you significant
"performance enhancement". I mention WordPress because you link to a
WordPress site in your signature. Since your domain was first registered
in November and since you only have a few posts most of which are
rudimentary, I am going to doubt that you don't have a lot of traffic.
Alexa does not even have data on your site yet, it's so new. Plus using
a self signed certificate and creating SSL links on your home page -
http://bsdbox.co - give the big red page on Chrome. I have no desire to
add an exception for a two month old domain. Spring for $4.99/year at
https://www.cheapssls.com/domain-only.html and get a PositiveSSL
certificate.
The shortcomings are yours indeed. The documentation is for people who
understand the concepts and is not meant to be a replacement for a "for
Dummies" book. I believe that (almost) every directive is covered. If
you do not understand what the directives mean, there are many ways to
figure it out. In such a case, Google is your friend.
Comparing nginx documentation to FreeBSD documentation is a bit
unrealistic. FreeBSD documentation is written by volunteers of which
there are dozens if not hundreds. The entire project is a community
effort. Despite that, some is out of date. For instance, look at
http://www5.us.freebsd.org/doc/handbook/svn-mirrors.html. Do you see
svn0.eu.FreeBSD.org listed there, or its fingerprint? There may be other
servers missing as well. I have found many other examples but that's the
first that comes to mind.
Anyone who wants to *volunteer* to improve the documentation should do
so. I'm sure the devs would at least look at any provided patches.
Of course, you can always create a community effort of your own and
organize your own wiki or alternate set of documentation. Or perhaps you
can apply for a job at Nginx.com to work on upgrading the documentation
to your standards.
The original purpose of the wiki was to serve as English documentation
when there was little to none. Sure, it had a bit more hand holding, but
it really has become superfluous at least in terms of providing up to
date documentation, at least IMMHO.
--
Jim Ohlstein
From nginx-forum at nginx.us Thu Jan 9 16:28:02 2014
From: nginx-forum at nginx.us (Larry)
Date: Thu, 09 Jan 2014 11:28:02 -0500
Subject: Dynamic ssl certificate ? (wildcard+ multiple different certs)
Message-ID:
Hello,
Here is my current conf
server {
listen 443;
server_name ~^(.*)\.sub\.domain\.com$
ssl on;
ssl_certificate $cookie_ident/$1.crt;
ssl_certificate_key $cookie_ident/$1.key;
server_tokens off;
ssl_protocols TLSv1.2 TLSv1.1 TLSv1 SSLv3;
ssl_prefer_server_ciphers on;
ssl_session_timeout 5m;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:RC4-SHA;
autoindex off;
root /upla/http/www.domain.com;
port_in_redirect off;
expires 10s;
#add_header Cache-Control "no-cache,no-store";
#expires max;
add_header Pragma public;
add_header Cache-Control "public";
location / {
try_files $uri /$request_uri =404;
}
}
I would like to be able to "load" the right cert according to the cookie set
and request uri.
A sort of dynamic setting.
But of course, when I start nginx, it complains :
SSL: error:02001002:system library:fopen:No such file or directory:
Perfectly normal since $cookie_ident is empty and no subdomain has been
requested.
So, what is the workaround I could use to avoid creating one file per new
(self-signed)certificate issued ?
I cannot use only one certificate for all since I have to be able to revoke
the certs with granularity.
How should I make it work ?
Thanks
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246178,246178#msg-246178
From wmark+nginx at hurrikane.de Thu Jan 9 16:40:35 2014
From: wmark+nginx at hurrikane.de (W-Mark Kubacki)
Date: Thu, 9 Jan 2014 17:40:35 +0100
Subject: Dynamic ssl certificate ? (wildcard+ multiple different certs)
In-Reply-To:
References:
Message-ID:
Certificates are selected and presented by the server before the
client even has the chance to send any cookies, the latter
happening after the ?TLS handshake?.
2014/1/9 Larry :
> Hello,
>
> Here is my current conf
>
> server {
> listen 443;
>
> server_name ~^(.*)\.sub\.domain\.com$
>
> ssl on;
> ssl_certificate $cookie_ident/$1.crt;
> ssl_certificate_key $cookie_ident/$1.key;
> server_tokens off;
>
> ssl_protocols TLSv1.2 TLSv1.1 TLSv1 SSLv3;
> ssl_prefer_server_ciphers on;
> ssl_session_timeout 5m;
> ssl_session_cache builtin:1000 shared:SSL:10m;
>
> ssl_ciphers
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:RC4-SHA;
>
>
> autoindex off;
> root /upla/http/www.domain.com;
> port_in_redirect off;
> expires 10s;
> #add_header Cache-Control "no-cache,no-store";
> #expires max;
> add_header Pragma public;
> add_header Cache-Control "public";
>
> location / {
>
> try_files $uri /$request_uri =404;
>
> }
>
> }
>
> I would like to be able to "load" the right cert according to the cookie set
> and request uri.
>
> A sort of dynamic setting.
>
> But of course, when I start nginx, it complains :
> SSL: error:02001002:system library:fopen:No such file or directory:
>
> Perfectly normal since $cookie_ident is empty and no subdomain has been
> requested.
>
> So, what is the workaround I could use to avoid creating one file per new
> (self-signed)certificate issued ?
>
> I cannot use only one certificate for all since I have to be able to revoke
> the certs with granularity.
>
>
> How should I make it work ?
>
> Thanks
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246178,246178#msg-246178
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
From contact at jpluscplusm.com Thu Jan 9 16:45:21 2014
From: contact at jpluscplusm.com (Jonathan Matthews)
Date: Thu, 9 Jan 2014 16:45:21 +0000
Subject: Dynamic ssl certificate ? (wildcard+ multiple different certs)
In-Reply-To:
References:
Message-ID:
On 9 January 2014 16:28, Larry wrote:
> I would like to be able to "load" the right cert according to the cookie set
> and request uri.
> A sort of dynamic setting.
> So, what is the workaround I could use to avoid creating one file per new
> (self-signed)certificate issued ?
Your problem is that, irrespective of Nginx's feelings about using a
variable in the ssl_certificate directive, what you're trying to
configure is a HTTP/SSL layering violation.
The information you want to use to choose the correct cert is
communicated inside the HTTP request (usually people ask about using
the Host header; you're asking here about cookies). But this
information is not available to the SSL libraries until /after/ the
SSL channel has been set up - which can't be done until a cert has
been selected. It's a catch-22 situation.
SNI /can/ help with this, as it transmits the host header in the clear
during SSL negotiation, but client support can prove limited (browsers
on XP, IIRC, don't support it). I'm not sure, but I don't believe SNI
communicates enough extra information (cookies and/or request paths)
for you to achieve what you want to here.
The usual suggestion for this situation is either to seperate out
sites, one per IP; or to look at wildcard certs or UCC/SaN certs.
You've mentioned self-signed certs, which suggests you may have some
control over the clients root CAs - is this the case? You could
perhaps automate UCC/SaN cert issuance based on your current whitelist
of unrevoked certs ...
tl;dr Buy some IPv4 space and use an IP per subdomain.
Jonathan
From miguelmclara at gmail.com Thu Jan 9 16:46:59 2014
From: miguelmclara at gmail.com (Miguel Clara)
Date: Thu, 9 Jan 2014 16:46:59 +0000
Subject: "Primary script unknown" wp-login.php
In-Reply-To: <52CE8C18.9040709@bsdbox.co>
References: <52CE2C47.8080905@bsdbox.co>
<20140109110124.GC19804@craic.sysops.org>
<52CE8C18.9040709@bsdbox.co>
Message-ID:
> I resolved this problem by making the /wordpress directory the server root.
> However, I now have the problem of /usr/local/www/phpMyAdmin being
> inaccessible, due to the same error.
>
You can, and its probably best to use:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
Also you should have those to in different nginx config files, its far
better to read/modify if needed.
In any case the .php block should work has long has the "root" is set
right in the different locations!
From r at roze.lv Thu Jan 9 16:52:39 2014
From: r at roze.lv (Reinis Rozitis)
Date: Thu, 9 Jan 2014 18:52:39 +0200
Subject: Dynamic ssl certificate ? (wildcard+ multiple different certs)
In-Reply-To:
References:
Message-ID:
> So, what is the workaround I could use to avoid creating one file per new
> (self-signed)certificate issued ?
> I cannot use only one certificate for all since I have to be able to
> revoke the certs with granularity.
If you don't want to use file/certificate per domain but the same time can't
work arround it with a wildcard certificate it (imo) leaves just one
option - to create a certificate including all the exact domains and
whenever there are some changes (expiration or a new domain added)
regenerate the cert.
p.s. you can do something like that even with non self-signed certificates -
for example (while manually) Godaddy lets you add or remove domains to their
"Multiple Domains UCC" certs (up to 100 domains) on the fly (the expiration
of the whole cert remains).
rr
From denis.papathanasiou at gmail.com Thu Jan 9 17:08:23 2014
From: denis.papathanasiou at gmail.com (Denis Papathanasiou)
Date: Thu, 9 Jan 2014 12:08:23 -0500
Subject: Time out errors using uwsgi with ngnix on debian 7 (wheezy)
In-Reply-To: <20140109150309.GL1835@mdounin.ru>
References:
<20140109150309.GL1835@mdounin.ru>
Message-ID:
Maxim,
Thank you for your reply.
On Thu, Jan 9, 2014 at 10:03 AM, Maxim Dounin wrote:
> [snip]
>
> If you are able to connect to localhost:9090 with your browser,
> you are likely using native HTTP support in your uWSGI server.
>
Yes, I am starting the uwsgi process like this, using the --http flag:
uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2
> The "uwsgi_pass" directive assumes uwsgi protocol though, which is
> different.
>
> You should either reconfigure uWSGI server to work via uwsgi, or
>
Ah, I see, I should use the --socket option instead, like this:
uwsgi --socket 127.0.0.1:9090 --wsgi-file foobar.py --master --processes 4
--threads 2
Thank you for clarifying that; it *is* in the uwsgi docs I quoted earlier,
but it is a subtle point under the "quickstart" section, and I had missed
it.
> instruct nginx to talk via HTTP (i.e., use "proxy_pass" instead of
> "uwsgi_pass").
>
I see: I could use "proxy_pass" and keep --http when I start uwsgi.
Thank you, that was very helpful!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jim at ohlste.in Thu Jan 9 17:13:01 2014
From: jim at ohlste.in (Jim Ohlstein)
Date: Thu, 09 Jan 2014 12:13:01 -0500
Subject: PHP below server root not served
In-Reply-To: <52CEB561.8050305@bsdbox.co>
References: <52CE78BC.7050500@bsdbox.co>
<52CE98FC.8000405@bsdbox.co>
<52CEB561.8050305@bsdbox.co>
Message-ID: <52CED89D.9070604@ohlste.in>
Hello,
On 1/9/14, 9:42 AM, nano wrote:
>
> I have attempted several variations of this format[1] you recommend and
> continue to produce a broken site; dialog to download
> application/octet-stream from the main servername.com and a 'File not
> found.' from https://servername.com/phpmyadmin.
>
> [1]
> location / {
> try_files $uri $uri/ /index.php?$args;
> }
>
> location ^~ /phpmyadmin {
> alias /usr/local/www/phpMyAdmin/;
> index index.php index.html;
>
> location ~ \.php$ {
> fastcgi_pass unix:/var/run/php-fpm.locatsock;
> fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
> fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
> fastcgi_param SCRIPT_FILENAME
> /usr/local/www/site1/wordpress$fastcgi_script_name;
> fastcgi_param PATH_INFO $fastcgi_script_name;
> include fastcgi_params;
> }
> }
>
> I eagerly anticipate a working example if and when you can provide one.
> Thank you.
>
Next to "IfIsEvil" there should be a "DoNotUseAlias (unless necessary)".
Use the "root" directive and nested locations
location /phpMyAdmin {
root /usr/local/www;
index index.php;
# above probably not necessary as it is inherited from above
location ~ \.php$ {
fastcgi_pass ...;
...
}
}
A few notes, in no particular order:
You *should* use auth_basic [0] at the very least as exposing this
functionality the world is a very bad idea.
You should consider using "https only" for this script.
If you want to enter phpmyadmin in all lower case in the URL (it is
easier), do it via rewrite.
Consider turning off access log on at least rewritten requests once you
know it's working.
Consider using your server's FQDN, not your server name. It's less
likely potential intruders would guess it, though far from impossible.
Something like (not tested but should get you very close if not there):
server {
listen 80;
server_name foo;
location ^~ /phpmyadmin {
access_log off;
rewrite ^ /phpMyAdmin/ permanent;
}
location /phpMyAdmin {
access_log off;
rewrite ^ https://foo$request_uri? break;
}
...
}
server {
listen 443 ssl;
server name foo;
ssl_certificate /path/to/cert;
ssl_certificate_key /path/to/key;
...
location ^~ /phpmyadmin {
access_log off;
rewrite ^ /phpMyAdmin/ permanent;
}
location /phpMyAdmin {
auth_basic "Blah";
auth_basic_usr_file /path/to/auth/file;
# access_log off; # optional
location ~ \.php$ {
fastcgi_pass ...;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param HTTPS on;
}
}
}
[0] http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
--
Jim Ohlstein
From nanotek at bsdbox.co Thu Jan 9 17:14:44 2014
From: nanotek at bsdbox.co (nano)
Date: Fri, 10 Jan 2014 04:14:44 +1100
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <52CEBE62.4090402@ohlste.in>
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
<52CE94E3.5090608@bsdbox.co> <52CEBE62.4090402@ohlste.in>
Message-ID: <52CED904.8010409@bsdbox.co>
On 10/01/2014 2:21 AM, Jim Ohlstein wrote:
> Hello,
>
> On 1/9/14, 7:24 AM, nano wrote:
>
> [snip]
>
>>
>> I share your opinion regarding nginx documentation. It is woeful.
>> Particularly when compared to other exemplary open source projects, such
>> as Postfix and FreeBSD. My inability to easily transfer my webservers to
>> nginx from Apache, due to (my own shortcomings compounded by) terribly
>> inadequate documentation, nearly made the transition impossible. Insult
>> was only added to injury when, after transferring some sites to the
>> recommended nginx, I found very little performance enhancement.
>> Admittedly, I am most probably not properly utilizing the application
>> and will only see improvements when my own abilities allow it.
>> Nevertheless, the documentation needs work. It is prudent to accommodate
>> less technically aware users.
>>
>
> You may not see much "performance enhancement" if your server was not
> heavily loaded or if it is using PHP to serve static content, such as
> WordPress used to do up until version 3.4 and continues to do on some
> sites that were upgraded from older versions to the current version.
> Also, if you are running a PHP daemon and a MySQL server on the same
> server as you run nginx, they may contribute more to server load than
> does nginx. Optimizing them, especially MySQL, may give you significant
> "performance enhancement".
Thanks, Jim, for the suggestions. I may look into optimizing MySQL at a
later date.
> I mention WordPress because you link to a
> WordPress site in your signature. Since your domain was first registered
> in November and since you only have a few posts most of which are
> rudimentary, I am going to doubt that you don't have a lot of traffic.
> Alexa does not even have data on your site yet, it's so new. Plus using
> a self signed certificate and creating SSL links on your home page -
> http://bsdbox.co - give the big red page on Chrome. I have no desire to
> add an exception for a two month old domain. Spring for $4.99/year at
> https://www.cheapssls.com/domain-only.html and get a PositiveSSL
> certificate.
>
That domain only hosts a personal blog documenting FreeBSD procedures,
and SOHO resource for colleagues, family and friends; in fact, the
server is still running Apache and is not relevant to my observations
pertaining to increased performance, or lack of, in transferring to
nginx on other sites. Further, I have no desire to satisfy your trust
concerns. My concern is to secure my own sensitive traffic. Moreover,
the paradigm of entrusting third parties is foolish and highly
susceptible to exploitation, but this, too, is irrelevant. Thank you for
your concern and advice; however, I will not be purchasing a
"PositiveSSL certificate".
> The shortcomings are yours indeed. The documentation is for people who
> understand the concepts and is not meant to be a replacement for a "for
> Dummies" book. I believe that (almost) every directive is covered. If
> you do not understand what the directives mean, there are many ways to
> figure it out. In such a case, Google is your friend.
>
I have no doubt, and iterated, my inadequacies affect my
(mis)understanding of the documentation. Similarly, I remarked on the
utility of alternative resources; found through Google. If you have some
"for Dummies" resources, please feel free to provide them. That would be
good.
> Comparing nginx documentation to FreeBSD documentation is a bit
> unrealistic. FreeBSD documentation is written by volunteers of which
> there are dozens if not hundreds. The entire project is a community
> effort. Despite that, some is out of date. For instance, look at
> http://www5.us.freebsd.org/doc/handbook/svn-mirrors.html. Do you see
> svn0.eu.FreeBSD.org listed there, or its fingerprint? There may be other
> servers missing as well. I have found many other examples but that's the
> first that comes to mind.
>
It is analogous, as is the comparison to Postfix documentation. I did
not claim FreeBSD literature is absent error, but that it is simply more
comprehensive and accommodates "Dummies". If nginx chooses to cater for
"for people who understand the concepts and is not meant to be a
replacement for a 'for Dummies' book", that is the prerogative of the
maintainers and developers of nginx documentation.
> Anyone who wants to *volunteer* to improve the documentation should do
> so. I'm sure the devs would at least look at any provided patches.
>
> Of course, you can always create a community effort of your own and
> organize your own wiki or alternate set of documentation. Or perhaps you
> can apply for a job at Nginx.com to work on upgrading the documentation
> to your standards.
>
I am certain there are people who value and appreciate the project
enough that will choose to contribute. When the values and objectives of
a project comport with my own, I often choose to contribute how I can;
such as, deploying Tor exit nodes, documenting up-to-date, basic
procedures, or making monetary donations to the FreeBSD Foundation. This
is a nice quality of open source communities. The good ones thrive, the
less valued do not.
> The original purpose of the wiki was to serve as English documentation
> when there was little to none.
I am sure that multimillion dollar donations will contribute to further
improvements.
> Sure, it had a bit more hand holding, but
> it really has become superfluous at least in terms of providing up to
> date documentation, at least IMMHO.
>
>
You are entitled to your opinion, as am I. Your advice will be
considered. Thank you, Jim.
--
syn.bsdbox.co
From nanotek at bsdbox.co Thu Jan 9 17:28:58 2014
From: nanotek at bsdbox.co (nano)
Date: Fri, 10 Jan 2014 04:28:58 +1100
Subject: PHP below server root not served
In-Reply-To: <52CED89D.9070604@ohlste.in>
References: <52CE78BC.7050500@bsdbox.co>
<52CE98FC.8000405@bsdbox.co>
<52CEB561.8050305@bsdbox.co> <52CED89D.9070604@ohlste.in>
Message-ID: <52CEDC5A.6090203@bsdbox.co>
On 10/01/2014 4:13 AM, Jim Ohlstein wrote:
> Hello,
>
> On 1/9/14, 9:42 AM, nano wrote:
>>
>> I have attempted several variations of this format[1] you recommend and
>> continue to produce a broken site; dialog to download
>> application/octet-stream from the main servername.com and a 'File not
>> found.' from https://servername.com/phpmyadmin.
>>
>> [1]
>> location / {
>> try_files $uri $uri/ /index.php?$args;
>> }
>>
>> location ^~ /phpmyadmin {
>> alias /usr/local/www/phpMyAdmin/;
>> index index.php index.html;
>>
>> location ~ \.php$ {
>> fastcgi_pass unix:/var/run/php-fpm.locatsock;
>> fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
>> fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
>> fastcgi_param SCRIPT_FILENAME
>> /usr/local/www/site1/wordpress$fastcgi_script_name;
>> fastcgi_param PATH_INFO $fastcgi_script_name;
>> include fastcgi_params;
>> }
>> }
>>
>> I eagerly anticipate a working example if and when you can provide one.
>> Thank you.
>>
>
> Next to "IfIsEvil" there should be a "DoNotUseAlias (unless necessary)".
> Use the "root" directive and nested locations
>
> location /phpMyAdmin {
> root /usr/local/www;
> index index.php;
> # above probably not necessary as it is inherited from above
> location ~ \.php$ {
> fastcgi_pass ...;
> ...
> }
> }
>
>
If my recollection is correct, I believe I had problems when using root
instead of alias directive. I will try again though.
> A few notes, in no particular order:
>
> You *should* use auth_basic [0] at the very least as exposing this
> functionality the world is a very bad idea.
>
> You should consider using "https only" for this script.
>
> If you want to enter phpmyadmin in all lower case in the URL (it is
> easier), do it via rewrite.
>
> Consider turning off access log on at least rewritten requests once you
> know it's working.
>
> Consider using your server's FQDN, not your server name. It's less
> likely potential intruders would guess it, though far from impossible.
>
> Something like (not tested but should get you very close if not there):
>
> server {
> listen 80;
> server_name foo;
>
> location ^~ /phpmyadmin {
> access_log off;
> rewrite ^ /phpMyAdmin/ permanent;
> }
>
> location /phpMyAdmin {
> access_log off;
> rewrite ^ https://foo$request_uri? break;
> }
> ...
>
> }
>
> server {
> listen 443 ssl;
> server name foo;
>
> ssl_certificate /path/to/cert;
> ssl_certificate_key /path/to/key;
>
> ...
>
> location ^~ /phpmyadmin {
> access_log off;
> rewrite ^ /phpMyAdmin/ permanent;
> }
>
> location /phpMyAdmin {
> auth_basic "Blah";
> auth_basic_usr_file /path/to/auth/file;
> # access_log off; # optional
> location ~ \.php$ {
> fastcgi_pass ...;
> include fastcgi_params;
> fastcgi_index index.php;
> fastcgi_param HTTPS on;
> }
> }
> }
>
I would like the whole server accessible over SSL. Not just for
phpMyAdmin but WordPress administration.
>
> [0] http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
>
Jim, thank you very much for your example(s) and advice, it is very much
appreciated. I had intended to secure phpMyAdmin access after resolving
my basic configuration issues. I will attempt to implement these changes
and report back with results.
--
syn.bsdbox.co
From agentzh at gmail.com Thu Jan 9 17:33:03 2014
From: agentzh at gmail.com (Yichun Zhang (agentzh))
Date: Thu, 9 Jan 2014 09:33:03 -0800
Subject: Nginx, Lua and blocking libraries
In-Reply-To: <52CEA595.2040505@digirati.com.br>
References: <52CEA595.2040505@digirati.com.br>
Message-ID:
Hello!
On Thu, Jan 9, 2014 at 5:35 AM, Andre Nathan wrote:
> However, as known,
> using the lua-sqlite3 library directly is not optimal because it would
> block the Nginx worker process.
>
Well, I suggest you benchmark the actual performance and measure the
actual blocking effect (We actually have systemtap-based tools to
measure the epoll loop blocking effect:
https://github.com/agentzh/stapxx#epoll-loop-blocking-distr and the
off-CPU flamegraph tool is very useful for determining the
contributors: https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt-off-cpu
).
Basically if your database is in-memory, then the blocking effect
should be much smaller because no disk IO involved.
Even if you're using on-disk database, the blocking effect should be
quite small if your disks are fast (like modern SSD cards) and/or the
kernel's page cache's hit rate is high enough.
Nginx core's popular in-file http cache (used by proxy_cache,
fastcgi_cache, and etc) also involves blocking file IO system calls
and people are still enjoying it a lot ;)
It's worth noting that when you're using ngx_lua to embed a database
like SQLite, you should always cache the file descriptor to save
`open` and `close` system calls.
> My question is, is there a way to work around this in any way?
Ideally you should use (or write) a pthread based network service
frontend (be it TCP or just unix domain sockets) for SQLite and let
your Nginx talk to this network interface in a 100% nonblocking way.
> For
> example, creating a coroutine to run the lua-sqlite3 calls?
>
Basically Lua coroutines cannot work around blocking system calls. You
need real OS threads for that.
Regards,
-agentzh
From jim at ohlste.in Thu Jan 9 17:33:10 2014
From: jim at ohlste.in (Jim Ohlstein)
Date: Thu, 09 Jan 2014 12:33:10 -0500
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <52CED904.8010409@bsdbox.co>
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
<52CE94E3.5090608@bsdbox.co> <52CEBE62.4090402@ohlste.in>
<52CED904.8010409@bsdbox.co>
Message-ID: <52CEDD56.9070109@ohlste.in>
Hello,
On 1/9/14, 12:14 PM, nano wrote:
> On 10/01/2014 2:21 AM, Jim Ohlstein wrote:
>> Hello,
>>
>> On 1/9/14, 7:24 AM, nano wrote:
>>
>> [snip]
>>
>>>
>>> I share your opinion regarding nginx documentation. It is woeful.
>>> Particularly when compared to other exemplary open source projects, such
>>> as Postfix and FreeBSD. My inability to easily transfer my webservers to
>>> nginx from Apache, due to (my own shortcomings compounded by) terribly
>>> inadequate documentation, nearly made the transition impossible. Insult
>>> was only added to injury when, after transferring some sites to the
>>> recommended nginx, I found very little performance enhancement.
>>> Admittedly, I am most probably not properly utilizing the application
>>> and will only see improvements when my own abilities allow it.
>>> Nevertheless, the documentation needs work. It is prudent to accommodate
>>> less technically aware users.
>>>
>>
>> You may not see much "performance enhancement" if your server was not
>> heavily loaded or if it is using PHP to serve static content, such as
>> WordPress used to do up until version 3.4 and continues to do on some
>> sites that were upgraded from older versions to the current version.
>> Also, if you are running a PHP daemon and a MySQL server on the same
>> server as you run nginx, they may contribute more to server load than
>> does nginx. Optimizing them, especially MySQL, may give you significant
>> "performance enhancement".
>
> Thanks, Jim, for the suggestions. I may look into optimizing MySQL at a
> later date.
Going to copy someone else's procedures and write another "tutorial"?
>
>> I mention WordPress because you link to a
>> WordPress site in your signature. Since your domain was first registered
>> in November and since you only have a few posts most of which are
>> rudimentary, I am going to doubt that you don't have a lot of traffic.
>> Alexa does not even have data on your site yet, it's so new. Plus using
>> a self signed certificate and creating SSL links on your home page -
>> http://bsdbox.co - give the big red page on Chrome. I have no desire to
>> add an exception for a two month old domain. Spring for $4.99/year at
>> https://www.cheapssls.com/domain-only.html and get a PositiveSSL
>> certificate.
>>
>
> That domain only hosts a personal blog documenting FreeBSD procedures,
> and SOHO resource for colleagues, family and friends; in fact, the
> server is still running Apache and is not relevant to my observations
> pertaining to increased performance, or lack of, in transferring to
> nginx on other sites. Further, I have no desire to satisfy your trust
> concerns. My concern is to secure my own sensitive traffic. Moreover,
> the paradigm of entrusting third parties is foolish and highly
> susceptible to exploitation, but this, too, is irrelevant. Thank you for
> your concern and advice; however, I will not be purchasing a
> "PositiveSSL certificate".
Whatever. You put a link in your signature and *very* rudimentary (and
somewhat incorrect) "tutorials" in your blog.
In fact, on December 20, 2013 you wrote:
"I recently decided to build my first FreeBSD box. First order of
business: roll my own Apache server to host my ownCloud service. I also
decided to stand up this WordPress site to document my progress. Mostly
for posterity?s sake; this way, I have tried-and-tested data to
reference during future UNIX operations. ?Why should I [?]"
Learn something about being a sysadmin before writing "tutorials".
Anyway, opinions are like assholes. Everybody has one. Yours just
happens to be wrong.
>
>> The shortcomings are yours indeed. The documentation is for people who
>> understand the concepts and is not meant to be a replacement for a "for
>> Dummies" book. I believe that (almost) every directive is covered. If
>> you do not understand what the directives mean, there are many ways to
>> figure it out. In such a case, Google is your friend.
>>
>
> I have no doubt, and iterated, my inadequacies affect my
> (mis)understanding of the documentation. Similarly, I remarked on the
> utility of alternative resources; found through Google. If you have some
> "for Dummies" resources, please feel free to provide them. That would be
> good.
>
>> Comparing nginx documentation to FreeBSD documentation is a bit
>> unrealistic. FreeBSD documentation is written by volunteers of which
>> there are dozens if not hundreds. The entire project is a community
>> effort. Despite that, some is out of date. For instance, look at
>> http://www5.us.freebsd.org/doc/handbook/svn-mirrors.html. Do you see
>> svn0.eu.FreeBSD.org listed there, or its fingerprint? There may be other
>> servers missing as well. I have found many other examples but that's the
>> first that comes to mind.
>>
>
> It is analogous, as is the comparison to Postfix documentation. I did
> not claim FreeBSD literature is absent error, but that it is simply more
> comprehensive and accommodates "Dummies". If nginx chooses to cater for
> "for people who understand the concepts and is not meant to be a
> replacement for a 'for Dummies' book", that is the prerogative of the
> maintainers and developers of nginx documentation.
See above.
>
>> Anyone who wants to *volunteer* to improve the documentation should do
>> so. I'm sure the devs would at least look at any provided patches.
>>
>> Of course, you can always create a community effort of your own and
>> organize your own wiki or alternate set of documentation. Or perhaps you
>> can apply for a job at Nginx.com to work on upgrading the documentation
>> to your standards.
>>
>
> I am certain there are people who value and appreciate the project
> enough that will choose to contribute. When the values and objectives of
> a project comport with my own, I often choose to contribute how I can;
> such as, deploying Tor exit nodes, documenting up-to-date, basic
> procedures, or making monetary donations to the FreeBSD Foundation. This
> is a nice quality of open source communities. The good ones thrive, the
> less valued do not.
>
>> The original purpose of the wiki was to serve as English documentation
>> when there was little to none.
>
> I am sure that multimillion dollar donations will contribute to further
> improvements.
I'm not aware of any "multimillion dollar donations" but maybe you are.
Commercial funding is not a "donation".
>
>> Sure, it had a bit more hand holding, but
>> it really has become superfluous at least in terms of providing up to
>> date documentation, at least IMMHO.
>>
>>
>
> You are entitled to your opinion, as am I. Your advice will be
> considered. Thank you, Jim.
Again, see above.
>
Peace out.
--
Jim Ohlstein
From nanotek at bsdbox.co Thu Jan 9 17:46:58 2014
From: nanotek at bsdbox.co (nano)
Date: Fri, 10 Jan 2014 04:46:58 +1100
Subject: Nginx as reverse Proxy, remove X-Frame-Options header
In-Reply-To: <52CEDD56.9070109@ohlste.in>
References: <52CE73DF.80200@arcor.de>
<20140109115732.GB1835@mdounin.ru>
<52CE94E3.5090608@bsdbox.co> <52CEBE62.4090402@ohlste.in>
<52CED904.8010409@bsdbox.co> <52CEDD56.9070109@ohlste.in>
Message-ID: <52CEE092.3000203@bsdbox.co>
On 10/01/2014 4:33 AM, Jim Ohlstein wrote:
> Hello,
>
> On 1/9/14, 12:14 PM, nano wrote:
>> On 10/01/2014 2:21 AM, Jim Ohlstein wrote:
>>> Hello,
>>>
>>> On 1/9/14, 7:24 AM, nano wrote:
>>>
>>> [snip]
>>>
>>>>
>>>> I share your opinion regarding nginx documentation. It is woeful.
>>>> Particularly when compared to other exemplary open source projects,
>>>> such
>>>> as Postfix and FreeBSD. My inability to easily transfer my
>>>> webservers to
>>>> nginx from Apache, due to (my own shortcomings compounded by) terribly
>>>> inadequate documentation, nearly made the transition impossible. Insult
>>>> was only added to injury when, after transferring some sites to the
>>>> recommended nginx, I found very little performance enhancement.
>>>> Admittedly, I am most probably not properly utilizing the application
>>>> and will only see improvements when my own abilities allow it.
>>>> Nevertheless, the documentation needs work. It is prudent to
>>>> accommodate
>>>> less technically aware users.
>>>>
>>>
>>> You may not see much "performance enhancement" if your server was not
>>> heavily loaded or if it is using PHP to serve static content, such as
>>> WordPress used to do up until version 3.4 and continues to do on some
>>> sites that were upgraded from older versions to the current version.
>>> Also, if you are running a PHP daemon and a MySQL server on the same
>>> server as you run nginx, they may contribute more to server load than
>>> does nginx. Optimizing them, especially MySQL, may give you significant
>>> "performance enhancement".
>>
>> Thanks, Jim, for the suggestions. I may look into optimizing MySQL at a
>> later date.
>
> Going to copy someone else's procedures and write another "tutorial"?
>
I will record the procedure that results in a successful mission. That
typically involves documenting steps taken from a variety of sources, as
finding one that works without requiring changes is not commonplace. If
you have any resources, please feel free to provide them.
>>
>>> I mention WordPress because you link to a
>>> WordPress site in your signature. Since your domain was first registered
>>> in November and since you only have a few posts most of which are
>>> rudimentary, I am going to doubt that you don't have a lot of traffic.
>>> Alexa does not even have data on your site yet, it's so new. Plus using
>>> a self signed certificate and creating SSL links on your home page -
>>> http://bsdbox.co - give the big red page on Chrome. I have no desire to
>>> add an exception for a two month old domain. Spring for $4.99/year at
>>> https://www.cheapssls.com/domain-only.html and get a PositiveSSL
>>> certificate.
>>>
>>
>> That domain only hosts a personal blog documenting FreeBSD procedures,
>> and SOHO resource for colleagues, family and friends; in fact, the
>> server is still running Apache and is not relevant to my observations
>> pertaining to increased performance, or lack of, in transferring to
>> nginx on other sites. Further, I have no desire to satisfy your trust
>> concerns. My concern is to secure my own sensitive traffic. Moreover,
>> the paradigm of entrusting third parties is foolish and highly
>> susceptible to exploitation, but this, too, is irrelevant. Thank you for
>> your concern and advice; however, I will not be purchasing a
>> "PositiveSSL certificate".
>
> Whatever. You put a link in your signature and *very* rudimentary (and
> somewhat incorrect) "tutorials" in your blog.
>
Please, feel free to highlight what is incorrect, Jim. I would be happy
to make corrections.
> In fact, on December 20, 2013 you wrote:
>
> "I recently decided to build my first FreeBSD box. First order of
> business: roll my own Apache server to host my ownCloud service. I also
> decided to stand up this WordPress site to document my progress. Mostly
> for posterity?s sake; this way, I have tried-and-tested data to
> reference during future UNIX operations. ?Why should I [?]"
>
As I said in the paragraph you quote above: "personal blog documenting
FreeBSD procedures." I find it useful to record my progress. If it helps
somebody else, that is good.
> Learn something about being a sysadmin before writing "tutorials".
>
I hope to continue learning. Please, feel free to contribute in any way
you like.
> Anyway, opinions are like assholes. Everybody has one. Yours just
> happens to be wrong.
>
If that is your opinion. Good for you. Like you say, "everybody has one."
>>
>>> The shortcomings are yours indeed. The documentation is for people who
>>> understand the concepts and is not meant to be a replacement for a "for
>>> Dummies" book. I believe that (almost) every directive is covered. If
>>> you do not understand what the directives mean, there are many ways to
>>> figure it out. In such a case, Google is your friend.
>>>
>>
>> I have no doubt, and iterated, my inadequacies affect my
>> (mis)understanding of the documentation. Similarly, I remarked on the
>> utility of alternative resources; found through Google. If you have some
>> "for Dummies" resources, please feel free to provide them. That would be
>> good.
>>
>>> Comparing nginx documentation to FreeBSD documentation is a bit
>>> unrealistic. FreeBSD documentation is written by volunteers of which
>>> there are dozens if not hundreds. The entire project is a community
>>> effort. Despite that, some is out of date. For instance, look at
>>> http://www5.us.freebsd.org/doc/handbook/svn-mirrors.html. Do you see
>>> svn0.eu.FreeBSD.org listed there, or its fingerprint? There may be other
>>> servers missing as well. I have found many other examples but that's the
>>> first that comes to mind.
>>>
>>
>> It is analogous, as is the comparison to Postfix documentation. I did
>> not claim FreeBSD literature is absent error, but that it is simply more
>> comprehensive and accommodates "Dummies". If nginx chooses to cater for
>> "for people who understand the concepts and is not meant to be a
>> replacement for a 'for Dummies' book", that is the prerogative of the
>> maintainers and developers of nginx documentation.
>
> See above.
>
>>
>>> Anyone who wants to *volunteer* to improve the documentation should do
>>> so. I'm sure the devs would at least look at any provided patches.
>>>
>>> Of course, you can always create a community effort of your own and
>>> organize your own wiki or alternate set of documentation. Or perhaps you
>>> can apply for a job at Nginx.com to work on upgrading the documentation
>>> to your standards.
>>>
>>
>> I am certain there are people who value and appreciate the project
>> enough that will choose to contribute. When the values and objectives of
>> a project comport with my own, I often choose to contribute how I can;
>> such as, deploying Tor exit nodes, documenting up-to-date, basic
>> procedures, or making monetary donations to the FreeBSD Foundation. This
>> is a nice quality of open source communities. The good ones thrive, the
>> less valued do not.
>>
>>> The original purpose of the wiki was to serve as English documentation
>>> when there was little to none.
>>
>> I am sure that multimillion dollar donations will contribute to further
>> improvements.
>
> I'm not aware of any "multimillion dollar donations" but maybe you are.
> Commercial funding is not a "donation".
>
Then, that multimillion dollar funding will surely help.
>>
>>> Sure, it had a bit more hand holding, but
>>> it really has become superfluous at least in terms of providing up to
>>> date documentation, at least IMMHO.
>>>
>>>
>>
>> You are entitled to your opinion, as am I. Your advice will be
>> considered. Thank you, Jim.
>
> Again, see above.
>
>>
>
> Peace out.
>
Likewise.
--
syn.bsdbox.co
From andre at digirati.com.br Thu Jan 9 18:22:09 2014
From: andre at digirati.com.br (Andre Nathan)
Date: Thu, 09 Jan 2014 16:22:09 -0200
Subject: Nginx, Lua and blocking libraries
In-Reply-To:
References: <52CEA595.2040505@digirati.com.br>
Message-ID: <52CEE8D1.2000207@digirati.com.br>
Thanks a lot for the detailed answer, Yichun! I'll try to benchmark it,
estimate the db size, see if it fits in memory, etc.
Cheers,
Andre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL:
From nginx-forum at nginx.us Thu Jan 9 19:00:24 2014
From: nginx-forum at nginx.us (Larry)
Date: Thu, 09 Jan 2014 14:00:24 -0500
Subject: Dynamic ssl certificate ? (wildcard+ multiple different certs)
In-Reply-To:
References:
Message-ID: <54842c6b3225d474149fa0785a725e3a.NginxMailingListEnglish@forum.nginx.org>
Thanks,
I left the cookies out of this context right now I understand.
But since there is a http request first why doesn't nginx is able to switch
to the right certificate accordingly ?
Without obliging me to create a new entry for each (which is the route I am
going to take)?
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246178,246197#msg-246197
From chigga101 at gmail.com Thu Jan 9 19:03:49 2014
From: chigga101 at gmail.com (Matthew Ngaha)
Date: Thu, 9 Jan 2014 19:03:49 +0000
Subject: config issue
Message-ID:
Im trying to set up nginx with django. This is the instruction given:
Symlink to this file from /etc/nginx/sites-enabled so nginx can see it:
sudo ln -s ~/path/to/your/mysite/mysite_nginx.conf
/etc/nginx/sites-enabled/
The problem is this folder doesn't exist: /etc/nginx/sites-enabled/
my only nginx folder is in "/usr/local/nginx" so i don't know what to
do (I'm on ubuntu btw.) I've tried including the file it wanted me to
symlink, into my nginx.conf via an "Include" statement but everytime i
reload nginx, this Include action is causing an error.
What can i do to make nginx see my django project's config file?
From francis at daoine.org Thu Jan 9 19:29:53 2014
From: francis at daoine.org (Francis Daly)
Date: Thu, 9 Jan 2014 19:29:53 +0000
Subject: config issue
In-Reply-To:
References:
Message-ID: <20140109192953.GD19804@craic.sysops.org>
On Thu, Jan 09, 2014 at 07:03:49PM +0000, Matthew Ngaha wrote:
Hi there,
> Im trying to set up nginx with django. This is the instruction given:
>
> Symlink to this file from /etc/nginx/sites-enabled so nginx can see it:
That instruction assumes that the nginx config file that is being used
already has something like "include /etc/nginx/sites-enabled/*conf",
so that every matching file will be processed.
Apparently that's not true in this case.
> my only nginx folder is in "/usr/local/nginx" so i don't know what to
> do (I'm on ubuntu btw.) I've tried including the file it wanted me to
> symlink, into my nginx.conf via an "Include" statement but everytime i
> reload nginx, this Include action is causing an error.
"include" is the correct directive to use.
Documentation at http://nginx.org/r/include, in case anything is unclear.
Hopefully the words of the error will be enough to let you find how to
overcome it.
f
--
Francis Daly francis at daoine.org
From appa at perusio.net Thu Jan 9 19:50:24 2014
From: appa at perusio.net (=?ISO-8859-1?Q?Ant=F3nio_P=2E_P=2E_Almeida?=)
Date: Thu, 9 Jan 2014 20:50:24 +0100
Subject: Dynamic ssl certificate ? (wildcard+ multiple different certs)
In-Reply-To: <54842c6b3225d474149fa0785a725e3a.NginxMailingListEnglish@forum.nginx.org>
References:
<54842c6b3225d474149fa0785a725e3a.NginxMailingListEnglish@forum.nginx.org>
Message-ID: