You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Yonts, Richard" <Ri...@smss.sony.com> on 2010/03/18 19:45:52 UTC
Question about LoadModule inside container
An Apache server was misconfigured where a LoadModule directive was inside a <VirtualHost *:444> definition. I have found a smattering of documentation saying that the LoadModule must be in the server context, not a container context. Assuming is correct, I have a question about what I did observe.
My module created a server configuration and initialized it, one flag of which was that the initialization was complete. When a Location directive was hit, the initialized data gets displayed. Here is the oddity: When I hit the Location from anything other than port 444, I would see the initialized data; however, when I hit the Location using port 444, the data was uninitialized. Why?
I would expect that the port 444 config block would be the initialized one and every other one would be uninitialized, but I observed the exact opposite. I think that in this case there would be two server config blocks, one for 444 and one in general. Of course, I can find no documentation to explain this, and possibly it needs no explanation, but does anyone have a reasonable idea as to what is going on?
I moved the LoadModule outside the virtual container and all works as expected; I simply remain puzzled why it broke "backwards".
Thank you,
Rich Yonts
sola fide, sola gratia, solus Christus, sola Scriptura, soli Deo gloria
****** ***** **
Re: Question about LoadModule inside container
Posted by Graham Leggett <mi...@sharp.fm>.
On 19 Mar 2010, at 7:21 PM, Jeff Trawick wrote:
> We came to the same conclusion ("don't") but via a different path.
>
> The LoadModule directive is already provided the global server_rec in
> the command_rec structure, whether or not it appears inside a
> <VirtualHost *>, by virtue of the EXEC_ON_READ flag. So using an
> expected server_rec for LoadModule doesn't seem to be the cause of
> Rich's problem symptom, and the usual code to disable a directive
> inside <VirtualHost > doesn't work/isn't needed.
>
> I don't know what caused the weird symptoms.
We uncovered a problem a while back with mod_perl, which in our case
was being used to load some httpd config against a wildcard directory
path, because the Include directive couldn't do it natively. As soon
as an attempt was made to run a LoadModule from within a config that
had been included with mod_perl's include functionality (the <Perl>
tags), the server would segfault on startup. As soon as mod_perl's
include functionality was removed from the config, everything worked
again.
This problem inspired the wildcard directory fixes that were recently
proposed for backport to v2.2. For us we had hacked around the lack of
support for wildcard directories with mod_perl, and it was easier to
fix the Include directive to support wildcards fully and remove our
hack than dig to the bottom of the problem at the time.
Regards,
Graham
--
Re: Question about LoadModule inside container
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Mar 19, 2010 at 1:12 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 19 Mar 2010, at 6:58 PM, Jeff Trawick wrote:
>
>> LoadFile and LoadModule should both ensure that they're coded at
>> global scope, or report a configuration error. That logic was added
>> to the 1.3 branch but lost in 2.0 and later.
>>
>> http://svn.apache.org/viewvc?view=revision&revision=87244
>>
>> I'll fix trunk.
>
> -1, please don't.
>
> We are trying to educate our users to declare modules just before they
> attempt to use them, instead of enabling every single module under the sun
> globally, and then suffering the performance penalty of doing so. The nett
> effect is the server is never bigger than it needs to be at any given time.
>
> The ability to load modules in a virtual host allows you to do this, and is
> an entirely valid configuration:
We came to the same conclusion ("don't") but via a different path.
The LoadModule directive is already provided the global server_rec in
the command_rec structure, whether or not it appears inside a
<VirtualHost *>, by virtue of the EXEC_ON_READ flag. So using an
expected server_rec for LoadModule doesn't seem to be the cause of
Rich's problem symptom, and the usual code to disable a directive
inside <VirtualHost > doesn't work/isn't needed.
I don't know what caused the weird symptoms.
Re: Question about LoadModule inside container
Posted by Graham Leggett <mi...@sharp.fm>.
On 19 Mar 2010, at 6:58 PM, Jeff Trawick wrote:
> LoadFile and LoadModule should both ensure that they're coded at
> global scope, or report a configuration error. That logic was added
> to the 1.3 branch but lost in 2.0 and later.
>
> http://svn.apache.org/viewvc?view=revision&revision=87244
>
> I'll fix trunk.
-1, please don't.
We are trying to educate our users to declare modules just before they
attempt to use them, instead of enabling every single module under the
sun globally, and then suffering the performance penalty of doing so.
The nett effect is the server is never bigger than it needs to be at
any given time.
The ability to load modules in a virtual host allows you to do this,
and is an entirely valid configuration:
<IfModule !mod_foo.c>
LoadModule foo_module modules/mod_foo.so
</IfModule>
FooDirective bar
Regards,
Graham
--
Re: Question about LoadModule inside container
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Mar 18, 2010 at 2:45 PM, Yonts, Richard
<Ri...@smss.sony.com> wrote:
> An Apache server was misconfigured where a LoadModule directive was inside a
> <VirtualHost *:444> definition. I have found a smattering of documentation
> saying that the LoadModule must be in the server context, not a container
> context. Assuming is correct, I have a question about what I did observe.
>
>
>
> My module created a server configuration and initialized it, one flag of
> which was that the initialization was complete. When a Location directive
> was hit, the initialized data gets displayed. Here is the oddity: When I
> hit the Location from anything other than port 444, I would see the
> initialized data; however, when I hit the Location using port 444, the data
> was uninitialized. Why?
>
>
>
> I would expect that the port 444 config block would be the initialized one
> and every other one would be uninitialized, but I observed the exact
> opposite. I think that in this case there would be two server config
> blocks, one for 444 and one in general. Of course, I can find no
> documentation to explain this, and possibly it needs no explanation, but
> does anyone have a reasonable idea as to what is going on?
>
>
>
> I moved the LoadModule outside the virtual container and all works as
> expected; I simply remain puzzled why it broke “backwards”.
My guess is that your module's server_config creation and merging was
broken because the LoadModule-driven call to create the server_config
structure used the vhost-specific server_rec instead of the global
server_rec. At a later point the vhost-specific config would be
created again if your module had directives in that vhost, or be
uninitialized.
LoadFile and LoadModule should both ensure that they're coded at
global scope, or report a configuration error. That logic was added
to the 1.3 branch but lost in 2.0 and later.
http://svn.apache.org/viewvc?view=revision&revision=87244
I'll fix trunk.