Environment confusion
Hi all,
I have just been picking apart the way that environment variables are
handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd to
include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed in
the config line, so far so good.
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
In this case, SetEnv sets a variable within mod_env's server-vars, but
this is ignored by ap_resolve_env, and so doesn't work as the user might
expect it to.
Zooming in some more on the way mod_env's environment works.
The mod_env environment in server-vars starts off empty, and then is
populated by explicit allocation (SetEnv), or by copying the value from
a system environment variable to a mod_env environment variable (PassEnv).
Would it make sense when parsing the config to try and insert mod_env's
server-vars variables first, and then if not present, fall back to (the
current behaviour of) looking at the system environment?
This will make some interesting templating options possible, and will
probably make lives easier for people doing mass hosting.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Environment confusion
On 10/20/08 1:19 PM, Graham Leggett [EMAIL PROTECTED] wrote: This will make some interesting templating options possible, and will probably make lives easier for people doing mass hosting. Seems like a place to get a lot of bug reports as well. I choose to just use a real template system to handle configs. I'm sure I'm not the only one. I'm +0 -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Environment confusion
On Oct 20, 2008, at 1:19 PM, Graham Leggett wrote:
Hi all,
I have just been picking apart the way that environment variables
are handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd
to include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed
in the config line, so far so good.
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
In this case, SetEnv sets a variable within mod_env's server-vars,
but this is ignored by ap_resolve_env, and so doesn't work as the
user might expect it to.
Zooming in some more on the way mod_env's environment works.
The mod_env environment in server-vars starts off empty, and then
is populated by explicit allocation (SetEnv), or by copying the
value from a system environment variable to a mod_env environment
variable (PassEnv).
Would it make sense when parsing the config to try and insert
mod_env's server-vars variables first, and then if not present,
fall back to (the current behaviour of) looking at the system
environment?
This will make some interesting templating options possible, and
will probably make lives easier for people doing mass hosting.
But isn't that 2 different things? Do we really want WEBAPP to be in
the running process env space and contaminate that? If people want
macros
I tend to point them to mod_macro, which I like quite a bit...
Re: Environment confusion
Graham Leggett wrote:
Hi all,
I have just been picking apart the way that environment variables are
handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd to
include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed in
the config line, so far so good.
Actually the feature is just undocumented, and has existed since 2.0
(maybe 1.3 too?)
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
In this case, SetEnv sets a variable within mod_env's server-vars, but
this is ignored by ap_resolve_env, and so doesn't work as the user might
expect it to.
-0, I would prefer to use a 'real' template language for configs, rather
than continuing to expand our current hacks upon hacks.
-Paul
Re: Environment confusion
Paul Querna schrieb:
Graham Leggett wrote:
Hi all,
I have just been picking apart the way that environment variables are
handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd
to include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed in
the config line, so far so good.
Actually the feature is just undocumented, and has existed since 2.0
(maybe 1.3 too?)
No, not 1.3. For 1.3 there was a simple module mod_define which came as
contrib in the mod_ssl package. I ported mod_define to 2.0 and 2.2
because I found it still useful: you can't change real environment
variables during graceful or restart, because the parent process doesn't
get a new environment. mod_define allows to either get the vars from the
process environment or via variable defines inside the config files,
which can of course be changed and activated via restarts.
I once asked about any interest on mod_define (could be ASL) on this
list, but got the hint about the support of environment variables
starting with 2.0 as a response.
mod_define and mod_macro are somewhat orthogonal. mod_macro allows you
to reuse config templates with variable parametrization in the
configuration, mod_define allows you to use the same value in very
different places of the config, without putting it in every time (e.g.
path values etc.). Instead you use a variable and thus managing the
values gets easier. An Example is a setup, that separates the httpd
product directory (modules etc.) from the instance directory (conf etc.)
and var part (logs, run) without fixig everything in a build layout. You
prepend three variables like APACHE_HOME, APACHE_BASE and APACHE_VAR to
the respective pathes and set them once according to your needs.
If httpd internal envvars were usable in configs, then of course
mod_define would be superfluous.
Concerning mod_macro: VirtualHost elements do not work inside Macros. I
never investigated wha.
Regards,
Rainer
Re: Environment confusion
On Mon, 20 Oct 2008 19:19:58 +0200
Graham Leggett [EMAIL PROTECTED] wrote:
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
Indeedie. Not IMHO a good thing, but to change it now would be worse.
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
Your argument here appears to point towards the functionality
of mod_macro.
In this case, SetEnv sets a variable within mod_env's server-vars,
but this is ignored by ap_resolve_env, and so doesn't work as the
user might expect it to.
Zooming in some more on the way mod_env's environment works.
The mod_env environment in server-vars starts off empty, and then is
populated by explicit allocation (SetEnv), or by copying the value
from a system environment variable to a mod_env environment variable
(PassEnv).
Would it make sense when parsing the config to try and insert
mod_env's server-vars variables first, and then if not present, fall
back to (the current behaviour of) looking at the system environment?
This will make some interesting templating options possible, and will
probably make lives easier for people doing mass hosting.
We have a start on enabling this with the expression parser, which
enables configuration sections to be applied conditionally on an
expression evaluated at runtime. That's work-in-progress and needs
revisiting, but it can use env vars in its expression evaluation,
and templating with them should be a natural future direction.
(and of course, you can always use mod_rewrite).
--
Nick Kew
