Forum: NGINX set variables within config

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jon G. (Guest)
on 2009-05-14 21:07
(Received via mailing list)
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
Michael S. (Guest)
on 2009-05-14 21:16
(Received via mailing list)
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?)
Maxim D. (Guest)
on 2009-05-14 23:46
(Received via mailing list)
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.
Jon G. (Guest)
on 2009-05-15 00:24
(Received via mailing list)
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
Michael S. (Guest)
on 2009-05-15 00:50
(Received via mailing list)
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!
Cliff W. (Guest)
on 2009-05-15 01:11
(Received via mailing list)
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
Michael S. (Guest)
on 2009-05-15 01:23
(Received via mailing list)
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.
Dave Bailey (Guest)
on 2009-05-15 01:56
(Received via mailing list)
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
Igor S. (Guest)
on 2009-05-15 09:25
(Received via mailing list)
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.
Michael S. (Guest)
on 2009-05-15 09:38
(Received via mailing list)
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 :)

I meant the whole

if ($1 == 'foo') {
   include something.conf;
}
This topic is locked and can not be replied to.