Set variables within config


#1

I haven’t seen any way to do this in the docs, so this might be more of
a feature request, but if someone knows of a way to accomplish this that
I missed, let me know.

I’d really like to be able to set a variable in the config and then use
it to set other settings, with the ultimate goal of DRYing up the config
file. For instance, right now I’ve got many different ‘server’ blocks,
each with a few lines that look like…

root /var/www/domain1/current/public;
access_log /var/www/domain1/shared/log/nginx.access.log;
error_log /var/www/domain1/shared/log/nginx.error.log;

Lots of repetition there. Would be great if instead I could say…

$basepath = /var/www/domain1
root $basepath/current/public;
access_log $basepath/shared/log/nginx.access.log;
error_log $basepath/shared/log/nginx.error.log;

And then even better to be able th extract out those last three lines
into a paths.conf file (or something), so that each server block could
just say…

$basepath = /var/www/domain#
include paths.conf

http://www.5valleys.com/

http://www.workingwithrails.com/person/8078


#2

Hello!

On Thu, May 14, 2009 at 10:59:26AM -0600, Jon G. wrote:

access_log /var/www/domain1/shared/log/nginx.access.log;
into a paths.conf file (or something), so that each server block could
just say…

$basepath = /var/www/domain#
include paths.conf

As of now nginx has no variables expanded during config loading -
everything expaneded during request processing. So using
variables just to save some config lines is somewhat stupid as it
means wasting lots of CPU time for every request.

If you really need to simplify configs - it’s easy to generate
them using make and sed.

Maxim D.


#3

I do this, for fastcgi ports currently.

Igor says it is supported, but I am running into an issue and I can’t
reproduce it yet but it is happening (today I actually have to fix it)

You can do this as long as the parameter you are using supports
variables. I am not sure if all of them do or not. The error_log might
not for example; not sure. Might be a nice thing to add to the wiki,
under the context it is accepted, whether or not it parses variables
too. (and perhaps parses captures?)


#4

Maxim D. wrote:

variables just to save some config lines is somewhat stupid as it
means wasting lots of CPU time for every request.

If you really need to simplify configs - it’s easy to generate
them using make and sed.

Maxim D.

Well, then that sounds like a great candidate for an Nginx enhancement
at some point in the future.

http://www.5valleys.com/

http://www.workingwithrails.com/person/8078


#5

On Thu, May 14, 2009 at 12:32 PM, Maxim D. removed_email_address@domain.invalid
wrote:

As of now nginx has no variables expanded during config loading -
everything expaneded during request processing. Â So using
variables just to save some config lines is somewhat stupid as it
means wasting lots of CPU time for every request.

If you really need to simplify configs - it’s easy to generate
them using make and sed.

This might be what Igor meant by “configuration macros”?

Interesting. Will have to examine if I am abusing variables that much
in real-time in my configurations!


#6

On Thu, 2009-05-14 at 13:39 -0700, Michael S. wrote:

This might be what Igor meant by “configuration macros”?
If you wanted, you could probably even leverage some template engine
(typically used for HTML generation, but often useful standalone) to
generate configs.

Cliff


#7

yeah i have a script to build some configs already. but to match
production i have to pull out the common stuff and put it into .conf
files, and then set $var something; include foo.conf; so that the
configs match on dev and production but the dynamic pieces are filled
in appropriately per user/environment.


#8

On Thu, May 14, 2009 at 2:01 PM, Cliff W. removed_email_address@domain.invalid wrote:

If you wanted, you could probably even leverage some template engine
(typically used for HTML generation, but often useful standalone) to
generate configs.

It would be neat if nginx had an “include_exec” command that executed
its argument and processed the output for configuration directives.

http {
include_exec “my_config.pl”
}

and then my_config.pl could query a DB for information about servers,
or whatever.

-dave


#9

On Thu, May 14, 2009 at 01:39:26PM -0700, Michael S. wrote:

This might be what Igor meant by “configuration macros”?
No, by “configuration macros” I meant nginx built-in macros, but not
using exteranl tools such as make, sed, etc.

One of the problem is how to distinguish syntactically these future
macros
from run-time variables, i.e.

root $root;
root ${root};

vs

root %root;
root %{root};

or something else.


#10

2009/5/14 Igor S. removed_email_address@domain.invalid:

No, by “configuration macros” I meant nginx built-in macros, but not
using exteranl tools such as make, sed, etc.

Correct, I don’t consider external tools to be anything you’d be
concerned with :slight_smile:

I meant the whole

if ($1 == ‘foo’) {
include something.conf;
}