Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 9, 2008, at 8:36 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Dienstag, 9. Dezember 2008 21:54 An: dev@httpd.apache.org Betreff: Re: [VOTE] Release Apache HTTP server 2.3.0-alpha Hmmm, normally ap_remove_output_filter should be able to handle this case. I guess this needs some investigation why it does not. Yeah... for me, that's the worrisome part. Will do some deeping tracing on the code path. I think I know what happens. The problem is that we have not updated the request_rec field in all filter structs at this point of time. So ap_remove_output_filter updates rr->output_filters instead of r->output_filters. The following patch reverts r724805 and fixes the issue by moving the calls to update_r_in_filters up in the code. I couldn't find any framework failures afterwards. Do you still see some? :) Yep. Some tracing indicated that and I did some alternate adjusting to work around it. But this one is cleaner. Added in r725077
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: > Gregg L. Smith wrote: >> Paul Querna wrote: >>> Test tarballs for Apache httpd 2.3.0-alpha are available at: >>> >>> http://httpd.apache.org/dev/dist/ >>> >>> Your votes please; >>> >>> ±1 >>> [ ] Release httpd-2.3.0 as Alpha >>> >>> >>> Vote closes at 7:00 UTC on Tuesday December 9 2008. >>> >>> Thanks, >>> >>> Paul >> -? tested on Windows XP built both VS9 and VS6 >> >> Am I missing something? >> >> [Mon Dec 08 13:21:17 2008] [crit] Server MUST relinquish startup >> privileges before accepting connections. Please ensure mod_unixd or >> other system security module is loaded. >> Configuration Failed > > I'm guessing no one updated the winnt mpm for the changes to unixd. > > So the proposed release is busted on windows too :-) Given the state of things - I'm not -1 on a unix-specific alpha release for this issue, but am leaning -.5 for the deflate/filtering/subrequest problems that were recently uncovered. I'll research this issue so when we are ready to try 2.3.1-alpha, it's been resolved. Might not be in the next 2 days though, think it will likely have to wait for my weekend.
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Henning Schmiedehausen wrote: > [... to the thread as a whole, not specifically to Jim's mail ...] > > Let's just say, I usually run alpha-level code in a sandbox for a while > to find problems, We could use it e.g. on people.a.o or maybe httpd.a.o > if you are so keen on it. :-) Sorry this seems to be a communications problem. Trunk on httpd is approximately as robust as the last stable release. But it is not stable. httpd alpha's (n.odd revs) represent an API in flux; users and developers are warned that the API can and likely will change before the next stable release. The alpha period provides a window during which 3rd party module developers can propose patches or ask for API enhancements or changes by actually running code which is headed for general release. The beta's (n.even.0 ...) are the first chance for module authors to stabilize their add ins and for users to point out to us very very odd edge cases due to their unique [cough, cough] configurations. The GA stable releases (n.even.x) represent a pretty much unbroken chain of bug fixes, and energies turn to the trunk again to develop new ideas. So there was little risk w.r.t. deploying 2.3.0 alpha on our infra; it only means that the folks deploying it had to adjust for new configuration syntax, API changes and watch things closely. They did this, and have therefore found a fix to a problem which would have later plagued infra. If the httpd developers weren't an active part of the infra team, I might share your concerns. If I didn't understand the health and state of the code, I'd likely share your concerns. But as I point out above, you have little cause for concern with httpd deployments.
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> Gesendet: Dienstag, 9. Dezember 2008 21:54
> An: dev@httpd.apache.org
> Betreff: Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
>
>
> On Dec 9, 2008, at 2:39 PM, Ruediger Pluem wrote:
>
> >
> >
> > On 12/09/2008 07:23 PM, Jim Jagielski wrote:
> >>
> >> On Dec 9, 2008, at 12:15 PM, Paul Querna wrote:
> >>
> >>> Ruediger Pluem wrote:
> >>>> On 12/09/2008 02:06 PM, Jim Jagielski wrote:
> >>>>> On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote:
> >>>>>
> >>>>>> Paul Querna wrote:
> >>>>>>> The change fixed velocity.apache.org, but broke
> www.apache.org.
> >>>>>>>
> >>>>>>> All of this sub-request + output filter stuff started
> in r620133
> >>>>>>> kinda
> >>>>>>> needs some more thought.
> >>>>>> My thought is that fast_internal_subrequest (which I last
> >>>>>> refactored, but
> >>>>>> was bogusly introduced for mod_negotiation) must die, now.
> >>>>>>
> >>>>>> Votes?
> >>>>>>
> >>>>> Can we simply revert r620133 (et.al.) and then start from *that*
> >>>>> point? That is, get to a known OK state and then boot
> >>>>> fast_internal_subrequest?
> >>>> Currently I would be more keen to know the issues we are still
> >>>> facing, so
> >>>> that we can keep these cases and issues in mind when we do a
> >>>> rewrite of
> >>>> this stuff.
> >>>
> >>> Applying the patch invsersed the working directoy indexes.
> >>>
> >>> velocity worked, but www.apache.org stopped working. Deflate was
> >>> loaded in both cases.
> >>>
> >>
> >> hmmm
> >>
> >> r724805 cleans up a lot of framework breaks from r724515
> >>
> >> looking to be a positional issue...
> >
> > Hmmm, normally ap_remove_output_filter should be able to handle this
> > case. I guess this needs some investigation why it does not.
>
> Yeah... for me, that's the worrisome part. Will do some deeping
> tracing on the code path.
I think I know what happens. The problem is that we have not updated the
request_rec field in all filter structs at this point of time. So
ap_remove_output_filter
updates rr->output_filters instead of r->output_filters. The following patch
reverts r724805 and fixes the issue by moving the calls to update_r_in_filters
up in the code. I couldn't find any framework failures afterwards. Do you still
see some?
Index: modules/http/http_request.c
===
--- modules/http/http_request.c (revision 724941)
+++ modules/http/http_request.c (working copy)
@@ -518,6 +518,15 @@
r->output_filters = rr->output_filters;
r->input_filters = rr->input_filters;
+/* If any filters pointed at the now-defunct rr, we must point them
+ * at our "new" instance of r. In particular, some of rr's structures
+ * will now be bogus (say rr->headers_out). If a filter tried to modify
+ * their f->r structure when it is pointing to rr, the real request_rec
+ * will not get updated. Fix that here.
+ */
+update_r_in_filters(r->input_filters, rr, r);
+update_r_in_filters(r->output_filters, rr, r);
+
if (r->main) {
ap_add_output_filter_handle(ap_subreq_core_filter_handle,
NULL, r, r->connection);
@@ -541,20 +550,8 @@
}
if (next && (next->frec == ap_subreq_core_filter_handle)) {
ap_remove_output_filter(next);
-if (next == r->output_filters) {
-r->output_filters = r->output_filters->next;
-}
}
}
-
-/* If any filters pointed at the now-defunct rr, we must point them
- * at our "new" instance of r. In particular, some of rr's structures
- * will now be bogus (say rr->headers_out). If a filter tried to modify
- * their f->r structure when it is pointing to rr, the real request_rec
- * will not get updated. Fix that here.
- */
-update_r_in_filters(r->input_filters, rr, r);
-update_r_in_filters(r->output_filters, rr, r);
}
AP_DECLARE(void) ap_internal_redirect(const char *new_uri, request_rec *r)
Regards
Rüdiger
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 9, 2008, at 2:39 PM, Ruediger Pluem wrote: On 12/09/2008 07:23 PM, Jim Jagielski wrote: On Dec 9, 2008, at 12:15 PM, Paul Querna wrote: Ruediger Pluem wrote: On 12/09/2008 02:06 PM, Jim Jagielski wrote: On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote: Paul Querna wrote: The change fixed velocity.apache.org, but broke www.apache.org. All of this sub-request + output filter stuff started in r620133 kinda needs some more thought. My thought is that fast_internal_subrequest (which I last refactored, but was bogusly introduced for mod_negotiation) must die, now. Votes? Can we simply revert r620133 (et.al.) and then start from *that* point? That is, get to a known OK state and then boot fast_internal_subrequest? Currently I would be more keen to know the issues we are still facing, so that we can keep these cases and issues in mind when we do a rewrite of this stuff. Applying the patch invsersed the working directoy indexes. velocity worked, but www.apache.org stopped working. Deflate was loaded in both cases. hmmm r724805 cleans up a lot of framework breaks from r724515 looking to be a positional issue... Hmmm, normally ap_remove_output_filter should be able to handle this case. I guess this needs some investigation why it does not. Yeah... for me, that's the worrisome part. Will do some deeping tracing on the code path. But for the time being this looks like a good fix. Thanks for doing and sorry that I didn't run the framework before committing r724515 :-(. Regards Rüdiger
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On 12/09/2008 07:23 PM, Jim Jagielski wrote: > > On Dec 9, 2008, at 12:15 PM, Paul Querna wrote: > >> Ruediger Pluem wrote: >>> On 12/09/2008 02:06 PM, Jim Jagielski wrote: On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote: > Paul Querna wrote: >> The change fixed velocity.apache.org, but broke www.apache.org. >> >> All of this sub-request + output filter stuff started in r620133 >> kinda >> needs some more thought. > My thought is that fast_internal_subrequest (which I last > refactored, but > was bogusly introduced for mod_negotiation) must die, now. > > Votes? > Can we simply revert r620133 (et.al.) and then start from *that* point? That is, get to a known OK state and then boot fast_internal_subrequest? >>> Currently I would be more keen to know the issues we are still >>> facing, so >>> that we can keep these cases and issues in mind when we do a rewrite of >>> this stuff. >> >> Applying the patch invsersed the working directoy indexes. >> >> velocity worked, but www.apache.org stopped working. Deflate was >> loaded in both cases. >> > > hmmm > > r724805 cleans up a lot of framework breaks from r724515 > > looking to be a positional issue... Hmmm, normally ap_remove_output_filter should be able to handle this case. I guess this needs some investigation why it does not. But for the time being this looks like a good fix. Thanks for doing and sorry that I didn't run the framework before committing r724515 :-(. Regards Rüdiger
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 9, 2008, at 12:15 PM, Paul Querna wrote: Ruediger Pluem wrote: On 12/09/2008 02:06 PM, Jim Jagielski wrote: On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote: Paul Querna wrote: The change fixed velocity.apache.org, but broke www.apache.org. All of this sub-request + output filter stuff started in r620133 kinda needs some more thought. My thought is that fast_internal_subrequest (which I last refactored, but was bogusly introduced for mod_negotiation) must die, now. Votes? Can we simply revert r620133 (et.al.) and then start from *that* point? That is, get to a known OK state and then boot fast_internal_subrequest? Currently I would be more keen to know the issues we are still facing, so that we can keep these cases and issues in mind when we do a rewrite of this stuff. Applying the patch invsersed the working directoy indexes. velocity worked, but www.apache.org stopped working. Deflate was loaded in both cases. hmmm r724805 cleans up a lot of framework breaks from r724515 looking to be a positional issue...
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Ruediger Pluem wrote: On 12/09/2008 02:06 PM, Jim Jagielski wrote: On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote: Paul Querna wrote: The change fixed velocity.apache.org, but broke www.apache.org. All of this sub-request + output filter stuff started in r620133 kinda needs some more thought. My thought is that fast_internal_subrequest (which I last refactored, but was bogusly introduced for mod_negotiation) must die, now. Votes? Can we simply revert r620133 (et.al.) and then start from *that* point? That is, get to a known OK state and then boot fast_internal_subrequest? Currently I would be more keen to know the issues we are still facing, so that we can keep these cases and issues in mind when we do a rewrite of this stuff. Applying the patch invsersed the working directoy indexes. velocity worked, but www.apache.org stopped working. Deflate was loaded in both cases. www.a.o didn't have SSI, or any othe rfilters to my knowledge, soI'd guess the patch broke it in anothe subtle way... -Paul
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On 12/09/2008 02:06 PM, Jim Jagielski wrote: > > On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote: > >> Paul Querna wrote: >>> >>> The change fixed velocity.apache.org, but broke www.apache.org. >>> >>> All of this sub-request + output filter stuff started in r620133 kinda >>> needs some more thought. >> >> My thought is that fast_internal_subrequest (which I last refactored, but >> was bogusly introduced for mod_negotiation) must die, now. >> >> Votes? >> > > Can we simply revert r620133 (et.al.) and then start from *that* > point? That is, get to a known OK state and then boot > fast_internal_subrequest? Currently I would be more keen to know the issues we are still facing, so that we can keep these cases and issues in mind when we do a rewrite of this stuff. Regards Rüdiger
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 8, 2008, at 7:43 PM, William A. Rowe, Jr. wrote: Paul Querna wrote: The change fixed velocity.apache.org, but broke www.apache.org. All of this sub-request + output filter stuff started in r620133 kinda needs some more thought. My thought is that fast_internal_subrequest (which I last refactored, but was bogusly introduced for mod_negotiation) must die, now. Votes? Can we simply revert r620133 (et.al.) and then start from *that* point? That is, get to a known OK state and then boot fast_internal_subrequest?
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On 12/09/2008 01:16 AM, Paul Querna wrote: > Paul Querna wrote: >> Paul Querna wrote: >>> The problem with velocity's site is an interaction between mod_deflate, >>> mod_include, subrequests and directory indexes. In production, we are >>> still running 2.3.0-alpha, but I have disabled mod_deflate, which seems >>> to work as a work around for now. >> >> We are now running with mod_deflate enabled again, with this revision >> patched into our version: >> http://svn.apache.org/viewvc?view=rev&revision=724515 >> >> Thanks to rpluem for figuring this out. > > We have reverted to 2.2.x on www for now. > > The change fixed velocity.apache.org, but broke www.apache.org. Can you please provide some details how it broke www.apache.org? Regards Rüdiger
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Nick,
"It works!" ... but needs to have mpm_common.h included
I notice it takes about 4 seconds to serve the "It works" page on this
P4 3.0G HT, 2.5G DDR2 XP VC6
Gregg
--- modules/arch/win32/mod_win32.c(revision 724570)
+++ modules/arch/win32/mod_win32.c(working copy)
@@ -31,6 +31,7 @@
#include "mod_cgi.h"
#include "apr_lib.h"
#include "ap_regkey.h"
+#include "mpm_common.h"
extern OSVERSIONINFO osver; /* hiding in mpm_winnt.c */
static int win_nt;
@@ -544,6 +545,7 @@
static int win32_pre_config(apr_pool_t *pconf_, apr_pool_t *plog,
apr_pool_t *ptemp)
{
win_nt = (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS);
+ap_sys_privileges_handlers(1);
return OK;
}
Nick Kew wrote:
Gregg L. Smith wrote:
Am I missing something?
[Mon Dec 08 13:21:17 2008] [crit] Server MUST relinquish startup
privileges before accepting connections. Please ensure mod_unixd or
other system security module is loaded.
Configuration Failed
Probably not. Looks like this'll be broken on all non-unix-family
platforms, for the same reason.
Does the following patch fix it for you?
--- modules/arch/win32/mod_win32.c(revision 724570)
+++ modules/arch/win32/mod_win32.c(working copy)
@@ -544,6 +544,7 @@
static int win32_pre_config(apr_pool_t *pconf_, apr_pool_t *plog,
apr_pool_t *ptemp)
{
win_nt = (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS);
+ap_sys_privileges_handlers(1);
return OK;
}
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Gregg L. Smith wrote:
Am I missing something?
[Mon Dec 08 13:21:17 2008] [crit] Server MUST relinquish startup
privileges before accepting connections. Please ensure mod_unixd or
other system security module is loaded.
Configuration Failed
Probably not. Looks like this'll be broken on all non-unix-family
platforms, for the same reason.
Does the following patch fix it for you?
--- modules/arch/win32/mod_win32.c (revision 724570)
+++ modules/arch/win32/mod_win32.c (working copy)
@@ -544,6 +544,7 @@
static int win32_pre_config(apr_pool_t *pconf_, apr_pool_t *plog,
apr_pool_t *ptemp)
{
win_nt = (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS);
+ap_sys_privileges_handlers(1);
return OK;
}
--
Nick Kew
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
* William A. Rowe, Jr. wrote: > Paul Querna wrote: > > The change fixed velocity.apache.org, but broke www.apache.org. > > > > All of this sub-request + output filter stuff started in r620133 kinda > > needs some more thought. > > My thought is that fast_internal_subrequest (which I last refactored, but > was bogusly introduced for mod_negotiation) must die, now. > > Votes? > > +1 here to kill fast_internal_subrequest and provide the one fastest > mechanism that we can safely craft. +1. wholeheartedly ;-) nd
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
2008/12/9 William A. Rowe, Jr. <[EMAIL PROTECTED]>: > Paul Querna wrote: >> >> The change fixed velocity.apache.org, but broke www.apache.org. >> >> All of this sub-request + output filter stuff started in r620133 kinda >> needs some more thought. > > My thought is that fast_internal_subrequest (which I last refactored, but > was bogusly introduced for mod_negotiation) must die, now. > > Votes? > > +1 here to kill fast_internal_subrequest and provide the one fastest > mechanism that we can safely craft. Are you referring to ap_internal_fast_redirect()? Still also used by mod_dir, with its use in the latter in the past causing odd issues with duplication of information in tables. For where this showed up in mod_python see: http://issues.apache.org/jira/browse/MODPYTHON-146 Was that duplication of information ever addressed? Graham
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: > > The change fixed velocity.apache.org, but broke www.apache.org. > > All of this sub-request + output filter stuff started in r620133 kinda > needs some more thought. My thought is that fast_internal_subrequest (which I last refactored, but was bogusly introduced for mod_negotiation) must die, now. Votes? +1 here to kill fast_internal_subrequest and provide the one fastest mechanism that we can safely craft. Bill
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: Paul Querna wrote: The problem with velocity's site is an interaction between mod_deflate, mod_include, subrequests and directory indexes. In production, we are still running 2.3.0-alpha, but I have disabled mod_deflate, which seems to work as a work around for now. We are now running with mod_deflate enabled again, with this revision patched into our version: http://svn.apache.org/viewvc?view=rev&revision=724515 Thanks to rpluem for figuring this out. We have reverted to 2.2.x on www for now. The change fixed velocity.apache.org, but broke www.apache.org. All of this sub-request + output filter stuff started in r620133 kinda needs some more thought. -Paul
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: > The problem with velocity's site is an interaction between mod_deflate, > mod_include, subrequests and directory indexes. In production, we are > still running 2.3.0-alpha, but I have disabled mod_deflate, which seems > to work as a work around for now. We are now running with mod_deflate enabled again, with this revision patched into our version: http://svn.apache.org/viewvc?view=rev&revision=724515 Thanks to rpluem for figuring this out.
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
While we are at it; If mod_mem_cache is no longer going to be used, needs to be removed from makefile.win Gregg Paul Querna wrote: Gregg L. Smith wrote: Paul Querna wrote: Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Tuesday December 9 2008. Thanks, Paul -? tested on Windows XP built both VS9 and VS6 Am I missing something? [Mon Dec 08 13:21:17 2008] [crit] Server MUST relinquish startup privileges before accepting connections. Please ensure mod_unixd or other system security module is loaded. Configuration Failed I'm guessing no one updated the winnt mpm for the changes to unixd. So the proposed release is busted on windows too :-) -Paul No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.15/1837 - Release Date: 12/8/2008 9:38 AM --- makefile.win(PR 720062) +++ makefile.win(Working Copy) @@ -302,7 +302,6 @@ cd modules\cache $(MAKE) $(MAKEOPT) -f mod_cache.mak CFG="mod_cache - Win32 $(LONG)" RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f mod_file_cache.mak CFG="mod_file_cache - Win32 $(LONG)" RECURSE=0 $(CTARGET) -$(MAKE) $(MAKEOPT) -f mod_mem_cache.mak CFG="mod_mem_cache - Win32 $(LONG)" RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f mod_disk_cache.mak CFG="mod_disk_cache - Win32 $(LONG)" RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f mod_socache_dbm.mak CFG="mod_socache_dbm - Win32 $(LONG)" RECURSE=0 $(CTARGET) !IFDEF ALL @@ -525,7 +524,6 @@ copy modules\arch\win32\$(LONG)\mod_isapi.$(src_so) "$(inst_so)" <.y copy modules\cache\$(LONG)\mod_cache.$(src_so) "$(inst_so)" <.y copy modules\cache\$(LONG)\mod_file_cache.$(src_so) "$(inst_so)" <.y - copy modules\cache\$(LONG)\mod_mem_cache.$(src_so) "$(inst_so)" <.y copy modules\cache\$(LONG)\mod_disk_cache.$(src_so) "$(inst_so)" <.y copy modules\cache\$(LONG)\mod_socache_dbm.$(src_so)"$(inst_so)" <.y -copy modules\cache\$(LONG)\mod_socache_dc.$(src_so)"$(inst_so)" <.y
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: > Gregg L. Smith wrote: >> >> [Mon Dec 08 13:21:17 2008] [crit] Server MUST relinquish startup >> privileges before accepting connections. Please ensure mod_unixd or >> other system security module is loaded. >> Configuration Failed > > I'm guessing no one updated the winnt mpm for the changes to unixd. > > So the proposed release is busted on windows too :-) Well, windows can't relinquish the context it is run-as (trivially) without such things as user account passwords and so forth. So, one could say the unixd API is busted ;-) But I wouldn't mind at all if windows emitted a notice that "This server is running as a privilaged LocalSystem user, preventing access to any network file systems (UNC Shares) - you are strongly encouraged to reconfigure the service to run-as a more restricted user" and if running in another privileged context; "This server is running as the a privilaged user, you are strongly encouraged to reconfigure the service to run-as a more restricted user" What happens on unix if started as the same user?
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Gregg L. Smith wrote: Paul Querna wrote: Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Tuesday December 9 2008. Thanks, Paul -? tested on Windows XP built both VS9 and VS6 Am I missing something? [Mon Dec 08 13:21:17 2008] [crit] Server MUST relinquish startup privileges before accepting connections. Please ensure mod_unixd or other system security module is loaded. Configuration Failed I'm guessing no one updated the winnt mpm for the changes to unixd. So the proposed release is busted on windows too :-) -Paul
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Tuesday December 9 2008. Thanks, Paul -? tested on Windows XP built both VS9 and VS6 Am I missing something? [Mon Dec 08 13:21:17 2008] [crit] Server MUST relinquish startup privileges before accepting connections. Please ensure mod_unixd or other system security module is loaded. Configuration Failed Gregg
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Tuesday December 9 2008. -1 for these two reasons: 1) Default build doesn't work with mod_proxy due to module load order issues. I believe even for an alpha, we should at least compile and start with the default configuration. 2) The sub-requests issues seen on velocity.apache.org, while I'm not so sure about this one being a blocker, it does prevent our own infrastructure from fully using 2.3.x without workarounds. Thanks, Paul
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Sonntag, 7. Dezember 2008 08:18 An: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Tuesday December 9 2008. Where do we track issues that do not prevent an alpha release but need to be resolved before 2.4.0? In the STATUS file of trunk? Yes, STATUS file on trunk should be the right place.
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 8, 2008, at 11:40 AM, William A. Rowe, Jr. wrote: Graham Leggett wrote: Henning Schmiedehausen wrote: If that is the reason that e.g. the Velocity site broke, I am +1 for rolling this back to a known stable 2.2.x version. Our production sites IMHO shouldn't be guinea pigs for -alpha versions. If we don't trust our own software to run in production, who else will? More to the point, it was already "rolled back" by disabling mod_deflate as soon as the issue was identified. Henning, if we take you literally, then we might as well pass infra the charter that they are not to develop code for deployment, because everything from your fingers to the keyboard is alpha until proven and juried by peers. This has been standard practice for 10 years; what's changed? It would have been nice to test 2.2.11 first, if even for a week, before 2.3.0, IMO After all, we do expect people to use 2.2.11 before they use 2.3.0 :) :)
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Graham Leggett wrote: > Henning Schmiedehausen wrote: > >> If that is the reason that e.g. the Velocity site broke, I am +1 for >> rolling this back to a known stable 2.2.x version. >> >> Our production sites IMHO shouldn't be guinea pigs for -alpha versions. > > If we don't trust our own software to run in production, who else will? More to the point, it was already "rolled back" by disabling mod_deflate as soon as the issue was identified. Henning, if we take you literally, then we might as well pass infra the charter that they are not to develop code for deployment, because everything from your fingers to the keyboard is alpha until proven and juried by peers. This has been standard practice for 10 years; what's changed?
Re: AW: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 8, 2008, at 8:34 AM, Jim Jagielski wrote: On Dec 8, 2008, at 8:15 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Sonntag, 7. Dezember 2008 08:18 An: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha I noticed one problem. Since we placed the proxy balancer modules in a separate folder they get loaded *before* mod_proxy in the created httpd.conf. This causes httpd to fail at start as the balancer modules need symbols from proxy_util (which is linked into mod_proxy). So I guess we either need to adjust the process that creates the LoadModule directives for our generated httpd.conf so that the balancer modules get loaded later or we need to make said symbols optional functions. H Actually, we could do this at build time, since make goes into the subdirs first and makes proxy/balancers and then proxy/, so I need to figure out how to convince the build system to do proxy first and then proxy/balancer... Any ideas from any build system gurus? Early, cold and no coffee... and Monday! Not a good start for using one's neurons. Fixed...
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
> -Ursprüngliche Nachricht- > Von: Jim Jagielski > Gesendet: Montag, 8. Dezember 2008 14:38 > An: dev@httpd.apache.org > Cc: [EMAIL PROTECTED] > Betreff: Re: AW: [VOTE] Release Apache HTTP server 2.3.0-alpha > > > On Dec 8, 2008, at 8:15 AM, Plüm, Rüdiger, VF-Group wrote: > > > > > > >> -Ursprüngliche Nachricht- > >> Von: Paul Querna > >> Gesendet: Sonntag, 7. Dezember 2008 08:18 > >> An: dev@httpd.apache.org; [EMAIL PROTECTED] > >> Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha > >> > >> Test tarballs for Apache httpd 2.3.0-alpha are available at: > >> > >> http://httpd.apache.org/dev/dist/ > >> > >> Your votes please; > >> > >> ±1 > >> [ ] Release httpd-2.3.0 as Alpha > >> > >> > > > > I noticed one problem. Since we placed the proxy balancer > modules in a > > separate folder they get loaded *before* mod_proxy in the created > > httpd.conf. This causes httpd to fail at start as the > balancer modules > > need symbols from proxy_util (which is linked into mod_proxy). > > > > > D'oh! Of course. We can simply define the load ordering > in register_hooks() How so? The loading of the module already fails in the dynamic linking phase. Regards Rüdiger
Re: AW: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 8, 2008, at 8:37 AM, Jim Jagielski wrote: On Dec 8, 2008, at 8:15 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Sonntag, 7. Dezember 2008 08:18 An: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha I noticed one problem. Since we placed the proxy balancer modules in a separate folder they get loaded *before* mod_proxy in the created httpd.conf. This causes httpd to fail at start as the balancer modules need symbols from proxy_util (which is linked into mod_proxy). D'oh! Of course. We can simply define the load ordering in register_hooks() ignore that... this isn't a hook issue
Re: AW: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 8, 2008, at 8:15 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Sonntag, 7. Dezember 2008 08:18 An: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha I noticed one problem. Since we placed the proxy balancer modules in a separate folder they get loaded *before* mod_proxy in the created httpd.conf. This causes httpd to fail at start as the balancer modules need symbols from proxy_util (which is linked into mod_proxy). D'oh! Of course. We can simply define the load ordering in register_hooks()
Re: AW: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 8, 2008, at 8:15 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Sonntag, 7. Dezember 2008 08:18 An: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha I noticed one problem. Since we placed the proxy balancer modules in a separate folder they get loaded *before* mod_proxy in the created httpd.conf. This causes httpd to fail at start as the balancer modules need symbols from proxy_util (which is linked into mod_proxy). So I guess we either need to adjust the process that creates the LoadModule directives for our generated httpd.conf so that the balancer modules get loaded later or we need to make said symbols optional functions. H Actually, we could do this at build time, since make goes into the subdirs first and makes proxy/balancers and then proxy/, so I need to figure out how to convince the build system to do proxy first and then proxy/balancer... Any ideas from any build system gurus?
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
> -Ursprüngliche Nachricht- > Von: Paul Querna > Gesendet: Sonntag, 7. Dezember 2008 08:18 > An: dev@httpd.apache.org; [EMAIL PROTECTED] > Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha > > Test tarballs for Apache httpd 2.3.0-alpha are available at: > > http://httpd.apache.org/dev/dist/ > > Your votes please; > > ±1 > [ ] Release httpd-2.3.0 as Alpha > > > Vote closes at 7:00 UTC on Tuesday December 9 2008. Where do we track issues that do not prevent an alpha release but need to be resolved before 2.4.0? In the STATUS file of trunk? Regards Rüdiger
AW: [VOTE] Release Apache HTTP server 2.3.0-alpha
> -Ursprüngliche Nachricht- > Von: Paul Querna > Gesendet: Sonntag, 7. Dezember 2008 08:18 > An: dev@httpd.apache.org; [EMAIL PROTECTED] > Betreff: [VOTE] Release Apache HTTP server 2.3.0-alpha > > Test tarballs for Apache httpd 2.3.0-alpha are available at: > > http://httpd.apache.org/dev/dist/ > > Your votes please; > > ±1 > [ ] Release httpd-2.3.0 as Alpha > > I noticed one problem. Since we placed the proxy balancer modules in a separate folder they get loaded *before* mod_proxy in the created httpd.conf. This causes httpd to fail at start as the balancer modules need symbols from proxy_util (which is linked into mod_proxy). So I guess we either need to adjust the process that creates the LoadModule directives for our generated httpd.conf so that the balancer modules get loaded later or we need to make said symbols optional functions. Regards Rüdiger
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Henning Schmiedehausen wrote: If that is the reason that e.g. the Velocity site broke, I am +1 for rolling this back to a known stable 2.2.x version. Our production sites IMHO shouldn't be guinea pigs for -alpha versions. If we don't trust our own software to run in production, who else will? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Mon, Dec 8, 2008 at 12:20 PM, Sander Temme <[EMAIL PROTECTED]> wrote: > > On Dec 7, 2008, at 6:33 PM, Henning Schmiedehausen wrote: > >> Our production sites IMHO shouldn't be guinea pigs for -alpha versions. > > Best. Place. Ever. to try out our stuff to find and fix bugs. > > Especially nasty edge cases like this one. > > www.apache.org should run dogfood whenever possible. How else can we > justify asking the general public to try our stuff out? ++1. -- justin
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Henning Schmiedehausen wrote: > If that is the reason that e.g. the Velocity site broke, I am +1 for > rolling this back to a known stable 2.2.x version. > > Our production sites IMHO shouldn't be guinea pigs for -alpha versions. We have always run -alpha versions, even with experimental MPMs on our production web servers. Eating our own dog food is very good, if we have developers around to fix it. The problem with velocity's site is an interaction between mod_deflate, mod_include, subrequests and directory indexes. In production, we are still running 2.3.0-alpha, but I have disabled mod_deflate, which seems to work as a work around for now. Hopefully in the next day we will have a patch to fix it. Thanks, Paul
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
On Dec 7, 2008, at 6:33 PM, Henning Schmiedehausen wrote: Our production sites IMHO shouldn't be guinea pigs for -alpha versions. Best. Place. Ever. to try out our stuff to find and fix bugs. Especially nasty edge cases like this one. www.apache.org should run dogfood whenever possible. How else can we justify asking the general public to try our stuff out? S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
{eos,aruroa}.apache.org, aka www.apache.org have both been upgraded to
2.3.0.
If anyone sees anything odd, please let me know.
Thanks,
Paul
Paul Querna wrote:
Test tarballs for Apache httpd 2.3.0-alpha are available at:
http://httpd.apache.org/dev/dist/
Your votes please;
±1
[ ] Release httpd-2.3.0 as Alpha
Vote closes at 7:00 UTC on Tuesday December 9 2008.
Thanks,
Paul
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
William A. Rowe, Jr. wrote: Paul Querna wrote: Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Tuesday December 9 2008. < 72 hours for a first alpha? Really sounds rushed to me, I may or may not have a chance to look at it in time. It was 72 hours form when I tagged it. /me shrugs. I'm not strongly stuck to it, if its controversial, we can extend it for a day, but I expect its either gonna work, or have fatal flaw, it is just an alpha after all :) -Paul
Re: [VOTE] Release Apache HTTP server 2.3.0-alpha
Paul Querna wrote: > > Your votes please; > > ±1 > [ ] Release httpd-2.3.0 as Alpha > > > Vote closes at 7:00 UTC on Tuesday December 9 2008. < 72 hours for a first alpha? Really sounds rushed to me, I may or may not have a chance to look at it in time.
[VOTE] Release Apache HTTP server 2.3.0-alpha
Test tarballs for Apache httpd 2.3.0-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Tuesday December 9 2008. Thanks, Paul
