On 7/9/2013 5:47 PM, Francis D. wrote:
On Tue, Jul 09, 2013 at 04:48:27PM -0400, Ben J. wrote:
I am working with a server configuration that is partly outside of my
I suspect that that’s not the intended use case for nginx. Whoever writes
the config file has the opportunity to configure it not to start.
To be clear, this lack of control is not due to a lack of privileges; I
use ISPConfig, which has its own way of doing things (and it usually
knows best, based on past experience).
and have a need to overwrite a fastcgi_param “after” the
directives that are outside of my control have already been included.
That sentence is possible; but not the one in your Subject: line.
I see; there is a distinction to be made. Thanks for making it.
This is the include file that I am able to modify.
That line must be within the “location @php” block, in order for it to
do what you want.
Okay; this means that I would need to modify the ISPConfig virtual host
template for nginx. I would love to avoid that, if at all possible, for
compatibility with future ISPConfig releases.
in my-include.conf, but that would be a good way to lose config privileges
on the server.)
No concerns in this regard; I administer the server. But it seems like
taking that measure would defeat the purpose of using ISPConfig.
Is it possible for me to overwrite the values that are defined on the
line “include /etc/nginx/fastcgi_params;” from within the included file
that I can modify, “my-include.conf”?
Current nginx sends all fastcgi_params that are defined, in order; so
if you set the same one multiple times in the same context, all are sent.
I see. Presumably, if I set the same fastcgi_param multiple times in
different contexts, any content in which inheritance applies will
overwrite any previously-defined value with the new value. Is this
presumption correct? It seems so, based on the documentation regarding
Your fastcgi server probably only pays attention to the first one
received, or maybe to the last one received. Test to find out.
When you know which it is, put your “include” line before or after the
other “include” line, and see how it works.
It seems that my FastCGI service is concerned with the last value only.
If I place the my preferred value after ISPConfig’s include line, it is
Future nginx may stop sending all repeated fastcgi_params. If you change
fastcgi server, the one it pays attention to may change. So your testing
should be repeated after every upgrade.
Perhaps it is prudent to proceed under this proviso. Maybe I can find a
way to make this work, using ISPConfig’s configuration template
“merging” functionality, to make this work.
I’ll post back with my findings.
Thanks for all your help, Francis. Very thorough, as always.