Trouble adding /pma location to all virtual hosts

[Francis Daly]

On Thu, Jun 27, 2013 at 12:42:34PM -0400, Ben Johnson wrote:
> 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,

> That's exactly what I've done; these directives reside within an include
> file that I include from within each vhost's main configuration.

Good stuff.

Note that "include" is sort-of invisible to the rest of the nginx
configuration, so the rules for selecting the one location{} which
handles a request may lead to different results depending on where in
the file the "include" line is, if you use any regex location blocks.

(The easy way to avoid that is not to use any top-level regex locations.)

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

That's what I expect. I suspect that even after you add the file
$document_root/pmap, it will still yield a 404, which may not be what
you expect.

> and /index.php brings-up the
> site's primary index page (unrelated to PMA),

That is a bit of a surprise to me; but it does all depend on what
top-level location definitions appear in the server block.

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

I do; they aren't; but these aren't regular expressions. The characters
after the word "location" mean something. Check the docs if you're not
clear on exactly which location is used for each request -- it'll make
further configuration understanding much easier.

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

Correct. "root" is inherited, so setting it like this is unnecessary but
not incorrect. It only becomes incorrect if you change one and expect
the other to auto-change.

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

Ah, ok.

That fastcgi_param line merely tells the php server that https was used
to access this url. With $https, it would tell the php server whether
https was used to access this url.

> Do I need to add something something like this to the location block?

Yes.

You've got the right answer in another mail.

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

Keep it simple.

  location = /pma { return 301 /pma/; }
  location = /PMA { return 301 /pma/; }
  location = /PMA/ { return 301 /pma/; }

> If I'm not mistaken, the location below would match all of the
> "incorrect" variants that I listed above:
> 
> location ~* /pma {

That location would match any url that contains the four character string,
case insensitive, "/pma". Unless the url was already matched by another ^~
or ~ or ~* location.

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

The details matter.

One request, one location.

When you list all of the top-level locations in the server{}, then you
should be able to say which one will match a particular request.

(After considering rewrites.)

"empty location block" usually means "serve from the filesystem".

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

Does it also allow you to get at /pma/index.php? That would surprise me --
but that's because I'm guessing what the rest of the configuration is.

> Is this because I have the following directive just before the
> PMA-related bit we've been discussing?

Maybe.

The full list of the top-level location lines should make it clear to you,
along with any server-level rewrite module directives.

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

You're welcome.

Glad to be of help.

	f
-- 
Francis Daly        francis at daoine.org