Welcome! Log In Create A New Profile

Advanced

Re: PHP below server root not served

nano
January 09, 2014 10:08PM
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.

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

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.

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

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

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

>> An example would help immensely and be very much appreciated.
>
> 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$".
>

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.

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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

SSL ciphers, disable or not to disable RC4?

Anonymous User January 09, 2014 04:30AM

Re: SSL ciphers, disable or not to disable RC4?

nano January 09, 2014 04:44AM

Re: SSL ciphers, disable or not to disable RC4?

Jeffrey Walton January 09, 2014 04:54AM

RE: SSL ciphers, disable or not to disable RC4?

Lukas Tribus January 09, 2014 04:54AM

Re: SSL ciphers, disable or not to disable RC4?

Jeffrey Walton January 09, 2014 05:06AM

PHP below server root not served

nano January 09, 2014 05:26AM

Re: PHP below server root not served

Richard Stanway January 09, 2014 05:30AM

Re: PHP below server root not served

nano January 09, 2014 05:34AM

Re: PHP below server root not served

Francis Daly January 09, 2014 05:56AM

Re: PHP below server root not served

nano January 09, 2014 06:46AM

Re: PHP below server root not served

nano January 09, 2014 07:42AM

Re: PHP below server root not served

B.R. January 09, 2014 08:00AM

Re: PHP below server root not served

nano January 09, 2014 08:52AM

Re: PHP below server root not served

Francis Daly January 09, 2014 04:00PM

Re: PHP below server root not served

nano January 09, 2014 10:08PM

Re: PHP below server root not served

Francis Daly January 10, 2014 04:38AM

Re: PHP below server root not served

nano January 10, 2014 06:40AM

Re: PHP below server root not served

Francis Daly January 10, 2014 10:36AM

Re: PHP below server root not served

nano January 12, 2014 05:28AM

Re: PHP below server root not served

Francis Daly January 14, 2014 05:14PM

Re: PHP below server root not served

Valentin V. Bartenev January 15, 2014 02:20PM

Re: PHP below server root not served

nano January 10, 2014 04:38AM

Re: PHP below server root not served

nano January 09, 2014 09:44AM

Re: PHP below server root not served

Jim Ohlstein January 09, 2014 12:14PM

Re: PHP below server root not served

nano January 09, 2014 12:30PM

Re: SSL ciphers, disable or not to disable RC4?

Axel January 12, 2014 12:44PM

Re: SSL ciphers, disable or not to disable RC4?

Darren Pilgrim January 12, 2014 02:10PM

Re: SSL ciphers, disable or not to disable RC4?

Axel January 13, 2014 04:02AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 50
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready