Trouble adding /pma location to all virtual hosts

Ben Johnson ben at
Thu Jun 27 16:42:34 UTC 2013

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.
> 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 ^$request_uri? permanent;

(Ideally, I would like the "" 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

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



More information about the nginx mailing list