Possible to overwrite a fastcgi_param "later", once a location block has already been closed?

Server NGINX
1

Hello,

I am working with a server configuration that is partly outside of my
control, and have a need to overwrite a fastcgi_param “after” the
directives that are outside of my control have already been included.

The basics of the configuration are:

[…]

location ~ .php$ {
try_files /2ed86bea62460140e9b23d047f7d68b1.htm @php;
}

location @php {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9013;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
}

At this point, the fastcgi_param values have already been defined.

This is the include file that I am able to modify.

include my-include.conf

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

In particular, I would like to hard-code the SERVER_NAME value within
“my-include.conf”.

Thanks for any help,

-Ben

2

On Tue, Jul 09, 2013 at 04:48:27PM -0400, Ben J. wrote:

Hi there,

I am working with a server configuration that is partly outside of my
control,

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.

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.

This is the include file that I am able to modify.

include my-include.conf

That line must be within the “location @php” block, in order for it to
do what you want.

(Otherwise, you could try completely hijacking the config by using
something like

location ^~ / {
location ~ php$ {
# you control what goes here
}
# and what goes here
}

in my-include.conf, but that would be a good way to lose config
privileges
on the server.)

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.

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.

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.

f

Francis D. [email protected]

3

On 7/9/2013 5:47 PM, Francis D. wrote:

On Tue, Jul 09, 2013 at 04:48:27PM -0400, Ben J. wrote:

Hi there,

I am working with a server configuration that is partly outside of my
control,

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

This is the include file that I am able to modify.

include my-include.conf

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

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

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.

f

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.

-Ben

4

On Tue, Jul 09, 2013 at 08:13:16PM -0400, Ben J. wrote:

On 7/9/2013 5:47 PM, Francis D. wrote:

Hi there,

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.

You could just modify /etc/nginx/fastcgi_params, but that may not suit
depending on other considerations.

(Otherwise, you could try completely hijacking the config by using

No concerns in this regard; I administer the server. But it seems like
taking that measure would defeat the purpose of using ISPConfig.

Correct.

The usual nginx rules of one request is handled in one location, and
inheritance is by replacement or not at all, mean this is so.

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?

If you set any fastcgi_param in one context, no fastcgi_param is
inherited
into that context.

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.

On the nginx side, if it does ever stop sending multiple values,
presumably it will be clear which single value it will send. At that
point, it won’t matter what your fastcgi server does with multiple
values. So it’s a relatively straightforward test after each upgrade.

Maybe I can find a
way to make this work, using ISPConfig’s configuration template
“merging” functionality, to make this work.

The good news is that nginx doesn’t care how the config file is created
:slight_smile:

You can add your “include” directive, or you can use an external macro
function to get the right lines into the right location.

Possibly this tool has a facility like that.

Thanks for all your help, Francis. Very thorough, as always.

Cheers; good luck with it,

f

Francis D. [email protected]