You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Rick Myers <ri...@sumthin.nu> on 2002/01/11 02:11:58 UTC
multiple configurations
This may sound silly, but is there an *easy* way to test
multiple server config's?
For example, I have a perl module that defines a new
RSRC_CONF directive that I want to test in every possible
way. To do that I need one server with no use of the module
(to validate the test, I guess), one server that uses the
directive in only the global area, and others for various
combinations of global vs. virtual use.
The only way I can see to make this happen is to write
various extra .conf.in's and remove includes from the
httpd.conf file as each test runs. To make it work I have to
HUP the server after editing httpd.conf in each test, but
while using -X the server just dies.
I managed to figure out a way around -X and keep the server
alive beyond the HUP, but it's a real pain. The end result
is overloading Apache::Test::config,
Apache::TestConfig::new_test_server, and
Apache::TestRunPerl::new_test_config -- all just to get back
to the point where I can finally overload
Apache::TestServer::start_cmd and leave out the $one.
Thoughts?
Rick Myers rik@sumthin.nu
----------------------------------------------------
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
Re: multiple configurations
Posted by Rick Myers <ri...@sumthin.nu>.
On Jan 15, 2002 at 11:25:06 +0800, Stas Bekman wrote:
>
> >>I think the first thing to figure out is whether you can have all the
> >>desired configuration co-exist using VirtualHosts, so you won't need to
> >>restart the server. I think you should be able to accomplish that.
> >>
> >>Once you do, I can think of many .pm response handlers include some
> >>httpd.conf bits in various VirtualHosts. So you can re-use these.
> >>
> >
> > Been there. :)
> >
> > # global
> > NewDirective On
> > <VirtualHost 1.2.3.4>
> > ServerName foobar
> > NewDirective Off
> > </VirtualHost>
> > <VirtualHost 1.2.3.4>
> > ServerName bazbam
> > </VirtualHost>
> >
> > vs.
> >
> > # global
> > NewDirective Off
> > <VirtualHost 1.2.3.4>
> > ServerName foobar
> > NewDiretive Off
> > </VirtualHost>
> > <VirtualHost 1.2.3.4>
> > ServerName bazbam
> > </VirtualHost>
> >
> > In each case, how should the bazbam virtual react? And the
> > better question (and the reason for testing) is, will my
> > module do what it's supposed to do? I don't see much way
> > around restarting the server to test for that.
>
>
> That's true, unless you can test the directive from within VirtualHost,
> i.e. not to set it on the global level at all. something like that:
>
>
> <VH ..>
> ND On
> <Loc ...>
> ND Off
> </Loc..>
>
> <Loc ...>
> ND On
> </Loc..>
> </VH>
>
> <VH ..>
> ND Off
> <Loc ...>
> ND Off
> </Loc..>
>
> <Loc ...>
> ND On
> </Loc..>
> </VH>
>
> so each VH behaves as a standalone server.
Yes, but I'm talking about an RSRC_CONF directive. It can
only live in global or virtual-global space. It can't live
anywhere below the global section of a virtual host.
> > Sorry, but you've lost me now.
> >
> > Running t/TEST myself will be three seperate test runs and
> > muck up a normal ``perl Makefile.PL && make && make test &&
> > make install''.
> >
> > Letting the test suite run itself three times though still
> > isn't going to do what you suggest, since it doesn't restart
> > the server. The server won't recognize the IfDef's until it
> > restarts, right?
>
> That's correct. It won't. I guess that when <Perl> sections will be
> implemented, it'll be possible to reconfigure the server from Perl and
> then HUPing it will get you a server with new configuration. Just an idea.
It seems we've come full circle. :)
Rick Myers rik@sumthin.nu
----------------------------------------------------
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
Re: multiple configurations
Posted by Stas Bekman <st...@stason.org>.
>>I think the first thing to figure out is whether you can have all the
>>desired configuration co-exist using VirtualHosts, so you won't need to
>>restart the server. I think you should be able to accomplish that.
>>
>>Once you do, I can think of many .pm response handlers include some
>>httpd.conf bits in various VirtualHosts. So you can re-use these.
>>
>
> Been there. :)
>
> # global
> NewDirective On
> <VirtualHost 1.2.3.4>
> ServerName foobar
> NewDirective Off
> </VirtualHost>
> <VirtualHost 1.2.3.4>
> ServerName bazbam
> </VirtualHost>
>
> vs.
>
> # global
> NewDirective Off
> <VirtualHost 1.2.3.4>
> ServerName foobar
> NewDiretive Off
> </VirtualHost>
> <VirtualHost 1.2.3.4>
> ServerName bazbam
> </VirtualHost>
>
> In each case, how should the bazbam virtual react? And the
> better question (and the reason for testing) is, will my
> module do what it's supposed to do? I don't see much way
> around restarting the server to test for that.
That's true, unless you can test the directive from within VirtualHost,
i.e. not to set it on the global level at all. something like that:
<VH ..>
ND On
<Loc ...>
ND Off
</Loc..>
<Loc ...>
ND On
</Loc..>
</VH>
<VH ..>
ND Off
<Loc ...>
ND Off
</Loc..>
<Loc ...>
ND On
</Loc..>
</VH>
so each VH behaves as a standalone server.
> Sorry, but you've lost me now.
>
> Running t/TEST myself will be three seperate test runs and
> muck up a normal ``perl Makefile.PL && make && make test &&
> make install''.
>
> Letting the test suite run itself three times though still
> isn't going to do what you suggest, since it doesn't restart
> the server. The server won't recognize the IfDef's until it
> restarts, right?
That's correct. It won't. I guess that when <Perl> sections will be
implemented, it'll be possible to reconfigure the server from Perl and
then HUPing it will get you a server with new configuration. Just an idea.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: multiple configurations
Posted by Rick Myers <ri...@sumthin.nu>.
On Jan 14, 2002 at 13:02:20 +0800, Stas Bekman wrote:
>
> Rick Myers wrote:
>
> > On Jan 14, 2002 at 11:24:41 +0800, Stas Bekman wrote:
> >
> >>Rick Myers wrote:
> >>
> >>
> >>>This may sound silly, but is there an *easy* way to test
> >>>multiple server config's?
> >>>
> >>>For example, I have a perl module that defines a new
> >>>RSRC_CONF directive that I want to test in every possible
> >>>way. To do that I need one server with no use of the module
> >>>(to validate the test, I guess), one server that uses the
> >>>directive in only the global area, and others for various
> >>>combinations of global vs. virtual use.
> >>>
> >>>The only way I can see to make this happen is to write
> >>>various extra .conf.in's and remove includes from the
> >>>httpd.conf file as each test runs. To make it work I have to
> >>>HUP the server after editing httpd.conf in each test, but
> >>>while using -X the server just dies.
> >>>
> >>>I managed to figure out a way around -X and keep the server
> >>>alive beyond the HUP, but it's a real pain. The end result
> >>>is overloading Apache::Test::config,
> >>>Apache::TestConfig::new_test_server, and
> >>>Apache::TestRunPerl::new_test_config -- all just to get back
> >>>to the point where I can finally overload
> >>>Apache::TestServer::start_cmd and leave out the $one.
> >>>
> >>>Thoughts?
> >>>
> >>I think you can do it using a set of a several .pm response handlers.
> >>Since the __DATA__ section is used to configure the server for the
> >>handler in the same file, you could write a single handler and then
> >>create a number of .pm files each having a different config section in
> >>its __DATA__ section as a virtual host, so they can all co-exist in the
> >>without restarting the server.
> >>
> >
> > That was my original thought also, but given the number of
> > tests I'm looking at I don't think I want to spend the next
> > couple years coding it. At last count there were almost 2400 tests
> > spread across 7 scripts.
>
>
> I think the first thing to figure out is whether you can have all the
> desired configuration co-exist using VirtualHosts, so you won't need to
> restart the server. I think you should be able to accomplish that.
>
> Once you do, I can think of many .pm response handlers include some
> httpd.conf bits in various VirtualHosts. So you can re-use these.
Been there. :)
# global
NewDirective On
<VirtualHost 1.2.3.4>
ServerName foobar
NewDirective Off
</VirtualHost>
<VirtualHost 1.2.3.4>
ServerName bazbam
</VirtualHost>
vs.
# global
NewDirective Off
<VirtualHost 1.2.3.4>
ServerName foobar
NewDiretive Off
</VirtualHost>
<VirtualHost 1.2.3.4>
ServerName bazbam
</VirtualHost>
In each case, how should the bazbam virtual react? And the
better question (and the reason for testing) is, will my
module do what it's supposed to do? I don't see much way
around restarting the server to test for that.
> >>Another alternative I can think of is writing one big .conf.in file with
> >><IfDefine> sections and allow t/TEST to have path-thru options to enable
> >>-D flags, so without changing the configuration you could run:
> >>
> >>t/TEST -Done; t/TEST -Dtwo; t/TEST -Dthree;
> >>
> >
> > Hmm.. Now that's interesting. I don't quite follow the
> > path-thru options bit though. I understand passing the -D's
> > to the server, but wouldn't that still mean you'd have to
> > restart it in mid-test?
>
>
> Yup, that's what I've suggested. In my example above you run t/TEST 3
> times invoking three different configurations. The path-through option
> doesn't exist yet, though.
>
>
> > If that's what you're saying, I have to admit I like the
> > thought of letting the test suite do the restarting as
> > opposed to just crossing my fingers and hoping nothing goes
> > wrong with my SIGHUP. Not to mention being able to forget
> > about all the monkey-motion I'm doing with overloading.
>
> Well, the test suite doesn't restart the server now.
Sorry, but you've lost me now.
Running t/TEST myself will be three seperate test runs and
muck up a normal ``perl Makefile.PL && make && make test &&
make install''.
Letting the test suite run itself three times though still
isn't going to do what you suggest, since it doesn't restart
the server. The server won't recognize the IfDef's until it
restarts, right?
Rick Myers rik@sumthin.nu
----------------------------------------------------
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
Re: multiple configurations
Posted by Stas Bekman <st...@stason.org>.
Rick Myers wrote:
> On Jan 14, 2002 at 11:24:41 +0800, Stas Bekman wrote:
>
>>Rick Myers wrote:
>>
>>
>>>This may sound silly, but is there an *easy* way to test
>>>multiple server config's?
>>>
>>>For example, I have a perl module that defines a new
>>>RSRC_CONF directive that I want to test in every possible
>>>way. To do that I need one server with no use of the module
>>>(to validate the test, I guess), one server that uses the
>>>directive in only the global area, and others for various
>>>combinations of global vs. virtual use.
>>>
>>>The only way I can see to make this happen is to write
>>>various extra .conf.in's and remove includes from the
>>>httpd.conf file as each test runs. To make it work I have to
>>>HUP the server after editing httpd.conf in each test, but
>>>while using -X the server just dies.
>>>
>>>I managed to figure out a way around -X and keep the server
>>>alive beyond the HUP, but it's a real pain. The end result
>>>is overloading Apache::Test::config,
>>>Apache::TestConfig::new_test_server, and
>>>Apache::TestRunPerl::new_test_config -- all just to get back
>>>to the point where I can finally overload
>>>Apache::TestServer::start_cmd and leave out the $one.
>>>
>>>Thoughts?
>>>
>>I think you can do it using a set of a several .pm response handlers.
>>Since the __DATA__ section is used to configure the server for the
>>handler in the same file, you could write a single handler and then
>>create a number of .pm files each having a different config section in
>>its __DATA__ section as a virtual host, so they can all co-exist in the
>>without restarting the server.
>>
>
> That was my original thought also, but given the number of
> tests I'm looking at I don't think I want to spend the next
> couple years coding it. At last count there were almost 2400 tests
> spread across 7 scripts.
I think the first thing to figure out is whether you can have all the
desired configuration co-exist using VirtualHosts, so you won't need to
restart the server. I think you should be able to accomplish that.
Once you do, I can think of many .pm response handlers include some
httpd.conf bits in various VirtualHosts. So you can re-use these.
>>Another alternative I can think of is writing one big .conf.in file with
>><IfDefine> sections and allow t/TEST to have path-thru options to enable
>>-D flags, so without changing the configuration you could run:
>>
>>t/TEST -Done; t/TEST -Dtwo; t/TEST -Dthree;
>>
>
> Hmm.. Now that's interesting. I don't quite follow the
> path-thru options bit though. I understand passing the -D's
> to the server, but wouldn't that still mean you'd have to
> restart it in mid-test?
Yup, that's what I've suggested. In my example above you run t/TEST 3
times invoking three different configurations. The path-through option
doesn't exist yet, though.
> If that's what you're saying, I have to admit I like the
> thought of letting the test suite do the restarting as
> opposed to just crossing my fingers and hoping nothing goes
> wrong with my SIGHUP. Not to mention being able to forget
> about all the monkey-motion I'm doing with overloading.
Well, the test suite doesn't restart the server now.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: multiple configurations
Posted by Rick Myers <ri...@sumthin.nu>.
On Jan 14, 2002 at 11:24:41 +0800, Stas Bekman wrote:
>
> Rick Myers wrote:
>
> > This may sound silly, but is there an *easy* way to test
> > multiple server config's?
> >
> > For example, I have a perl module that defines a new
> > RSRC_CONF directive that I want to test in every possible
> > way. To do that I need one server with no use of the module
> > (to validate the test, I guess), one server that uses the
> > directive in only the global area, and others for various
> > combinations of global vs. virtual use.
> >
> > The only way I can see to make this happen is to write
> > various extra .conf.in's and remove includes from the
> > httpd.conf file as each test runs. To make it work I have to
> > HUP the server after editing httpd.conf in each test, but
> > while using -X the server just dies.
> >
> > I managed to figure out a way around -X and keep the server
> > alive beyond the HUP, but it's a real pain. The end result
> > is overloading Apache::Test::config,
> > Apache::TestConfig::new_test_server, and
> > Apache::TestRunPerl::new_test_config -- all just to get back
> > to the point where I can finally overload
> > Apache::TestServer::start_cmd and leave out the $one.
> >
> > Thoughts?
>
> I think you can do it using a set of a several .pm response handlers.
> Since the __DATA__ section is used to configure the server for the
> handler in the same file, you could write a single handler and then
> create a number of .pm files each having a different config section in
> its __DATA__ section as a virtual host, so they can all co-exist in the
> without restarting the server.
That was my original thought also, but given the number of
tests I'm looking at I don't think I want to spend the next
couple years coding it. At last count there were almost 2400 tests
spread across 7 scripts.
> Another alternative I can think of is writing one big .conf.in file with
> <IfDefine> sections and allow t/TEST to have path-thru options to enable
> -D flags, so without changing the configuration you could run:
>
> t/TEST -Done; t/TEST -Dtwo; t/TEST -Dthree;
Hmm.. Now that's interesting. I don't quite follow the
path-thru options bit though. I understand passing the -D's
to the server, but wouldn't that still mean you'd have to
restart it in mid-test?
If that's what you're saying, I have to admit I like the
thought of letting the test suite do the restarting as
opposed to just crossing my fingers and hoping nothing goes
wrong with my SIGHUP. Not to mention being able to forget
about all the monkey-motion I'm doing with overloading.
Rick Myers rik@sumthin.nu
----------------------------------------------------
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
Re: multiple configurations
Posted by Stas Bekman <st...@stason.org>.
Rick Myers wrote:
> This may sound silly, but is there an *easy* way to test
> multiple server config's?
>
> For example, I have a perl module that defines a new
> RSRC_CONF directive that I want to test in every possible
> way. To do that I need one server with no use of the module
> (to validate the test, I guess), one server that uses the
> directive in only the global area, and others for various
> combinations of global vs. virtual use.
>
> The only way I can see to make this happen is to write
> various extra .conf.in's and remove includes from the
> httpd.conf file as each test runs. To make it work I have to
> HUP the server after editing httpd.conf in each test, but
> while using -X the server just dies.
>
> I managed to figure out a way around -X and keep the server
> alive beyond the HUP, but it's a real pain. The end result
> is overloading Apache::Test::config,
> Apache::TestConfig::new_test_server, and
> Apache::TestRunPerl::new_test_config -- all just to get back
> to the point where I can finally overload
> Apache::TestServer::start_cmd and leave out the $one.
>
> Thoughts?
I think you can do it using a set of a several .pm response handlers.
Since the __DATA__ section is used to configure the server for the
handler in the same file, you could write a single handler and then
create a number of .pm files each having a different config section in
its __DATA__ section as a virtual host, so they can all co-exist in the
without restarting the server.
Another alternative I can think of is writing one big .conf.in file with
<IfDefine> sections and allow t/TEST to have path-thru options to enable
-D flags, so without changing the configuration you could run:
t/TEST -Done; t/TEST -Dtwo; t/TEST -Dthree;
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/