On 6/26/2013 5:33 PM, Francis Daly wrote:
> On Wed, Jun 26, 2013 at 10:22:21AM -0400, Ben Johnson wrote:
>
> Hi there,
>
>> I was able to accomplish my objective with some help from the tutorial
>> at:
>
> It's good that you've got it working now.
>
> There are a few things that you might like to consider when deploying
> it across all vhosts.
>
> First: for a request, nginx picks one server and then one location
> to process things in. So for this configuration to be common across
> multiple servers, you either must copy-paste it into each; or else put
> it in an external file and "include" that file in each per-server config
> that matters.
>
That's exactly what I've done; these directives reside within an include
file that I include from within each vhost's main configuration.
>> location /pma {
>
> Next, you probably want this to become "location ^~ /pma" -- or maybe
> even "location ^~ /pma/", with a separate "location = /pma {return 301
> /pma/;}" block.
>
> http://nginx.org/r/location for the details of why that is.
>
> (Hint: try to access /pmap, or /index.php, and you may see that things
> go wrong.)
>
Attempting to access /pmap yields a 404, and /index.php brings-up the
site's primary index page (unrelated to PMA), but that may due to other
"location {}" blocks that ISPConfig (which I'm using to create each
vhost) includes in the nginx vhost configuration template.
In any case, what you say makes sense, and I see how using a regular
expression without a right-side anchor or a trailing slash could lead to
unexpected results, as your examples describe.
Do you happen to know if regular expressions in this context are
anchored, implicitly, if a least one explicit anchor is not specified?
>> root /var/www/;
>> index index.php index.html index.htm;
>> location ~ ^/pma/(.+\.php)$ {
>> try_files $uri =404;
>> root /var/www/;
>
> That line, because it is identical to the enclosing one, probably does
> nothing useful and can be removed.
>
Are you referring to the two "root /var/www/" lines? If so, then what
you say makes sense, and I'll remove the second/duplicate line.
>> fastcgi_pass unix:/var/run/php5-fpm.sock;
>> fastcgi_param HTTPS on;
>
> You may be able to use the $https variable there, if you want to share
> this config with both http and https servers *and* want to tell the
> php server the truth about the original connection. But that's not
> critical here.
>
I don't want PMA (anything within the /pma/ location) to be accessible
over a plaintext connection. In other words, I wish to force HTTPS.
Do I need to add something something like this to the location block?
rewrite ^ https://domain.com$request_uri? permanent;
(Ideally, I would like the "domain.com" part to be dynamic, so it works
for all vhosts; would I use $host, $server_name? Something else entirely?)
>> fastcgi_index index.php;
>> fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>> include /etc/nginx/fastcgi_params;
>> }
>> location ~* ^/pma/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
>> root /var/www/;
>> }
>
> That 3-line section, I don't think does anything useful as-is.
>
> With it, requests that match are served from the filesystem below
> /var/www/; while requests that don't match are served from the filesystem
> below /var/www/.
>
> Without it, requests won't match and so will be served from the filesystem
> below /var/www/.
>
I see; that makes sense, and I'll remove that location block.
>> }
>> location /PMA {
>> rewrite ^/* /pma last;
>> }
>
> That will match both /PMA and /PMA/, which are probably what you want.
>
> It will also match /PMAP, which may be unrelated; and it will match
> /PMA/file.png and rewrite it to just /pma, which may not be wanted.
>
Ah! Right you are, sir. /PMAP and /PMA/file.png are matched, which is
undesirable.
> The rewrite itself could omit the "/*" part and have the same effect.
>
> I would suggest actively redirecting to the correct /pma/ url, rather
> than trying an internal rewrite -- but again, if what you have works
> for you, it's good enough.
>
I'm not the type to accept "good enough". I want it to be perfect :).
What would be your preferred course of action to eliminate the internal
rewrite and instead perform an external redirect for /pma, /PMA, and
/PMA/ (all redirected to /pma/)?
The documentation states, "There is no syntax for NOT matching a regular
expression. Instead, match the target regular expression and assign an
empty block, then use location / to match anything else."
If I'm not mistaken, the location below would match all of the
"incorrect" variants that I listed above:
location ~* /pma {
}
But then I'm confused as to where the "return 301 /pma/;" needs to be
placed, if anywhere.
To be clear, I have a "normal website" running on this vhost (a
customer's own site), so I had assumed that I can't use an empty
location block, as the manual suggests, and fall-back to "location /".
Somewhat surprisingly, including the above location block actually works
to redirect /pma, /PMA, and /PMA/ to /pma, while still allowing the
"normal site content" to function correctly.
Is this because I have the following directive just before the
PMA-related bit we've been discussing?
location / {
try_files $uri $uri/ @virtual;
}
location @virtual {
if ($uri !~ '/$') {
return 301 $uri/$is_args$args;
}
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/lib/php5-fpm/web2.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
rewrite ^(.*)$ /index.php?q=$1 last;
}
>> I don't know if the key is the nested location block, or something else.
>> If anyone is able to point-out the fundamental differences between the
>> configuration snippet that I posted previously and the snippet above,
>> which actually works, I would be most appreciative.
>
> You posted a few snippets previously. That last ones where you reported
> 404s, I failed to reproduce the 404s. They worked for me.
>
> Possibly there was something else in the full configuration that meant
> that the location{}s you showed were not the chosen ones for the requests
> you made?
>
That is quite possible and very likely. I am adding my own directives to
ISPConfig's nginx vhost configuration template, and at my limited level
of experience with nginx, I probably failed to realize that my location
blocks were being ignored in favor of another preferred match.
> f
>
I really appreciate you sharing your time and expertise to get me
off-the-ground. I am learning a lot from you and I am profoundly
thankful for your detailed insights.
Respectfully,
-Ben
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
