Re: Syntax error during HTTP2 reload

["Dr. Peter Poeml" <po...@suse.de>]

On Tue, Mar 01, 2005 at 05:57:39AM -0500, Jeff Trawick wrote:
> On Tue, 1 Mar 2005 10:04:03 +0100, Henri Gomez <he...@gmail.com> wrote:
> > Nobody to wonder about this bug ?
> 
> sure; note that you're using old code (2.0.49/2.0.49) which isn't
> supported here anyway since we don't know what code is in it (SuSE)

(sorry about the late reply)

The apache shipped by SUSE is basically built from the pristine sources.
A package named 2.0.49 would contain exactly version 2.0.49, except for
- changes of configuration (I always complied 100% to the old license :)
- security fixes, which are added later (inevitably)
- and, since the codebase was relicensed under the Apache License 2.0
  and it is now allowed to do that, an occasional important fix from
  later released versions of the respective branch

> > > It's seems the problem occurs will Apache receive the SIGUSR1 and is
> > > also handling requests  (forwared to Tomcat via mod_jk 1.2.5 and
> > > 1.2.6).
> 
> the config parsing happens in the parent process, which shouldn't be
> impacted by active requests
> 
> seems fairly likely that there is memory corruption which occurs at
> restart time (a relatively common time to find out about such
> badness)...  I'd bet my money on it being caused by a module not
> distributed as part of Apache httpd...

I was not able to reproduce the problem but I wonder if the problem is
that the BrowserMatch directives are located in an unusual place in our
configuration. They are placed before the LoadModule statements. But
BrowserMatch is provided by the module mod_setenvif, so they should
probably be put after loading that module. However, I wonder why the
server does not error out about this on normal startup, but only during
the graceful restart, and only in rare setups.

Henri, did you ever try to move the BrowserMatch directives further down
in the config? (sorry if you alread did so, and my memory is just too
weak)

Peter

-- 
SUSE LINUX Products GmbH                 Thought is limitation.
Research & Development                   Free your mind.

Re: Syntax error during HTTP2 reload

[Jeff Trawick <tr...@gmail.com>]

On 6/8/05, Henri Gomez <he...@gmail.com> wrote:
> Nope, there are still in the usual location /etc/apache2/server-tuning.conf
> 
> I didn't understand the problem evocated by Jeff since the Apache

It is very simple: A user has a concern about the operation of the web
server and I want to try to help them.  What is the svn command to
extract the source of that web server so I can build the exact
version?  Or what is the httpd-xxx source tarball I can download so I
have the exact version?  I can't do either of these things.  Why? 
User isn't using our web server (strictly speaking).

What if I fix something and/or want user to try a patch?  They have to
use Apache for that to work.  I'm not going to interface with SuSE and
ask them to give the user a build of their web server with my patch to
see if it helps.  I'm not going to give you a patch for a server based
on something 5 revisions old so that you can work with SuSE (or source
RPM or whatever) to build the patch.

Support questions only make sense when the user talks to the people
that gave them the web server.  If you want we Apache folks to help,
use something you obtain from us.

Re: Syntax error during HTTP2 reload

[Henri Gomez <he...@gmail.com>]

Nope, there are still in the usual location /etc/apache2/server-tuning.conf

I didn't understand the problem evocated by Jeff since the Apache
server used in Suse is the one from the ASF (in contrario of IBM HTTP
Server powered by Apache found on iSeries and pSeries which derive
from ASF code but contains many specific code).

Suse us ASF source tarball, and ASF patches, so what's the problem ?

Suse only use a different configuration system but nothing special or
exotic, just a reworked and splitted configuration loaded with
include.

