httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: test base line
Date Mon, 13 Jul 2015 14:02:20 GMT
If you are using something like a hostname of foo.localdomain (or
whatever), make sure that /etc/hosts has that resolving to 127.0.0.1

> On Jul 13, 2015, at 9:50 AM, Stefan Eissing <stefan@eissing.org> wrote:
> 
> Rainer, 
> 
> many thanks for the detailed description. I installed all the perl modules you listed,
cleaned the test conf, rebuild the httpd with reallyreallyall modules and now the tests are
running *almost* fine.
> 
> I get 31 failures in modules/access.t and, frankly, cannot figure out what is wrong on
my system. This seem basic grant/deny tests.
> Test Summary Report
> -------------------
> t/modules/access.t                (Wstat: 0 Tests: 408 Failed: 31)
>  Failed tests:  4, 20-21, 24, 26, 28, 30, 38, 55, 72, 89
>                106-107, 123-124, 141, 154, 168, 170, 175
>                192, 209, 226, 277, 290, 304, 306, 311
>                328, 345, 362
> Files=110, Tests=4312, 72 wallclock secs ( 1.69 usr  0.17 sys + 32.46 cusr  8.66 csys
= 42.98 CPU)
> Result: FAIL
> Failed 1/110 test programs. 31/4312 subtests failed.
> 
> Since it matches the remote ip/host, it must be something in my name resolution, I assume?
Does that ring a bell with anyone?
> 
> PS. Btw. to eventually be helpful, I switched testing from trunk to the 2.4.16. Same
access errors, but everything else runs. (Ubuntu 14.04 LTS x86_64)
> 
> 
>> Am 11.07.2015 um 12:44 schrieb Rainer Jung <rainer.jung@kippdata.de>:
>> 
>> Hi Stefan,
>> 
>> Am 09.07.2015 um 13:46 schrieb Stefan Eissing:
>>> I need some help with establishing a test baseline. I checked out the test framework
from  https://svn.apache.org/repos/asf/httpd/test/framework/trunk, followed the README and
ran the tests against a freshly installed 2.4.x in /opt/httpd/2.4-plain. It did PASS with
the default httpd.conf, but many tests were skipped due to modules missing.
>>> 
>>> I tried enable some more modules like mod_ssl or mod_rewrite and all of these
attempts led to test failures and perl errors such as
>>> "t/security/CVE-2011-3368-rewrite.t .. 1/3 # Failed test 1 in t/security/CVE-2011-3368-rewrite.t
at line 13
>>> Can't call method "print" on an undefined value at t/security/CVE-2011-3368-rewrite.t
line 19.
>>> "
>>> My perl is the default Ubuntu 14.04 perl 5.18.
>>> 
>>> Is this a failure on my part or is the system supposed to operate like this?
I am a bit confused...
>> 
>> I typically use the default config from fresh build I do with configure flags --enable-modules=reallyall
and --enable-load-all-modules.
>> 
>> I don't get failures as described by you above. I typically run the perl framework
with perl plus locally installed modules. To instal modules as a normal user separate from
the system installed perl I use local::lib. The stuff I add is Bundle::ApacheTest and recent
versions of Test::Harness, Crypt::SSLeay, Net:SSLeay, IO::Socket::SSL, LWP::Protocol::https,
HTTP::DAV (plus whatever cpan automatically adds as further dependencies). The list probably
could be shortened, but that's the cruft I accumulated over time. When building the HTTPS/SSL
parts one must be careful to use the same OpenSSL version that one uses to build the web server.
Sometimes this is a bit tricky.
>> 
>> The failure in line 19 you describe happens at the end of the following snippet:
>> 
>> my $sock = Apache::TestRequest::vhost_socket();
>> ok $sock && $sock->connected;
>> 
>> my $req = "GET @"."localhost/foobar.html HTTP/1.1\r\n".
>>  "Host: " . Apache::TestRequest::hostport() . "\r\n".
>>   "\r\n";
>> 
>> ok $sock->print($req);
>> 
>> So it seems $sock is not defined. And indeed the failure in line 13 is the ok check
in the second code line above. So the test could not connect to the vhost.
>> 
>> Using t/TEST (try help or -help or -h to see the options) you can also just start
the web server configured for the tests without immediately running them. You can then try
to connect yourself.
>> 
>> You can also edit LogLevel in Apache-Test/lib/Apache/TestConfig.pm and increase it
before the perl Makefile.PL and the t/TEST to get more log output.
>> 
>> Not likely but maybe your system openssl is used by perl and can't connect to a vhost
powered by some other OpenSSL that you build your web server against?
>> 
>> The vhost_socket() used by the test is defined in lib/Apache/TestRequest.pm as:
>> 
>> sub vhost_socket {
>>   my $module = shift;
>>   local $Apache::TestRequest::Module = $module if $module;
>> 
>>   my $hostport = hostport(Apache::Test::config());
>> 
>>   my($host, $port) = split ':', $hostport;
>>   my(%args) = (PeerAddr => $host, PeerPort => $port);
>> 
>>   if ($module and $module =~ /ssl/) {
>>       require Net::SSL;
>>       local $ENV{https_proxy} ||= ""; #else uninitialized value in Net/SSL.pm
>>       return Net::SSL->new(%args, Timeout => UA_TIMEOUT);
>>   }
>>   else {
>>       require IO::Socket;
>>       return IO::Socket::INET->new(%args);
>>   }
>> }
>> 
>> Maybe you can add some debug output to STDOUT there to see to which socket it tries
to connect and where it fails.
>> 
>> Finally: any locally active pieces of security software intercepting the connect?
>> 
>> Regards,
>> 
>> Rainer
> 


Mime
View raw message