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 Stas Bekman <st...@stason.org> on 2004/08/07 04:26:31 UTC
failing httpd-test tests
Do you also get these tests failing with the current httpd-2.0?
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/apache/limits.t 10 2 20.00% 7 9
t/ssl/basicauth.t 3 2 66.67% 2-3
t/ssl/env.t 28 14 50.00% 15-28
t/ssl/proxy.t 169 116 68.64% 1-58 112-169
t/ssl/require.t 5 2 40.00% 2 5
t/ssl/varlookup.t 72 72 100.00% 1-72
t/ssl/verify.t 3 1 33.33% 2
It's hard to know whether my recent changes in Apache-Test didn't break
things, when so many tests fail (they were failing before my changes).
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Aug 06, 2004 at 07:26:31PM -0700, Stas Bekman wrote:
> Do you also get these tests failing with the current httpd-2.0?
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -------------------------------------------------------------------------------
> t/apache/limits.t 10 2 20.00% 7 9
> t/ssl/basicauth.t 3 2 66.67% 2-3
> t/ssl/env.t 28 14 50.00% 15-28
> t/ssl/proxy.t 169 116 68.64% 1-58 112-169
> t/ssl/require.t 5 2 40.00% 2 5
> t/ssl/varlookup.t 72 72 100.00% 1-72
> t/ssl/verify.t 3 1 33.33% 2
I get just the ssl/basicauth.t failures and a whole bunch in
modules/access.t too using HEAD of httpd and httpd-test. The tests were
all passing on July 25th before I went on holiday so it is a relatively
recent regression, but I turned off my nightly builds in the meantime so
I'll try and track it down manually...
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> There is something funky in the default_module detection; it's picking
> up mod_auth.c and mod_access.c as the {auth,access}_module settings
> rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
>
> $ grep access_ conf/apache_test_config.pm
> 'access_module_name' => 'mod_access',
> 'access_module' => 'mod_access.c
>
> that the failures I'm seeing here.
>
> ./TEST -debug seems to have stopper working sometime too
>
> $ ./TEST -debug
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/bin/perl /tmp/regressPPKikg/pf/t/TEST -debug
> [warning] server localhost.localdomain:8529 shutdown
> Use of uninitialized value in concatenation (.) or string at
> Apache-Test/lib/Apache/TestServer.pm line 130.
>
> any ideas?
Indeed. I've committed the fix.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Joe Orton wrote:
>
>>There is something funky in the default_module detection; it's picking
>>up mod_auth.c and mod_access.c as the {auth,access}_module settings
>>rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
>>
>>$ grep access_ conf/apache_test_config.pm
>> 'access_module_name' => 'mod_access',
>> 'access_module' => 'mod_access.c
>>
>>that the failures I'm seeing here.
>
>
>>any ideas?
>
>
> I'm not sure if that's something stas touched or not.
I think not, but I'm not 100% sure. All I did is split the A-T
configuration process in 2 parts, postponing the httpd-specific
information finding to a later stage.
> helpful information at this point would be some of the verbose output from
> the module selection reports using 'export APACHE_TEST_TRACE_LEVEL=debug'
> when running t/TEST -conf.
it's simpler with: t/TEST -conf -trace=debug :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>> Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage.
no problem, that's part of the process.
>>
>>
>>
>> Oh, yeah, I got it right away when trying to build mp2. Looking at it.
>
>
> I think I've a good workaround for now. Please try again with the
> current cvs. Still having a problem?
nope, looks good.
--Geoff
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Stas Bekman wrote:
>
>> Geoffrey Young wrote:
>>
>>>> But things are getting more and more fragile and dependant on each
>>>> other
>>>
>>>
>>>
>>>
>>> indeed. right now a fresh checkout will not even run for me because
>>> I don't
>>> have an ssl-enabled apache to run against. this is not a minor
>>> issue, as I
>>> suspect I'm in the majority for normal users.
>>
>>
>>
>> Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage.
>
>
> Oh, yeah, I got it right away when trying to build mp2. Looking at it.
I think I've a good workaround for now. Please try again with the
current cvs. Still having a problem?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> But things are getting more and more fragile and dependant on each
>>> other
>>
>>
>>
>> indeed. right now a fresh checkout will not even run for me because I
>> don't
>> have an ssl-enabled apache to run against. this is not a minor issue,
>> as I
>> suspect I'm in the majority for normal users.
>
>
> Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage.
Oh, yeah, I got it right away when trying to build mp2. Looking at it.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>But things are getting more and more fragile and dependant on each
>>other
>
>
> indeed. right now a fresh checkout will not even run for me because I don't
> have an ssl-enabled apache to run against. this is not a minor issue, as I
> suspect I'm in the majority for normal users.
Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage.
>>making the code less and less maintainable.
>
>
> exactly - I'm kind of at a loss for what exactly to do here to fix it. you
> made a few suggestions, but I really don't know what's best - between the
> sticky configuration stuff (that I still don't care for) and the new
> configuration breakdown I'm pretty much lost at the moment.
>
>
>>We need to rethink
>>how the things are configured in A-T,
>
>
> I think it all used to be just fine. well, maybe not fine but maintainable
> to a certain degree. then we started adding magic things like sticky
> preferences and the ability to move the test directory around and things got
> considerably more complex.
Well, those things aren't magical, they were just solutions to the
existing (some pretty bad) problems. I've a way too many other things to
do, to just go and break Apache-Test for fun.
>>write some sort of test suite to
>>cover what's working, then completely rewrite the configuration process
>>from scratch, making sure that things are still working.
>
>
> ideally, sure. I just can't think of how to do that.
Do what? The test suite? I think this is the first step.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> But things are getting more and more fragile and dependant on each
> other
indeed. right now a fresh checkout will not even run for me because I don't
have an ssl-enabled apache to run against. this is not a minor issue, as I
suspect I'm in the majority for normal users.
> making the code less and less maintainable.
exactly - I'm kind of at a loss for what exactly to do here to fix it. you
made a few suggestions, but I really don't know what's best - between the
sticky configuration stuff (that I still don't care for) and the new
configuration breakdown I'm pretty much lost at the moment.
> We need to rethink
> how the things are configured in A-T,
I think it all used to be just fine. well, maybe not fine but maintainable
to a certain degree. then we started adding magic things like sticky
preferences and the ability to move the test directory around and things got
considerably more complex.
> write some sort of test suite to
> cover what's working, then completely rewrite the configuration process
> from scratch, making sure that things are still working.
ideally, sure. I just can't think of how to do that.
--Geoff
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Joe Orton wrote:
>
>>On Wed, Aug 11, 2004 at 01:17:04AM -0700, Stas Bekman wrote:
>>
>>
>>>I'd rather see it moved two statements (it still works, doesn't it?) so
>>>the eapi comes right after inherit_config. Otherwise, yes, please commit it.
>>
>>
>>Yes, great, done.
>>
>>
>>
>>>so are we all clean now? Any other problems?
>>
>>
>>No failures with HEAD again now - thanks a lot.
>
>
> since I don't have ssl compiled in I still have one issue:
>
> t/TEST -clean
> Use of uninitialized value in hash element at
> /src/httpd-test-pristine/perl-framework/Apache-Test/lib/Apache/TestConfig.pm
> line 1340.
Hmm, but httpd_config() calls clean() on its own. So if you didn't
supply httpd/apxs, you will get into an endless loop.
sub httpd_config {
my $self = shift;
my $vars = $self->{vars};
$self->configure_apxs;
$self->configure_httpd;
unless ($vars->{httpd} or $vars->{apxs}) {
if ($ENV{APACHE_TEST_NO_STICKY_PREFERENCES}) {
error "You specified APACHE_TEST_NO_STICKY_PREFERENCES=1 " .
"in which case you must explicitly specify -httpd " .
"and/or -apxs options";
Apache::TestRun::exit_perl(0);
}
$self->clean(1);
...
so the only way to do what you want (which makes sense) is to call
$self->httpd_config() only if ($vars->{httpd} or $vars->{apxs})
or may be it's possible to drop that clean(1) call in the above code and
if so, you the better way to handle that is to adjust TestRun.pm's
@exit_opts_need_httpd, making -conf requiring httpd config.
But things are getting more and more fragile and dependant on each
other, making the code less and less maintainable. We need to rethink
how the things are configured in A-T, write some sort of test suite to
cover what's working, then completely rewrite the configuration process
from scratch, making sure that things are still working.
> the attached patch fixes it and explains what the issue is.
One more thing I'm not happy about is the name I've chosen:
$self->httpd_config. Any better name ideas, such so it clearly indicates
that httpd is found and the config object is configured with it?
> ? ssl.patch
> Index: lib/Apache/TestConfig.pm
> ===================================================================
> RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
> retrieving revision 1.236
> diff -u -r1.236 TestConfig.pm
> --- lib/Apache/TestConfig.pm 11 Aug 2004 08:42:36 -0000 1.236
> +++ lib/Apache/TestConfig.pm 11 Aug 2004 12:44:57 -0000
> @@ -1013,6 +1013,12 @@
> my $self = shift;
> $self->{clean_level} = shift || 2; #2 == really clean, 1 == reconfigure
>
> + # we can't clean the server until it is fully configured
> + # for instance, at this point we haven't called default_module yet,
> + # which means that we don't know which ssl module we're even looking
> + # for in sslca_clean/sslca_can
> + $self->httpd_config;
> +
> $self->new_test_server->clean;
> $self->cmodules_clean;
> $self->sslca_clean;
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> On Wed, Aug 11, 2004 at 01:17:04AM -0700, Stas Bekman wrote:
>
>>I'd rather see it moved two statements (it still works, doesn't it?) so
>>the eapi comes right after inherit_config. Otherwise, yes, please commit it.
>
>
> Yes, great, done.
>
>
>>so are we all clean now? Any other problems?
>
>
> No failures with HEAD again now - thanks a lot.
since I don't have ssl compiled in I still have one issue:
t/TEST -clean
Use of uninitialized value in hash element at
/src/httpd-test-pristine/perl-framework/Apache-Test/lib/Apache/TestConfig.pm
line 1340.
the attached patch fixes it and explains what the issue is.
--Geoff
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Wed, Aug 11, 2004 at 01:17:04AM -0700, Stas Bekman wrote:
>
>>I'd rather see it moved two statements (it still works, doesn't it?) so
>>the eapi comes right after inherit_config. Otherwise, yes, please commit it.
>
>
> Yes, great, done.
>
>
>>so are we all clean now? Any other problems?
>
>
> No failures with HEAD again now - thanks a lot.
Excellent. Thanks Joe!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Aug 11, 2004 at 01:17:04AM -0700, Stas Bekman wrote:
> I'd rather see it moved two statements (it still works, doesn't it?) so
> the eapi comes right after inherit_config. Otherwise, yes, please commit it.
Yes, great, done.
> so are we all clean now? Any other problems?
No failures with HEAD again now - thanks a lot.
joe
Re: forcing full config in Makefile.PL (was Re: failing httpd-test
tests)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>As a result of my changes, now the API has two wrappers
>>Apache::Test::config (full config as before), and
>>Apache::Test::basic_config, which is the same sans httpd information.
>>For example to autogenerate t/TEST and other files you don't need to
>>know anything about httpd, and therefore you shouldn't require users to
>>supply that info before it's really needed.
>
>
> one of the things I've tried to do but was never able to get working was
> call have_apache within Makefile.PL. being able to do this would be a nice
> way to add a PREREQ_PM-type precondition for building modules that rely on,
> say, httpd 2.1.
>
> as a user it doesn't quite make sense why this wouldn't work - Makefile.PL
> is getting passed -apxs or -httpd, so you would think that after the call to
> filter_args the httpd version would be known.
>
> being able to support something like this, whether automatically or on
> command would be really great. that is, forcing a full configuration before
> calling WriteMakefile so that all the standard Apache::Test functions are
> available.
Sure, just call Apache::Test::config and voila you have the full config
in Makefile.PL. Don't forget that at the moment 99.9% of users will not
have that provision of httpd/apxs during Makefile.PL, so you will want
to check whether it's provided (and that's not bogus). Otherwise asking
for a full config with no httpd/apxs provision will trigger interactive
config at the Makefile.PL level, which doesn't sound good at all for the
general case.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
forcing full config in Makefile.PL (was Re: failing httpd-test tests)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> As a result of my changes, now the API has two wrappers
> Apache::Test::config (full config as before), and
> Apache::Test::basic_config, which is the same sans httpd information.
> For example to autogenerate t/TEST and other files you don't need to
> know anything about httpd, and therefore you shouldn't require users to
> supply that info before it's really needed.
one of the things I've tried to do but was never able to get working was
call have_apache within Makefile.PL. being able to do this would be a nice
way to add a PREREQ_PM-type precondition for building modules that rely on,
say, httpd 2.1.
as a user it doesn't quite make sense why this wouldn't work - Makefile.PL
is getting passed -apxs or -httpd, so you would think that after the call to
filter_args the httpd version would be known.
being able to support something like this, whether automatically or on
command would be really great. that is, forcing a full configuration before
calling WriteMakefile so that all the standard Apache::Test functions are
available.
--Geoff
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Tue, Aug 10, 2004 at 09:56:12AM -0700, Stas Bekman wrote:
>
>>Aha! Excellent, Geoff! Does it solve the problem by moving those
>>default_module calls after getting httpd config?
>
>
> Moving the calls one line further on fixed it for me. OK to check in?
> (BTW your patch had whitespace issues and only applied with patch -l)
>
> Index: Apache-Test/lib/Apache/TestConfig.pm
> ===================================================================
> RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
> retrieving revision 1.235
> diff -u -r1.235 TestConfig.pm
> --- Apache-Test/lib/Apache/TestConfig.pm 9 Aug 2004 06:19:15 -0000 1.235
> +++ Apache-Test/lib/Apache/TestConfig.pm 10 Aug 2004 21:12:59 -0000
> @@ -313,13 +313,6 @@
> $vars->{proxyssl_url} ||= '';
> $vars->{defines} ||= '';
>
> - $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
> - $self->default_module(thread => [qw(worker threaded)]);
> - $self->default_module(ssl => [qw(mod_ssl)]);
> - $self->default_module(access => [qw(mod_access mod_authz_host)]);
> - $self->default_module(auth => [qw(mod_auth mod_auth_basic)]);
> - $self->default_module(php => [qw(mod_php4 mod_php5)]);
> -
> $self->{hostport} = $self->hostport;
> $self->{server} = $self->new_test_server;
>
> @@ -359,6 +352,14 @@
> }
>
> $self->inherit_config; #see TestConfigParse.pm
> +
> + $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
> + $self->default_module(thread => [qw(worker threaded)]);
> + $self->default_module(ssl => [qw(mod_ssl)]);
> + $self->default_module(access => [qw(mod_access mod_authz_host)]);
> + $self->default_module(auth => [qw(mod_auth mod_auth_basic)]);
> + $self->default_module(php => [qw(mod_php4 mod_php5)]);
> +
> $self->configure_httpd_eapi; #must come after inherit_config
>
> $self->{server}->post_config;
I'd rather see it moved two statements (it still works, doesn't it?) so
the eapi comes right after inherit_config. Otherwise, yes, please commit it.
so are we all clean now? Any other problems?
As a result of my changes, now the API has two wrappers
Apache::Test::config (full config as before), and
Apache::Test::basic_config, which is the same sans httpd information.
For example to autogenerate t/TEST and other files you don't need to
know anything about httpd, and therefore you shouldn't require users to
supply that info before it's really needed. Until now things were
silently failing (to find httpd stuff), making it really hard to trace
some problems. Now things fail when something goes wrong, so this
separation was important.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Aug 10, 2004 at 09:56:12AM -0700, Stas Bekman wrote:
> Aha! Excellent, Geoff! Does it solve the problem by moving those
> default_module calls after getting httpd config?
Moving the calls one line further on fixed it for me. OK to check in?
(BTW your patch had whitespace issues and only applied with patch -l)
Index: Apache-Test/lib/Apache/TestConfig.pm
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.235
diff -u -r1.235 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm 9 Aug 2004 06:19:15 -0000 1.235
+++ Apache-Test/lib/Apache/TestConfig.pm 10 Aug 2004 21:12:59 -0000
@@ -313,13 +313,6 @@
$vars->{proxyssl_url} ||= '';
$vars->{defines} ||= '';
- $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
- $self->default_module(thread => [qw(worker threaded)]);
- $self->default_module(ssl => [qw(mod_ssl)]);
- $self->default_module(access => [qw(mod_access mod_authz_host)]);
- $self->default_module(auth => [qw(mod_auth mod_auth_basic)]);
- $self->default_module(php => [qw(mod_php4 mod_php5)]);
-
$self->{hostport} = $self->hostport;
$self->{server} = $self->new_test_server;
@@ -359,6 +352,14 @@
}
$self->inherit_config; #see TestConfigParse.pm
+
+ $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
+ $self->default_module(thread => [qw(worker threaded)]);
+ $self->default_module(ssl => [qw(mod_ssl)]);
+ $self->default_module(access => [qw(mod_access mod_authz_host)]);
+ $self->default_module(auth => [qw(mod_auth mod_auth_basic)]);
+ $self->default_module(php => [qw(mod_php4 mod_php5)]);
+
$self->configure_httpd_eapi; #must come after inherit_config
$self->{server}->post_config;
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Joe Orton wrote:
>
>>On Mon, Aug 09, 2004 at 02:33:34PM -0700, Stas Bekman wrote:
>>
>>
>>>I have tested with a checkout from Aug 1 and t/modules/access fails just
>>>the same, so it's definitely unrelated to my changes over the weekend. I
>>
>>
>>I can't confirm that - the break occurs from the change between 18:00
>>and 19:00 UTC on 6th August
Doh! I wonder why my checkout from Aug 1st was failing just as well :(
May be it was a wrong checkout.
> which would seem to correspond to this comment:
>
> "split the config object creation in 2 parts - first not requiring the
> knowledge of httpd location, the second requiring one"
>
> and the following change:
>
>
>> - $self->configure_apxs;
>> - $self->configure_httpd;
>> - $self->inherit_config; #see TestConfigParse.pm
>> - $self->configure_httpd_eapi; #must come after inherit_config
>> -
>> $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
>> $self->default_module(thread => [qw(worker threaded)]);
>> $self->default_module(ssl => [qw(mod_ssl)]);
>
>
> which occurs in TestConfig::new(), which is now designated as
>
> # setup httpd-independent components
> # for httpd-specific call $self->httpd_config()
>
> so I guess that assumption is wrong - default_module needs a complete httpd
> setup to apply module naming magic, at least in cases where the module is
> compiled in statically.
Aha! Excellent, Geoff! Does it solve the problem by moving those
default_module calls after getting httpd config?
Index: lib/Apache/TestConfig.pm
===================================================================
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.235
diff -u -r1.235 TestConfig.pm
--- lib/Apache/TestConfig.pm 9 Aug 2004 06:19:15 -0000 1.235
+++ lib/Apache/TestConfig.pm 10 Aug 2004 16:55:29 -0000
@@ -313,13 +313,6 @@
$vars->{proxyssl_url} ||= '';
$vars->{defines} ||= '';
- $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
- $self->default_module(thread => [qw(worker threaded)]);
- $self->default_module(ssl => [qw(mod_ssl)]);
- $self->default_module(access => [qw(mod_access mod_authz_host)]);
- $self->default_module(auth => [qw(mod_auth mod_auth_basic)]);
- $self->default_module(php => [qw(mod_php4 mod_php5)]);
-
$self->{hostport} = $self->hostport;
$self->{server} = $self->new_test_server;
@@ -357,6 +350,14 @@
unless (custom_config_exists()) {
$self->custom_config_save($self->{vars});
}
+
+ $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
+ $self->default_module(thread => [qw(worker threaded)]);
+ $self->default_module(ssl => [qw(mod_ssl)]);
+ $self->default_module(access => [qw(mod_access mod_authz_host)]);
+ $self->default_module(auth => [qw(mod_auth mod_auth_basic)]);
+ $self->default_module(php => [qw(mod_php4 mod_php5)]);
+
$self->inherit_config; #see TestConfigParse.pm
$self->configure_httpd_eapi; #must come after inherit_config
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> On Mon, Aug 09, 2004 at 02:33:34PM -0700, Stas Bekman wrote:
>
>>I have tested with a checkout from Aug 1 and t/modules/access fails just
>>the same, so it's definitely unrelated to my changes over the weekend. I
>
>
> I can't confirm that - the break occurs from the change between 18:00
> and 19:00 UTC on 6th August
which would seem to correspond to this comment:
"split the config object creation in 2 parts - first not requiring the
knowledge of httpd location, the second requiring one"
and the following change:
> - $self->configure_apxs;
> - $self->configure_httpd;
> - $self->inherit_config; #see TestConfigParse.pm
> - $self->configure_httpd_eapi; #must come after inherit_config
> -
> $self->default_module(cgi => [qw(mod_cgi mod_cgid)]);
> $self->default_module(thread => [qw(worker threaded)]);
> $self->default_module(ssl => [qw(mod_ssl)]);
which occurs in TestConfig::new(), which is now designated as
# setup httpd-independent components
# for httpd-specific call $self->httpd_config()
so I guess that assumption is wrong - default_module needs a complete httpd
setup to apply module naming magic, at least in cases where the module is
compiled in statically.
--Geoff
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Aug 09, 2004 at 02:33:34PM -0700, Stas Bekman wrote:
> I have tested with a checkout from Aug 1 and t/modules/access fails just
> the same, so it's definitely unrelated to my changes over the weekend. I
I can't confirm that - the break occurs from the change between 18:00
and 19:00 UTC on 6th August
+ cvs -Q co -D '2004-08-06 18:00 +0000' -d pf-2004-08-06-18:00 httpd-test/perl-framework
+ pushd pf-2004-08-06-18:00
/tmp/regressoE4Aym/pf-2004-08-06-18:00 /tmp/regressoE4Aym
+ perl Makefile.PL -apxs /tmp/regressoE4Aym/2.1-root/bin/apxs
+ ./t/TEST -conf
+ grep auth_module t/conf/apache_test_config.pm
'auth_module_name' => 'mod_auth_basic',
'auth_module' => 'mod_auth_basic.c',
+ popd
/tmp/regressoE4Aym
+ dir=pf-2004-08-06-19:00
+ rm -rf pf-2004-08-06-19:00
+ cvs -Q co -D '2004-08-06 19:00 +0000' -d pf-2004-08-06-19:00 httpd-test/perl-framework
+ pushd pf-2004-08-06-19:00
/tmp/regressoE4Aym/pf-2004-08-06-19:00 /tmp/regressoE4Aym
+ perl Makefile.PL -apxs /tmp/regressoE4Aym/2.1-root/bin/apxs
+ ./t/TEST -conf
+ grep auth_module t/conf/apache_test_config.pm
'auth_module_name' => 'mod_auth',
'auth_module' => 'mod_auth.c',
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Joe Orton wrote:
>
>>On Mon, Aug 09, 2004 at 11:55:57AM -0400, Geoffrey Young wrote:
>>
>>
>>>Joe Orton wrote:
>>>
>>>
>>>>Yes, sorry I'm talking about 2.1 here of course. I debugged this as far
>>>>as finding that $self->{modules} appears to be empty at the time that
>>>>the ->default_module calls are made.
>>>
>>>yes, I see that there is no aaa stuff in your resulting conf, which I assume
>>>is because you don't have any aaa LoadModule statements in your main
>>>httpd.conf. this should be fine under normal circumstances. the only thing
>>>I can think of that might trip this up is if you have those modules compiled
>>>statically, but I'm not entirely sure.
>>
>>
>>Yes, indeed.
>>
>>$ ./bin/httpd -l | grep mod_auth
>> mod_authn_file.c
>> mod_authn_default.c
>> mod_authz_host.c
>> mod_authz_groupfile.c
>> mod_authz_user.c
>> mod_authz_default.c
>> mod_auth_basic.c
>
>
> ok, that's an important point. if these used to work with an identical
> (static) httpd then something definitely broke recently. personally, I've
> never tried with a heavy-static httpd so I don't know how it used to behave.
>
>
>>>and post the resulting output - the call to need_access should be sufficient
>>>to keep that test from running at all if it can't find an appropriate aaa
>>>module.
>>
>>
>>All tests which expect access do pass, all those expecting access denial
>>fail, i.e. failing exactly as if no access control is applied.
>
>
> ok, I think I see it.
>
> anyway, check t/conf/extra.conf for <IfModule "mod_access.c"> - the
> mod_access there is expanded from @ACCESS_MODULE" which is supposed to find
> the right one (mod_access or mod_authz_host). since it wasn't found, the
> default mod_access was used and thus the .htaccess files would not be picked up.
>
> funny that the call to need_access isn't stopping the tests, though - that
> seems like a bug as well.
>
> anyway, at this point we can probably wait for stas to show up, since I
> wasn't following his changes of late.
I have tested with a checkout from Aug 1 and t/modules/access fails just
the same, so it's definitely unrelated to my changes over the weekend. I
suppose the easiest way to figure out what change broke things is to try
a few more checkouts and see when it got bad. Since Joe says that July
25 was fine, then it's somewhere in those 5 days in between that things
got wrong.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> On Mon, Aug 09, 2004 at 11:55:57AM -0400, Geoffrey Young wrote:
>
>>
>>Joe Orton wrote:
>>
>>>Yes, sorry I'm talking about 2.1 here of course. I debugged this as far
>>>as finding that $self->{modules} appears to be empty at the time that
>>>the ->default_module calls are made.
>>
>>yes, I see that there is no aaa stuff in your resulting conf, which I assume
>>is because you don't have any aaa LoadModule statements in your main
>>httpd.conf. this should be fine under normal circumstances. the only thing
>>I can think of that might trip this up is if you have those modules compiled
>>statically, but I'm not entirely sure.
>
>
> Yes, indeed.
>
> $ ./bin/httpd -l | grep mod_auth
> mod_authn_file.c
> mod_authn_default.c
> mod_authz_host.c
> mod_authz_groupfile.c
> mod_authz_user.c
> mod_authz_default.c
> mod_auth_basic.c
ok, that's an important point. if these used to work with an identical
(static) httpd then something definitely broke recently. personally, I've
never tried with a heavy-static httpd so I don't know how it used to behave.
>>and post the resulting output - the call to need_access should be sufficient
>>to keep that test from running at all if it can't find an appropriate aaa
>>module.
>
>
> All tests which expect access do pass, all those expecting access denial
> fail, i.e. failing exactly as if no access control is applied.
ok, I think I see it.
anyway, check t/conf/extra.conf for <IfModule "mod_access.c"> - the
mod_access there is expanded from @ACCESS_MODULE" which is supposed to find
the right one (mod_access or mod_authz_host). since it wasn't found, the
default mod_access was used and thus the .htaccess files would not be picked up.
funny that the call to need_access isn't stopping the tests, though - that
seems like a bug as well.
anyway, at this point we can probably wait for stas to show up, since I
wasn't following his changes of late.
--Geoff
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Aug 09, 2004 at 11:55:57AM -0400, Geoffrey Young wrote:
>
>
> Joe Orton wrote:
> > Yes, sorry I'm talking about 2.1 here of course. I debugged this as far
> > as finding that $self->{modules} appears to be empty at the time that
> > the ->default_module calls are made.
>
> yes, I see that there is no aaa stuff in your resulting conf, which I assume
> is because you don't have any aaa LoadModule statements in your main
> httpd.conf. this should be fine under normal circumstances. the only thing
> I can think of that might trip this up is if you have those modules compiled
> statically, but I'm not entirely sure.
Yes, indeed.
$ ./bin/httpd -l | grep mod_auth
mod_authn_file.c
mod_authn_default.c
mod_authz_host.c
mod_authz_groupfile.c
mod_authz_user.c
mod_authz_default.c
mod_auth_basic.c
> anyway, if t/modules/access.t is failing for you, please run
>
> $ t/TEST t/modules/access.t -v
>
> and post the resulting output - the call to need_access should be sufficient
> to keep that test from running at all if it can't find an appropriate aaa
> module.
All tests which expect access do pass, all those expecting access denial
fail, i.e. failing exactly as if no access control is applied.
# Order mutual-failure
# Allow from 127.0.0.1/16
# Deny from 66.6.6.6
# expecting access.
ok 374
# ---
...
# Order mutual-failure
# Allow from 66.6.6.6
# Deny from 66.6.6.6
# expecting access denial.
# Failed test 408 in t/modules/access.t at line 185 fail #8
not ok 408
does that help?
joe
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> Yes, sorry I'm talking about 2.1 here of course. I debugged this as far
> as finding that $self->{modules} appears to be empty at the time that
> the ->default_module calls are made.
yes, I see that there is no aaa stuff in your resulting conf, which I assume
is because you don't have any aaa LoadModule statements in your main
httpd.conf. this should be fine under normal circumstances. the only thing
I can think of that might trip this up is if you have those modules compiled
statically, but I'm not entirely sure.
anyway, if t/modules/access.t is failing for you, please run
$ t/TEST t/modules/access.t -v
and post the resulting output - the call to need_access should be sufficient
to keep that test from running at all if it can't find an appropriate aaa
module.
--Geoff
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
Yes, sorry I'm talking about 2.1 here of course. I debugged this as far
as finding that $self->{modules} appears to be empty at the time that
the ->default_module calls are made.
Attached:
1) patch to add debugging to default_module
2) ./TEST -conf output with patch applied
3) resultant apache_test_config.pm
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> On Mon, Aug 09, 2004 at 10:48:39AM -0400, Geoffrey Young wrote:
>
>>Joe Orton wrote:
>>
>>>There is something funky in the default_module detection; it's picking
>>>up mod_auth.c and mod_access.c as the {auth,access}_module settings
>>>rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
looking at it again, I think you mean mod_auth_basic and mod_authz_host for
2.1, right? it's still mod_auth and mod_access for 2.0.
> OK, attached ./t/TEST -conf output after fresh checkout.
> [ debug] inheriting config file: /tmp/regressPPKikg/2.1-root/conf/httpd.conf
> [ debug] using httpd.conf inherited ServerRoot to resolve conf/ssl.conf
> [ debug] conf/ssl.conf successfully resolved to existing file /tmp/regressPPKikg/2.1-root/conf/ssl.conf
> [ debug] inheriting config file: /tmp/regressPPKikg/2.1-root/conf/ssl.conf
> [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_echo.so
> [ debug] modules/mod_echo.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_echo.so
> [ debug] Found: echo_module => mod_echo.c
> [ debug] LoadModule echo_module mod_echo.c
> [ debug] saving config data to apache_test_config.pm
unless I missed it, I didn't see any information for the auth modules in
your output. if you are still having problems with the auth modules what
does apache_test_config.pm look like wrt the auth modules? of particular
interest is 'auth_module_name' (in vars) and the mod_auth-specific parts of
'LoadModule'.
--Geoff
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Aug 09, 2004 at 10:48:39AM -0400, Geoffrey Young wrote:
> Joe Orton wrote:
> > There is something funky in the default_module detection; it's picking
> > up mod_auth.c and mod_access.c as the {auth,access}_module settings
> > rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
...
> I'm not sure if that's something stas touched or not.
>
> helpful information at this point would be some of the verbose output from
> the module selection reports using 'export APACHE_TEST_TRACE_LEVEL=debug'
> when running t/TEST -conf. just to reduce things a bit, starting from a
> fresh checkout might be useful too - I'm still seeing random failures in
> some tests when I switch from 2.0 to 2.1 in the same working directory, even
> after running 'make realclean' and t/TEST -clean, but I haven't been able to
> put my finger on it.
OK, attached ./t/TEST -conf output after fresh checkout.
joe
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> There is something funky in the default_module detection; it's picking
> up mod_auth.c and mod_access.c as the {auth,access}_module settings
> rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
>
> $ grep access_ conf/apache_test_config.pm
> 'access_module_name' => 'mod_access',
> 'access_module' => 'mod_access.c
>
> that the failures I'm seeing here.
> any ideas?
I'm not sure if that's something stas touched or not.
helpful information at this point would be some of the verbose output from
the module selection reports using 'export APACHE_TEST_TRACE_LEVEL=debug'
when running t/TEST -conf. just to reduce things a bit, starting from a
fresh checkout might be useful too - I'm still seeing random failures in
some tests when I switch from 2.0 to 2.1 in the same working directory, even
after running 'make realclean' and t/TEST -clean, but I haven't been able to
put my finger on it.
--Geoff
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Aug 09, 2004 at 02:45:29PM +0100, Joe Orton wrote:
> There is something funky in the default_module detection; it's picking
> up mod_auth.c and mod_access.c as the {auth,access}_module settings
> rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
>
> $ grep access_ conf/apache_test_config.pm
> 'access_module_name' => 'mod_access',
> 'access_module' => 'mod_access.c
>
> that the failures I'm seeing here.
^ explains
Re: failing httpd-test tests
Posted by Joe Orton <jo...@redhat.com>.
There is something funky in the default_module detection; it's picking
up mod_auth.c and mod_access.c as the {auth,access}_module settings
rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
$ grep access_ conf/apache_test_config.pm
'access_module_name' => 'mod_access',
'access_module' => 'mod_access.c
that the failures I'm seeing here.
./TEST -debug seems to have stopper working sometime too
$ ./TEST -debug
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /tmp/regressPPKikg/pf/t/TEST -debug
[warning] server localhost.localdomain:8529 shutdown
Use of uninitialized value in concatenation (.) or string at
Apache-Test/lib/Apache/TestServer.pm line 130.
any ideas?
joe
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>> t/apache/limits.t 10 2 20.00% 7 9
>>
>>
>>
>> I only get this one on a clean checkout (before your changes - no time to
>> test now :)
>
>
> Thanks Geoff. What openssl library do you have?
>
> I have:
> libopenssl0.9.7-0.9.7c-3mdk
> libopenssl0-0.9.6i-1.1mdk
>
ugh, that's what I get for working so late at night - I didn't notice that
those were ssl tests :)
so, I only get failures with limit.1 and don't run the ssl stuff. I should
probably change that ;)
--Geoff
Re: failing httpd-test tests
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>Do you also get these tests failing with the current httpd-2.0?
>>
>>Failed Test Stat Wstat Total Fail Failed List of Failed
>>-------------------------------------------------------------------------------
>>
>>t/apache/limits.t 10 2 20.00% 7 9
>
>
> I only get this one on a clean checkout (before your changes - no time to
> test now :)
Thanks Geoff. What openssl library do you have?
I have:
libopenssl0.9.7-0.9.7c-3mdk
libopenssl0-0.9.6i-1.1mdk
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Do you also get these tests failing with the current httpd-2.0?
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -------------------------------------------------------------------------------
>
> t/apache/limits.t 10 2 20.00% 7 9
I only get this one on a clean checkout (before your changes - no time to
test now :)
--Geoff