2005/6/8, Dr. Peter Poeml <po...@suse.de>:
> On Tue, Mar 01, 2005 at 05:57:39AM -0500, Jeff Trawick wrote:
> > On Tue, 1 Mar 2005 10:04:03 +0100, Henri Gomez <he...@gmail.com> wrote:
> > > Nobody to wonder about this bug ?
> >
> > sure; note that you're using old code (2.0.49/2.0.49) which isn't
> > supported here anyway since we don't know what code is in it (SuSE)
> 
> (sorry about the late reply)
> 
> The apache shipped by SUSE is basically built from the pristine sources.
> A package named 2.0.49 would contain exactly version 2.0.49, except for
> - changes of configuration (I always complied 100% to the old license :)
> - security fixes, which are added later (inevitably)
> - and, since the codebase was relicensed under the Apache License 2.0
>   and it is now allowed to do that, an occasional important fix from
>   later released versions of the respective branch
> 
> > > > It's seems the problem occurs will Apache receive the SIGUSR1 and is
> > > > also handling requests  (forwared to Tomcat via mod_jk 1.2.5 and
> > > > 1.2.6).
> >
> > the config parsing happens in the parent process, which shouldn't be
> > impacted by active requests
> >
> > seems fairly likely that there is memory corruption which occurs at
> > restart time (a relatively common time to find out about such
> > badness)...  I'd bet my money on it being caused by a module not
> > distributed as part of Apache httpd...
> 
> I was not able to reproduce the problem but I wonder if the problem is
> that the BrowserMatch directives are located in an unusual place in our
> configuration. They are placed before the LoadModule statements. But
> BrowserMatch is provided by the module mod_setenvif, so they should
> probably be put after loading that module. However, I wonder why the
> server does not error out about this on normal startup, but only during
> the graceful restart, and only in rare setups.
> 
> Henri, did you ever try to move the BrowserMatch directives further down
> in the config? (sorry if you alread did so, and my memory is just too
> weak)

Re: Syntax error during HTTP2 reload

[Henri Gomez <he...@gmail.com>]

Suse like many others major Linux distributions do not follow the
release rate since they should be sure that they won't break anything
in their users/customers settings after jumping from 2.0.49 to say
2.0.54.

To resume the question from Peter, who is the Suse Apache rpm
mainteners, was more to see if it was a known bug may be solved in
later release.

Regards 

