You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Kraemer <Ma...@Fujitsu-Siemens.com> on 2001/01/25 21:43:10 UTC
Flame bait: Apache-2.0 on Unix is almost unusable.
Hi everyone,
A bit frustrating it is to me that so much time has been spent on
Apache 2.0, rearranging, writing, discussing, patching to and fro,
but the basic and most important problems have not been addressed
in quite a while. To me, that code is definitely NOT Beta quality.
On the computer fair "SYSTEMS 2000" last october, we had an apache booth,
and on the machine we had there, I tried to compile apache-2.0a7 on Linux.
No problem, but when I ran it, and did some tests, it failed so miserably
that I decided not to show it to any of the Apache "customers".
Now I spent an evening on re-checking the current status (2 Alpha versions
have been published in the meantime), but the obvious errors I noticed
back then have not changed a bit!
a) fatal protocol errors, leading to the browser hanging and waiting
forever.
b) extra header output, leading to a garbled "It works" page which shows
everyone at the first glance that this is ALPHA code.
c) Intolerable behavior when trying to stop or restart the server to
have it reread its configuration files.
Even though (almost) all discussions on new-httpd circle on the philosophies
behind the next incompatible API change for Apache-2.0, nobody apparently
even noticed these bugs, which I observed on Linux just as well as on FreeBSD
after minutes of using Apache 2.0.
The STATUS file does mumble a bit about mod_negotiation, but does not
list the fatal behavior as a SHOWSTOPPER, which -to me, at least- it is.
Martin
Here's my observations:
== Result of Apache-2.0b1-dev tests on 25-jan-2001, (platform FreeBSD4.2) ==
* When I access Apache/2.0b1-dev, I see duplicate header lines, like in:
% echo GET http://apache.mch.fsc.net:8007/ HTTP/1.0\\n | nc localhost 8007
HTTP/1.1 200 OK
Date: Thu, 25 Jan 2001 19:29:35 GMT
Server: Apache/2.0b1-dev (Unix)
Content-Location: index.html.en
Vary: negotiate,accept-language,accept-charset
TCN: choice
Last-Modified: Sat, 20 Jan 2001 02:01:20 GMT
ETag: "1588a-51f-ce0b3c00;ecb9dd00"
Accept-Ranges: bytes
Content-Length: 1311
Connection: close
Content-Type: Accept-Ranges: bytes
Content-Length: 1311 <---------?!??!!
Connection: close <---------?!??!!
Content-Language: en <---------?!??!!
Expires: ngth: 1311 <---------!??!?!!!!!!!!!!!
Connection: close <---------?!??!!
Content-Type: Accept-Ranges: bytes <---------?!??!!
Content-Length: 1311 <---------?!??!!
Connection: close <---------?!??!!
<---------?!??!!
Content-Language: en <---------?!??!!
<---------?!??!!
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Test Page for Apache Installation</TITLE>
</HEAD>
...
* Interestingly, this mangled header does NOT appear when mod_negotiation
is bypassed: retrieving "/index.html.de" works, but "/" does not. So this
is a problem caused by mod_negotiation.
* When trying to gracefully restart the server, something hangs.
A subsequent "apachectl stop" says "httpd stopped", yet the monitor process
keeps respawning client processes. Even a "kill -TERM" does not help.
The only way to recover is a manual "kill -9".
* The processes do not even react on -HUP, -TERM, -SEGV
-- what the f§$! is going on?
* When retrieving /manual/mod/core.html (97kB), I notice that the file
looks truncated. However, when doing:
% echo GET http://apache.mch.fsc.net:8007/manual/mod/core.html \
sed -n '/^</,$p' | tail +2 > tmp.html
% cmp tmp.html manual/mod/core.html
tmp.html manual/mod/core.html differ: char 16385, line 438 <--------!!!!
Astonishing that a difference should occur so close to a 16kB boundary...
And a diff gives me:
% diff tmp.html core.html | head -20
438,452c438,508
< of that director<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
< <HTML>
< <HEAD>
< <TITLE>Apache Core Features</TITLE>
< </HEAD>
<
< <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
< <BODY
< BGCOLOR="#FFFFFF"
< TEXT="#000000"
< LINK="#0000FF"
< VLINK="#000080"
< ALINK="#FF0000"
< >
< <!--#include virtual="header.html" -->
---
> of that directory. Any directive which is allowed in a directory
> context may be used. <EM>Directory</EM> is either the full path to a directory,
> or a wild-card string. In a wild-card string, `?' matches any single character
Look at the garbled file, repeating part of the beginning.
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Jeff Trawick <tr...@bellsouth.net>.
Jeff Trawick <tr...@bellsouth.net> writes:
> Martin Kraemer <Ma...@Fujitsu-Siemens.com> writes:
>
> > a) fatal protocol errors, leading to the browser hanging and waiting
> > forever.
>
> tell me what data to send to httpd to reproduce
okay, I'm an idiot... I shouldn't try to read new-httpd and talk on
the phone and send signals to my daughter that she needs to be quiet
for a sec at the same time... I see now that after "Martin" and a
blank line was documentation; please ignore me for now...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Thu, Jan 25, 2001 at 04:23:29PM -0500, Jeff Trawick wrote:
> Martin Kraemer <Ma...@Fujitsu-Siemens.com> writes:
>
> > a) fatal protocol errors, leading to the browser hanging and waiting
> > forever.
>
> tell me what data to send to httpd to reproduce
Ehmmm. difficult... Maybe a follow-up on a keepalive connection which
got the mangled headers? Then the message body is too long, and the
next reply won't parse.
> > b) extra header output, leading to a garbled "It works" page which shows
> > everyone at the first glance that this is ALPHA code.
>
> this started in the last 36 hours or so
No, I observed it last october already.
> > c) Intolerable behavior when trying to stop or restart the server to
> > have it reread its configuration files.
>
> you aren't sending signals to a threaded server which interfere with
> the thread package on Linux, are you?
Only the lethal -KILL at the end. No, I tried to use apachectl for everything,
but the monitor process kept running (and apparently forking new processes).
My load average went from 0.x up to 12.x
> > Even though (almost) all discussions on new-httpd circle on the philosophies
> > behind the next incompatible API change for Apache-2.0, nobody apparently
> > even noticed these bugs, which I observed on Linux just as well as on FreeBSD
> > after minutes of using Apache 2.0.
>
> I guess we need you then :)
Yes, and I am very sad that I could give so little time to the httpd project(s)
lately. Work wouldn't permit.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Sascha Schumann <sa...@schumann.cx>.
> IMHO, the apache group has no right to force somebody to upgrade their
> OS. There are many vulnerable platforms out there, and we can't take
> responsability for forcing people to get off of them.
Well, I advocated giving users an incentive to do something
for their own advantage. By explicitly supporting systems
which are known to be a security risk, we deliberately
encourage users to continue running such systems.
Anyway, I don't want to drag out this discussion further.
- Sascha
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Tony Finch" <do...@dotat.at>
Sent: Friday, January 26, 2001 5:47 PM
> James Sutherland <ja...@cam.ac.uk> wrote:
> >
> >A warning would be nice, though - "Warning: Your current kernel is
> >vulnerable to <foo> attacks. For security reasons, you should upgrade to
> >at least kernel version <bar>."
>
> It is not an HTTP daemon's job to track and report security vulnerabilities.
Worse yet ... this opens us up to 'liability' - although in the strictest sense
we disclaim all liability in the server. Commercial vendors and rpm distributors
are possibly a different matter.
The question comes like this ... "You warn about foo, bar, and bat vulnerabilities,
but you didn't warn me before my system was hacked through the much older ugh hole."
If we take on this job, we take it all on, or we walk away from it. We can always
advise against specific kernels/clibs/configurations in the readme, or even in the
configurator, but if we are going to 'audit' their system for security do it right,
or don't do it at all.
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 26 Jan 2001, Tony Finch wrote:
> James Sutherland <ja...@cam.ac.uk> wrote:
> >
> >A warning would be nice, though - "Warning: Your current kernel is
> >vulnerable to <foo> attacks. For security reasons, you should upgrade to
> >at least kernel version <bar>."
>
> It is not an HTTP daemon's job to track and report security vulnerabilities.
Of course it is not. The whole point of the discussion was
that we are spending time to make Apache work on platforms
which are known to be vulnerable to all kind of attacks. And
that is IMO quite pointless.
- Sascha
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by James Sutherland <ja...@cam.ac.uk>.
On Fri, 26 Jan 2001, Tony Finch wrote:
> James Sutherland <ja...@cam.ac.uk> wrote:
> >
> >A warning would be nice, though - "Warning: Your current kernel is
> >vulnerable to <foo> attacks. For security reasons, you should upgrade to
> >at least kernel version <bar>."
>
> It is not an HTTP daemon's job to track and report security vulnerabilities.
No, of course not. However, someone was suggesting forcing those platforms
to be upgraded, just to run Apache. This is certainly not desirable; as
rbb and I pointed out, what about isolated machines for testing purposes,
for example?
I think warning those installing on OLD platforms would be
reasonable. I'm not suggesting building in a vulnerabilities database,
just warning people using glibc 2.0 or whatever that it's not secure.
James.
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Tony Finch <do...@dotat.at>.
James Sutherland <ja...@cam.ac.uk> wrote:
>
>A warning would be nice, though - "Warning: Your current kernel is
>vulnerable to <foo> attacks. For security reasons, you should upgrade to
>at least kernel version <bar>."
It is not an HTTP daemon's job to track and report security vulnerabilities.
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"There are flying saucers. There's no doubt they are
in our skies. They've been there for some time."
RE: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by James Sutherland <ja...@cam.ac.uk>.
On Fri, 26 Jan 2001, Jeffrey A. Stuart wrote:
> Why not? IMHO Apache should set a good example as a net neighbor and
> "force" a base system. If that means for Linux, a recent kernel and a
> recent version of glibc, so be it! You are already requiring certain things
> to be on the system... (IE a C compiler, etc) So go a step further and
> require a relatively secure system...
Where Apache can run on an older system, though, I'd like it to work. Not
everything is a production server: I might well want to put 2.0 on an old
machine I have lying around at home, just for test purposes. I'm not
necessarily bothered about buffer overflows etc. - if it's at home, for
my use only, nobody will even be able to get packets to it!
A warning would be nice, though - "Warning: Your current kernel is
vulnerable to <foo> attacks. For security reasons, you should upgrade to
at least kernel version <bar>." Just don't stop me running tests on old
hardware/software unnecessarily.
Obviously, I don't expect to be able to install on a 386 running Minix,
but as long as the platform has the features needed to run, why not let it
do so?
James.
RE: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by rb...@covalent.net.
We do not require that a user have anything on their system. Other than
an Operating System with a TCP stack. You only need a compiler if you
want to build Apache.
Think of it this way. What if I am running a web server in a secure
environment (my house, behind a firewall), and it is running on a linux
box with a 2.2.1 kernel, and an old glibc. I am forced to run that
version, because of some hacks that I have in my kernel that I don't have
time to port to a later version. Why can't I run Apache 2.0 on that
machine?
The Apache group shouldn't be telling competant people how to do their
jobs IMHO.
Ryan
On Fri, 26 Jan 2001, Jeffrey A. Stuart wrote:
> Why not? IMHO Apache should set a good example as a net neighbor and
> "force" a base system. If that means for Linux, a recent kernel and a
> recent version of glibc, so be it! You are already requiring certain things
> to be on the system... (IE a C compiler, etc) So go a step further and
> require a relatively secure system...
>
> --
> Jeff Stuart
> jstuart@neo.rr.com
>
> -----Original Message-----
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Friday, January 26, 2001 10:53 AM
> To: Sascha Schumann
> Cc: rbb@covalent.net; new-httpd@apache.org; Jeff Trawick
> Subject: Re: Flame bait: Apache-2.0 on Unix is almost unusable.
>
>
> > > Since (I believe) we were on a 2.2 kernel at the time, and an
> > > up-to-date glibc (for that time), I would prefer if Apache
> > > didn't just assume that everybody has upgraded.
> >
> > If they did not upgrade, they are subject to many remote
> > attacks. Those attacks can at least crash the whole system,
> > possibly allowing the attacker to take over the system. I
> > think we should encourage people to use more recent software,
> > instead of continuing to support dangerous releases. If
> > Apache 2.0 is installed on such a system and that system is
> > broken into, it might as well generate bad PR for Apache
> > (this happened recently to thttpd where compatibility was
> > rated higher than security).
>
> IMHO, the apache group has no right to force somebody to upgrade their
> OS. There are many vulnerable platforms out there, and we can't take
> responsability for forcing people to get off of them.
>
> Ryan
>
> ____________________________________________________________________________
> ___
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> ----------------------------------------------------------------------------
> ---
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by "Jeffrey A. Stuart" <js...@neo.rr.com>.
Why not? IMHO Apache should set a good example as a net neighbor and
"force" a base system. If that means for Linux, a recent kernel and a
recent version of glibc, so be it! You are already requiring certain things
to be on the system... (IE a C compiler, etc) So go a step further and
require a relatively secure system...
--
Jeff Stuart
jstuart@neo.rr.com
-----Original Message-----
From: rbb@covalent.net [mailto:rbb@covalent.net]
Sent: Friday, January 26, 2001 10:53 AM
To: Sascha Schumann
Cc: rbb@covalent.net; new-httpd@apache.org; Jeff Trawick
Subject: Re: Flame bait: Apache-2.0 on Unix is almost unusable.
> > Since (I believe) we were on a 2.2 kernel at the time, and an
> > up-to-date glibc (for that time), I would prefer if Apache
> > didn't just assume that everybody has upgraded.
>
> If they did not upgrade, they are subject to many remote
> attacks. Those attacks can at least crash the whole system,
> possibly allowing the attacker to take over the system. I
> think we should encourage people to use more recent software,
> instead of continuing to support dangerous releases. If
> Apache 2.0 is installed on such a system and that system is
> broken into, it might as well generate bad PR for Apache
> (this happened recently to thttpd where compatibility was
> rated higher than security).
IMHO, the apache group has no right to force somebody to upgrade their
OS. There are many vulnerable platforms out there, and we can't take
responsability for forcing people to get off of them.
Ryan
____________________________________________________________________________
___
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
----------------------------------------------------------------------------
---
RE: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by "Peter J. Cranstone" <cr...@remotecommunications.com>.
> IMHO, the apache group has no right to force somebody to upgrade their
> OS. There are many vulnerable platforms out there, and we can't take
> responsibility for forcing people to get off of them.
+1 Ryan you are 100% correct. Apache 2.0 is a fundamental shift in design
from the 1.x series. You have >10 million users out there with almost every
imaginable combination OS/hardware plus a million personal hacks on the
code. They will not change overnight. Testing of Apache 2.0 will consume an
incredible amount of time, probably years, why?, because it's not a simple
upgrade and the world has changed while it's been in development.
Apache 2.0 has grown into a major release and needs to be coordinated
carefully. You must (IMHO) manage the expectation level and not cause
"whiplash" to the installed base. I think Roy was right in his recent emails
regarding release stats. I would add one more thing. You must (again my
opinion) release on a system which you have tested personally. By that I
mean you show everyone *your* config and your *OS* etc.
Apache 2.0 will be big, eventually, but it has many miles to go before that
happens. Little steps will turn into big ones, but only if you manage the
expectation level.
... Peter
-----Original Message-----
From: rbb@covalent.net [mailto:rbb@covalent.net]
Sent: Friday, January 26, 2001 8:53 AM
To: Sascha Schumann
Cc: rbb@covalent.net; new-httpd@apache.org; Jeff Trawick
Subject: Re: Flame bait: Apache-2.0 on Unix is almost unusable.
> > Since (I believe) we were on a 2.2 kernel at the time, and an
> > up-to-date glibc (for that time), I would prefer if Apache
> > didn't just assume that everybody has upgraded.
>
> If they did not upgrade, they are subject to many remote
> attacks. Those attacks can at least crash the whole system,
> possibly allowing the attacker to take over the system. I
> think we should encourage people to use more recent software,
> instead of continuing to support dangerous releases. If
> Apache 2.0 is installed on such a system and that system is
> broken into, it might as well generate bad PR for Apache
> (this happened recently to thttpd where compatibility was
> rated higher than security).
IMHO, the apache group has no right to force somebody to upgrade their
OS. There are many vulnerable platforms out there, and we can't take
responsability for forcing people to get off of them.
Ryan
____________________________________________________________________________
___
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
----------------------------------------------------------------------------
---
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by rb...@covalent.net.
> > Since (I believe) we were on a 2.2 kernel at the time, and an
> > up-to-date glibc (for that time), I would prefer if Apache
> > didn't just assume that everybody has upgraded.
>
> If they did not upgrade, they are subject to many remote
> attacks. Those attacks can at least crash the whole system,
> possibly allowing the attacker to take over the system. I
> think we should encourage people to use more recent software,
> instead of continuing to support dangerous releases. If
> Apache 2.0 is installed on such a system and that system is
> broken into, it might as well generate bad PR for Apache
> (this happened recently to thttpd where compatibility was
> rated higher than security).
IMHO, the apache group has no right to force somebody to upgrade their
OS. There are many vulnerable platforms out there, and we can't take
responsability for forcing people to get off of them.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Sascha Schumann <sa...@schumann.cx>.
> Since (I believe) we were on a 2.2 kernel at the time, and an
> up-to-date glibc (for that time), I would prefer if Apache
> didn't just assume that everybody has upgraded.
If they did not upgrade, they are subject to many remote
attacks. Those attacks can at least crash the whole system,
possibly allowing the attacker to take over the system. I
think we should encourage people to use more recent software,
instead of continuing to support dangerous releases. If
Apache 2.0 is installed on such a system and that system is
broken into, it might as well generate bad PR for Apache
(this happened recently to thttpd where compatibility was
rated higher than security).
- Sascha
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by rb...@covalent.net.
> > > c) Intolerable behavior when trying to stop or restart the server to
> > > have it reread its configuration files.
> >
> > you aren't sending signals to a threaded server which interfere with
> > the thread package on Linux, are you?
>
> Just to clear up some confusion: There are no standard
> signals which interfere with the Linuxthreads package, if you
> are running a kernel which was released during the last two
> years (that is Linux 2.2 and later) and if you are using a C
> library released during the last three years.
In February of 99, this bug bit us, so we made the change. Since (I
believe) we were on a 2.2 kernel at the time, and an up-to-date glibc (for
that time), I would prefer if Apache didn't just assume that everybody has
upgraded.
Also, there are other platforms that dislike mixing threads and signals.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Sascha Schumann <sa...@schumann.cx>.
> > c) Intolerable behavior when trying to stop or restart the server to
> > have it reread its configuration files.
>
> you aren't sending signals to a threaded server which interfere with
> the thread package on Linux, are you?
Just to clear up some confusion: There are no standard
signals which interfere with the Linuxthreads package, if you
are running a kernel which was released during the last two
years (that is Linux 2.2 and later) and if you are using a C
library released during the last three years.
- Sascha
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Jeff Trawick <tr...@bellsouth.net>.
Martin Kraemer <Ma...@Fujitsu-Siemens.com> writes:
> a) fatal protocol errors, leading to the browser hanging and waiting
> forever.
tell me what data to send to httpd to reproduce
> b) extra header output, leading to a garbled "It works" page which shows
> everyone at the first glance that this is ALPHA code.
this started in the last 36 hours or so
> c) Intolerable behavior when trying to stop or restart the server to
> have it reread its configuration files.
you aren't sending signals to a threaded server which interfere with
the thread package on Linux, are you?
> Even though (almost) all discussions on new-httpd circle on the philosophies
> behind the next incompatible API change for Apache-2.0, nobody apparently
> even noticed these bugs, which I observed on Linux just as well as on FreeBSD
> after minutes of using Apache 2.0.
I guess we need you then :)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> b) extra header output, leading to a garbled "It works" page which shows
> everyone at the first glance that this is ALPHA code.
I reported this bug this morning which reignited the API discussion. Jeff has
posted a patch for this.
Bill
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by jean-frederic clere <jf...@fujitsu.siemens.es>.
rbb@covalent.net wrote:
>
> > > Some of the bugs may be the platform you are on, especially if you are
> > > using threads. That doesn't mean FreeBSD doesn't support Apache 2.0, but
> > > FreeBSD has some known problems with threads and some functions, so we are
> > > trying our best to work around those problems, and many of these problems
> > > may go away if you use the prefork MPM.
> >
> > Thanks -- will try!
>
> The big thing I am thinking of, is the truncated file. This is a known
> problem when using sendfile with some versions of FreeBSD. I thought we
> had tracked them all down, but this may be another version that needs to
> be hacked into configure.in. :-)
The page I got on LINUX is also corrupted - As I use 2.4.0 and some old
libc. It could be a similar problem, I will try with other Kernels to
check this.
>
> Thanks for the good info Martin.
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by rb...@covalent.net.
> > Some of the bugs may be the platform you are on, especially if you are
> > using threads. That doesn't mean FreeBSD doesn't support Apache 2.0, but
> > FreeBSD has some known problems with threads and some functions, so we are
> > trying our best to work around those problems, and many of these problems
> > may go away if you use the prefork MPM.
>
> Thanks -- will try!
The big thing I am thinking of, is the truncated file. This is a known
problem when using sendfile with some versions of FreeBSD. I thought we
had tracked them all down, but this may be another version that needs to
be hacked into configure.in. :-)
Thanks for the good info Martin.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Thu, Jan 25, 2001 at 10:04:58PM +0100, rbb@covalent.net wrote:
> Thank you for the
> reports. If you have the time to get more information, please do so.
Sorry, I noticed too late that the mod_negotiation bug already appeared
on the list.
> At
> the very least, can we get the configuration you used?
Plain vanilla. "configure --prefix=/somewhere", make, make install.
Only changed the port# and prepared for activating modules later:
diff httpd-std.conf httpd.conf
209c209
< Port 80
---
> Port 8007
231c231
< ServerAdmin you@your.address
---
> ServerAdmin WebMaster+Apache2.0@deejai.mch.fsc.net
306c306
< UserDir public_html
---
> UserDir WWW
312,323c312,323
< #<Directory /home/*/public_html>
< # AllowOverride FileInfo AuthConfig Limit
...
< #</Directory>
---
> <Directory /home/*/WWW>
> AllowOverride FileInfo AuthConfig Limit
...
> </Directory>
467c467
< ServerSignature On
---
> ServerSignature EMail
755,756c755,756
< #AddType text/html .shtml
< #AddHandler server-parsed .shtml
---
> AddType text/html .shtml
> AddHandler server-parsed .shtml
843,844c843,844
< #<Location /server-status>
< # SetHandler server-status
---
> <Location /server-status>
> SetHandler server-status
848c848
< #</Location>
---
> </Location>
855,856c855,856
< #<Location /server-info>
< # SetHandler server-info
---
> <Location /server-info>
> SetHandler server-info
860c860
< #</Location>
---
> </Location>
> Some of the bugs may be the platform you are on, especially if you are
> using threads. That doesn't mean FreeBSD doesn't support Apache 2.0, but
> FreeBSD has some known problems with threads and some functions, so we are
> trying our best to work around those problems, and many of these problems
> may go away if you use the prefork MPM.
Thanks -- will try!
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by rb...@covalent.net.
> * When trying to gracefully restart the server, something hangs.
> A subsequent "apachectl stop" says "httpd stopped", yet the monitor process
> keeps respawning client processes. Even a "kill -TERM" does not help.
> The only way to recover is a manual "kill -9".
I have not seen this, but will investigate it.
> * The processes do not even react on -HUP, -TERM, -SEGV
> -- what the f�$! is going on?
This is by design. On some OS's, linux mainly, threads and signals do not
play nicely. This means that rather than even try to deal with most
signals, we use a pipe to communicate between the parent and the child
process.
Martin, please understand that we are working at finding and fixing many
of these bugs. Some of these have been reported before, some are new
since yesterday, and some have never been seen before. Thank you for the
reports. If you have the time to get more information, please do so. At
the very least, can we get the configuration you used?
Some of the bugs may be the platform you are on, especially if you are
using threads. That doesn't mean FreeBSD doesn't support Apache 2.0, but
FreeBSD has some known problems with threads and some functions, so we are
trying our best to work around those problems, and many of these problems
may go away if you use the prefork MPM.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 25, 2001 at 09:52:41PM +0000, James Sutherland wrote:
> On Thu, 25 Jan 2001 rbb@covalent.net wrote:
> > >
> > > Right now, 2.0 doesn't look ready for an alpha, let alone a beta. Is
> > > anyone looking at the broken header problem yet???
> >
> > Not only are we looking at it, but we have a potential solution, and we
> > are discussing long term fixes.
>
> OK - sorry to be so blunt, but I posted a transcript showing that problem
> some time ago, and nobody even mentioned it in their replies!
Because there is only so much that we can do, and only so much that we can
keep track of. If you posted it, then I either didn't see it or I've
forgotten about it.
-g
--
Greg Stein, http://www.lyra.org/
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by James Sutherland <ja...@cam.ac.uk>.
On Thu, 25 Jan 2001 rbb@covalent.net wrote:
> >
> > Right now, 2.0 doesn't look ready for an alpha, let alone a beta. Is
> > anyone looking at the broken header problem yet???
>
> Not only are we looking at it, but we have a potential solution, and we
> are discussing long term fixes.
OK - sorry to be so blunt, but I posted a transcript showing that problem
some time ago, and nobody even mentioned it in their replies!
James.
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by rb...@covalent.net.
>
> Right now, 2.0 doesn't look ready for an alpha, let alone a beta. Is
> anyone looking at the broken header problem yet???
Not only are we looking at it, but we have a potential solution, and we
are discussing long term fixes.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Flame bait: Apache-2.0 on Unix is almost unusable.
Posted by James Sutherland <ja...@cam.ac.uk>.
Correction to subject: As of last night, CVS httpd-2.0 is unbuildable,
never mind unusable :-)
On Thu, 25 Jan 2001, Martin Kraemer wrote:
> A bit frustrating it is to me that so much time has been spent on
> Apache 2.0, rearranging, writing, discussing, patching to and fro,
> but the basic and most important problems have not been addressed
> in quite a while. To me, that code is definitely NOT Beta quality.
Agreed.
(snip)
> a) fatal protocol errors, leading to the browser hanging and waiting
> forever.
> b) extra header output, leading to a garbled "It works" page which shows
> everyone at the first glance that this is ALPHA code.
Alpha code? From the output, it sometimes looks like Alpha code running on
x86! :-)
(snip report about duplicated headers, which I've also mentioned before)
Yep; I've seen two (DIFFERENT) headers at once, too; one 200 OK, followed
by the whole set of headers, then another 200 OK, and SOME of those
headers again - WTF?!
(snip)
Right now, 2.0 doesn't look ready for an alpha, let alone a beta. Is
anyone looking at the broken header problem yet???
James.