Re: perl-framework + apache 2.1.9 + openssl-0.9.8a
On Wed, Nov 23, 2005 at 03:42:42PM +0100, Oden Eriksson wrote:
> onsdagen den 23 november 2005 15.17 skrev Joe Orton:
> > On Sun, Nov 20, 2005 at 04:43:57PM +0100, Oden Eriksson wrote:
> > > Not so long ago I started packaging apache 2.1.x (rpm) and also run the
> > > perl-framework tests at build time in Mandriva Cooker (development branch
> > > of Mandriva Linux). Ever since I updated openssl-0.9.7i -> openssl-0.9.8a
> > > some ssl tests in the perl-framework stopped working. Is this a known
> > > fact?
> >
> > I see this too now that I have a box running 0.9.8a, all tests which
> > involve a client cert are failing. It looks like a failure on the
> > client side; from a quick manual test mod_ssl seems to be behaving
> > correctly. I'll investigate this further.
> >
> > joe
>
> I forgot to give an update on this. It fixed in Mandriva now. It was because
> openssl must not be built with these (or one of these) "no-mdc2 no-ec no-ecdh
> no-ecdsa".
Thanks. Having spoken to our OpenSSL maintainer it's something more
specifically to do with zlib compression being enabled by default now in
0.9.8a. We're using the below patch for the moment, be careful of the
patent minefield if you start turning on all those cipher suites.
--- openssl-0.9.8a/ssl/ssl_ciph.c.no-builtin-comp 2005-10-01
01:38:20.0 +0200
+++ openssl-0.9.8a/ssl/ssl_ciph.c 2005-11-22 16:08:37.0 +0100
@@ -203,6 +203,7 @@
static void load_builtin_compressions(void)
{
+#if 0
if (ssl_comp_methods != NULL)
return;
@@ -233,6 +234,7 @@
MemCheck_on();
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
+#endif
}
#endif
Re: Perl framework patch for Apache bug 37145
On Wed, Oct 26, 2005 at 01:30:22AM -0700, Zubin Kika wrote: > The patch is attached. > It contains the following files: > t/ssl/proxy_bug37145.t :The script file > t/htdocs/test.txt :Test file of size 100Kb > t/htdocs/test1.txt :Test file of size less than 8 Kb > t/htdocs/test2.txt :Test file of size 8Kb > t/htdocs/modules/cgi/testrev_proxy.pl :Perl file that > will handle the posted data > > Request you to please review the same. Thanks for the contribution. - the CGI script should not rely on CGI.pm - call the new test simply "t/ssl/pr37145.t" - attach files not tarballs when posting new code - create a new directory for new htdocs (t/htdocs/modules/ssl) - a CGI script which outputs 100Kb of data would be preferable to adding a 100Kb file directly to the repos - follow the normal code style (indenting, whitespace etc) for the .t code; should be something like: http://perl.apache.org/docs/2.0/devel/core/coding_style.html#Coding_Style_Guide joe
Re: mod_cache brokenness test
On Tue, Sep 27, 2005 at 10:55:17AM +0100, Colm MacCarthaigh wrote:
> I've done up a test for mod_cache + mod_dir brokenness;
>
> http://people.apache.org/~colm/cache-test.patch
>
> I've added a virtualhost for mod_cache, because caching can easily
> interfere with a lot of the other tests, and it's best kept out of
> the way (and to be expanded upon!).
>
> Anyway, as this is my first attempt at something in httpd/test/, I'm
> sure I got something wrong, and I'm not too sure of the procedures.
>
> Is it vaguely right? And can I commit it?
Some nits but otherwise go ahead, great!
1. use - the _default_: is not necessary AFAIK
2. use just "need 'cache', 'disk_cache'" for the requirements
But this test is going to fail with current releases, is that right? I
aim to keep the tests all passing with each tip-of-branch
2.0.x/2.2.x/trunk. So an additional requirement:
need foo, bar, need_min_apache_version('2.3.0')
would be good.
joe
Re: svn commit: r290157 - /httpd/test/trunk/perl-framework/c-modules/test_ssl/mod_test_ssl.c
On Mon, Sep 19, 2005 at 01:39:22PM -0400, Geoffrey Young wrote:
>
> > +#ifdef HAVE_SSL_EXT_LOOKUP
> > if (!ext_lookup) {
> > ap_rputs("ssl_ext_lookup not available", r);
> > return OK;
> > }
>
> hey, speaking of this ext_lookup, can you give me an example of what this
> function does? in Apache::SSLLookup I've added perl glue for this method,
> and right now I've got 2 forms:
>
> my $client_foo = $r->ext_lookup($something, 1);
> my $server_foo = $r->ext_lookup($something);
>
> but I really could never figure out what to glean from the generated ssl
> certificates to test against, what to pass as $something, etc.
"$something" should be the OID (unique identifier) of the extension
which you wish to look up.
The ssl_ext_lookup function has just been replaced with ssl_ext_list so
you'd probably want to support the latter. ssl_ext_list returns an
array of all extensions with that
All the certificates which are automatically generated in Apache-Test
have an "nsComment" extension, which has OID "2.16.840.1.113730.1.13",
set to "This Is A Comment", that's what I used for the t/ssl/extlookup.t
test.
So with 2.1.7 $r->ext_lookup("2.16.840.1.113730.1.13") should return
"This Is A Comment" for any SSL vhost in the test suite if it works
properly.
joe
Re: Looking for some help...
On Fri, Aug 19, 2005 at 05:24:06PM +0100, Joe Orton wrote: > On Fri, Aug 19, 2005 at 12:10:11PM -0400, Jim Jagielski wrote: > > Now I also have in proxy.conf.in: > > > > > > > > > > > >BalancerMember http://proxy_http_bal1 loadfactor=1 > >BalancerMember http://proxy_http_bal2 loadfactor=1 > > I tweaked Apache::Test to make this possible: try ... BalancerMember http://@SERVERNAME@:@PROXY_HTTP_BAL1_PORT@ ... etc - you must ensure that the referenced vhost is defined before you use the corresponding _PORT variable; i.e. put them in the same .conf.in file in that order. joe
Re: Looking for some help...
On Fri, Aug 19, 2005 at 12:10:11PM -0400, Jim Jagielski wrote: > I am trying to add a test for the proxy balancer stuff. yay! :) > In extra.conf.in I have: > > > > DocumentRoot @SERVERROOT@/htdocs/modules/proxy > > > > DocumentRoot @SERVERROOT@/htdocs/modules/proxy > > > > to define the 2 balanced proxies > > Now I also have in proxy.conf.in: > > > > > >BalancerMember http://proxy_http_bal1 loadfactor=1 >BalancerMember http://proxy_http_bal2 loadfactor=1 > > > ProxySet balancer://foo lbmethod=bytraffic > > >ProxyPass balancer://foo/ > > > > > > Now, the rub is that those 2 BalancerMember lines (http:// ...) > should actually have the url for the 2 balanced proxies > (localhost:port)... But I can't for the life of me figure > out how to obtain what the auto-gen'ed port numbers for those > 2 balanced vhosts will be. Hmm - do you really need the special vhosts if they will just behave the same as the default server? You can use @SERVERNAME@:@PORT@ to get that vhost name out. joe
Re: perl-framework: cgi.t 21 test failures due to missing mod_cgi.log file
On Mon, Aug 01, 2005 at 02:11:04AM -0700, Girish Muraly wrote: > Hi Joe, > > I am running the tests on Fedora Core 3. My Apache > (version 2.0.54) is configured as part of a LAMP stack > and I am running tests on each of the components > (Apache, Mysql and PHP,Perl,Python). I am quite new to > the httpd-tests. Are these details enough? Would you > like to me provide any specific details that would > help you? I've not seen this problem before, so I think you'll have to investigate it further yourself unless someone else can help. Is it a permissions problem, perhaps? Do you run as root, or as a normal user? (I always run httpd-test as a local user) You can run the tests using "./t/TEST -v t/modules/cgi.t" to get perhaps more useful information; look at t/logs/error_log to see if any pertinent error messages concerning creation of the script log are mentioned (though it doesn't look like mod_cgi would log any actually) joe
Re: perl-framework: cgi.t 21 test failures due to missing mod_cgi.log file
On Mon, Aug 01, 2005 at 12:04:42AM -0700, Girish Muraly wrote: > I ran the httpd-tests and I got 21 test failures in > the perl-framework due to t/modules/cgi.t and 1 error > due to t/modules/include.t. The errors are: > [just the snippet from running t/TEST] > > t/modules/cgi...NOK 14# Failed test 14 in On what platform are you seeing this, and what httpd configuration (what version, what MPM)? joe
Re: Listen 0.0.0.0: is invalid
On Wed, Feb 23, 2005 at 07:37:54AM -0800, Justin Erenkrantz wrote: > --On Wednesday, February 23, 2005 9:42 AM +0000 Joe Orton > <[EMAIL PROTECTED]> wrote: > > >But there is no way to differentiate between any different interfaces > >for the address (without doing magic), so I would say that is a resolver > >misfeature. > > But, the resolver was explicitly told that the socket addresses will be > used to connect() - not for bind(). That's why I'm not convinced this > behavior is 'wrong' per se. A connect() to 0.0.0.0:80 is just the same; I don't see why it would ever be useful to include two completely identical addresses in the getaddrinfo results. Simply passing AI_PASSIVE does make it omit the duplicates? (http://cvs.apache.org/~jorton/gai.c is useful for testing getaddrinfo behaviour) > >to configure httpd to bind only to "all IPv4 addresses on the local host > >with port X" (right?), which is certainly a valid and useful thing to > >do. > > > >I think httpd should work around this: does something like the attached > >work? (tested only to compile ;) Not necessarily the best place to put > >this logic. > > It seems that we should have a better internal semantic than passing in a > bogus address to connect to. Perhaps httpd in alloc_listener should > intercept the '0.0.0.0' case and set the hostname to NULL and set the > family to IPv4? This would preserve the correct internal semantics we're > looking for such that AI_PASSIVE can be set so we get bind()able addresses. > > Would that be better? -- justin INADDR_ANY is not really a bogus address, but yes I think that does make more sense. It would also need to translate "::" into hostname=NULL+family=AF_INET6 for consistency I suppose. But triggering the AI_PASSIVE path is generally desirable. Do you have time to try that out? joe
Re: Listen 0.0.0.0: is invalid
On Wed, Feb 23, 2005 at 09:42:12AM +, Joe Orton wrote: > On Tue, Feb 22, 2005 at 10:52:57PM -0800, Justin Erenkrantz wrote: > > The issue with this is that wildcard IP addresses aren't really supposed to > > be explicit in Listen statements. httpd has a bunch of logic for inferring > > the right IP wildcards - trying to out-guess can lead to real badness. > > Specifically, this mucks with APR's ability to set AI_PASSIVE - which is > > required for use with address that we will later call bind() on - i.e. our > > listeners. So, Listen with an IP address should only be used for real > > addresses. > > The problem was that 2.0.x will only accept connections to IPv6 > addresses with a single "Listen " Missing the critical qualifier :) "on *BSD systems which disable V4-mapped addresses by default"
Re: Listen 0.0.0.0: is invalid
On Tue, Feb 22, 2005 at 10:52:57PM -0800, Justin Erenkrantz wrote:
> No idea why I'm suddenly hitting this, but in preparation for 2.1.3, I
> spent another one of my patented hours searching for bugs in httpd that end
> up being bugs in the perl-framework tests. =(
>
> perl-framework generates Listen directives in the order of:
> 'Listen 0.0.0.0:8529'
>
> For me, this causes errors like:
> (48)Address already in use: make_sock: could not bind to address
> 0.0.0.0:8531
> no listening sockets available, shutting down
> Unable to open logs
>
> On Mac OS X 10.3.8 (7.8.0 via uname -r), getaddrinfo() without AI_PASSIVE
> can return duplicate IP addresses. This leads to the error condition that
> causes the failure. And, based on my reading of the docs, I'm not sure
> that's patently incorrect behavior on Darwin's part: that's 0.0.0.0 for
> both the localhost and the network card.
But there is no way to differentiate between any different interfaces
for the address (without doing magic), so I would say that is a resolver
misfeature.
"Listen 0.0.0.0:" should always work because there's no other way
to configure httpd to bind only to "all IPv4 addresses on the local host
with port X" (right?), which is certainly a valid and useful thing to
do.
I think httpd should work around this: does something like the attached
work? (tested only to compile ;) Not necessarily the best place to put
this logic.
> The issue with this is that wildcard IP addresses aren't really supposed to
> be explicit in Listen statements. httpd has a bunch of logic for inferring
> the right IP wildcards - trying to out-guess can lead to real badness.
> Specifically, this mucks with APR's ability to set AI_PASSIVE - which is
> required for use with address that we will later call bind() on - i.e. our
> listeners. So, Listen with an IP address should only be used for real
> addresses.
The problem was that 2.0.x will only accept connections to IPv6
addresses with a single "Listen "; but since LWP doesn't support
IPv6, that doesn't work for httpd-test. The alternative is to start
getting complicated but with the different logic in 2.0 and 2.1 I think
it would be better to avoid this.
joe
Index: server/listen.c
===
--- server/listen.c (revision 154212)
+++ server/listen.c (working copy)
@@ -353,6 +353,18 @@
continue;
}
#endif
+/* Skip duplicates addresses returned for an AI_PASSIVE
+ * lookup for 0.0.0.0 on Darwin: */
+if (previous != NULL
+&& lr->bind_addr->family == APR_INET
+&& lr->bind_addr->sa.sin.sin_addr.s_addr == INADDR_ANY
+&& previous->bind_addr->family == APR_INET
+&& previous->bind_addr->sa.sin.sin_addr.s_addr == INADDR_ANY
+&& lr->bind_addr->port == previous->bind_addr->port) {
+previous->next = lr->next;
+continue;
+}
+
if (make_sock(pool, lr) == APR_SUCCESS) {
++num_open;
lr->active = 1;
Re: svn commit: r148889 - /httpd/test/trunk/perl-framework/t/conf/ssl/ssl.conf.in /httpd/test/trunk/perl-framework/t/ssl/fakeauth.t
On Fri, Jan 28, 2005 at 05:22:28PM +, Joe Orton wrote: > On Fri, Jan 28, 2005 at 06:03:14PM +0100, Dominique Quatravaux wrote: > > Geoffrey Young wrote: > > > > | > > | so, are you saying that can remove SSLVerifyClient here and all is > > | ok? > > > > No no, you're right and Joe was wrong, you must not change a thing. > > Sorry for being unclear! > > I think you're confused about the difference between SSLVerifyClient > "optional" and "require" ...he says... > : both insist on a new handshake, both send the > client a CertificateRequest message, but the former will fail the SSL > handshake if no cert is presented; the latter will not. ...and then explains it backwards - exchange "former" and "latter" in that sentence...
Re: svn commit: r148889 - /httpd/test/trunk/perl-framework/t/conf/ssl/ssl.conf.in /httpd/test/trunk/perl-framework/t/ssl/fakeauth.t
On Fri, Jan 28, 2005 at 06:03:14PM +0100, Dominique Quatravaux wrote:
> Geoffrey Young wrote:
>
> |
> | so, are you saying that can remove SSLVerifyClient here and all is
> | ok?
>
> No no, you're right and Joe was wrong, you must not change a thing.
> Sorry for being unclear!
I think you're confused about the difference between SSLVerifyClient
"optional" and "require": both insist on a new handshake, both send the
client a CertificateRequest message, but the former will fail the SSL
handshake if no cert is presented; the latter will not. So doing an
SSLRequire check for %{SSL_VERIFY_CLIENT} after using "SSLVerifyClient
require" is redundant. Geoff, removing the SSLRequire line is right, it
doesn't really matter though...
joe
Re: svn commit: r148889 - /httpd/test/trunk/perl-framework/t/conf/ssl/ssl.conf.in /httpd/test/trunk/perl-framework/t/ssl/fakeauth.t
On Fri, Jan 28, 2005 at 02:40:38PM -, [EMAIL PROTECTED] wrote:
> +
> +# specific to 2.1
> +
> +
> +
> +SSLVerifyClient require
> +SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
> +SSLOptions +FakeBasicAuth +StdEnvVars
Did you mean SSLVerifyClient optional? Otherwise the SSLRequire is
surely redundant?
Re: svn commit: r111596 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/server/listen.c
On Sat, Dec 11, 2004 at 09:53:17AM -, Paul Querna wrote:
> Author: pquerna
> Date: Sat Dec 11 01:53:16 2004
> New Revision: 111596
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=111596
> Log:
> * Add bits to use APR_TCP_DEFER_ACCEPT
> * Log Warnings when adding defer accept or an accept filter fails.
Hmmm - t/protocol/nntp-lite.t now hangs in the test suite on Linux. I
suppose that doing a deferred accept is fundamentally incompatible with
protocols like NNTP where the client will connect() then read() a banner
line before writing any data. Did this test work on FreeBSD before,
does anyone know?
> --- httpd/httpd/trunk/server/listen.c (original)
> +++ httpd/httpd/trunk/server/listen.c Sat Dec 11 01:53:16 2004
> @@ -164,7 +164,20 @@
> #endif
> #endif
> #endif
> -apr_socket_accept_filter(s, ACCEPT_FILTER_NAME, "");
> +stat = apr_socket_accept_filter(s, ACCEPT_FILTER_NAME, "");
> +if (stat != APR_SUCCESS && !APR_STATUS_IS_ENOTIMPL(stat)) {
> +ap_log_perror(APLOG_MARK, APLOG_WARNING, stat, p,
> + "Failed to enable the '%s' Accept Filter",
> + ACCEPT_FILTER_NAME);
> +}
> +#else
> +#ifdef APR_TCP_DEFER_ACCEPT
> +stat = apr_socket_opt_set(s, APR_TCP_DEFER_ACCEPT, 1);
> +if (stat != APR_SUCCESS && !APR_STATUS_IS_ENOTIMPL(stat)) {
> +ap_log_perror(APLOG_MARK, APLOG_WARNING, stat, p,
> + "Failed to enable APR_TCP_DEFER_ACCEPT");
> +}
> +#endif
> #endif
>
> server->sd = s;
Re: SVN release methodology : svn copy
On Sat, Dec 11, 2004 at 11:43:56AM -0800, Philippe M. Chiasson wrote: > [EMAIL PROTECTED] wrote: > >Author: stas > >Date: Sat Dec 11 11:15:27 2004 > >New Revision: 111615 > > > >URL: http://svn.apache.org/viewcvs?view=rev&rev=111615 > >Log: > >tag 1.17 > > > >Added: > > httpd/test/tags/APACHE_TEST_1_17/ > > - copied from r111612, httpd/test/trunk/perl-framework/Apache-Test/ > > httpd/test/tags/APACHE_TEST_1_17/Changes > > - copied unchanged from r111614, > > httpd/test/trunk/perl-framework/Apache-Test/Changes > > httpd/test/tags/APACHE_TEST_1_17/Makefile.PL > > - copied unchanged from r111613, > > httpd/test/trunk/perl-framework/Apache-Test/Makefile.PL > > httpd/test/tags/APACHE_TEST_1_17/RELEASE > > - copied unchanged from r111613, > > httpd/test/trunk/perl-framework/Apache-Test/RELEASE > > Anybody care to shed some light to what exactly this means? > > Our normal release process is something like this: > > $> make dist > [... test ...] > $> vi lib/Apache/Test.pm [bump version] > $> svn ci -m'Bump version' lib/Apache/Test.pm > $> svn copy . https://svn.apache.org/[...]/tags/1.17 > > And I thought this was the appropriate way to go about it. From what I > can gather by reading this message, the copy operation wasn't 100% > clean, am I right ? I think it's OK, but since you had a mixed revision working copy it looks a little strange: you had: . => last "svn update" at r111612 Makefile.PL, RELEASE => committed changes in r111613 Changes => committed changes in r111614 and so when you copied the WC to the tag, that's exactly what SVN copied. If you had run "svn update" first, it would all have been copied from the same revision, r111614 (or whatever). But the normal procedure for tagging is to copy from URL to URL, which avoids this and is faster: svn copy https://svn.apache.org/.../trunk \ https://svn.apache.org/.../tags/1.17 (optionally with an -r to peg at specific revision, I guess) joe > > At this point, I am just a bit worried that there is something going > on that I am not fully aware, so if anybody can shed some light, it > would be much appreciated. > > > Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : > 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 > A107 88C3A5A5
Re: Problem building Apache::Test module on RHEL WS 3.0
On Wed, Dec 01, 2004 at 03:46:55PM -0500, Brian McEntire wrote: ... > I did a make clean > perl Makefile.PL > make test > > This time I get a different error message, it appears to success past the > original 'nobody' problem. The output is: > > [warning] setting ulimit to allow core files > ulimit -c unlimited; /usr/bin/perl /tmp/Apache-Test-1.16/t/TEST -bugreport > -verbose=0 > APXS (/usr/sbin/apxs) query for SBINDIR failed > APXS (/usr/sbin/apxs) query for TARGET failed ... Do you have the httpd-devel package installed? IIRC this failure can occur when Apache-Test finds /usr/sbin/httpd but not /usr/sbin/apxs. I only ever build directly from the source repos not a tarball, and use: perl Makefile.PL -apxs /usr/sbin/apxs make && ./t/TEST running as a local user not root (it's simpler that way); this works fine with the RHEL3 httpd, unless you have enough modules installed that you hit the dynamic module limit. Regards, joe
Re: is it safe to enable Lockfile for all mpms across all apache generations?
On Wed, Nov 24, 2004 at 04:45:18PM -0500, Stas Bekman wrote: > It looks like some poeple have a problem with LockFile directive being > compiled to a hardcoded value. > > The problem: > > [Tue Nov 02 17:16:22 2004] [emerg] (13)Permission denied: Couldn't create > accept lock > > Is it safe to set LockFile for all mpms? Yes, looks like it should be. > For apache 1.3? I think so too. joe
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
On Tue, Nov 23, 2004 at 12:55:16PM -0600, William Rowe wrote: > What I questioned was why we were doing the security validation > of PHP when it's outside the scope of httpd, or isn't due to some > interaction with httpd. This is true for most of the functional tests of PHP in t/php/ which Covalent donated. I don't necessarily disagree, but I do I find it useful. Possibly these tests could go in the PHP test suite as well, I'm not sure. If that's your itch... > I also questioned shoving scary security/CAN-2004-.t failures > at our users. FIRST this should never have been in security/ - > it should have been a php/ test. Again, this is not our security > incident within httpd. I don't really care either way, smells like a freshly painted bikeshed to me ;) > Second, whenever we fail any CAN-2004-.t we must direct the > user to some patch where they can remedy the situation. I'm sort > of laughing that I spent 4 hours yesterday researching two vulns > that many other engineers had spent 4 hours researching. The > laughable thing - show me on www.php.net where they call out any > patches for 4.3.x to these two incidents? They don't, it was fixed silently, I mailed them about that but they didn't seem inclined to do anything about it. If you want to follow up on that some more, great, but ranting about it here won't make much difference. joe
Re: svn commit: r105803 - etc
On Fri, Nov 19, 2004 at 04:21:31PM -0500, Stas Bekman wrote: > Joe Orton wrote: > >When a propchange is committed a notification mail *will* be sent, but > >the post-commit script won't actually tell you the before-and-after in > >that case, it seems. I'm not sure whether that's a deficiency of the > >script being used or of SVN itself. > > You mean it only tells that there was a change, but not what was the > change? if so who should be asked to fix that? http://marc.theaimsgroup.com/?l=apache-cvs&m=110085589310749&w=2 Looks that way, yup. infrastructure@ is who, I guess, if they're still awake ;)
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/ea
On Fri, Nov 19, 2004 at 03:23:46PM -0500, Stas Bekman wrote: > Geoffrey Young wrote: > > > >>what's the replacement for .cvsignore under svn? I can't see where the > >>data in .cvsignore has migrated to. > > > > > >each directory now has properties and one of those properties is which > >files > >to ignore. see > > Yes, but how do I see the change? I've seen Joe removing .cvsignore files. > I have no idea whether he has added the properties for each of the removed > files or not. The changes should be emailed no? The .cvsignore properties were automatically added into the svn:ignore properties by cvs2svn when the repos was converted, so when I removed the .cvsignore files that's all I did, nothing else needed tweaking. When a propchange is committed a notification mail *will* be sent, but the post-commit script won't actually tell you the before-and-after in that case, it seems. I'm not sure whether that's a deficiency of the script being used or of SVN itself. (For Geoff): the quick'n'easy way to add a file to svn:ignore is: $ svn propedit svn:ignore . which brings up the property contents in $EDITOR. joe
Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t
On Thu, Oct 28, 2004 at 03:19:32PM -0400, Geoffrey Young wrote: > > > [EMAIL PROTECTED] wrote: > > jorton 2004/10/25 06:04:14 > > > > Modified:perl-framework/t/conf extra.conf.in > > Added: perl-framework/t/htdocs/security CAN-2004-0940.shtml > >perl-framework/t/security CAN-2004-0940.t > > Log: > > Regression test for CAN-2004-0940, 1.3 mod_include overflow. > > hi joe :) > > I get the following failures on 1.3.32 but not on 1.3.33. > > t/modules/rewrite.t 222 9.09% 18 20 > t/security/CAN-2004-0940.t11 100.00% 1 Those bugs are present in 1.3.32, so that's expected. > t/security/CAN-2004-0958.t92 22.22% 1 3 Did you change PHP version too? That's a PHP test, the result shouldn't change unless you change PHP version too with 1.3.33? > I think these are all recent additions from you. should each of these > failures be skipped unless something like > > ( have_apache(1) && have_min_apache_version(1.3.33) ) || > ( have_apache(2) && have_min_apache_version(2.0.XX) ) Welll... we started having this debate a while back :) Here's my take: I think it's correct to: 1) only test for new features in versions on which they are known to be present 2) test for bugs in all versions unconditionally in all affected versions I think it's the desired outcome that if you test 1.3.32 for CAN-2004-0940, it should fail: 1.3.32 is after all vulnerable to CAN-2004-0940. Why hide that by skipping the test? Likewise, if you're running 1.3.32 you *should* be told that there is a nasty mod_rewrite regression in that version. Maybe I'm hawking my corporate agenda here a little too, because it makes httpd-test slightly more useful to me since I can test for 1.3.x + backported patch, whereas if the test was skipped for <1.3.33 it won't demonstrate that the code is patched. Does that make sense? joe
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
On Mon, Oct 25, 2004 at 06:47:12PM -0700, David Wheeler wrote: > No, just hacking. Let's see...oh, I get it. I changed it so that it > ignored $RedirectOK if LWP was installed. Thanks David. No comments here on what's right, only what works ;)
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
On Sun, Oct 24, 2004 at 11:37:11AM +0100, Joe Orton wrote: > On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote: > > theory 2004/10/22 15:09:54 > > > > Modified:perl-framework/Apache-Test Changes > >perl-framework/Apache-Test/lib/Apache TestRequest.pm > > Log: > > Redirect from POST fixes (or prevention, depending on how you lok at it). > > It looks like this change broke the t/modules/alias.t test in > httpd-test? Also mod_perl's t/apache/scanhdrs2.t started failing and I > can't see anything else that changed, sorry, no time to look any further > into it at the mo... Any chance this could be fixed or reverted? It's hindering regression testing... unexpected failures in httpd-test are currently: t/modules/alias.t 62 15 24.19% 14-18 49-58 t/ssl/proxy.t1723 1.74% 8 62 121 joe
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote: > theory 2004/10/22 15:09:54 > > Modified:perl-framework/Apache-Test Changes >perl-framework/Apache-Test/lib/Apache TestRequest.pm > Log: > Redirect from POST fixes (or prevention, depending on how you lok at it). It looks like this change broke the t/modules/alias.t test in httpd-test? Also mod_perl's t/apache/scanhdrs2.t started failing and I can't see anything else that changed, sorry, no time to look any further into it at the mo... joe
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm
On Wed, Oct 20, 2004 at 11:37:45PM -0400, Stas Bekman wrote: > [EMAIL PROTECTED] wrote: > >jorton 2004/10/20 06:42:07 > > > > Modified:perl-framework/Apache-Test/lib/Apache Test.pm > > Log: > > Add the need_php4 export. > > It's of little value if it's not documented, especially when the rest is. > Joe, please see the pod at the end of that file (search for need_php). I documented it in the commit before :)
Re: automagical support for PHP scripts in Apache-Test
On Mon, Oct 18, 2004 at 04:13:02PM -0400, Geoffrey Young wrote: ... > you're on your way to writing Test::Harness compatible php scripts via > Apache-Test. whee! Cool stuff! > the missing parts are important parts of Aapche::Test and Apache::TestUtil > implemented in php. but if we just focused on adding plan(), ok() and > t_cmp() I think we would have enough to ship. andy lester started some of > this here: > > http://use.perl.org/~petdance/journal/14227 > > so I just need a clue on how to load a library in php and how to adjust > httpd.conf so that that the library is picked up, then we can port andy's > code over and... If by "library" you mean "file containing PHP code" you just have the include() and require() statements AFAIK, there's no way to this globally from php.ini/httpd.conf, again, AFAIK. __DATA__ emulation in PHP sounds... difficult ;) joe
t/htdocs/php/* licensing
I just noticed that t/htdocs/php/regression* look like they are copies of files in the PHP source tree, yet have no associated license or copyright notices attached: http://cvs.apache.org/viewcvs.cgi/httpd-test/perl-framework/t/htdocs/php/regression2.php?rev=1.1.1.1&view=markup vs http://cvs.php.net/co.php/php-src/tests/lang/024.phpt?r=1.5 can anyone clarify where these files came from? joe
test status
http://www.apache.org/~jorton/regress/httpd-test.html shows nightly test build status against: (tip of 2.0 branch, HEAD) x (prefork, worker, prefork with --enable-pool-debug -lefence) for a few Linux boxes. There are some segfaults in mod_rewrite triggered in the 2.0/prefork+debug build: http://www.apache.org/~jorton/regress/2004-10-08/jolt/httpd-test-on-2.0-debug-test.log Otherwise, there are the expected apache/contentlength.t failures with all 2.0 builds on Linux, and everything else looks OK. joe
Re: cvs commit: httpd-test/perl-framework/c-modules/test_pass_brigade mod_test_pass_brigade.c
On Wed, Sep 29, 2004 at 01:19:24PM -0400, Cliff Woolley wrote:
> On Wed, 29 Sep 2004 [EMAIL PROTECTED] wrote:
>
> > jorton 2004/09/29 08:03:59
> >
> > Modified:perl-framework/c-modules/test_pass_brigade
> > mod_test_pass_brigade.c
> > Log:
> > Prevent death by memory consumption in an --enable-pool-debug/-lefence
> > build: allocate and {ab,re}use a single brigade structure rather than
> > allocating one out of r->pool for each block sent (see also "why are
> > brigades allocated out of pools this is insane" threads).
>
> Um, I actually never saw any such threads. Where were they?
OK, I paraphrased somewhat, but:
recent: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108732600304014&w=2
historic: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=104039770718467&w=2
> Anyway, there actually was a brief period of time about two years ago when
> they were not allocated out of pools. I was under the mistaken impression
> that that was still the case, but apparently brianp reverted his own
> commit about a week afterward for some reason I can no longer recall
> (presumably it broke something and it was easier at the time to revert
> than fix because a new release of httpd was pending).
The fact is that now, we can't fix it in 2.0 because there are output
filters which presume they can apr_brigade_destroy() the brigade passed
in, and there are other filters which presume they can reuse a brigade
which they passed down.
Many of the filters in httpd will allocate new brigades when you pass a
FLUSH bucket up (e.g. PR23567, a slow-running CGI), which leads to
memory usage proportional to number of FLUSH buckets sent etc etc...
joe
Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t
On Wed, Sep 29, 2004 at 10:26:05AM +0100, Joe Orton wrote: > On Wed, Sep 29, 2004 at 06:53:42AM -, [EMAIL PROTECTED] wrote: > > jerenkrantz2004/09/28 23:53:42 > > > > Modified:perl-framework/c-modules/nntp_like mod_nntp_like.c > >perl-framework/t/apache contentlength.t > >perl-framework/t/protocol nntp-like.t > > Log: > > Fix up nntp-like and content-length tests to pass. > > To pass against what httpd on what platform? They were passing on Linux > against 2.0 and HEAD. But now they're not :) Against HEAD I now get: OK, the difference is in the handling of an empty Content-Length header. The glibc strtoll does not return an error for an empty string, as C99 requires, and so ap_http_filter treats it exactly as "Content-Length: 0". I guess the strto* on your platform does return an error for this case: I'd say a 400 is a better error than a 413 for "Content-Length:\r\n" but 413 is clearly better than 200, so I've fixed ap_http_filter in HEAD. joe
Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t
On Wed, Sep 29, 2004 at 06:53:42AM -, [EMAIL PROTECTED] wrote: > jerenkrantz2004/09/28 23:53:42 > > Modified:perl-framework/c-modules/nntp_like mod_nntp_like.c >perl-framework/t/apache contentlength.t >perl-framework/t/protocol nntp-like.t > Log: > Fix up nntp-like and content-length tests to pass. To pass against what httpd on what platform? They were passing on Linux against 2.0 and HEAD. But now they're not :) Against HEAD I now get: t/apache/contentlength..# Failed test 2 in t/apache/contentlength.t at line 54 # Failed test 4 in t/apache/contentlength.t at line 54 fail #2 FAILED tests 2, 4 Failed 2/20 tests, 90.00% okay Yup, the t_cmp arguments were flipped a while back.
shell_ready function
Does the quote escaping really work in this function? It confuses emacs
font-lock mode which doesn't see a closing quote so thinks the rest of
the file is part of the string. This fixes at least the latter:
Index: TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.239
diff -u -r1.239 TestConfig.pm
--- TestConfig.pm 15 Aug 2004 23:19:57 - 1.239
+++ TestConfig.pm 18 Aug 2004 08:55:29 -
@@ -1754,7 +1754,7 @@
# escape quotes)
sub shell_ready {
my $arg = shift;
-$arg =~ s/"/\"/g;
+$arg =~ s/"/\\"/g;
return qq["$arg"];
}
Re: cvs commit: httpd-test/perl-framework/t/htdocs/modules/cgi nph-foldhdr.pl.PL .cvsignore
On Tue, Aug 17, 2004 at 01:15:57PM -0400, Geoffrey Young wrote:
>
> > +sok {
> > +t_cmp(200,
> > + GET('/modules/cgi/nph-foldhdr.pl')->code,
> > + "CGI script with folded headers");
>
> I swapped the arguments passed to t_cmp() here and elsewhere in the file so
> that they match the new order (received results first). as I don't have ssl
> installed at the moment, if you could run through it again to make sure I
> didn't break anything that would be great :)
Thanks, yes, it still works. I'll try to remember to switch the
arguments around whenever I touch other files too...
joe
Re: failing httpd-test tests
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: failing httpd-test tests
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.pm9 Aug 2004 06:19:15 -
1.235
+++ Apache-Test/lib/Apache/TestConfig.pm10 Aug 2004 21:12:59 -
@@ -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
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 +' -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 +' -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
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
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
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.pm9 Aug 2004 06:19:15 -
1.235
+++ Apache-Test/lib/Apache/TestConfig.pm9 Aug 2004 15:37:38 -
@@ -371,13 +371,27 @@
my $mname = $name . '_module_name';
+debug "dm: looking for $mname";
+
+if ($self->{vars}->{$mname}) {
+debug "dm: already got $self->{vars}->{$mname}";
+}
+
unless ($self->{vars}->{$mname}) {
($self->{vars}->{$mname}) = grep {
$self->{modules}->{"$_.c"};
} @$choices;
+if ($self->{vars}->{$mname}) {
+debug "dm: found $self->{vars}->{$mname} from choices";
+} else {
+debug "dm: falling back on default $choices->[0]";
+}
+
$self->{vars}->{$mname} ||= $choices->[0];
}
+
+debug "dm: found $self->{vars}->{$mname}";
$self->{vars}->{$name . '_module'} =
$self->{vars}->{$mname} . '.c'
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /var/tmp/pf-4/t/TEST -conf
[ debug] no custom config data was loaded
[ debug] dm: looking for cgi_module_name
[ debug] dm: falling back on default mod_cgi
[ debug] dm: found mod_cgi
[ debug] dm: looking for thread_module_name
[ debug] dm: falling back on default worker
[ debug] dm: found worker
[ debug] dm: looking for ssl_module_name
[ debug] dm: falling back on default mod_ssl
[ debug] dm: found mod_ssl
[ debug] dm: looking for access_module_name
[ debug] dm: falling back on default mod_access
[ debug] dm: found mod_access
[ debug] dm: looking for auth_module_name
[ debug] dm: falling back on default mod_auth
[ debug] dm: found mod_auth
[ debug] dm: looking for php_module_name
[ debug] dm: falling back on default mod_php4
[ debug] dm: found mod_php4
[ debug] configuring httpd
[ debug] no custom config data was loaded
[ debug] Writing custom config /var/tmp/pf-4/lib/Apache/TestConfigData.pm
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <[EMAIL PROTECTED]>
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <[EMAIL PROTECTED]>
[ debug] isolated httpd_info VERSION = Apache/2.1.0-dev
[ debug] isolated httpd_info BUILT = Aug 9 2004 09:08:40
[ debug] isolated httpd_info MODULE_MAGIC_NUMBER = 20040425:1
[ debug] isolated httpd_info SERVER_MPM = Prefork
[ debug] isolated httpd_defines APACHE_MPM_DIR = server/mpm/prefork
[ debug] isolated httpd_defines APR_HAS_SENDFILE = 1
[ debug] isolated httpd_defines APR_HAS_MMAP = 1
[ debug] isolated httpd_defines APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
= 1
[ debug] isolated httpd_defines APR_USE_SYSVSEM_SERIALIZE = 1
[ debug] isolated httpd_defines APR_USE_PTHREAD_SERIALIZE = 1
[ debug] isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1
[ debug] isolated httpd_defines APR_HAS_OTHER_CHILD = 1
[ debug] isolated httpd_defines AP_HAVE_RELIABLE_PIPED_LOGS = 1
[ debug] isolated httpd_defines HTTPD_ROOT = /tmp/regressPPKikg/2.1-root
[ debug] isolated httpd_defines SUEXEC_BIN =
/tmp/regressPPKikg/2.1-root/bin/suexec
[ debug] isolated httpd_defines DEFAULT_PIDLOG = logs/httpd.pid
[ debug] isolated httpd_defines DEFAULT_SCOREBOARD = logs/apache_runtime_status
[ debug] isolated httpd_defines DEFAULT_LOCKFILE = logs/accept.lock
[ debug] isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log
[ debug] isolated httpd_defines AP_TYPES_CONFIG_FILE = conf/mime.types
[ debug] isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd.conf
[ 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] using httpd.conf inherited ServerRoot to resolve
modules/mod_case_filter.so
[ debug] modules/mod_case_filter.so successfully resolved to existing file
/tmp/regressPPKikg/2.1-root/modules/mod_case_filter.so
[ debug] Found: case_filter_module => mod_case_filter.c
[ debug] LoadModule case_filter_module mod_case_filter.c
[ deb
Re: failing httpd-test tests
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
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /var/tmp/pf-4/t/TEST -conf
[ debug] no custom config data was loaded
[ debug] configuring httpd
[ debug] no custom config data was loaded
[ debug] Writing custom config /var/tmp/pf-4/lib/Apache/TestConfigData.pm
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <[EMAIL PROTECTED]>
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <[EMAIL PROTECTED]>
[ debug] isolated httpd_info VERSION = Apache/2.1.0-dev
[ debug] isolated httpd_info BUILT = Aug 9 2004 09:08:40
[ debug] isolated httpd_info MODULE_MAGIC_NUMBER = 20040425:1
[ debug] isolated httpd_info SERVER_MPM = Prefork
[ debug] isolated httpd_defines APACHE_MPM_DIR = server/mpm/prefork
[ debug] isolated httpd_defines APR_HAS_SENDFILE = 1
[ debug] isolated httpd_defines APR_HAS_MMAP = 1
[ debug] isolated httpd_defines APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
= 1
[ debug] isolated httpd_defines APR_USE_SYSVSEM_SERIALIZE = 1
[ debug] isolated httpd_defines APR_USE_PTHREAD_SERIALIZE = 1
[ debug] isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1
[ debug] isolated httpd_defines APR_HAS_OTHER_CHILD = 1
[ debug] isolated httpd_defines AP_HAVE_RELIABLE_PIPED_LOGS = 1
[ debug] isolated httpd_defines HTTPD_ROOT = /tmp/regressPPKikg/2.1-root
[ debug] isolated httpd_defines SUEXEC_BIN =
/tmp/regressPPKikg/2.1-root/bin/suexec
[ debug] isolated httpd_defines DEFAULT_PIDLOG = logs/httpd.pid
[ debug] isolated httpd_defines DEFAULT_SCOREBOARD = logs/apache_runtime_status
[ debug] isolated httpd_defines DEFAULT_LOCKFILE = logs/accept.lock
[ debug] isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log
[ debug] isolated httpd_defines AP_TYPES_CONFIG_FILE = conf/mime.types
[ debug] isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd.conf
[ 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] using httpd.conf inherited ServerRoot to resolve
modules/mod_case_filter.so
[ debug] modules/mod_case_filter.so successfully resolved to existing file
/tmp/regressPPKikg/2.1-root/modules/mod_case_filter.so
[ debug] Found: case_filter_module => mod_case_filter.c
[ debug] LoadModule case_filter_module mod_case_filter.c
[ debug] using httpd.conf inherited ServerRoot to resolve
modules/mod_case_filter_in.so
[ debug] modules/mod_case_filter_in.so successfully resolved to existing file
/tmp/regressPPKikg/2.1-root/modules/mod_case_filter_in.so
[ debug] Found: case_filter_in_module => mod_case_filter_in.c
[ debug] LoadModule case_filter_in_module mod_case_filter_in.c
[ debug] using httpd.conf inherited ServerRoot to resolve
modules/mod_deflate.so
[ debug] modules/mod_deflate.so successfully resolved to existing file
/tmp/regressPPKikg/2.1-root/modules/mod_deflate.so
[ debug] Found: deflate_module => mod_deflate.c
[ debug] LoadModule deflate_module mod_deflate.c
[ debug] using httpd.conf inherited ServerRoot to resolve
modules/mod_expires.so
[ debug] modules/mod_expires.so successfully resolved to existing file
/tmp/regressPPKikg/2.1-root/modules/mod_expires.so
[ debug] Found: expires_module => mod_expires.c
[ debug] LoadModule expires_module mod_expires.c
[ debug] using httpd.conf inherited ServerRoot to resolve
modules/mod_headers.so
[ debug] modules/mod_headers.so successfully resolved to existing file
/tmp/regressPPKikg/2.1-root/modules/mo
Re: failing httpd-test tests
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
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
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 102 20.00% 7 9 > t/ssl/basicauth.t32 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 52 40.00% 2 5 > t/ssl/varlookup.t 72 72 100.00% 1-72 > t/ssl/verify.t 31 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: cvs commit: httpd-test/perl-framework/t/apache errordoc.t
On Fri, Jul 16, 2004 at 09:08:42AM -0400, Geoffrey Young wrote: > > > This makes the test fail against 2.0.50, but it's just a lack-of-feature > > right, so OK if I half-revert this? > > the last time I asked about this, the consensus was that the perl-framework > is expected to be for developer use only, expected to run (and in some cases > compile) successfully only on current CVS 1.3/2.0/2.1. Well, my position is: I don't care whether it passes against 1.3 (which it doesn't :), I do care that it works against the latest 2.0 release along with tip-of-2.0-branch and 2.1/HEAD as you say. When testing for *bugs*, there's certainly a debate about whether to skip tests for bugs in older releases (I don't care much are about that). For *features*, I don't think there's much to argue about. We know this feature works only in 2.0.51 and later, so why test for it in earlier releases? (this is the only failure against 2.0.50 other than the mod_include unexpected passes fwiw) Regards, joe
Re: cvs commit: httpd-test/perl-framework/t/apache errordoc.t
On Mon, Jul 12, 2004 at 05:03:50PM -, [EMAIL PROTECTED] wrote:
> --- errordoc.t 12 Jul 2004 16:44:47 - 1.2
> +++ errordoc.t 12 Jul 2004 17:03:49 - 1.3
> @@ -59,8 +59,7 @@
> '/redefine/notfound.html code');
>
># 1.3 requires quotes for hard-coded messages
> -my $expected = have_min_apache_version('2.1') ? qr/Not Found/ :
> - have_apache(2) ? 'default' :
> +my $expected = have_apache(2) ? qr/Not Found/ :
> qr/Additionally, a 500/;
>
This makes the test fail against 2.0.50, but it's just a lack-of-feature
right, so OK if I half-revert this?
--- t/apache/errordoc.t 12 Jul 2004 17:03:49 - 1.3
+++ t/apache/errordoc.t 16 Jul 2004 12:16:25 -
@@ -59,7 +59,8 @@
'/redefine/notfound.html code');
# 1.3 requires quotes for hard-coded messages
-my $expected = have_apache(2) ? qr/Not Found/ :
+my $expected = have_min_apache_version('2.0.51') ? qr/Not Found/ :
+ have_apache(2)? 'default' :
qr/Additionally, a 500/;
ok t_cmp($content,
Re: Error running apache test
On Tue, Jun 22, 2004 at 06:08:17PM -0700, Abhishek Khandelwal wrote: > I am getting another strange problem. > I compile and install apache 2.0.49 for both fedora core 1 and red-hat > linux. > > Everything seems okay, and installs properly. > When I start httpd manually, it start running and when I do wget using > http://localhost It works fine in both the machines. > > But, when I run the test provided my perl-test-framework. And try to run > the server using t/TEST -httpd-start, the server starts perfectly on > Fedora core but it dies immediately with exit code 255 on Red-hat > machine. The httpd binary you built on Fedora Core 1 will not work correctly out-of-the-box on Red Hat Linux 8.0 and earlier. If you want to build a single binary which works correctly across a set of distributions, build it on the *oldest* target distribution, not the newest. joe
Re: Apache::test + mod_ssl
On Mon, Jun 14, 2004 at 12:13:53AM +0300, Stas Bekman wrote: > David Wheeler wrote: > >>Where does it create that semaphore file with A-T? May be it's the env > >>val for $TMPDIR? but it's specific to modperl-2.0. > > > >All I know is what the error message says: > > > >Ouch! ap_mm_create(1048576, "/usr/local/apache/logs/httpd.mm.6521") failed > >Error: MM: mm:core: failed to open semaphore file (Permission denied): > >OS: No such file or directory > > > >I'm guessing that under A-T, it creates it in the test directory. The problem is that if you use an EAPI-patched-1.3, you get a path to a mutex file hard-coded into the httpd binary. If this path is absolute, as above, then you need permission in that path to create a file, so using httpd-test to run httpd as a user doesn't work if that path is only writable by root, obviously. You can compile EAPI-patched-1.3 with a relative EAPI_MM_CORE_PATH (or wahtever it is, I don't remember), and the problem will go away as it will become effectively ServerRoot-relative. All IIRC :) joe
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On Fri, May 21, 2004 at 02:19:10PM -0700, Stas Bekman wrote: > >Yes, it exists and is executable. I wonder if there is a permissions > >problem That appears to be a problem. If I try to run it as a normal > >user (which is how I was testing), I get the following error: > > > > Ouch! ap_mm_create(1048576, "/usr/local/apache/logs/httpd.mm.6895") > > failed > > Error: MM: mm:core: failed to open semaphore file (Permission denied): > > OS: No such file or directory This is an inevitable failure if you build httpd patched with EAPI (for mod_ssl), using an absolute path for EAPI_MM_CORE_PATH. You can fix it by using a relative path, e.g. -DEAPI_MM_CORE_PATH=\"logs/httpd.mm\" joe
Re: LWP 5.79 issues?
On Thu, May 06, 2004 at 11:45:00AM -0700, Stas Bekman wrote: > This should do the trick. I'm testing with the mp2 test suite now. Works for me with httpd-test - thanks a lot!
LWP 5.79 issues?
I just tried httpd-test on a machine which has libwww-perl 5.79, and it's failing all over the shop with this error (always the same): t/apache/rwriteok 104/114Use of uninitialized value in length at /usr/lib/perl5/vendor_perl/5.8.3/HTTP/Message.pm line 132. anyone else seen this or something else to add to my TODO list? joe
Re: [Patch] Better IPv6 detection and configuration
Would it not be simpler to just change the Listen statements to be "Listen 0.0.0.0:port" by default and avoid the IPv6 issue entirely? joe
Re: running singleton tests, and individual descriptions
On Fri, Feb 27, 2004 at 07:54:07AM -0500, Ken Coar wrote: > two aspects of the framework that i consider deficiencies are: > > 1. the inability to run a *single* test within a script. This is possible if the test script is written to use sok: http://perl.apache.org/docs/general/testing/testing.html#Running_only_Selected_Sub_tests > 2. the lack of per-test descriptive text. > (you *can* run single scripts, as with 't/TEST t/modules/access.t', > but that doesn't appear to be well documented [if at all].) It's documented pretty clearly in the documentation :) http://perl.apache.org/docs/general/testing/testing.html#Individual_Testing > the second one, however, is a significant pain in the arse, and > there ought to be a solution (says i). as i mentioned before, > i'm wrapping the suite up so a testing group can run it in a > push-button fashion. Could you just have them always run the test suite using -verbose? Regards, joe
Re: [PATCH] fix @INC when running all.t
On Fri, Feb 27, 2004 at 03:04:20AM -0800, Stas Bekman wrote:
> Joe Orton wrote:
> >It works if you also have Apache-Test installed in the system site_perl
> >directory of course, which I have on most boxes so only just noticed
> >this. This fixes it for me, OK to checkin?
>
> Yup. That's one of those remaining places that have relied on the fact that
> we were running from within t/. It should be fixed in a better way, using a
> full path, concating the value of $config->vars->{top_dir} and
> "Apache-Test/lib"
>
> my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test lib);
> my $cmd = "$^X -Mlib=$lib $file";
Hokay, thanks, committed that.
[PATCH] fix @INC when running all.t
The all.t tests are all failing for me on HEAD with errors like:
Can't locate Apache/Test.pm in @INC (@INC contains: ../Apache-Test/lib
/usr/lib/perl5/5.8.1/i386-linux-thread-multi /usr/lib/perl5/5.8.1
etc etc .) at
t/ssl/all.t line 4.
from an strace, the cwd of the process is the top-level perl-framework
directory, so INC should be pointed at the Apache-Test subdir directly
rather than ../Apache-Test.
It works if you also have Apache-Test installed in the system site_perl
directory of course, which I have on most boxes so only just noticed
this. This fixes it for me, OK to checkin?
Index: Apache-Test/lib/Apache/TestHarness.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestHarness.pm,v
retrieving revision 1.15
diff -u -r1.15 TestHarness.pm
--- Apache-Test/lib/Apache/TestHarness.pm 23 Feb 2004 20:37:39 -
1.15
+++ Apache-Test/lib/Apache/TestHarness.pm 27 Feb 2004 09:43:53 -
@@ -49,7 +49,7 @@
sub run_t {
my($self, $file) = @_;
my $ran = 0;
-my $cmd = "$^X -Mlib=../Apache-Test/lib $file";
+my $cmd = "$^X -Mlib=Apache-Test/lib $file";
my $h = Symbol::gensym();
open $h, "$cmd|" or die "open $cmd: $!";
Re: passing -D values?
On Fri, Feb 20, 2004 at 01:30:03PM -0500, Geoffrey Young wrote: > is there really no way to pass additional -D switches to the server? I > can't see any, so unless I'm missing it... Ooh, cool, I tried to add that feature earlier in the week too (and didn't come up with a patch as simple as yours :). Get's my vote! joe
Re: port conflicts issue
On Wed, Feb 18, 2004 at 01:59:31PM -0800, Stas Bekman wrote: > Joe Orton wrote: > >Has anyone else seen this? I regularly manage to get my httpd-test > >checkout into a state where the config suddenly has conflicting Listen > >statements (when it didn't on the previous ./t/TEST invocation): > > > >$ grep -r --include \*.conf Listen.*:8530 t/conf > >t/conf/ssl/ssl.conf:Listen 127.0.0.1:8530 > >t/conf/ssl/proxyssl.conf:Listen 127.0.0.1:8530 > > > >and the server won't start up. A -clean fixes it but it's kind of > >annoying... haven't managed to work out why. > > Yup. I saw that many times. It happes because of the inconsistency in what > config files are reparsed. Every time config files are reparsed the ports > are reassigned. If some files don't get regenerated they will still have > the old port numbers. So what needs to be traced, is why 't/TEST -conf' > doesn't pick up ssl config files. > > t/TEST -trace=debug -conf > > should be helpful. If you don't figure it out, I'll try to resolve that > later. I haven't written the ssl part, so I'll need to first understand how > does it work. Since it's not a part of the normal config. I didn't get anywhere tonight, but I worked out a repro case for the issue: ./t/TEST -clean ./t/TEST -start-httpd ./t/TEST -stop-httpd touch t/conf/ssl/* ./t/TEST -start-httpd joe
port conflicts issue
Has anyone else seen this? I regularly manage to get my httpd-test checkout into a state where the config suddenly has conflicting Listen statements (when it didn't on the previous ./t/TEST invocation): $ grep -r --include \*.conf Listen.*:8530 t/conf t/conf/ssl/ssl.conf:Listen 127.0.0.1:8530 t/conf/ssl/proxyssl.conf:Listen 127.0.0.1:8530 and the server won't start up. A -clean fixes it but it's kind of annoying... haven't managed to work out why. joe
Re: [PATCH] Enable client certificate for https-https proxy tests
On Mon, Aug 04, 2003 at 12:37:51PM -0700, Sander Temme wrote: > Hi all, > > This patch fixes a problem that occurs when RSA SSL-C is used as back-end > for mod_ssl: Just looked into this again, we'd seen this same problem on a few boxes (using OpenSSL of course), but not on others, and had been using exactly the same patch as you, and now I triggered the thing again today. It is a directory ordering bug (they are the order of the day it seems :): successful operation depends on readdir() returning client_ok.pem first, which is not guaranteed but happens sometimes; since all the certs match the CA names offered any of them will be chosen. So this really is a correct fix. I suppose there is a mod_ssl bug here too: SSLP.M.C.Path is not consistent in determining which client cert is used if several would match the CA names offered, it just relies on directory ordering. I'll check this in, anyway. Very belated thanks :) > Index: t/conf/ssl/proxyssl.conf.in > === > RCS file: > /home/cvspublic/httpd-test/perl-framework/t/conf/ssl/proxyssl.conf.in,v > retrieving revision 1.11 > diff -u -r1.11 proxyssl.conf.in > --- t/conf/ssl/proxyssl.conf.in 2 May 2002 19:25:52 - 1.11 > +++ t/conf/ssl/proxyssl.conf.in 4 Aug 2003 19:30:00 - > @@ -34,7 +34,7 @@ > #these are not on by default in the 1.x based mod_ssl > > SSLProxyEngine On > -#SSLProxyMachineCertificateFile @SSLCA@/asf/proxy/client_ok.pem > +SSLProxyMachineCertificateFile @SSLCA@/asf/proxy/client_ok.pem > #client_ok.pem should be loaded first > SSLProxyMachineCertificatePath @SSLCA@/asf/proxy > SSLProxyCACertificateFile @SSLCA@/asf/certs/ca.crt
Re: [PATCH] vhost_socket tweak
On Wed, Feb 18, 2004 at 10:40:51AM -0500, Geoffrey Young wrote: > > > Well, it gets my vote. If it were to be an argument, it would have to > > be stripped out of @_ before being passed through to LWP, which sounds > > like it could get messy. > > ok, give this a whirl and see if it works for you. Yup, works great.
Re: [PATCH] vhost_socket tweak
On Wed, Feb 18, 2004 at 09:54:26AM -0500, Geoffrey Young wrote: > > I should have explained this... the issue is that in response to an HTTP > > request on an SSL port, mod_ssl in 2.0 issues an "HTTP/0.9" response, > > i.e. it just spits out the response body without headers. This makes > > TestRequest.pm:lwp_call() barf. > > indeed. I've been bitten by that myself when trying to specifically test > HTTP/0.9. > > http://marc.theaimsgroup.com/?l=apache-test-dev&m=102407609105935&w=2 > > perhaps now is a good time to fix that little bit. Ah ha, neat. Yes, I can work around the ssl.t failure very easily like that. > agreed. the stuff I proposed before is just one suggestion, but > perhaps you can think up a better idea. 0.9 is probably rare enough > that it doesn't warrant a huge interface was my thought. Well, it gets my vote. If it were to be an argument, it would have to be stripped out of @_ before being passed through to LWP, which sounds like it could get messy. joe
Re: [PATCH] vhost_socket tweak
On Wed, Feb 18, 2004 at 09:05:47AM -0500, Geoffrey Young wrote:
>
> > sub vhost_socket {
...
> that all looks reasonable.
Thanks for the review Geoff!
...
> that the appropriate status code is returned seems like a valid test
> that we would want to keep around. maybe keep this but issue another
> request to test your below logic?
I should have explained this... the issue is that in response to an HTTP
request on an SSL port, mod_ssl in 2.0 issues an "HTTP/0.9" response,
i.e. it just spits out the response body without headers. This makes
TestRequest.pm:lwp_call() barf.
That mod_ssl bug is not really a regression worth worrying about IMO:
browsers handle the error response just fine, so I was trying to just
detect that it sent the right response body.
Now I think about it maybe a better way to fix this would be to let
lwp_call take an argument to allow it to *not* barf on an "HTTP/0.9"
response:
if ($1 ne "1.0" && $1 ne "1.1") {
$error = "response had protocol HTTP/$1 (headers not sent?)";
}
But working out how lwp_call even gets *called* via GET gives me
headaches. Can anyone help?
joe
[PATCH] vhost_socket tweak
Is this patch OK for TestRequest.pm?
--- Apache-Test/lib/Apache/TestRequest.pm 28 Nov 2003 18:19:45 -
1.93
+++ Apache-Test/lib/Apache/TestRequest.pm 18 Feb 2004 10:06:32 -
@@ -214,7 +214,7 @@
}
sub vhost_socket {
-my $module = shift;
+my ($module, $nossl) = @_;
local $Apache::TestRequest::Module = $module if $module;
my $hostport = hostport(Apache::Test::config());
@@ -224,7 +224,7 @@
my($host, $port) = split ':', $hostport;
my(%args) = (PeerAddr => $host, PeerPort => $port);
-if ($module and $module =~ /ssl/) {
+if (!$nossl and $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);
This allows a fix for the ssl/http.t failure which has been around
forever:
--- t/ssl/http.t3 Apr 2002 09:14:48 - 1.10
+++ t/ssl/http.t18 Feb 2004 10:07:03 -
@@ -14,24 +14,39 @@
if (Apache::TestConfig::WIN32) {
print "\n#ap_core_translate() chokes on ':' here\n",
"#where r->uri = /mod_ssl:error:HTTP-request\n";
-@todo = (todo => [2]);
+@todo = (todo => [1]);
}
-plan tests => 2, @todo;
+plan tests => 1, @todo;
my $config = Apache::Test::config();
my $ssl_module = $config->{vars}->{ssl_module_name};
my $hostport = $config->{vhosts}->{$ssl_module}->{hostport};
-my $rurl = "http://$hostport$url";;
+my $rurl = "http://$hostport/";;
+my $CRLF = "\015\012";
-my $res = GET($rurl);
-ok t_cmp(400,
- $res->code,
- "Expected bad request from 'GET $rurl'"
-);
-
-ok t_cmp(qr{speaking plain HTTP to an SSL-enabled server port},
- $res->content,
- "that error document contains the proper hint"
-);
+my $s = Apache::TestRequest::vhost_socket($ssl_module, 1);
+
+unless ($s) {
+warn "cannot connect to $hostport: $!";
+return undef;
+}
+
+my $req = join $CRLF,
+"GET / HTTP/1.1",
+"Host: $hostport", $CRLF;
+
+$s->write($req);
+
+my $res = 0;
+
+while (<$s>) {
+print "# read: $_";
+$res = 1 if /speaking plain HTTP to an SSL-enabled server port/;
+}
+
+ok t_cmp(1,
+ $res,
+ "expected error document hint from HTTP request on SSL port"
+ );
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRun.pm TestSSLCA.pm
Oh, I see I just undid your commit. Did this really work for you?
I was always getting, from a clean checkout:
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl ./t/TEST
[warning] generating SSL CA for asf
[ error] configure() has failed:
open t/conf/ca.cnf: No such file or directory at /blah/TestSSLCA.pm line 494.
[warning] forcing Apache::TestConfig object save
[warning] run 't/TEST -clean' to clean up before continuing
On Mon, Feb 09, 2004 at 06:07:49PM -, [EMAIL PROTECTED] wrote:
> --- TestSSLCA.pm8 Jan 2004 17:15:37 - 1.15
> +++ TestSSLCA.pm9 Feb 2004 18:07:49 - 1.16
> @@ -170,7 +170,7 @@
>sub config_file {
>my $name = shift;
>
> -my $file = "conf/$name.cnf";
> +my $file = "t/conf/$name.cnf";
>return $file if -e $file;
>
>my $dn = dn($name);
>
>
>
Re: Error when compiling flood-0.4
On Mon, Oct 06, 2003 at 08:20:26PM -0300, Fernando Marques wrote: > > Hello, > > I experienced an error when compiling flood-0.4. For instance, I'm using > Red Hat 9. First, I've used your recomendations: The APR installation included in the Subversion package in RHL9 does not have a fully working apr-config script. If you first do: # rpm --erase subversion-devel then flood should work. Regards, joe
Re: httpd-test: failing to generate certificates for testing
On Tue, Jul 29, 2003 at 05:12:24PM +0200, Stas Bekman wrote: ... > Certificate is to be certified until Jul 28 15:07:29 2004 GMT (365 days) > failed to update database > TXT_DB error number 2 This is reproducible on every clean checkout? It works OK here with openssl 0.9.7a. openssl can sometimes get confused and gives odd errors like this when the text files in the "database" aren't how it expects.
Re: [PATCH] Re: TestConfigPerl problem
On Thu, Mar 20, 2003 at 09:52:55AM +1100, Stas Bekman wrote:
> Joe Orton wrote:
> >On Tue, Feb 11, 2003 at 10:01:07AM +1100, Stas Bekman wrote:
> >
> >>Joe Orton wrote:
> >>
> >>>Since rev 1.63 of TestConfigPerl.pm I get this error running TEST (after
> >>>a fresh checkout)
> >>>
> >>>make[1]: Leaving directory
> >>>`/home/joe/src/httpd-test/pf/c-modules/authany'
> >>>!!! configure() has failed:
> >>>Use of uninitialized value in subroutine entry at
> >>>/home/joe/src/httpd-test/pf/t/../Apache-Test/lib/Apache/TestConfigPerl.pm
> >>>line 318, line 18.
> >>>
> >>>backing down to r1.62 works fine. Any ideas? I'm using perl 5.8.0.
> >>
> >>I can't reproduce it. The difference between 1.62 and 1.63 is a big
> >>refactoring of the code that parses the config sections.
> >>
> >>Can you please check what is undefined? $line, $indent? Also a trace of
> >>calls that leads to this situation will help, which the following patch
> >>should accomplish:
> >
> >
> >I think I've tracked this down: parse_vhost() can return undef when it's
> >passed a line like "" but
> >parse_vhost_open_tag() assumes otherwise and barfs doing $cfg-> in the
> >following lines.
>
> Your example perfectly matches the regex in parse_vhost:
>
> perl -le '$_ = ""; print $1||"", $2 if
> /^(\s*)\s*$/'
> mod_nntp_like_ssl
>
> or is it something else? I mean what causes the undef to be returned, that
> I was unable to reproduce with perl-framework tests?
It's this bit that returns undef I think:
if ($module =~ /^mod_/ and not $mods->{$have_module}) {
return undef;
}
> >This seems to fix it for me (and the config file produced doesn't cause
> >httpd to barf), is this OK to checkin?
>
> Otherwise it's certainly a good fix. thanks Joe!
>
> Just a slight change before you commit: since the returned value is either
> a hash ref or undef, there is no need to check for defined $cfg, but just
> true/false $cfg. Also I'd write it the other way around:
Thanks Stas - I'll check this in.
...
[PATCH] Re: TestConfigPerl problem
On Tue, Feb 11, 2003 at 10:01:07AM +1100, Stas Bekman wrote:
> Joe Orton wrote:
> >Since rev 1.63 of TestConfigPerl.pm I get this error running TEST (after
> >a fresh checkout)
> >
> >make[1]: Leaving directory `/home/joe/src/httpd-test/pf/c-modules/authany'
> >!!! configure() has failed:
> >Use of uninitialized value in subroutine entry at
> >/home/joe/src/httpd-test/pf/t/../Apache-Test/lib/Apache/TestConfigPerl.pm
> >line 318, line 18.
> >
> >backing down to r1.62 works fine. Any ideas? I'm using perl 5.8.0.
>
> I can't reproduce it. The difference between 1.62 and 1.63 is a big
> refactoring of the code that parses the config sections.
>
> Can you please check what is undefined? $line, $indent? Also a trace of
> calls that leads to this situation will help, which the following patch
> should accomplish:
I think I've tracked this down: parse_vhost() can return undef when it's
passed a line like "" but
parse_vhost_open_tag() assumes otherwise and barfs doing $cfg-> in the
following lines.
This seems to fix it for me (and the config file produced doesn't cause
httpd to barf), is this OK to checkin?
--- Apache-Test/lib/Apache/TestConfigPerl.pm3 Feb 2003 02:18:32 -
1.65
+++ Apache-Test/lib/Apache/TestConfigPerl.pm19 Mar 2003 15:58:27 -
@@ -316,11 +316,15 @@
my($self, $line, $indent) = @_;
my $cfg = $self->parse_vhost($line);
-my $port = $cfg->{port};
-$cfg->{out_postamble}->();
-$self->postamble("$indent");
-$cfg->{in_postamble}->();
+if (!defined $cfg) {
+$self->postamble("$indent$line");
+} else {
+my $port = $cfg->{port};
+$cfg->{out_postamble}->();
+$self->postamble("$indent");
+$cfg->{in_postamble}->();
+}
}
#the idea for each group:
PHP getenv() test
This is a regression test for http://bugs.php.net/bug.php?id=19840
Apparently I already have commit access - OK if I go ahead and commit
these?
joe
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestRequest;
use Apache::TestUtil;
plan tests => 1, have_module 'php4';
# Regression test for http://bugs.php.net/bug.php?id=19840
ok t_cmp("GET",
GET_BODY "/php/getenv.php",
"getenv(REQUEST_METHOD)"
);
TestConfigPerl problem
Since rev 1.63 of TestConfigPerl.pm I get this error running TEST (after a fresh checkout) make[1]: Leaving directory `/home/joe/src/httpd-test/pf/c-modules/authany' !!! configure() has failed: Use of uninitialized value in subroutine entry at /home/joe/src/httpd-test/pf/t/../Apache-Test/lib/Apache/TestConfigPerl.pm line 318, line 18. backing down to r1.62 works fine. Any ideas? I'm using perl 5.8.0. joe
Re: are perl-framework apache tests still used?
On Fri, Feb 07, 2003 at 06:04:29PM +1100, Stas Bekman wrote: > William A. Rowe, Jr. wrote: > >AHHH... you are confusing apr/test (Ryan's ongoing efforts, even apart > >from the apr group) which tests internal functions, with perl-testsuite, > >which tests behavior of the server. > > > >If Joe's tests work - commit them :-) > > I don't have php installed. Preferrably, someone who can test them first, > will commit them. Otherwise I can commit without testing, though they need > some cleanup (use hardcoded / path separator is not crossplatform)... OK - is there some easy way to make this portable? The only other places I can find which use local files seem to be doing the same thing, though: modules/cgi.t with $cgi_log and write_htaccess in modules/dir.t? Regards, joe
Re: are perl-framework apache tests still used?
On Fri, Feb 07, 2003 at 03:34:55PM +1100, Stas Bekman wrote:
> I haven't seen any activity with maintaining tests in a while and I have a
> bunch of ssl tests failing. I remember Ryan working on a new test suite.
> What's the current status of things? Should Joe's new php tests be
> committed?
>
> These fail for me:
> ssl/basicauth.t31 33.33% 2
> ssl/http.t 255 65280 22 100.00% 1-2
> ssl/proxy.t 1695 2.96% 113-117
> ssl/varlookup.t 724 5.56% 38-39 52-53
> 5 tests and 6 subtests skipped.
The varlookup.t tests fail if you use OpenSSL 0.9.7, since it uses the
string "emailAddress" not "Email" for an e-mail attribute in a DN. I
hacked round this by just removing the e-mail attributes from the DN.
--- perl-framework/Apache-Test/lib/Apache/TestSSLCA.pm.os0972003-01-28
15:08:50.0 +
+++ perl-framework/Apache-Test/lib/Apache/TestSSLCA.pm 2003-01-28
15:11:52.0 +
@@ -44,7 +44,6 @@
O => 'ASF',
OU => 'httpd-test',
CN => '',
-Email => '[EMAIL PROTECTED]',
},
};
@@ -132,7 +131,7 @@
my $string = "";
-for my $k (qw(C ST L O OU CN Email)) {
+for my $k (qw(C ST L O OU CN)) {
next unless $dn->{$k};
$string .= "/$k=$dn->{$k}";
}
@@ -185,7 +184,6 @@
O = $dn->{O}
OU = $dn->{OU}
CN = $dn->{CN}
-emailAddress = $dn->{Email}
[ req_attributes ]
challengePassword = $pass
tests for PHP getlastmod()
Hi, attached are a t/php/getlastmod.t and t/htdocs/php/getlastmod.php, a
regression test for the PHP getlastmod() function.
Please excuse my poor Perl code in these... :)
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestRequest;
use Apache::TestUtil;
use POSIX qw(strftime);
plan tests => 1, have_module 'php4';
my $vars = Apache::Test::vars();
my $docroot = $vars->{documentroot};
my $fname = $docroot . "/php/getlastmod.php";
my $mtime = (stat($fname))[9] || die "could not find file";
my $month = strftime "%B", gmtime($mtime);
printf "# debug: month is %s\n", $month;
my $result = GET_BODY "/php/getlastmod.php";
ok t_cmp($result, $month);
test for PHP no_local_copy bug
Hi, attached is a perl-framework regression test for:
http://bugs.php.net/bug.php?id=17098
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestRequest;
use POSIX qw(strftime);
plan tests => 1, have_module 'php4';
# Test for bug where Apache serves a 304 if the PHP file (on disk) has
# not been modified since the date given in an If-Modified-Since
# header; http://bugs.php.net/bug.php?id=17098
ok GET_RC("/php/hello.php",
"If-Modified-Since" => strftime("%a, %d %b %Y %T GMT", gmtime))
== 200;