2005/6/8, Bill Stoddard <bi...@wstoddard.com>:
> Dr. Peter Poeml wrote:
> > On Wed, Jun 08, 2005 at 10:08:35AM -0400, Jeff Trawick wrote:
> >
> >>On 6/8/05, Dr. Peter Poeml <po...@suse.de> wrote:
> >>
> >>>On Tue, Mar 01, 2005 at 05:57:39AM -0500, Jeff Trawick wrote:
> >>>
> >>>>On Tue, 1 Mar 2005 10:04:03 +0100, Henri Gomez <he...@gmail.com> wrote:
> >>>>
> >>>>>Nobody to wonder about this bug ?
> >>>>
> >>>>sure; note that you're using old code (2.0.49/2.0.49) which isn't
> >>>>supported here anyway since we don't know what code is in it (SuSE)
> >>>
> >>>(sorry about the late reply)
> >>>
> >>>The apache shipped by SUSE is basically built from the pristine sources.
> >>>A package named 2.0.49 would contain exactly version 2.0.49, except for
> >>>- changes of configuration (I always complied 100% to the old license :)
> >>>- security fixes, which are added later (inevitably)
> >>>- and, since the codebase was relicensed under the Apache License 2.0
> >>>  and it is now allowed to do that, an occasional important fix from
> >>>  later released versions of the respective branch
> >>
> >>I didn't mean to imply that there is anything at all wrong with taking
> >>pristine Apache sources and turning it into a product, with the
> >>ncessary modifications  (applying security fixes == modifying).  After
> >>all, that's a major part of the job that pays my mortgage.  There are
> >>a number of vendors who do this.
> >
> > [...]
> >
> > After I found your reply a bit puzzling at first, I think I understand
> > it now ;) I realize that I should add to my previous posting that I did
> > not mean to say that you should be expected to support vendor packages.
> > If it sounded like that, it wasn't my intention.
> >
> > It's just that you said you didn't know what code is in there, which
> > implied that there could be arbitrary modifications,
> 
> No, this is not the issue at all... Let me try to explain via an extreme example to make the point.
> 
> I can download Apache 2.0.32 from the subversion repository. Then I use 2.0.32, and randomly apply 73 patches
> that have gone into the source code repository between 2.0.32 and today (2.0.54). I complie that server and it
> has bugs. All the code in my Apache HTTP Server 2.0.32 + 73 patches is -all- available from the ASF. Would it
> be reasonable for me to expect this community to help me debug that server? Even if I tell the community which
> 73 patches I applied, is it still reasonable to expect this community to help me debug that server?  The
> answer is -no-, it is not reasonable.
> 
> To drive the point home a bit more deeply... What would you say if I told you that aside from two standalone
> modules (mod_ibm_ssl and mod_ibm_ldap) that all the other code in the core IBM HTTP Server (v2) is available
> from the ASF (either via the source code repository or the mailing list archives)?  Does that mean this
> community should be expected to help 'support' the "ASF portion" of IBM HTTP Server? Absoulutely not.
> 
> Bill (who's is happy you found the solution to your problem)
> 
>

Re: Syntax error during HTTP2 reload

[Bill Stoddard <bi...@wstoddard.com>]

Dr. Peter Poeml wrote:
> On Wed, Jun 08, 2005 at 10:08:35AM -0400, Jeff Trawick wrote:
> 
>>On 6/8/05, Dr. Peter Poeml <po...@suse.de> wrote:
>>
>>>On Tue, Mar 01, 2005 at 05:57:39AM -0500, Jeff Trawick wrote:
>>>
>>>>On Tue, 1 Mar 2005 10:04:03 +0100, Henri Gomez <he...@gmail.com> wrote:
>>>>
>>>>>Nobody to wonder about this bug ?
>>>>
>>>>sure; note that you're using old code (2.0.49/2.0.49) which isn't
>>>>supported here anyway since we don't know what code is in it (SuSE)
>>>
>>>(sorry about the late reply)
>>>
>>>The apache shipped by SUSE is basically built from the pristine sources.
>>>A package named 2.0.49 would contain exactly version 2.0.49, except for
>>>- changes of configuration (I always complied 100% to the old license :)
>>>- security fixes, which are added later (inevitably)
>>>- and, since the codebase was relicensed under the Apache License 2.0
>>>  and it is now allowed to do that, an occasional important fix from
>>>  later released versions of the respective branch
>>
>>I didn't mean to imply that there is anything at all wrong with taking
>>pristine Apache sources and turning it into a product, with the
>>ncessary modifications  (applying security fixes == modifying).  After
>>all, that's a major part of the job that pays my mortgage.  There are
>>a number of vendors who do this.
> 
> [...]
> 
> After I found your reply a bit puzzling at first, I think I understand
> it now ;) I realize that I should add to my previous posting that I did
> not mean to say that you should be expected to support vendor packages.
> If it sounded like that, it wasn't my intention.
> 
> It's just that you said you didn't know what code is in there, which
> implied that there could be arbitrary modifications,

No, this is not the issue at all... Let me try to explain via an extreme example to make the point.

I can download Apache 2.0.32 from the subversion repository. Then I use 2.0.32, and randomly apply 73 patches 
that have gone into the source code repository between 2.0.32 and today (2.0.54). I complie that server and it 
has bugs. All the code in my Apache HTTP Server 2.0.32 + 73 patches is -all- available from the ASF. Would it 
be reasonable for me to expect this community to help me debug that server? Even if I tell the community which 
73 patches I applied, is it still reasonable to expect this community to help me debug that server?  The 
answer is -no-, it is not reasonable.

To drive the point home a bit more deeply... What would you say if I told you that aside from two standalone 
modules (mod_ibm_ssl and mod_ibm_ldap) that all the other code in the core IBM HTTP Server (v2) is available 
from the ASF (either via the source code repository or the mailing list archives)?  Does that mean this 
community should be expected to help 'support' the "ASF portion" of IBM HTTP Server? Absoulutely not.

