Forum: NGINX SSL ciphers, disable or not to disable RC4?

088f415cfe9dfdeb8195fcfa1e3788ca?d=identicon&s=25 unknown (Guest)
on 2014-01-09 10:30
(Received via mailing list)
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.
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 10:42
(Received via mailing list)
On 9/01/2014 8:29 PM, Pekka.Panula@sofor.fi wrote:
> 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@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
8d313c5d85c52a953e498c4f66d59c8a?d=identicon&s=25 Jeffrey Walton (Guest)
on 2014-01-09 10:53
(Received via mailing list)
On Thu, Jan 9, 2014 at 4:29 AM,  <Pekka.Panula@sofor.fi> wrote:
> 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_Secu....

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.
63f341734581b167c7b698169bdd2510?d=identicon&s=25 Lukas Tribus (Guest)
on 2014-01-09 10:53
(Received via mailing list)
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
8d313c5d85c52a953e498c4f66d59c8a?d=identicon&s=25 Jeffrey Walton (Guest)
on 2014-01-09 11:05
(Received via mailing list)
On Thu, Jan 9, 2014 at 4:53 AM, Lukas Tribus <luky-37@hotmail.com>
wrote:
>
> 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
8d313c5d85c52a953e498c4f66d59c8a?d=identicon&s=25 Jeffrey Walton (Guest)
on 2014-01-09 11:05
(Received via mailing list)
On Thu, Jan 9, 2014 at 4:53 AM, Lukas Tribus <luky-37@hotmail.com>
wrote:
>
> 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
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 11:24
(Received via mailing list)
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"
<Directory "/usr/local/www/phpMyAdmin">
   Options None
         AllowOverride None
         Require all granted
