Re: File::Tail
i have no problem with this. i also thought about the false passes for that test, but have been too busy with other test modules to think much about how to fix it. -j On Thu, Aug 30, 2001 at 05:07:02PM +0100, Gary Benson wrote: + + Hi all, + + I've got three problems which I could resolve easily if I were able to + call on the File::Tail package (which tails files would you believe). These + being: + + * php/func5.t fails if the log entry doesn't get written straight +to the disk + * php/func5.t will pass on the first foo() has been called message, so +we could have false passes. + * TestServer::start sometimes fails on slow machines + + What I want to know is if anyone has a problem with me using this package, + and whether or not we could add it to the httpd-test-bundle. + + Comments? + Gary + + [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ] +
Re: Anyone know what this means?
CVS has an extra layer of access permissions that are preventing you from doing a commit. You need to get added to the accel file for httpd-test. (I don't know who can do this for you, sorry). -aaron On Thu, Aug 30, 2001 at 07:34:56PM +0100, Gary Benson wrote: Access denied: Insufficient Karma (gbenson|httpd-test/perl-framework/t/php)cvs server: Pre-commit check failed Access denied: Insufficient Karma (gbenson|httpd-test/perl-framework/t/htdocs/php) cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! cvs commit: saving log message in /tmp/cvsS0ABZQ
Re: Is there a way to disable the ANSI?
On Thu, 30 Aug 2001, Ian Holsman wrote: I'm trying to get a nightly test going, (nearly done) If you are running it from cron then the mod_env tests will fail. Don't worry; when my commit access works I'll commit a fix... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: cvs commit: httpd-2.0/modules/experimental mod_charset_lite.c
Ryan Bloom [EMAIL PROTECTED] writes: On Thursday 30 August 2001 06:53, Jeff Trawick wrote: I think you're saying that beyond core (whose config I was looking at), any other modules (e.g., mime) might add a charset filter too based on their own directives. And if this is the case, then obviously my insert-filter hook shouldn't bother checking because another module could add my filter after my insert-filter hook is called. Thus, I have to wait until my filter is called to see if my implicitly-added filter needs to be removed. Right? Or, you could make your insert_filter phase a REALLY_LAST function, and walk r-output_filters. this seems reasonable for the short term; I just don't want to use REALLY_LAST unless absolutely necessary because sooner or later somebody else that I need to run after will think they are special and be REALLY_LAST too (but perhaps this isn't an imminent occurrence :) ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Comments on accept-mutex/single-listen patch ??
Peace! I'll commit minus SingleListen :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Re: 2.0.26?
[snip] tag and roll and test. If that one isn't good enough, then we do it again a week later. We would easily get to a beta or production release, if we didn't keep changing the internals of the server, or if we posted large patches before they were committed, or if people ran the httpd-test/perl-framework test suite before committing, and if people would write tests once they fix a bug. The problem we have right now, is that most people don't use the test-suite, so even though it is catching most of the bugs when they are committed, nobody knows it. ok. I'm going to set up the perl framework to run nightly at report the errors it sees back to this list. If this works properly my intention is to get it going after every commit. I can also get something like the mod-proxy nightly build as well. Ryan __ Ryan Bloom[EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -- -- Ian Holsman Performance Measurement Analysis CNET Networks-415 364-8608
RE: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page
Is that always true? For example, expat is not compiled with those flags. -Original Message- From: Roy T. Fielding [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 29, 2001 7:08 PM To: [EMAIL PROTECTED] Subject: Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page As a side note, some portions of the code are compiled with -D_REENTRANT -D_THREAD_SAFE even when building using the prefork mpm. Why? Doesn't that have the potential to do the wrong thing on some platforms? No, it would do the wrong thing if they were not defined. They are required for the entire executable if any part of the exec has been compiled with those flags. In our case, since modules like PHP and others will be compiled with those flags, we must always compile with those flags or mod_php's return values for errno won't be correctly interpreted by the httpd core (a problem that was fixed in some version of 1.3.x by always setting those flags on platforms that support it). Roy
Re: libtool vs purify?
On Thu, 2001-08-30 at 08:42, Charles Randall wrote: Purify requires you to prefix the purify command in the final link. For example, gcc -c file-a.c gcc -c file-b.c purify gcc file-a.o file-b.o With 1.3.x, I'd simply hand-edit src/Makefile to achieve this. How can I either get libtool to invoke purify or hack the files by hand to accomplish this? we do it manually at the moment. we grab the last link line the makefile produces and just append 'purify' to it. Charles -- Ian Holsman Performance Measurement Analysis CNET Networks-415 364-8608
Re: 2.0.26?
Ian Holsman [EMAIL PROTECTED] writes:
should we re-rolltar 26 (which would include a patch to worker and
ldap_cache, some NW fixes and the apr-dbm change)
we might wanna wait to tag 2.0.26 until we get httpd not to leave
behind shared memory on Linux every time you start and stop it :)
this helps, though
ipcs -m | grep 49160 | awk '{print $2}' | xargs -n 1 ipcrm shm
where 49160 is the size I'm currently getting for the scoreboard
(wow, the day goes by and I haven't even gotten to any tasks I'd
planned on working on)
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: make distclean doesn't
how can I do to unsuscribe?? thanks -Mensaje original- De: Charles Randall [mailto:[EMAIL PROTECTED]] Enviado el: jueves, 30 de agosto de 2001 13:25 Para: '[EMAIL PROTECTED]' Asunto: make distclean doesn't How clean is distclean supposed to be? I assumed that it would remove all files that weren't part of the distribution. Running these commands, tar zxf httpd-2_0_25-alpha.tar.gz find httpd-2_0_25 -type f | xargs md5 before.md5 cd httpd-2_0_25 ./configure --prefix=$HOME/test/apache --with-port=8080 make make distclean cd .. find httpd-2_0_25 -type f | xargs md5 after.md5 I see these differences between before.md5 and after.md5, % diff -u before.md5 after.md5 | egrep '^[\+\-]' --- before.md5 Thu Aug 30 10:00:04 2001 +++ after.md5 Thu Aug 30 10:10:08 2001 +MD5 (httpd-2_0_25/build/rules.mk) = 3f4234161d15947992b65ae2e774802f +MD5 (httpd-2_0_25/os/beos/Makefile) = 520b595f9e4a5c074a649d456be82b5c +MD5 (httpd-2_0_25/os/beos/.deps) = d41d8cd98f00b204e9800998ecf8427e +MD5 (httpd-2_0_25/os/os2/Makefile) = 319b8e10e5d84e633141dc0014f3ef2a +MD5 (httpd-2_0_25/os/os2/.deps) = d41d8cd98f00b204e9800998ecf8427e +MD5 (httpd-2_0_25/server/exports.c) = 1a936f30687ea076db8dd268fee9 +MD5 (httpd-2_0_25/srclib/pcre/config.log) = 0217408a0a100fd7f745268f4947ddb0 +MD5 (httpd-2_0_25/srclib/pcre/config.status) = cfe194138481ee6b117b6915628b7ec8 +MD5 (httpd-2_0_25/srclib/apr/config.nice) = 828b3b21e8573f5898114b790cd381b5 +MD5 (httpd-2_0_25/srclib/apr-util/include/apr_ldap.h) = bb6d10f320c8b59bc350160fd4726112 +MD5 (httpd-2_0_25/srclib/apr-util/config.nice) = 2d0b2089455807771bdc09690cf0dcd9 -MD5 (httpd-2_0_25/.deps) = d41d8cd98f00b204e9800998ecf8427e +MD5 (httpd-2_0_25/config.nice) = 105cb0052bc9fa0f83f4a4af9a875d00 That doesn't seem right. In addition to the files that are created during configure/make but not removed, note that httpd-2_0_25/.deps is in the distribution but removed by make distclean. Charles
Re: 2.0.26?
From: Ryan Bloom [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 11:04 AM On Thursday 30 August 2001 08:09, Cliff Woolley wrote: On Thu, 30 Aug 2001, Ryan Bloom wrote: We shouldn't do either. If you go back and read the original thread, one of the general rules of this release strategy is that we don't release every day. We just rolled a tarball, and announced it to the new-httpd, so there are people testing it at this point. That tarball has to stand or fall on it's own. In a week, we can re-roll 2.0.26, and try again. HuH? Ok, you rolled a tarball. Why? Our first-line testers are capable of checking out cvs. Bump a tag (or branch), and a 30 second cvs checkout and a three minute make is all it takes to get testing. That's silly. That makes it very difficult to be sure we're stable again by the time we're allowed to tag 2.0.26. I agree wholeheartedly with whomever it was that said the only problem with our current system is the concatenation of the words tag and roll into a single tagroll operation. We need to tag, test for just a little while to sort out the obvious problems that have just bitten 2.0.25, and THEN roll. Rolling That doesn't work. The last time I tagged, and then waited to roll, I was told that I needed to get tarballs up so that people could download them. WTF? I don't remember seeing that discussion on the list. Since oh, about 2.0.21 we've been giving folks the opportunity to test. You are the only individual who seems to be tarring as you tag these days. before preliminary tests are done is silly. Half the time it means that we don't even build on some systems, which we could have found out about if we'd waited an hour to give people a chance to check. I agree with Waiting an hour doesn't do anything. Most people on this list don't hack Apache all day every day. The whole point of the current system, is that we tag when things all look good. If we are wrong, then we wait a week, and try again. Not if you ever want to get anywhere. Tomcat has a good model - pay attention to it - they get releases out the door. Bill that there needs to be a time limit on the duration between the tag and the roll... four days sounds good (if not excessive). That's what killed 2.0.23 and 2.0.24 in a way... they took too damned long. At least if we spread it out over a couple days, we don't twiddle our thumbs for a week after we realize that the tarball we just rolled is broken for some piddly-ass reason or another. Besides, if we wait a day or two between the tag and the roll, there would never BE a reason to release every day, so that problem just vanishes for free. You are still asking testers to test multiple versions. Or, you are going back to the 1.3 model, where we hit a code-freeze, so every developer out there commits everything they have in their tree just before we go code-freeze. That is the problem that killed Apache 1.3.13, 14, 15, 16. And brought .14, .17, .19 and .20 out the door, as solid as we could expect them to be under any release model. But 1.3 code is stable (if not always correct). And it would go a long way towards pissing off our testers. We have people who download the tarball when we release it, and if we replace that tarball after just a few hours, Ryan, how many testers lists do we have? dev@httpd is _NOT_ the tarball test list. The order must go 1. Tag. Announce as version candidate at [EMAIL PROTECTED] 2. wait for folks to build and regress (24 hours???) 3. vote. Is the feedback [at least] alpha quality? Are there no beta showstoppers? 4. bump subrevision to -alpha [optional - but I think we need to go here] 5. Tar. Announce as beta candidate at [EMAIL PROTECTED] 6. wait for folks to build, regress, and stress (72 hours???) 7. vote. Is the feedback [at least] beta quality? Are there no release showstoppers? 8. bump subrevision to -beta [optional - but I think we need to go here] 9. Tar. Announce as release candidate at [EMAIL PROTECTED] 10. wait for folks to build, regress, and further stress (one week???). 11. The Adventuous may experiment with installing to production on non-critical servers. 12. vote. Is the feedback of release quality? Are there no new showstoppers? 14. bump subrevision to -gold. 15. Tar. Up to www.apache.org/dist/. Broadcast the release There will be no changes to a -gold release, ever. We could subversion the -alpha and -beta versions, e.g. 2.0.25.-alpha. I propose the number of days since the official release of Apache 1.0 ;) Whoa... time out. I'm saying (and I think Bill is, too), that we *do not* replace the tarball. Once it's rolled, that's it. If the tarball's broken, try again with a new tag later. We can easily test it for obvious flaws ourselves between the tag and the roll. Once *we're* satisfied, roll it and give it to the testers. If
Re: 2.0.26?
Cliff Woolley [EMAIL PROTECTED] writes: On 30 Aug 2001, Jeff Trawick wrote: Ian Holsman [EMAIL PROTECTED] writes: should we re-rolltar 26 (which would include a patch to worker and ldap_cache, some NW fixes and the apr-dbm change) we might wanna wait to tag 2.0.26 until we get httpd not to leave behind shared memory on Linux every time you start and stop it :) Okay. I wasn't aware of this problem. Does it look like there might possibly be an easy fix? fixed now... just copied some ommitted code from mm -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: 2.0.26?
From: Bill Stoddard [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 11:55 AM Not really. The process Cliff and I outlined is really aimed at getting -a- stable release available. The process will take at least 2 days to go through but shouldn't take more than maybe 4 days total. If we use this process AND use your suggestions to not commit huge chunks of untested code during our 'stabilization period' I am confident we can get stable releases out on almost every try. We can control the release of tarballs to the test community. And what is the point of having testers spend time on a release that we know is broken? Isn't it better to just tell them hey don't waste your time on this tarball?. OTOH... what rule says that testers must test each and every tarball? If a tarball (even an alpha tarball) works well enough, the testers can still find and report bugs that we havent discovered yet. One other question... have you received complaints from testers about the frequencey of our tarball updates? Keep in mind one key detail, our most _active_ testers are using cvs (even on win32 ;) I don't think we are currently using the model suggested by Roy. I believe Roy's model is closer to what Cliff and I are advocating. With one exception... The exception is that some of us believe a 'feature freeze' (or 'big code change freeze', whatever you want to call it) needs to go into effect during the 'stabilizing period'. I know Roy doesn't like this idea but I see no other way out of our current inability to get stable releases. There is no such need. Tag. Roll in or out the changes that get a particular version stable. We have CVS. Use it. Yep. :-) But we also need to stop committing every possible change immediately. +1. Announce when we are in the 'stabilization period' and discourage (prohibit? :-) big commits during the period that do not enhance stability. My other post suggests we simply follow R-T-C (with a strict 3 +1's except on obscure build maintenance by platform maintainers) on a tagged branch. There's no need for this in the main tree. See my post to rbb for the rest of my thoughts on this personal slight, you are certainly impliciated as well. Bill
Re: 2.0.26?
From: Ryan Bloom [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 8:57 AM On Thursday 30 August 2001 06:38, Bill Stoddard wrote: Completely agree that our release strategy (with Dr. Evil quotes around strategy) is broken. But we should be able to tag the tree anytime, IMHO. If HEAD is good, I am for tagging 2.0.26 and testing it but let's not roll the tarball. Fix any problems in 2.0.26 and bump the tag on affected files. When we are satisfied, roll 2.0.26. Put a time limit on the whole process of say, 4 days. If the time limit is exceeded (showstopper problems have not been driven out within 4 days of the tag) or the rolled tarball has showstoppers, consider the beta effort a failure and move on. I'd say scope, over time. If two platforms are 'touchy' about the build, and there is a three line patch to get those to build, then we do it. If there is a segfault we can close (say J. Trawick's fix of my oops last night) then we close it. I'm going to suggest a simple, absolute rule. If a .h file changes (even a generated one) then the tag is deep six-ed. If the httpd-std.conf file changes, it's axed. And if the syntax parsers change, it's axed. Anything in between is our call. I'm going to suggest we branch every release as APACHE_2_0_nn once we apply any patch out-of-sequence (from HEAD). E.g., I commit a feature after HTTP_2_0_30 is tagged. Then someone notices a rare segfault dating to 2.0.12. Well, That patch goes in, but if it needs to be dropped on HTTP_2_0_30, then we branch with the original APACHE_2_0_nn tag. Anyone who checks out from cvs co -r APACHE_2_0_nn has the authoritative, current candidate. And I suggest we go to r-t-c on following any tag. I'm not suggesting r-t-c on the main branch, since there aren't enough people following some obscure aspects of the server to comment (in a timely manner.) But once it's tagged - 3 +1's before patching (or even bumping) a tag! This is basically what we did with 2.0.24 and it was almost successful. 2.0.24 dragged on a bit too long (over a week) and we rolled a couple of different 2.0.24 tarballs, which was not cool. Tagging a good HEAD, incrementally fixing showstoppers (provided the fixes are relatively limited in scope and simple) and bumping the tag on affected files, and exercising a little disipline and restraint for a few days (even just a few hours) prior to our target for rolling a beta would go a long way to solving this problem. And it would go a long way towards pissing off our testers. We have people who download the tarball when we release it, and if we replace that tarball after just a few hours, then we are basically telling them that we don't need their input, and they are only useful if they actually follow new-httpd, which I think we all know is INCREDIBLY hard to do most days. Ryan, how many testers lists do we have? dev@httpd is _NOT_ the tarball test list. The order must go 1. Tag. Announce as version candidate at [EMAIL PROTECTED] 2. wait for folks to build and regress (24 hours???) 3. vote. Is the feedback [at least] alpha quality? Are there no beta showstoppers? 4. bump subrevision to -alpha [optional - but I think we need to go here] 5. Tar. Announce as beta candidate at [EMAIL PROTECTED] 6. wait for folks to build, regress, and stress (72 hours???) 7. vote. Is the feedback [at least] beta quality? Are there no release showstoppers? 8. bump subrevision to -beta [optional - but I think we need to go here] 9. Tar. Announce as release candidate at [EMAIL PROTECTED] 10. wait for folks to build, regress, and further stress (one week???). 11. The Adventuous may experiment with installing to production on non-critical servers. 12. vote. Is the feedback of release quality? Are there no new showstoppers? 14. bump subrevision to -gold. 15. Tar. Up to www.apache.org/dist/. Broadcast the release There will be no changes to a -gold release, ever. We could subversion the -alpha and -beta versions, e.g. 2.0.25.-alpha. I propose the number of days since the official release of Apache 1.0 ;) Take a page from the Jakarta project - their release schema works. tag and roll and test. If that one isn't good enough, then we do it again a week later. We would easily get to a beta or production release, if we didn't keep changing the internals of the server, or if we posted large patches before they were committed, or if people ran the httpd-test/perl-framework test suite before committing, and if people would write tests once they fix a bug. The problem we have right now, is that most people don't use the test-suite, so even though it is catching most of the bugs when they are committed, nobody knows it. Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike apache-1.3) that is mildly difficult in some quarters. I've specifically introduced the cygwin support to allow me to build httpd-test. We will
Re: Apache 2.0.25 tagged
Greg Ames wrote: Now I see several [Wed Aug 29 20:56:44 2001] [error] [client 24.163.38.112] unable to include FAQ-F.html? in parsed file /www/httpd.apache.org/docs/misc/FAQ.html ...when I replay the logs I can't recreate these today from inside the IBM firewall. Log replay runs clean. Normally, I would bounce us over to the new build (2.0.25 tarball + fix to install suexec) when it looks this good, but the server is pretty busy right now. Greg
[patch] -- add mod_core.h to 'installed' header files
mod_proxy refers to this file. Index: Makefile.in === RCS file: /home/cvs/httpd-2.0/Makefile.in,v retrieving revision 1.80 diff -u -u -r1.80 Makefile.in --- Makefile.in 2001/08/30 03:45:30 1.80 +++ Makefile.in 2001/08/30 18:36:30 @@ -118,6 +118,7 @@ @cp -p $(srcdir)/server/mpm/$(MPM_NAME)/*.h $(includedir) @cp -p $(srcdir)/modules/dav/main/mod_dav.h $(includedir) @cp -p $(srcdir)/modules/filters/mod_include.h $(includedir) + @cp -p $(srcdir)/modules/httpd/mod_core.h $(includedir) @cp -p $(srcdir)/modules/ssl/*.h $(includedir) @cp -p $(srcdir)/srclib/pcre/*.h $(includedir) @cp -p $(srcdir)/srclib/apr/include/*.h $(includedir)
Fw: mod_log-any/8021: [PATCH] %b,%B in LogFormat not logged zero for HEAD request
Would someone be willing to review, patch, and close this PR?
Bill
- Original Message -
From: Taketo Kabe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 13, 2001 5:31 AM
Subject: mod_log-any/8021: [PATCH] %b,%B in LogFormat not logged zero for HEAD request
Number: 8021
Category: mod_log-any
Synopsis: [PATCH] %b,%B in LogFormat not logged zero for HEAD request
Confidential: no
Severity: non-critical
Priority: medium
Responsible:apache
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: apache
Arrival-Date: Fri Jul 13 03:40:05 PDT 2001
Closed-Date:
Last-Modified:
Originator: [EMAIL PROTECTED]
Release:2.0.20
Organization:
apache
Environment:
SunOS 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-60
gcc version 2.95.2 19991024 (release)
./configure [--enable-log-config]
Description:
The %b %B directives in LogFormat should indicate - or 0 for
HEAD requests, because no response body is sent --
but actually, the file size is logged.
This was because r-sent_bodyct flag, which tells logger to
log r-bytes_sent, is set to 1 BEFORE checking discarding the body in
modules/http/http_protocol.c:ap_http_header_filter() .
Setting r-sent_bodyct AFTER checking for HEAD fixed it.
How-To-Repeat:
* Setup a LogFormat with %b or %B within
(the default combined log is enough)
* Issue a HEAD request for a plain file.
* Examine the access_log.
The 7th field (bytes transmitted) should be - or 0,
but actually is the size of the file.
Fix:
#
#** modules/http/http_protocol.c HEAD logs full content bytes
#
# This patch fixes that %b %B (bytes sent, excluding response headers)
# directives for mod_log_config, is logged as full file size (should be zero).
#
##find httpd-2_0_20 -name '*.dist7' -exec ./0diff {} \;
/usr/local/gnu/bin/patch -p1 --backup --suffix=.dist7 'EOP'
=== {
diff -u httpd-2_0_20/modules/http/http_protocol.c.dist7
httpd-2_0_20/modules/http/http_protocol.c
--- httpd-2_0_20/modules/http/http_protocol.c.dist7 Fri Jul 13 07:32:53 2001
+++ httpd-2_0_20/modules/http/http_protocol.c Fri Jul 13 07:37:42 2001
@@ -1206,14 +1206,14 @@
terminate_header(b2);
-r-sent_bodyct = 1; /* Whatever follows is real body stuff... */
-
ap_pass_brigade(f-next, b2);
if (r-header_only) {
apr_brigade_destroy(b);
return OK;
}
+
+r-sent_bodyct = 1; /* Whatever follows is real body stuff... */
if (r-chunked) {
/* We can't add this filter until we have already sent the headers.
=== }}
EOP
Release-Note:
Audit-Trail:
Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include [EMAIL PROTECTED] in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as general/1098: or ]
[Re: general/1098:). If the subject doesn't match this ]
[pattern, your message will be misfiled and ignored. The ]
[apbugs address is not added to the Cc line of messages from ]
[the database automatically because of the potential for mail ]
[loops. If you do not include this Cc, your reply may be ig- ]
[nored unless you are responding to an explicit request from a ]
[developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]
Re: 2.0.26?
Certainly converting mod_mime to a hash makes the other key whiner of we've got to get this out the door look equally foolish. That patch ate a week of several people's lives. I hope the performance improvement proves worth it. Heh, heh. You already know the answer to that question. If there are still problems with the hash, I would vote to revert back to tables. A little performance boost is nice but not at the expense of reasonable simplicity. Bill
Re: 2.0.26?
From: Bill Stoddard [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 11:55 AM Not really. The process Cliff and I outlined is really aimed at getting -a- stable release available. The process will take at least 2 days to go through but shouldn't take more than maybe 4 days total. If we use this process AND use your suggestions to not commit huge chunks of untested code during our 'stabilization period' I am confident we can get stable releases out on almost every try. We can control the release of tarballs to the test community. And what is the point of having testers spend time on a release that we know is broken? Isn't it better to just tell them hey don't waste your time on this tarball?. OTOH... what rule says that testers must test each and every tarball? If a tarball (even an alpha tarball) works well enough, the testers can still find and report bugs that we havent discovered yet. One other question... have you received complaints from testers about the frequencey of our tarball updates? Keep in mind one key detail, our most _active_ testers are using cvs (even on win32 ;) I don't think we are currently using the model suggested by Roy. I believe Roy's model is closer to what Cliff and I are advocating. With one exception... The exception is that some of us believe a 'feature freeze' (or 'big code change freeze', whatever you want to call it) needs to go into effect during the 'stabilizing period'. I know Roy doesn't like this idea but I see no other way out of our current inability to get stable releases. There is no such need. Tag. Roll in or out the changes that get a particular version stable. We have CVS. Use it. Yep. :-) But we also need to stop committing every possible change immediately. +1. Announce when we are in the 'stabilization period' and discourage (prohibit? :-) big commits during the period that do not enhance stability. My other post suggests we simply follow R-T-C (with a strict 3 +1's except on obscure build maintenance by platform maintainers) on a tagged branch. There's no need for this in the main tree. See my post to rbb for the rest of my thoughts on this personal slight, you are certainly impliciated as well. No slight intended, personal or otherwise. Big code drops going in right as we announce a tag roll is normal. It happens -every- time and most of us have been the perps at one time or another. This is pretty normal in closed source development shops as well when trying to hit driver dates. Everybody has code that -must- go in or the release will just be totally hosed (in their mind :-). We clearly have a problem getting stable releases out and I'm interested in solving the problem, not pointing fingers. Bill
Re: 2.0.26?
On 30 Aug 2001, Jeff Trawick wrote: Okay. I wasn't aware of this problem. Does it look like there might possibly be an easy fix? fixed now... just copied some ommitted code from mm Sweet. Thanks. Tag time now planned for 6:30pm EDT (right now I'm late for class)... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.26?
From: Bill Stoddard [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 2:17 PM Certainly converting mod_mime to a hash makes the other key whiner of we've got to get this out the door look equally foolish. That patch ate a week of several people's lives. I hope the performance improvement proves worth it. Heh, heh. You already know the answer to that question. If there are still problems with the hash, I would vote to revert back to tables. A little performance boost is nice but not at the expense of reasonable simplicity. Problems? Of course not (anymore). Of course nobody but Brian Pane has commented on the optimization schema to avoid merges of all sorts without introducing conf-pool corruption. Message-ID: 00d301c125ea$ea541b00$[EMAIL PROTECTED] From: William A. Rowe, Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Optimizing dir_merge() Date: Wed, 15 Aug 2001 19:28:31 -0500 and it's suppliment Message-ID: 02a601c125f3$f152a350$[EMAIL PROTECTED] From: William A. Rowe, Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: 00d301c125ea$ea541b00$[EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Optimizing dir_merge() Date: Wed, 15 Aug 2001 20:36:08 -0500 this schema helps any module be a good citizen in Apache performance, if we adopt these guidelines. The entire server should pick up a good bit. Bill - want a fun one line patch? Go find the expand hash fn, and change the hash size growth from (last_element * 2 + 1) to ((last_element + 1) * 4 - 1)
Re: [PATCH] Final version of AcceptMutex
Jim Jagielski [EMAIL PROTECTED] writes: You'll also notice that I decided to do some error handling if someone does something stupid like AcceptMutex BiteMe. Instead of dieing, Apache will continue with the default method. That's just too cool. Oh wow... ISTR that I have an uncommitted patch to 1.3 that makes Apache start up if I misspell the argument to LogLevel (boy do I have problems with certain spellings). I'll go ahead and commit that one too. (You were joking, right?) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: 2.0.26?
From: William A. Rowe, Jr. [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 1:03 PM At least on this front, I'm in total agreement... the httpd-test suite is excellent. I've gotten to where I rely on it heavily to test any change I make (even small ones) before committing, because it's so good at sniffing out the subtle (and not-so-subtle) problems. If everybody used it, we'd be set. Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike apache-1.3) that is mildly difficult in some quarters. I've specifically introduced the cygwin support to allow me to build httpd-test. We will see how this goes. Well, just so those of you on cygwin are aware, it seems that there is a bit more work todo before cygwin will work with httpd-test (although it serves pages by simply commenting out the user and group directives. I suspect that's the problem with the test framework, as well.) I'm jumping over to Doug's suggestion to customize the code just a bit for win32 native, as long as I have to do the work. If anyone wants to play in cygwin, just check out httpd-test from CVS, and go to town :) I'm asking key architechture questions to the list, and only about three of us are even participating in that discussion. As long as that's true, I don't expect a release this year unless I follow c-t-r to underlying opportunities for future exploits to appear. ^^ s/I/we/ fix the if it wasn't obvious in spite the total lack of grammer, and this doesn't just go for me ;) There are enough others working dilligently in their corners of the code to get those parts right - code I certainly don't grok (nor expect to.) Thanks esp. Jeff, Ryan, Graham, and the handful of others for touching new emits or breakage from my sometimes sloppy incremental application of these patches. I'm doing what I can to move or touch one bit at a time so the commits are more easily reviewed; my layering is sometimes hazerdous.
Bandwidth control
Greetings all, I have recently been looking around for a means to control bandwidth utilization of my Apache server. I have in the process found three or four modules which attempt to do this in various ways, all of which seem to be less than ideal to me in one or more areas, and of course lots of general responses by various people suggesting using traffic shaping in the linux kernel, etc, which is also less-than-ideal for my applications.. I am therefore looking at writing my own implementation of general-purpose bandwidth control for Apache. I have noticed that the framework of the 1.3 server is apparently not well suited to generic output filters, which would mean that to do this in a comprehensive way there would probably require some hacks to the core of the server and wouldn't be possible just as a plain module, but I have also noticed that the 2.0 line apparently has much better support for exactly this sort of module, so I'm looking at starting with a module for 2.0 and then possibly backporting to 1.3.. For general information, I'm looking at making something with the following features: * Real-time rate-limiting of output (not just sticking delays between requests) * Hard (instantaneous rate) or soft (average rate over request) limiting. * Ability to control total bandwidth used by the whole server, individual vhosts, locations, or directories. * Support for limits based on source IP/domain, user, time of day, day of week, etc. * Multiple limits with varying criteria, all simultaneously enforced. * Minimum bandwidth setting which, when hit, maximum limits will be stretched to accomodate or requests will be turned away (configurable). I've already got a basic model for limit calculations working, and have a good idea how to go about most of the rest of it, I think, but suggestions are welcome.. Before I get deeply into this, however, I do have a couple of questions which I hope some folks here could help out with: 1. Are my analyses of the architecture issues with 1.3/2.0 basically correct, or am I missing something obvious? (I'm relatively new to all this code so I may be overlooking something) 2. Is there in general some reason why bandwidth control is not already built into Apache httpd (philosophical/technical/political issues), or is it just that nobody has gotten around to doing it? If the latter, would people be adverse to possibly including this stuff into the main tree down the line? 3. Are other people already working on this who I'm not aware of and would be duplicating effort with? 4. I've looked around the various apache web sites, source tarballs, etc, and found a bit of documentation, but noticed that there isn't a lot of developer docs for the 2.0 architecture lying around yet.. This is, understandable as I do realize it's still seriously under development, but I just wanted to throw out a brief query to see if anybody has any pointers to less-obvious sources of information (notes, scribbles, partially-finished whatevers) that might be helpful for a prospective 2.0 module developer.. Alternately, any big gotchas I should watch out for or general advice is welcome, too. 5. If anybody else out there is interested in this sort of thing and has specific features or things they'd like me to work into what I'm doing, I'm open to suggestions. Anyway, I basically wanted to pop my head up, say hi, let people know what I was contemplating, and get any input people out there might have before proceeding, so if anybody's got any thoughts on this, please let me know.. -alex
Re: please make SIG_GRACEFUL configurable
On Thursday 30 August 2001 13:22, Roy T. Fielding wrote: On Wed, Aug 29, 2001 at 08:04:03PM -0700, Ryan Bloom wrote: On Wednesday 29 August 2001 18:21, Roy T. Fielding wrote: This was discussed at length before, and it was decided that we should use the same signal on all platforms for all MPMs (assuming the platform supports signals). Making this be a different signal on different platforms is just plain wrong. Okay. -1 on the change to SIGWINCH. Restore SIGUSR1 on all platforms. How are you going to make that work on older versions of Linux again? Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Comments on accept-mutex/single-listen patch ??
On Wed, 29 Aug 2001, Jim Jagielski wrote: Jeff Trawick wrote: how would it not work? fubar kernel? The trick would be in it *working*... NONE implies no mutexing at all, even for multiple listeners. And *that's* the exception. In some environments - for example with a clever linux or freebsd kernel it may may perfect sense - i.e. if you can be sure that the kernel has enough (filtering/sense) to take care of this. But yes - do this in the wrong environment and you shoot yourself in the foot. But then again pick the wrong Accept method and you do the same ! Dw
Re: Comments on accept-mutex/single-listen patch ??
On Wed, 29 Aug 2001, Marc Slemko wrote: On Wed, 29 Aug 2001, Jim Jagielski wrote: Marc Slemko wrote: So I don't see how NONE is viable on _ANY_ platform in the multiple listener case. It may seem to mostly work, but it is not reliable and can not be permitted. threaded ??? First off, simply being threaded doesn't avoid the issue... it depends on the particular model being used (ie. the MPM in 2.x...). FreeBSD with clever enough kernel hacking. Just have a look at the http filtering in freebsd for some fun. I am sure someone could do the same with linux. Dw
Re: 2.0.26?
From: Brian Pane [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 3:09 PM What's not clear, however, is how much of a speedup we're getting from all the subsequent enhancements to avoid copying in the same-pool case (which is where all the real complexity is). Anybody have benchmark or profile data on this part? We still copy in this case. You would need to experiment, per the short writeup I did, by modifying any module that does a table_merge or table_overlap or some hash merge. If you could post such numbers, perhaps that would get some further scrutiny from members of the list. Bill
Re: 2.0.26?]
From: "William A. Rowe, Jr." [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 6:34 PM From: "Ian Holsman" [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 5:42 PM the only thing 'funny' I'm noticing is that the map_to_storage hook isn't getting called for a sub-request.. this may be my code I just noticed that 10 minutes ago, I'm still investigating it. That would be a problem. It doesn't surprize me either. Every month I go back over the discrepancies in the internal_internal_redirect v.s. ap_process_request v.s. all the other ways we set up redirects/subrequests. These distinctions have to go away. Not that the steps can't be _heavily_ optimized by looking at r-prev or r-main for clues, but we need a single code path through this potentially tricky code. Notice all the fooness in the subreq mechanisms "Hey, if this, then we don't need to do that!" All well and good until some module gets hurt ;) If the authn/authz module _itself_ peeked at the pool data for r-main-p, "my_own_cache" and sees it's being redundant, it pulls a fast exit (fast OK, fast DECLINED, or fast HTTP_NOT_AUTHORIZED.) There is probably another weeks worth of work in optimizing these modules (see the ap_location_walk function for such an example.) Then all these code paths can be folded into a single place. The other option is that we patch these to a single code path _today_. Let Apache run a bit slow until these optimizations are moved into the right, magic places. Thoughts? Bill
Re: Tagging tree...
On Thu, 30 Aug 2001, Ian Holsman wrote: hold off for a second. I think I found something in mod_env I'm still in the pre-tag testing phase, so let me know what you find. CC: me directly so it gets to me faster... the list is a tad sluggish for me right now. Thanks, Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Bandwidth control
Alex Stewart wrote: I've already got a basic model for limit calculations working, and have a good idea how to go about most of the rest of it, I think, but suggestions are welcome.. An output filter in Apache v2.0 would be ideal for this. However I would question why you would want to do bandwidth limiting in Apache when they are so many options for doing this on the network itself. One thing that would be quite cool is bandwidth control on a per user basis. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
map_to_storage
in the main request the process goes... (http://lxr.webperf.org/source.cgi/modules/http/http_request.c#L256) ap_location_walk ap_run_translate_name map_to_storage ap_location_walk in the subrequest (http://lxr.webperf.org/source.cgi/server/request.c#L1264) ap_location_walk ap_run_translate_name directroy_walk/file/location/sub_req_common shouldn't the subreq be the same as the main?
Re: 2.0.26?]
On 30 Aug 2001, Ian Holsman wrote: There is probably another weeks worth of work in optimizing these modules (see the ap_location_walk function for such an example.) Then all these code paths can be folded into a single place. The other option is that we patch these to a single code path _today_. Let Apache run a bit slow until these optimizations are moved into the right, magic places. I think that would make more sense. +1 --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.26?
What's with this? Failed Test Status Wstat Total Fail Failed List of failed --- modules/cgi.t36 31 86.11% 1-4, 6, 8-25, 29-36 modules/info.t11 100.00% 1 modules/vhost_a 88 100.00% 1-8 I'm currently getting lots of Use of uninitialized value warnings from the test harness, so I don't know if this is the tests being broken or the httpd being broken or both. Anyone else seeing this on HEAD? Thanks, Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.26?
Ill get the subreq fix in in the next 45 minutes - let's see what disappears. - Original Message - From: Cliff Woolley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 7:32 PM Subject: Re: 2.0.26? What's with this? Failed Test Status Wstat Total Fail Failed List of failed --- modules/cgi.t36 31 86.11% 1-4, 6, 8-25, 29-36 modules/info.t11 100.00% 1 modules/vhost_a 88 100.00% 1-8 I'm currently getting lots of Use of uninitialized value warnings from the test harness, so I don't know if this is the tests being broken or the httpd being broken or both. Anyone else seeing this on HEAD? Thanks, Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Marc Slemko wrote: On 22 Aug 2001 [EMAIL PROTECTED] wrote: gregames01/08/22 16:12:24 Modified:modules/filters mod_include.c Log: get rid of nuisance log messages due to subrequests failing with EPIPE Erm... forgive me if I haven't followed any discussion on this... but why are subrequests failing with EPIPE, and why is that considered normal? I see EPIPE on FreeBSD when the user hits stop on the browser and goes off to a different site. Greg
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, 2001-08-30 at 18:12, Greg Ames wrote: Marc Slemko wrote: On 22 Aug 2001 [EMAIL PROTECTED] wrote: gregames01/08/22 16:12:24 Modified:modules/filters mod_include.c Log: get rid of nuisance log messages due to subrequests failing with EPIPE Erm... forgive me if I haven't followed any discussion on this... but why are subrequests failing with EPIPE, and why is that considered normal? I see EPIPE on FreeBSD when the user hits stop on the browser and goes off to a different site. Is there any way to log when people 'stop' the downlaod ? Greg -- Ian Holsman Performance Measurement Analysis CNET Networks-415 364-8608
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Ian Holsman wrote: On Thu, 2001-08-30 at 18:12, Greg Ames wrote: Marc Slemko wrote: On 22 Aug 2001 [EMAIL PROTECTED] wrote: gregames01/08/22 16:12:24 Modified:modules/filters mod_include.c Log: get rid of nuisance log messages due to subrequests failing with EPIPE Erm... forgive me if I haven't followed any discussion on this... but why are subrequests failing with EPIPE, and why is that considered normal? I see EPIPE on FreeBSD when the user hits stop on the browser and goes off to a different site. Is there any way to log when people 'stop' the downlaod ? Sure. Set LogLevel info in the config file. That will cause CoreOutputFilter to log write errors, in addition to this code in mod_include. To be consistent, I suppose we should do the same on the read side (ap_getline and ap_get_client_block), but we didn't the last time I looked. Greg
Re: 2.0.26?
Unless I made a fatal flaw, this should be it... lets get testing/auditing, folks ;) I had to move the ap_die/decl_die/finalize_request_protocol from ap_process_request_internal to make it truly portable. Really a straightfoward change, if I've done it right. I'll caution I'm a bit tired tonight, so we need to be cautious. Cliff - you are set up with the test bench :-? Bill - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 7:49 PM Subject: Re: 2.0.26? Ill get the subreq fix in in the next 45 minutes - let's see what disappears. - Original Message - From: Cliff Woolley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 30, 2001 7:32 PM Subject: Re: 2.0.26? What's with this? Failed Test Status Wstat Total Fail Failed List of failed --- modules/cgi.t36 31 86.11% 1-4, 6, 8-25, 29-36 modules/info.t11 100.00% 1 modules/vhost_a 88 100.00% 1-8 I'm currently getting lots of Use of uninitialized value warnings from the test harness, so I don't know if this is the tests being broken or the httpd being broken or both. Anyone else seeing this on HEAD? Thanks, Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Fw: [INFO] [CLA-2001:418] Conectiva Linux Security Announcement - openssl
The following provides a very respectible detail of why we can't install Apache 2.0 mod_ssl with anything less than 0.9.6b. Hope some of you find this interesting or otherwise useful. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- CONECTIVA LINUX SECURITY ANNOUNCEMENT - -- PACKAGE : openssl SUMMARY : Several vulnerabilities in the OpenSSL library DATE : 2001-08-30 16:11:00 ID: CLA-2001:418 RELEVANT RELEASES : 4.0, 4.0es, 4.1, 4.2, 5.0, prg graficos, ecommerce, 5.1, 6.0, 7.0 - - DESCRIPTION OpenSSL is a library providing several crypto and digital certificate handling functions. Several vulnerabilities have been addressed in newer versions of this library: 1. OpenSSL now avoids using environment variables when running as root; 2. The result of RSA-CRT is now checked to reduce the possibility of deducing the private key from an incorrectly calculated signature; 3. Changes to prevent Bleichenbacher's DSA attack; 4. OpenSSL now zeroes the premaster secret after deriving the master secret in DH ciphersuites; 5. Fix for a vulnerability in the pseudo random number generator which allowed an attacker to predict the internal state of the PRNG and thus predict future PRNG output. The first four vulnerabilities have been addressed in the 0.9.6a version of the library and affect Conectiva Linux = 6.0 only, while the last one was fixed with the 0.9.6b release and affects Conectiva Linux 7.0 and earlier. The packages available through this update have been patched to fix all these vulnerabilities. Thanks to the OpenSSL team for releasing the new versions and to Nalin Dahyabhai from Redhat for providing patches for older versions. SOLUTION All users should upgrade the OpenSSL library. After the update, programs which use the library, such as apache and openssh, should be restarted. IMPORTANT: updated packages for Conectiva Linux 4.0 and 4.0es are not yet available. REFERENCES 1. http://www.securityfocus.com/bid/3004 2. http://www.openssl.org 3.http://marc.theaimsgroup.com/?l=openssl-announcem=98655255404174w=2 DIRECT DOWNLOAD LINKS TO THE UPDATED PACKAGES ftp://atualizacoes.conectiva.com.br/4.1/SRPMS/openssl-0.9.5a-2U41_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/openssl-devel-0.9.5a-2U41_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/openssl-0.9.5a-2U41_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/SRPMS/openssl-0.9.5a-2U42_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/openssl-devel-0.9.5a-2U42_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/openssl-0.9.5a-2U42_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/SRPMS/openssl-0.9.5a-2U50_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/openssl-devel-0.9.5a-2U50_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/openssl-0.9.5a-2U50_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/SRPMS/openssl-0.9.5a-2U51_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/openssl-0.9.5a-2U51_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/openssl-devel-0.9.5a-2U51_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/openssl-0.9.6-4U60_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/openssl-0.9.6-4U60_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/openssl-devel-0.9.6-4U60_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/7.0/SRPMS/openssl-0.9.6a-3U70_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-doc-0.9.6a-3U70_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-devel-0.9.6a-3U70_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-0.9.6a-3U70_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-devel-static-0.9.6a-3U70_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-progs-0.9.6a-3U70_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/SRPMS/openssl-0.9.5a-2U50_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/openssl-devel-0.9.5a-2U50_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/openssl-0.9.5a-2U50_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/SRPMS/openssl-0.9.5a-2U50_1cl.src.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/openssl-devel-0.9.5a-2U50_1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/openssl-0.9.5a-2U50_1cl.i386.rpm ADDITIONAL INSTRUCTIONS Users of Conectiva Linux version 6.0 or higher may use apt to perform upgrades of RPM packages: - add the following line to /etc/apt/sources.list if it is not there yet (you may also use linuxconf to do this): rpm
Re: 2.0.26?
On Thu, 30 Aug 2001, Cliff Woolley wrote: I was just running the tests from httpd-test (which seems to now be working) in order to post the results here (they were failing miserably), but I see that you just committed a fix. I'll stop my test and do a cvs up. Stay tuned... It's a helluva lot closer than I've seen it all day I think. That last fix definitely helped a LOT. Right now everything seems good except mod_include: using Apache/2.0.26-dev (threaded MPM) waiting for server to warm up...ok server localhost:8529 started (pid=8981) server localhost:8530 listening (mod_vhost_alias) server localhost:8531 listening (mod_ssl) apache/404..ok apache/byterangeok apache/getfile..ok apache/post.ok apache/rwrite...ok apr/uri.ok filter/case.ok filter/case_in..ok filter/input_body...ok modules/access..ok modules/alias...ok modules/cgi.ok modules/dav.skipped test on this platform modules/dir.ok modules/env.ok modules/expires.ok modules/headers.ok modules/include.ok 22/22FAILED tests 1, 15, 17-20 Failed 6/22 tests, 72.73% okay modules/infook modules/negotiation.ok modules/rewrite.ok modules/setenvifok modules/status..ok modules/vhost_alias.ok ssl/all.ok Failed Test Status Wstat Total Fail Failed List of failed --- modules/include 226 27.27% 1, 15, 17-20 1 test skipped. server localhost:8529 shutdown (pid=8981) error running tests (please examine t/logs/error_log) Failed 1/25 test scripts, 96.00% okay. 6/1685 subtests failed, 99.64% okay. More details on the mod_include tests that failed, which are essentially all the ones involving valid subrequests: modules/include.1..22 GET /modules/include/big.shtml expected: -hello pass pass pass hello- actual: -- not ok 1 # Failed test 1 in modules/include.t at line 73 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 ok 13 ok 14 GET /modules/include/include1.shtml expected: -inc-two.shtml body include.shtml body- actual: -- not ok 15 # Failed test 15 in modules/include.t at line 73 fail #15 ok 16 GET /modules/include/include3.shtml expected: -inc-two.shtml body inc-one.shtml body include.shtml body- actual: -- not ok 17 # Failed test 17 in modules/include.t at line 73 fail #17 GET /modules/include/include4.shtml expected: -inc-two.shtml body inc-one.shtml body include.shtml body- actual: -- not ok 18 # Failed test 18 in modules/include.t at line 73 fail #18 GET /modules/include/include5.shtml expected: -inc-two.shtml body inc-one.shtml body inc-three.shtml body include.shtml body- actual: -- not ok 19 # Failed test 19 in modules/include.t at line 73 fail #19 GET /modules/include/include6.shtml expected: -inc-two.shtml body inc-one.shtml body inc-three.shtml body include.shtml body- actual: -- not ok 20 # Failed test 20 in modules/include.t at line 73 fail #20 ok 21 ok 22 FAILED tests 1, 15, 17-20 Failed 6/22 tests, 72.73% okay One harmless, unrelated warning during the compile which resulted from the #if 0's you added: request.c:297: warning: `resolve_symlink' defined but not used --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.26?
From: Cliff Woolley [EMAIL PROTECTED] Cc: William Rowe [EMAIL PROTECTED] On Thu, 30 Aug 2001, Cliff Woolley wrote: I was just running the tests from httpd-test (which seems to now be working) in order to post the results here (they were failing miserably), but I see that you just committed a fix. I'll stop my test and do a cvs up. Stay tuned... It's a helluva lot closer than I've seen it all day I think. That last fix definitely helped a LOT. Right now everything seems good except mod_include: Your segfaults prove that up. Something is wrong in URI assignment, I haven't figured exactly where, but I'm certain it's in the subreq #if 0 /* XXX */'d code. Gut instinct? The INTERNAL FOONESS uri's which are now going through Location walk, we have to think those through. One harmless, unrelated warning during the compile which resulted from the #if 0's you added: request.c:297: warning: `resolve_symlink' defined but not used That will become used, rather soon (after the next tag.)
Re: 2.0.26?
On Thu, 30 Aug 2001, William A. Rowe, Jr. wrote: Gut instinct? The INTERNAL FOONESS uri's which are now going through Location walk, we have to think those through. You're right: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 20591)] ap_getparents (name=0x80e0420 INTERNALLY GENERATED file-relative req) at util.c:488 488 name[w++] = name[l++]; (gdb) bt #0 ap_getparents (name=0x80e0420 INTERNALLY GENERATED file-relative req) at util.c:488 #1 0x080e0420 in core_cmds () at eval.c:41 #2 0x080b9912 in ap_process_request_internal (r=0x8159acc) at request.c:152 #3 0x080bacf4 in ap_sub_req_lookup_file (new_file=0xbfffaf50 if4.shtml, r=0x8155aac, next_filter=0x8156c34) at request.c:1672 #4 0x08067e77 in handle_include (ctx=0x81a02f4, bb=0xbfffd414, r=0x8155aac, f=0x8156c1c, head_ptr=0x81b37c8, inserted_head=0xbfffcfb4) at mod_include.c:794 #5 0x0806a875 in send_parsed_content (bb=0xbfffd414, r=0x8155aac, f=0x8156c1c) at mod_include.c:2518 #6 0x0806ae01 in includes_filter (f=0x8156c1c, b=0x8156d4c) at mod_include.c:2777 #7 0x080b212a in ap_pass_brigade (next=0x8156c1c, bb=0x8156d4c) at util_filter.c:247 #8 0x080b856a in default_handler (r=0x8155aac) at core.c:3062 #9 0x080a7de6 in ap_run_handler (r=0x8155aac) at config.c:185 #10 0x080a826b in ap_invoke_handler (r=0x8155aac) at config.c:344 #11 0x08080339 in ap_process_request (r=0x8155aac) at http_request.c:286 #12 0x0807c421 in ap_process_http_connection (c=0x81a005c) at http_core.c:287 #13 0x080b0996 in ap_run_process_connection (c=0x81a005c) at connection.c:82 #14 0x080a699e in child_main (child_num_arg=0) at prefork.c:829 #15 0x080a6b00 in make_child (s=0x80f034c, slot=0) at prefork.c:865 #16 0x080a6c11 in startup_children (number_to_start=5) at prefork.c:939 #17 0x080a7393 in ap_mpm_run (_pconf=0x80ee9e4, plog=0x8128bb4, s=0x80f034c) at prefork.c:1155 #18 0x080abe00 in main (argc=2, argv=0xb6c4) at main.c:431 #19 0x40206177 in __libc_start_main (main=0x80abb30 main, argc=2, ubp_av=0xb6c4, init=0x80621f8 _init, fini=0x80c1130 _fini, rtld_fini=0x4000e184 _dl_fini, stack_end=0xb6bc) at ../sysdeps/generic/libc-start.c:129 One harmless, unrelated warning during the compile which resulted from the #if 0's you added: request.c:297: warning: `resolve_symlink' defined but not used That will become used, rather soon (after the next tag.) Figured it would. -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.26?
From: Cliff Woolley [EMAIL PROTECTED]
Sent: Thursday, August 30, 2001 11:38 PM
On Thu, 30 Aug 2001, William A. Rowe, Jr. wrote:
Gut instinct? The INTERNAL FOONESS uri's which are now going
through Location walk, we have to think those through.
You're right:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 20591)]
ap_getparents (name=0x80e0420 INTERNALLY GENERATED file-relative req)
at util.c:488
488 name[w++] = name[l++];
(gdb) bt
#0 ap_getparents (name=0x80e0420 INTERNALLY GENERATED file-relative
req)
at util.c:488
#1 0x080e0420 in core_cmds () at eval.c:41
#2 0x080b9912 in ap_process_request_internal (r=0x8159acc) at
request.c:152
#3 0x080bacf4 in ap_sub_req_lookup_file (new_file=0xbfffaf50 if4.shtml,
r=0x8155aac, next_filter=0x8156c34) at request.c:1672
I suggest we handle this as follows; r-uri becomes NULL. If a hook fn doesn't
like it, it needs to decline. Where we go an reject the URI out of hand, let's
also test for r-main, and if we have a parent, then let it slide. If we don't
(we are the main request) we can cough up a 500 if there was a leading slash
or asterisk on the original uri, or a 400 if there was not.
I've had it (for tonight.) I'll be happy to pick back up anything necessary in
the morning, and will finish my audit of the overall delta after we pin this
down. But I would much rather see non-file requests get r-filename of NULL
(what about mime filename extensions? I don't think they should apply to
non-files) and r-uri of NULL for truly bogus internal redirects.
I know this will break some 3rd party modules. This is 2.0, and we are working
to _help_ them avoid the bugtrac reports on their modules. I'd think getting
this right (in this day and age of the hourly new exploit) is far perferable to
inconviencing an author with a set of five new rules. {Ok ok... this will get
documented once decisions are reached!}
Bill
Re: cvs commit: httpd-2.0/server request.c
On 31 Aug 2001 [EMAIL PROTECTED] wrote: Assuming that's a correct translation, which I believe to be the case (and which also seems to jive with the previous version of the test), then that first part darned well better check == 0, as opposed to != 0. strncmp returns 0 when they match. =-) And voila, All tests successful, 1 test skipped. is the result from httpd-test And of course there's a downside: the tests are only as good as what they check for. It's still possible to get into the else case (and therefore segfault later) if you just make a relative subrequest for a file in some other directory. None of the mod_include tests currently test that (I'll ask the httpd-test guys to add some tests that check this). So you still segfault if you do something like this: !--#include file=subdir/foo.shtml-- Though this now works: !--#include file=foo.shtml-- Arggh. I think I like Bill's solution of ditching this INTERNALLY GENERATED crap and just make it NULL. But my brain is too fried right now to get that working. I'm going to sleep. We'll fix this tomorrow. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