Bill (who's is happy you found the solution to your problem)

Re: Syntax error during HTTP2 reload

["Dr. Peter Poeml" <po...@suse.de>]

On Wed, Jun 08, 2005 at 10:08:35AM -0400, Jeff Trawick wrote:
> On 6/8/05, Dr. Peter Poeml <po...@suse.de> wrote:
> > On Tue, Mar 01, 2005 at 05:57:39AM -0500, Jeff Trawick wrote:
> > > On Tue, 1 Mar 2005 10:04:03 +0100, Henri Gomez <he...@gmail.com> wrote:
> > > > Nobody to wonder about this bug ?
> > >
> > > sure; note that you're using old code (2.0.49/2.0.49) which isn't
> > > supported here anyway since we don't know what code is in it (SuSE)
> > 
> > (sorry about the late reply)
> > 
> > The apache shipped by SUSE is basically built from the pristine sources.
> > A package named 2.0.49 would contain exactly version 2.0.49, except for
> > - changes of configuration (I always complied 100% to the old license :)
> > - security fixes, which are added later (inevitably)
> > - and, since the codebase was relicensed under the Apache License 2.0
> >   and it is now allowed to do that, an occasional important fix from
> >   later released versions of the respective branch
> 
> I didn't mean to imply that there is anything at all wrong with taking
> pristine Apache sources and turning it into a product, with the
> ncessary modifications  (applying security fixes == modifying).  After
> all, that's a major part of the job that pays my mortgage.  There are
> a number of vendors who do this.
[...]

After I found your reply a bit puzzling at first, I think I understand
it now ;) I realize that I should add to my previous posting that I did
not mean to say that you should be expected to support vendor packages.
If it sounded like that, it wasn't my intention.

It's just that you said you didn't know what code is in there, which
implied that there could be arbitrary modifications, but this is not the
case, which is why I'm confident that the bug that Henri saw would occur
with a tarball from apache.org just as well. However, digging deeper in
my mailbox I just found a later mail from Henri and it looks as if the
problem disappeared in a later version (2.0.53). So it seems the problem
was solved already. (Sorry about the confusion. Still catching up.)

Thanks,
Peter

-- 
SUSE LINUX Products GmbH                 Thought is limitation.
Research & Development                   Free your mind.

Re: Syntax error during HTTP2 reload

[Jeff Trawick <tr...@gmail.com>]

On 6/8/05, Dr. Peter Poeml <po...@suse.de> wrote:
> On Tue, Mar 01, 2005 at 05:57:39AM -0500, Jeff Trawick wrote:
> > On Tue, 1 Mar 2005 10:04:03 +0100, Henri Gomez <he...@gmail.com> wrote:
> > > Nobody to wonder about this bug ?
> >
> > sure; note that you're using old code (2.0.49/2.0.49) which isn't
> > supported here anyway since we don't know what code is in it (SuSE)
> 
> (sorry about the late reply)
> 
> The apache shipped by SUSE is basically built from the pristine sources.
> A package named 2.0.49 would contain exactly version 2.0.49, except for
> - changes of configuration (I always complied 100% to the old license :)
> - security fixes, which are added later (inevitably)
> - and, since the codebase was relicensed under the Apache License 2.0
>   and it is now allowed to do that, an occasional important fix from
>   later released versions of the respective branch

I didn't mean to imply that there is anything at all wrong with taking
pristine Apache sources and turning it into a product, with the
ncessary modifications  (applying security fixes == modifying).  After
all, that's a major part of the job that pays my mortgage.  There are
a number of vendors who do this.

What I wanted to point out is that SuSE's web server based on Apache
is supported by SuSE, not by Apache HTTP project.  Just like:

* RedHat's server based on Apache is supported by RedHat
* IBM's server based on Apache is supported by IBM
* HP's server based on Apache is supported by HP
* etc. etc.

Whenever somebody starts asking detailed questions/reporting bugs
against an Apache-based server that has been modified by a third
party, we defer to that third party.  There is no consideration of 
exactly what got modified (e.g., "Foo Systems only adds patches from
later Apache 2.0.x releases, so we Apache folks can offer support to
users of their 2.0.47-based server without any concerns"  vs. "Bar
Systems has some unique function in their 2.0.47-based server so we'll
refuse to support it."  We are a volunteer group with little time to
spare, and we simply can't deal with anything other than the exact
software package which we deliver.

The vendor can choose to discuss with us in terms of pure Apache on
behalf of that customer's requirement, or tell their customer to
reproduce with pure Apache and do it themselves.