</Directory>

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@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
Af4485ec4dc38936297a641eee74b0d8?d=identicon&s=25 Richard Stanway (Guest)
on 2014-01-09 11:28
(Received via mailing list)
>             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?
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 11:32
(Received via mailing list)
On 9/01/2014 9:27 PM, Richard Stanway wrote:
> nginx mailing list
> nginx@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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2014-01-09 11:55
(Received via mailing list)
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@daoine.org
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 12:45
(Received via mailing list)
On 9/01/2014 9:55 PM, Francis Daly wrote:
>>          location ~ \.php$ {
>
> (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
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 13:42
(Received via mailing list)
On 9/01/2014 9:23 PM, nano wrote:
> HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host:
> user  www www;
>      include       mime.types;
>          server_name servername.com;
>          root /usr/local/www/site1/wordpress;
>                  fastcgi_param PATH_INFO $fastcgi_script_name;
>          location ~ ^/phpmyadmin/(.*\.php)$ {
>          }
>
> Server intel:
> --conf-path=/usr/local/etc/nginx/nginx.conf
> --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
1266aa99d1601b47bbd3ec22affbb81c?d=identicon&s=25 B.R. (Guest)
on 2014-01-09 13:58
(Received via mailing list)
Try to understand what you are doing first.

 One request is handled in one 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 <nanotek@bsdbox.co> 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.*
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 14:51
(Received via mailing list)
On 9/01/2014 11:57 PM, B.R. wrote:
> Try to understand what you are doing first.
>

I really am trying.

>             ​3. ​
>         above, not the fourth.
>
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?

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

>     different place. I would like to know why this works, but am just
>
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
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 15:43
(Received via mailing list)
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
7e5b9e3ef674f859551ae0e283061b52?d=identicon&s=25 Jim Ohlstein (Guest)
on 2014-01-09 18:13
(Received via mailing list)
Hello,

On 1/9/14, 9:42 AM, nano wrote:
>
>      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_...

--
Jim Ohlstein
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-09 18:29
(Received via mailing list)
On 10/01/2014 4:13 AM, Jim Ohlstein wrote:
>> location  / {
>>      fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
>
>      }
> }
>
>

If my recollection is correct, I believe I had problems when using root
instead of alias directive. I will try again though.

> Consider turning off access log on at least rewritten requests once you
>
>
>
>              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_...
>

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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2014-01-09 21:59
(Received via mailing list)
On Fri, Jan 10, 2014 at 12:51:24AM +1100, nano wrote:
> On 9/01/2014 11:57 PM, B.R. wrote:
> >On Thu, Jan 9, 2014 at 1:41 PM, nano <nanotek@bsdbox.co> wrote:

Hi there,

The nginx config follows its own logic, which may not match your
previous
experiences. When you understand that, you'll have a much better chance
of knowing the configuration you are looking for.

One important feature is that one request is handled in one location.

Another is that there are very specific rules on how the one location
is selected. You are likely to find it frustrating to guess at possible
configurations, until you can determine for yourself which one location
will be used for a request.

The documentation for this is at
http://nginx.org/r/location, with a worked example at
http://nginx.org/en/docs/http/request_processing.h...
("How nginx processes a request" on http://nginx.org/en/docs/)

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

I'm not sure what that means. nginx must choose which location block
to use. The config in, or inherited into, that block is the only config
that applies for this request.

> What defines a prefix string and a regular expression?

Documentation, paragraph 3, sentence 2. (Or see below.)

> Would " ~
> ^/phpmyadmin/(.*\.php)$ " not be the longest matching prefix to be
> selected and remembered?

No. If it starts "~", it's a regular expression.

> I think I am gradually understanding your explanation: despite location
> 3 being the longest prefix, regular expression in location 2 is found
> and used.

Yes, but I'd say "because" rather than "despite".

> This found and used regex does not suit the requirements of
> executing PHP instructions necessary to serve files from location 4?

I'm not sure what that means. The location chosen is the only one used
to handle this request. If the config isn't right, the config isn't
right.

> In my example, nginx was instructing php-fpm to execute
> /usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?

...for any urls that matched the regular expression \.php$, yes.

> I misunderstood Francis' advice. I thought he advised nesting my
> /phpmyadmin location(s) inside the location ~ \.php$ block which further
> broke my site.

What I intended was:

* option 1, preferred but more changes: regex location inside prefix
^~ location.

* option 2, fewer changes so quicker to do: swap the order of the two
regex locations.


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

Swapping the location blocks was enough to have the block you wanted,
be the one chosen for this request, because the first regex block that
matched was the one you wanted to be used. The other changes were then
presumably enough for the fastcgi server to know which file to process.

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

I don't have a phpmyadmin install to hand here to test against, but will
be surprised to learn that there is no "here is how you install on
nginx"
on the phpmyadmin site, or no "here is how you configure phpmyadmin" on
the nginx web site -- it doesn't seem like an especially unusual thing
to want to do, and hopefully someone who has done it has advertised what
they did.

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

No -- "nested" is different from "ordered".

When nginx chooses the one location to use for a request, it chooses
the one top-level location{} block to use. Within that block, if there
are further choices to make, they are independent.

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

The suggestion is along the lines of:

  location ^~ /phpmyadmin/ {
    location ~ \.php$ {
      # config for php scripts to be fastcgi_pass'd elsewhere
    }
    # config for static files to be served directly
  }

and then whatever other top-level location{} blocks that you want for
the rest of the server config -- possibly include a "location /" and a
"location ~ \.php$".


Overall, I find it helpful to think "what request am I making?", and
then "which location block will be used to handle it?". Followed by
"will that do what I want it to do?".

And have a small test system that you can easily change things on
and check.

Good luck with it,

  f
--
Francis Daly        francis@daoine.org
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-10 04:08
(Received via mailing list)
On 10/01/2014 7:58 AM, Francis Daly wrote:
> Hi there,
>
> The nginx config follows its own logic, which may not match your previous
> experiences. When you understand that, you'll have a much better chance
> of knowing the configuration you are looking for.
>

I think this is very true in my case. I will continue reading through
the documentation and implementing different configurations to better my
understanding of nginx. It was my mistake assuming Apache logic[0] would
be used.

> One important feature is that one request is handled in one location.
>
> Another is that there are very specific rules on how the one location
> is selected. You are likely to find it frustrating to guess at possible
> configurations, until you can determine for yourself which one location
> will be used for a request.
>
> The documentation for this is at [...}
>

Thank you, Francis.

>> I had the impression that each location block would adhere to its own
assignments.
>
> I'm not sure what that means. nginx must choose which location block
> to use. The config in, or inherited into, that block is the only config
> that applies for this request.
>

I mean to say, I thought each location block would use the config that
is inside it, notwithstanding instructions contained inside previous
location blocks. Like an Apache <Directory> directive, for example.

>> What defines a prefix string and a regular expression?
>
> Documentation, paragraph 3, sentence 2. (Or see below.)
>
>> Would " ~
>> ^/phpmyadmin/(.*\.php)$ " not be the longest matching prefix to be
>> selected and remembered?
>
> No. If it starts "~", it's a regular expression.
>

That makes things clearer.

> to handle this request. If the config isn't right, the config isn't right.
>

I mean to say, even though location 4 contains its own config, the
config from location 2 is globally used, thus rendering location 4
requests broken.

>> In my example, nginx was instructing php-fpm to execute
>> /usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?
>
> ...for any urls that matched the regular expression \.php$, yes.
>

More clarification. Thank you, Francis.

> regex locations.
>
>
>>>     The syntax is identical, just those two location blocks are in a
>>>     different place.
>
> Swapping the location blocks was enough to have the block you wanted,
> be the one chosen for this request, because the first regex block that
> matched was the one you wanted to be used. The other changes were then
> presumably enough for the fastcgi server to know which file to process.
>

I still find this confusing: why has this move not broken the generic
location ~\.php$ block, which now comes after the location
/phpmyadmin/(.*\.php)$ block, rendering root requests (sitename.com)
broken? The inverse breaks the /phpmyadmin/(.*\.php)$ config.

> be surprised to learn that there is no "here is how you install on nginx"
> on the phpmyadmin site, or no "here is how you configure phpmyadmin" on
> the nginx web site -- it doesn't seem like an especially unusual thing
> to want to do, and hopefully someone who has done it has advertised what
> they did.
>

This is not as easily found as you might think[1]. Most instructions
available assume a Linux platform. Further, many guides only provide
instructions absent other configuration objectives, which, when
incorporated into existing nginx.conf, breaks something or does not
work; such as, my situation. The configuration I had was pieced from
here[2] and here[3] after reading
nginx.org/en/docs/http/ngx_http_core_module.html#location.

>> Does location ~\.php$ coming before /phpmyadmin/(.*\.php)$ [...]  not emulate
the same situation I
>> created in the first place
>
> No -- "nested" is different from "ordered".
>
> When nginx chooses the one location to use for a request, it chooses
> the one top-level location{} block to use. Within that block, if there
> are further choices to make, they are independent.
>

More clarification! Your explanations are really helpful. How will
having  ~\.php$ nested inside ^~ /phpmyadmin affect the main site
(server root / sitename.com) WordPress administration of PHP? (I think
you may have already answered this with your upcoming example.)

>
> and then whatever other top-level location{} blocks that you want for
> the rest of the server config -- possibly include a "location /" and a
> "location ~ \.php$".
>

So, PHP directives, such as fastcgi_param SCRIPT_FILENAME, contained
within the ~ \.php$ location nested inside the ^~ /phpmyadmin/ location
will not apply to the rest of the site -- only to /phpmyadmin? The
subsequent location ~ \.php$ applies to the rest of the site?

I will attempt to implement the configuration you and John have provided
and will report back with results.

>   f
>

Francis, I really appreciate your assistance, your explanations are
extremely helpful. I am sure it must be mundane educating Dummies, I am
grateful for your time. Thank you very much.

[0]
Alias /phpmyadmin /usr/local/www/phpMyAdmin
<Directory "/usr/local/www/phpMyAdmin">
  Order allow,deny
  Allow from all
</Directory>
[1] http://lmgtfy.com/?q=freebsd+phpmyadmin+nginx
[2] http://blog.stfalcon.com/2009/11/nginx-php-fpm-phpmyadmin/
[3] http://bin63.com/how-to-install-phpmyadmin-on-freebsd

--
syn.bsdbox.co <- for dummies
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2014-01-10 10:37
(Received via mailing list)
On Fri, Jan 10, 2014 at 02:07:34PM +1100, nano wrote:
> On 10/01/2014 7:58 AM, Francis Daly wrote:

Hi there,

just some quick responses to parts...

> It was my mistake assuming Apache logic[0] would be used.

Yes -- in general, in Apache, the configuration that applies to a
request
can come from multiple places. In nginx, it comes from one location,
plus the surrounding contexts.

> I mean to say, even though location 4 contains its own config, the
> config from location 2 is globally used, thus rendering location 4
> requests broken.

Per nginx logic, location 4 is used for every request for which it is
the
"best match". It just happens that there are no such requests. It's the
administrator's job to spot this "brokenness".

> I still find this confusing: why has this move not broken the generic
> location ~\.php$ block, which now comes after the location
> /phpmyadmin/(.*\.php)$ block, rendering root requests (sitename.com)
> broken? The inverse breaks the /phpmyadmin/(.*\.php)$ config.

What request do you make?

What (top-level) location{}s do you have?

Which one location will be chosen for the request?

Try those questions with each of the requests you care about, and see
if you can see why it works.

> >When nginx chooses the one location to use for a request, it chooses
> >the one top-level location{} block to use. Within that block, if there
> >are further choices to make, they are independent.
>
> More clarification! Your explanations are really helpful. How will
> having  ~\.php$ nested inside ^~ /phpmyadmin affect the main site
> (server root / sitename.com) WordPress administration of PHP? (I think
> you may have already answered this with your upcoming example.)

The same questions apply:

What request do you make?

What (top-level) location{}s do you have?

Which one location will be chosen for the request?

> >The suggestion is along the lines of:
> >
> >   location ^~ /phpmyadmin/ {
> >     location ~ \.php$ {

At this point, you could instead use "location ~
^/phpmyadmin/.*\.php$". It will match exactly the same requests --
can you see why?

Depending on the rest of your setup, there may be a reason to use this.

> So, PHP directives, such as fastcgi_param SCRIPT_FILENAME, contained
> within the ~ \.php$ location nested inside the ^~ /phpmyadmin/ location
> will not apply to the rest of the site -- only to /phpmyadmin? The
> subsequent location ~ \.php$ applies to the rest of the site?

Each http request is independent.

Each nginx request is handled in one location.

For each request, only the configuration in, or inherited into, the one
location, applies.

This may seem repetitive; that's because it is. Until you understand
that point, you will not understand nginx configuration.

Good luck with it,

  f
--
Francis Daly        francis@daoine.org
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-10 10:38
(Received via mailing list)
On 10/01/2014 7:58 AM, Francis Daly wrote:
> and then whatever other top-level location{} blocks that you want for
> the rest of the server config -- possibly include a "location /" and a
> "location ~ \.php$".
>

I have done some extensive testing, using the suggestions you and Jim
provided. In summary, the nesting of "location ~ \.php$" inside
"location ^~ /phpmyadmin/" does not work. The error logged is:

[error] 50038#0: *7541 FastCGI sent in stderr: "Primary script unknown"
while reading response header from upstream, client: clientIP, server:
domain.com, request: "GET /phpMyAdmin/ HTTP/1.1", upstream:
"fastcgi://unix:/var/run/php-fpm.sock:", host: "domain.com"

No matter what variation I tried[0], that was the repeated result.

However, the nesting of "~ ^/phpMyAdmin/(.*\.php)$" inside "location ^~
/phpmyadmin/" does work. With everything else the same, this regular
expression works. See the current working configuration, making use of
your nesting advice:

location ^~ /phpmyadmin {
         access_log  off;
         rewrite ^  /phpMyAdmin/ permanent;
}

location /phpMyAdmin {
         root /usr/local/www;
         index index.php index.html;

                 location ~ ^/phpMyAdmin/(.*\.php)$ {
                         root /usr/local/www/;
                         include conf.d/php-fpm;
                 }
}

The included php-fpm[1] file is provided below.

I do not know why your suggested regular expression does not work;
however, your advice to nest does work. Thank you very much for your
repeated efforts to help, it is very much appreciated.

I am interested as to why this is more efficient and considered better
practice than my former configuration[2]? Why the statement:
"DoNotUseAlias (unless necessary)"? My original working setup[2] got the
job done with only two location blocks. Your recommendations require
three and a rewrite. Does this not create more work for the server as
well as more lines of configuration?

Francis, Jim; thank you both very much for your help.


[0] example variations of your suggestions:
https://cloud.bsdbox.co/public.php?service=files&t...

[1] conf.d/php-fpm:
https://cloud.bsdbox.co/public.php?service=files&t...

[2]
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;
}
[3]

--
syn.bsdbox.co <- for dummies
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-10 12:38
(Received via mailing list)
On 10/01/2014 8:36 PM, Francis Daly wrote:
> On Fri, Jan 10, 2014 at 02:07:34PM +1100, nano wrote:
>> On 10/01/2014 7:58 AM, Francis Daly wrote:
>
> Per nginx logic, location 4 is used for every request for which it is the
> "best match". It just happens that there are no such requests. It's the
> administrator's job to spot this "brokenness".
>

Hopefully I can improve my ability to identify and correct mistakes.

>
> The same questions apply:
>
> What request do you make?
>
> What (top-level) location{}s do you have?
>
> Which one location will be chosen for the request?
>

I will contemplate these questions and try to find the right answers.

>>> The suggestion is along the lines of:
>>>
>>>    location ^~ /phpmyadmin/ {
>>>      location ~ \.php$ {
>
> At this point, you could instead use "location ~
> ^/phpmyadmin/.*\.php$". It will match exactly the same requests --
> can you see why?
>

Is it because "~^ /phpmyadmin/.*\.php$" will be the longest prefix
string *and* will be selected because even though nginx would find
regular expressions in the configuration file that match the URI
request, the "^~" modifier instructs nginx to not search the regular
expressions?[0]

> Depending on the rest of your setup, there may be a reason to use this.

I am not sure if the rest of my setup provides reason to not implement
this improved location block: ~^ /phpmyadmin/.*\.php$
The deployments are simply WordPress + phpMyAdmin + ownCloud + Roundcube
with the last two on subdomain vhosts.

>> So, PHP directives, such as fastcgi_param SCRIPT_FILENAME, contained
>> within the ~ \.php$ location nested inside the ^~ /phpmyadmin/ location
>> will not apply to the rest of the site -- only to /phpmyadmin? The
>> subsequent location ~ \.php$ applies to the rest of the site?
>
> Each http request is independent.
>
> Each nginx request is handled in one location.
>

But, doesn't "...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" imply that all requests are subject to the entirety of the
configuration file and not just a specific location block?

For example, if one specifies a location, such as /example/.*\.php$ and
assigns certain directives inside that location block, if there are
other matching expressions (\.php$) in the configuration file, they
could supersede any directives contained within the /example block
simply *because they come before the /example block?*

> For each request, only the configuration in, or inherited into, the one
> location, applies.
>
> This may seem repetitive; that's because it is. Until you understand
> that point, you will not understand nginx configuration.
>

It is good; repetition makes practice. And this point you reiterate is a
rule I am struggling to understand but that needs to be understood.
Thanks again, Francis. Your input is very helpful. Much obliged.

[0] http://nginx.org/en/docs/http/ngx_http_core_module...
"If the longest matching prefix location has the ^~ modifier then
regular expressions are not checked."

--
syn.bsdbox.co <- for dummies
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2014-01-10 16:35
(Received via mailing list)
On Fri, Jan 10, 2014 at 10:37:50PM +1100, nano wrote:
> On 10/01/2014 8:36 PM, Francis Daly wrote:
> >On Fri, Jan 10, 2014 at 02:07:34PM +1100, nano wrote:
> >>On 10/01/2014 7:58 AM, Francis Daly wrote:

Hi there,

This mail is going to sound a bit negative.

> >>>   location ^~ /phpmyadmin/ {
> >>>     location ~ \.php$ {
> >
> >At this point, you could instead use "location ~
> >^/phpmyadmin/.*\.php$". It will match exactly the same requests --
> >can you see why?
>
> Is it because "~^ /phpmyadmin/.*\.php$" will be the longest prefix
> string

No.

"^~" is not the same as "~^". "~^ /" is not the same as "~ ^/".

Read everything very slowly and carefully. The order of the various
squiggles matters.

> >Each nginx request is handled in one location.

> But, doesn't "...the location
<snip>
> used" imply that all requests are subject to the entirety of the
> configuration file and not just a specific location block?

No. Read it again.

What way of phrasing it would allow you to understand that one location
is chosen? Perhaps a documentation patch could be provided.

> For example, if one specifies a location, such as /example/.*\.php$ and
> assigns certain directives inside that location block, if there are
> other matching expressions (\.php$) in the configuration file, they
> could supersede any directives contained within the /example block
> simply *because they come before the /example block?*

No.

One location is chosen.

The configuration in any other location is irrelevant for this request.

There is no superseding across locations. There is no merging across
locations. There is only the configuration in, and inherited into,
the one location that matters for this request.

> It is good; repetition makes practice. And this point you reiterate is a
> rule I am struggling to understand but that needs to be understood.

After you accept that one location is chosen, then you can start
wondering
about what happens when there are nested locations, or when no locations
match, and what happens when there are (e.g. rewrite module) directives
outside of all locations.

But until you accept that one location is chosen, you're unlikely to be
comfortable making new nginx configurations.

  f
--
Francis Daly        francis@daoine.org
852dc51f145bb11af7be64b5ee3fbe88?d=identicon&s=25 nano (Guest)
on 2014-01-12 11:28
(Received via mailing list)
On 11/01/2014 2:34 AM, Francis Daly wrote:
> On Fri, Jan 10, 2014 at 10:37:50PM +1100, nano wrote:
>> On 10/01/2014 8:36 PM, Francis Daly wrote:
>>> On Fri, Jan 10, 2014 at 02:07:34PM +1100, nano wrote:
>>>> On 10/01/2014 7:58 AM, Francis Daly wrote:
>
> Hi there,
>
> This mail is going to sound a bit negative.
>

I find your disposition pleasant and more than generous, not negative at
all, Francis, and I am very grateful for your continued assistance.

> No.
>
> "^~" is not the same as "~^". "~^ /" is not the same as "~ ^/".
>

Another presumption on my part, however, where is the nginx regex
documentation? I cannot seem to find it or even what syntax nginx uses.
Also, what is the answer, I still cannot figure it out?

> No. Read it again.
>
> What way of phrasing it would allow you to understand that one location
> is chosen? Perhaps a documentation patch could be provided.
>

I found the request processing page [0] more explicit and, for me,
comprehensible. A cursory look at any search engine result indicates a
lot of people struggle with this point; your suggestion of a
documentation patch might be a good idea. If I actually understood the
logic of this particular point well enough I would happily contribute to
the development of such documentation.

> The configuration in any other location is irrelevant for this request.
> match, and what happens when there are (e.g. rewrite module) directives
> outside of all locations.
>
> But until you accept that one location is chosen, you're unlikely to be
> comfortable making new nginx configurations.
>
>   f
>

Thank you, Francis. I need to understand what each prefix and regex
character is and what it does. For example, the documentation is clear
that "^~" prefix will stop the search if it matches the request.
However, there is nothing regarding "~^". This might help me better
construct my location blocks and ensure the correct location is used for
each request.

[0] http://nginx.org/en/docs/http/request_processing.html

--
syn.bsdbox.co <- for dummies
28802c1455ba9b8b14838c2934410448?d=identicon&s=25 Axel (Guest)
on 2014-01-12 18:43
(Received via mailing list)
I juggled around with ssl ciphers and tried to disable RC4, but still be
able to serve IE under WinXP.

Those ciphers are my choice - if anyone has 'better' ciphers or prefers
another order i am pleased to hear...

ssl_ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-
AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES256-SHA256:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-

CBC3-SHA:AES256-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!PSK:!RC4:!MD5:!LOW;

You can test your ciphers online at https://www.ssllabs.com

rgds


Am 9.1.2014 10:29, schrieb Pekka.Panula@sofor.fi:
8b0e4dc8d49f6c405d9d915423fd779f?d=identicon&s=25 Darren Pilgrim (Guest)
on 2014-01-12 20:09
(Received via mailing list)
On 1/12/2014 9:42 AM, Axel wrote:
>
CBC3-SHA:AES256-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!PSK:!RC4:!MD5:!LOW;
HIGH will add in only high-grade ciphers, so you don't need to add them
manually or exclude export- and low-grade ciphers.  You can
use @STRENGTH to sort the list for you instead of doing it by hand:

ssl_ciphers HIGH:!CAMELLIA:!RC4:!PSK:!aNULL:@STRENGTH;

XP schannel (IE, Outlook, et al) lacks AES support, IE6 only does SSLv3.
28802c1455ba9b8b14838c2934410448?d=identicon&s=25 Axel (Guest)
on 2014-01-13 10:00
(Received via mailing list)
Am 12.1.2014 20:08, schrieb Darren Pilgrim:
> HIGH will add in only high-grade ciphers, so you don't need to add them
> manually or exclude export- and low-grade ciphers.  You can
> use @STRENGTH to sort the list for you instead of doing it by hand:
>
> ssl_ciphers HIGH:!CAMELLIA:!RC4:!PSK:!aNULL:@STRENGTH;
>
> XP schannel (IE, Outlook, et al) lacks AES support, IE6 only does
> SSLv3.

thx for this info. i'll check the differences.

rgds
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2014-01-14 23:13
(Received via mailing list)
On Sun, Jan 12, 2014 at 09:27:23PM +1100, nano wrote:
> On 11/01/2014 2:34 AM, Francis Daly wrote:
> >>On 10/01/2014 8:36 PM, Francis Daly wrote:
> >>>>On 10/01/2014 7:58 AM, Francis Daly wrote:

Hi there,

> >>>>>   location ^~ /phpmyadmin/ {
> >>>>>     location ~ \.php$ {
> >>>
> >>>At this point, you could instead use "location ~
> >>>^/phpmyadmin/.*\.php$". It will match exactly the same requests --
> >>>can you see why?

> Another presumption on my part, however, where is the nginx regex
> documentation? I cannot seem to find it or even what syntax nginx uses.

I don't think I've ever looked for nginx regex documentation. I think
I've always just used "normal" regex characters, and they worked.

It's not difficult to test. Example below.

One thing that was not immediately obvious to me from the documentation,
was that the whitespace separating the uri from the modifier in the
location directive is optional. But it shows up pretty quickly in
testing
(and is clear from the "real" documentation, which is in the directory
marked "src").

So: knowing that, it may make it easier to interpret other people's
config files.

> Also, what is the answer, I still cannot figure it out?

Which requests would match the original top-level prefix location?

Of those, which would match the first suggested nested regex location?
And
which would match the second suggested nested regex location?

Are there any that would match only one of the two suggested nested
regex locations? If so, they don't match exactly the same requests.

> Thank you, Francis. I need to understand what each prefix and regex
> character is and what it does.

Fair enough. There are four modifiers (plus "no modifier"; plus @,
which is separate).

> For example, the documentation is clear
> that "^~" prefix will stop the search if it matches the request.

Yes, that's one of the four modifiers.

> However, there is nothing regarding "~^".

That's not one of the four modifiers. It is one of the four modifiers
followed by something else. There's also nothing explicit regarding
"~A". Or "~\.".

(If it doesn't start with one of the modifiers, then it is "no
modifier",
which means "prefix string". If *that* doesn't start with /, it is
unlikely to be useful.)

Could """nginx: [emerg] invalid location modifier "~^" in
/usr/local/nginx/conf/nginx.conf:29""" be made clearer? The only way
you won't get that is if you don't have a separate uri in the directive.

> This might help me better
> construct my location blocks and ensure the correct location is used for
> each request.

"starts with ~" means "it's a regex". Everything after the ~ is the
regex. Apart from one documented case which could not be a regex anyway.

If you have as your server block the following:

===
    server {
      listen       8888;
      location / { return 200 "location / \n"; }
      location ~A { return 200 "location ~A \n"; }
      location ~ \. { return 200 "location ~ \. \n"; }
      location = / { return 200 "location = / \n"; }
    }
===

Then can you predict the response to each of:

  curl http://localhost:8888/path
  curl http://localhost:8888/
  curl http://localhost:8888/A.A

Add your sample locations, make your sample requests, understand why
each location was chosen each time.

Add

    debug_connection 127.0.0.1;

to the "events{}" block if you want to see lots more in the error log.

Good luck with it,

  f
--
Francis Daly        francis@daoine.org
40b4c848b8fcd63b0cb60b9d170c3a77?d=identicon&s=25 Valentin V. Bartenev (Guest)
on 2014-01-15 20:19
(Received via mailing list)
On Sunday 12 January 2014 21:27:23 nano wrote:
[..]
> Another presumption on my part, however, where is the nginx regex
> documentation? I cannot seem to find it or even what syntax nginx uses.

Nginx uses PCRE.  The documentation should be available in your system:

$ man pcrepattern
$ man pcresyntax

  wbr, Valentin V. Bartenev
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.