Re: test base line
On 2015-07-09 1:46 PM, Stefan Eissing wrote: 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. What I have done - using a MUCH older version of perl is the following: # perl -MCPAN -e shell And once configured to get sources, install Bundle::ApacheTest You may run into other issues you need to resolve before the Bundle installs successfully. Hope this helps! Is this a failure on my part or is the system supposed to operate like this? I am a bit confused... Thanks for the help, Stefan bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: test base line
OK. Case solved. test/framework/trunk found hardly innocent: On my Parallels Ubuntu image, the lines 127.0.0.1 localhost ::1 localhost existed. But the httpd.conf which is generated by t/TEST does a Listen 0.0.0.0:8529 which is a mix of ipv4/ipv6 that causes the startup to wait indefinitely for localhost to warm up. I assume the checks are done on ::1 and never answered. Removing the ::1 line from /etc/hosts solved the problem. On the other hand, If one replaces the "Listen 0.0.0.0:port" with "Listen port" and adds the ::1 line again to /etc/hosts, the startup problems are also gone. But the access.t tests now fail. So, something has to give. I think the tests should work in the presence of ipv6 nowadays. I definitely think that the Listen should be done with port only. //Stefan PS. This was a plain vanilla ubuntu 14.04 lts install. nothing fancy added. > Am 13.07.2015 um 22:17 schrieb Rainer Jung : > > Am 13.07.2015 um 17:34 schrieb Stefan Eissing: >> Ok, narrowing it down, but not done yet. Problem is as follows: >> >> 1 with 'localhost' as servername, tests were failing with "waiting for >> server to warm up", although server was reachable as http://localhost:8529/ >> strange. >> 2 with 'test.example.org' as servername and entry in /etc/hosts everything >> works except modules/access.t with 31 failures. >> After reading that code, I see that >> a) mod_access_compat makes a reverse lookup if it thinks the deny/allow is >> a host name and lookups are allowed. >> b) HostnameLookups is 'Off' in the test config >> c) /etc/hosts does not enable reverse lookups for the resolver (at least >> not on ubuntu/osx) >> >> So, it seems to me you all are testing with "127.0.0.1" or enable lookups >> and have a name from a DNS zone with proper reverse. Everything else should >> not work. > > Testing with localhost here. > > No precise idea here about your problem, but > > - make sure you don't have any proxy shell environment variables set > (http_proxy, https_proxy or similar) > > - we might get an idea if we can see your /etc/hosts and /etc/resolv.conf > (cleared from private info). > >> //Stefan (needs a drink) > > Taming the beast makes one thirsty. > > Rainer bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: test base line
Am 13.07.2015 um 17:34 schrieb Stefan Eissing: Ok, narrowing it down, but not done yet. Problem is as follows: 1 with 'localhost' as servername, tests were failing with "waiting for server to warm up", although server was reachable as http://localhost:8529/ strange. 2 with 'test.example.org' as servername and entry in /etc/hosts everything works except modules/access.t with 31 failures. After reading that code, I see that a) mod_access_compat makes a reverse lookup if it thinks the deny/allow is a host name and lookups are allowed. b) HostnameLookups is 'Off' in the test config c) /etc/hosts does not enable reverse lookups for the resolver (at least not on ubuntu/osx) So, it seems to me you all are testing with "127.0.0.1" or enable lookups and have a name from a DNS zone with proper reverse. Everything else should not work. Testing with localhost here. No precise idea here about your problem, but - make sure you don't have any proxy shell environment variables set (http_proxy, https_proxy or similar) - we might get an idea if we can see your /etc/hosts and /etc/resolv.conf (cleared from private info). //Stefan (needs a drink) Taming the beast makes one thirsty. Rainer
Re: test base line
Ok, narrowing it down, but not done yet. Problem is as follows: 1 with 'localhost' as servername, tests were failing with "waiting for server to warm up", although server was reachable as http://localhost:8529/ strange. 2 with 'test.example.org' as servername and entry in /etc/hosts everything works except modules/access.t with 31 failures. After reading that code, I see that a) mod_access_compat makes a reverse lookup if it thinks the deny/allow is a host name and lookups are allowed. b) HostnameLookups is 'Off' in the test config c) /etc/hosts does not enable reverse lookups for the resolver (at least not on ubuntu/osx) So, it seems to me you all are testing with "127.0.0.1" or enable lookups and have a name from a DNS zone with proper reverse. Everything else should not work. //Stefan (needs a drink) PS. And yes, 2.4.16 seems to work on Ubuntu 14.04 LTS. > Am 13.07.2015 um 16:02 schrieb Jim Jagielski : > > 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 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 : >>> >>> 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 your
Re: test base line
On Mon, Jul 13, 2015 at 9:50 AM, Stefan Eissing wrote: > 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) Maybe some non world readable/executable directory above docroot like $HOME?
Re: test base line
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 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 :
>>
>> 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);
>> }
>> }
>
Re: test base line
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 :
>
> 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
Re: test base line
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
