Trouble adding /pma location to all virtual hosts

[Ben Johnson]

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