Support for Apache HTTPD 2.4

RESOLVED FIXED in Bugzilla 4.4

Status

()

Bugzilla
Installation & Upgrading
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Jochen Wiedmann, Assigned: Jochen Wiedmann)

Tracking

4.4.6
Bugzilla 4.4
x86_64
Windows 7
Dependency tree / graph
Bug Flags:
approval +
approval5.0 +
blocking5.0 +
approval4.4 +
blocking4.4.9 +

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

2 years ago
I failed to get Bugzilla working on Apache HTTPD 2.4.

Did all steps (Web server, Database, Perl, Modules) as I did in the past. However, when I pointed my browser to index.cgi, I've got an HTTP error 403, because my IP address (127.0.0.1) was blocked.

For details on the necessary configuration changes, see

  http://httpd.apache.org/docs/2.4/upgrading.html#run-time
Assuming I get the tuits, I'll go over the docs and square them with reality.
Status: UNCONFIRMED → NEW
Ever confirmed: true
My docker containers are using Centos7 and apache 2.4 without issue once you make a couple of small tweaks:

https://github.com/dklawren/docker-bugzilla

The main one is to use "Require all granted" in the conf file:

https://github.com/dklawren/docker-bugzilla/blob/master/bugzilla.conf

Another less critical difference (a plus) is that I can designate "User" and "Group" in the site specific conf file where with 2.2 I had to grep/replace in the main httpd.conf.

dkl

Comment 3

2 years ago
I use Bugzilla together with HTTPD 2.4 for a long time without problems.
(Assignee)

Comment 4

2 years ago
Created attachment 8549421 [details] [diff] [review]
Filesystem.patch

Suggested solution. General idea: Checksetup.pl will generate sections like

  <IfVersion <= 2.2>
    # Old Version
    allow from all
  </IfVersion>
  <IfVersion > 2.2>
    # New Version
    require all granted
  </IfVersion>

I haven't covered the docs, but they might be changed accordingly.
Attachment #8549421 - Flags: review?
Attachment #8549421 - Flags: feedback?
(Assignee)

Comment 5

2 years ago
(In reply to David Lawrence [:dkl] from comment #2)

> The main one is to use "Require all granted" in the conf file:

Personally, I find the generated .htaccess files much more important, since there are so many of them. See my proposed patch.

(In reply to Frederic Buclin from comment #3)

> I use Bugzilla together with HTTPD 2.4 for a long time without problems.

Davids comment (see above) confirms, that there is a problem. Apparently it isn't exposed on every 2.4 installation. However, I found it to be present on at least two independent, and fresh, installations, one on Windows 7, and one on Fedora 21.
(Assignee)

Updated

2 years ago
Version: unspecified → 4.4.6
(Assignee)

Updated

2 years ago
Attachment #8549421 - Flags: review?(dkl)
Attachment #8549421 - Flags: review?
Attachment #8549421 - Flags: feedback?(LpSolit)
Attachment #8549421 - Flags: feedback?
(Assignee)

Updated

2 years ago
Flags: blocking5.0?
Flags: blocking4.4.7?
Comment on attachment 8549421 [details] [diff] [review]
Filesystem.patch

Review of attachment 8549421 [details] [diff] [review]:
-----------------------------------------------------------------

Make a patch for master branch first (then the stable branches after r+) which this fails to apply to:

patching file Bugzilla/Install/Filesystem.pm
Hunk #1 succeeded at 47 (offset 4 lines).
Hunk #2 succeeded at 345 (offset 11 lines).
Hunk #3 FAILED at 357.
Hunk #4 succeeded at 378 with fuzz 1 (offset 11 lines).
1 out of 4 hunks FAILED -- saving rejects to file Bugzilla/Install/Filesystem.pm.rej

Also does Apache enabled mod_version by default? Maybe we should be cautious and do

<IfModule mod_version.c>
  <IfVersion <= 2.2>
     Deny from all
  </IfVersion>
  <IfVersion > 2.2>
    Require all denied
  </IfVersion>
</IfModule>

::: Bugzilla/Install/Filesystem.pm.orig
@@ +47,5 @@
> +  deny from all
> +</IfVersion>
> +<IfVersion > 2.2>
> +  require all denied
> +</IfVersion>   

Remove all trailing whitespace
Attachment #8549421 - Flags: review?(dkl) → review-

Comment 7

2 years ago
Comment on attachment 8549421 [details] [diff] [review]
Filesystem.patch

>+<IfVersion <= 2.2>
>+  deny from all
>+</IfVersion>
>+<IfVersion > 2.2>
>+  require all denied
>+</IfVersion>   

Just to match the Apache documentation, please write 'Require' instead of 'require'.


>+  Require all granted>

Remove the trailing >.


> # if research.att.com ever changes their IP, or if you use a different
> # webdot server, you'll need to edit this
> <FilesMatch \\.dot\$>
>+<IfVersion <= 2.2>					
>   Allow from 192.20.225.0/24
>   Deny from all
>+</IfVersion>
>+<IfVersion > 2.2>
>+  Require ip 192.20.225.0/24
>+</IfVersion>
> </FilesMatch>

AFAICS, this IP address is no longer correct. It's 204.178.8.30, right? Moreover, their webdot script is no longer available, so this should simply go away.


Moreover, I have the same concern as dkl about mod_version. Are we sure it's enabled by default, for both HTTPD 2.2 and 2.4? I didn't test your patch yet, but will existing .htaccess files be updated to use this new code, or will this only apply to new installations?
Attachment #8549421 - Flags: feedback?(LpSolit) → feedback-
(Assignee)

Comment 8

2 years ago
(In reply to David Lawrence [:dkl] from comment #6)

> Make a patch for master branch first (then the stable branches after r+)
> which this fails to apply to:

Understood. I'll do that. Sorry, that I didn't do at first go.


> Also does Apache enabled mod_version by default? Maybe we should be cautious and do

That's a fairly difficult question. As I see it, the question should be: "Does HTTPD distribution foo (or Linux version bar, or whatever) enable mod_version by default? Because the list of modules being enabled and shipped is decided upon on compile time.

Or to rephrase that: The answer must (and will) be "It depends.".

I considered that problem and my impression was: "I'd rather see an error message when the configuration is tested, or the server is started than another error message at runtime." (The latter would be given by using "IfModule mod_version".)

Another alternative would be to introduce a new parameter for localconfig ("httpd_version = 2.2, 2.4, or none, the latter suppressing the generation of .htaccess files)

Whatever we choose here, that is not for me to decide, so I'd like to ask for clarification.
> Whatever we choose here, that is not for me to decide, so I'd like to ask for clarification.

david's IfModule in comment 6 looks reasonable.  if mod_version isn't available we should revert to the current behaviour to avoid breaking existing sites.

the installation documentation should also be updated to recommend enabling of the mod_version module.
Assignee: installation → jochen.wiedmann
Flags: blocking5.0?
Flags: blocking5.0+
Flags: blocking4.4.7?
Flags: blocking4.4.7+
(Assignee)

Comment 10

2 years ago
(In reply to Byron Jones ‹:glob› from comment #9)
> > Whatever we choose here, that is not for me to decide, so I'd like to ask for clarification.
> 
> david's IfModule in comment 6 looks reasonable.  if mod_version isn't
> available we should revert to the current behaviour to avoid breaking
> existing sites.
> 
> the installation documentation should also be updated to recommend enabling
> of the mod_version module.

Sorry, Byron, but I disagree.

We have absoltely no possibility to know, whether mod_version is available. We can assume, though.

However, if it is not, then the snippet from comment 6 is simply not present, and we have no valid configuration, because there is nothing that authorizes the client. (And the global default is "deny".)
(In reply to Jochen Wiedmann from comment #10)
> We have absoltely no possibility to know, whether mod_version is available.

the <IfModule mod_version.c> directive tells us exactly if mod_version is available.

> However, if it is not, then the snippet from comment 6 is simply not
> present, and we have no valid configuration, because there is nothing that
> authorizes the client. (And the global default is "deny".)

that's correct -- on a new 2.4 installation that doesn't have mod_version enabled we'll end up with a "deny" scenario.  if they installed mod_version as per the suggested documentation changes then their installation will work.

it's a trade-off between requiring existing functional installations to install/enable mod_version to continue to work, or possibly breaking new installations for admins who don't read the documentation.

i tested the following distros to see if mod_version is enabled by default:
ubuntu 14 : yes
fedora 21 : yes
debian  7 : yes
centos  7 : yes

this means by default using mod_version will work, so having a "please read the docs" as a fallback isn't that bad.
(Assignee)

Comment 12

2 years ago
Created attachment 8552313 [details] [diff] [review]
bug1121477.patch

Updated Patch. Changes with regard to the first version:

- Relative to the Master Branch, not to the 4.4.6 version, as suggested by dkl.
- Removed trailing whitespace, as pointed out by dkl.
- Respecting case, as suggested by LpSolit.
- Fixed bug regarding a trailing ">", as pointed out by LpSolit
- Including .htaccess in the top directory. (See bug 1124082.)
Attachment #8552313 - Flags: review?(dkl)
Attachment #8552313 - Flags: feedback?(LpSolit)
Comment on attachment 8552313 [details] [diff] [review]
bug1121477.patch

Review of attachment 8552313 [details] [diff] [review]:
-----------------------------------------------------------------

please use <IfModule mod_version.c> as per comment 9
also, only remove trailing whitespace from lines that you've modified instead of from the whole file.
Attachment #8552313 - Flags: review?(dkl) → review-
(Assignee)

Comment 14

2 years ago
Created attachment 8552359 [details] [diff] [review]
bug1121477.patch

Version 3 of the proposed patch.
Changes, as compared to version 2 are:

- Using <IfModule mod_version.c>, as pointed out by glob in comment 13.
- Removal of trailing whitespace now limited to updated content, as suggested by glob in comment 13.
Attachment #8549421 - Attachment is obsolete: true
Attachment #8552313 - Attachment is obsolete: true
Attachment #8552313 - Flags: feedback?(LpSolit)
Attachment #8552359 - Flags: review?(dkl)
Attachment #8552359 - Flags: feedback?(LpSolit)

Comment 15

2 years ago
Comment on attachment 8552359 [details] [diff] [review]
bug1121477.patch

If mod_version.c is not installed, nothing happens. You don't enter the block at all. If mod_version.c is not installed, you must fall back to the 2.2 syntax.
Attachment #8552359 - Flags: review?(dkl)
Attachment #8552359 - Flags: review-
Attachment #8552359 - Flags: feedback?(LpSolit)
(Assignee)

Comment 16

2 years ago
You mean, you are requesting that any section IfModule mod_version.c is being paired with a corresponding section IfModule !mod_version.c?

Comment 17

2 years ago
(In reply to Jochen Wiedmann from comment #16)
> You mean, you are requesting that any section IfModule mod_version.c is
> being paired with a corresponding section IfModule !mod_version.c?

Yes, else all installations which don't have mod_version.c enabled would get no rules. This would be a regression.

Comment 18

2 years ago
4.4.7 has already been released.
Flags: blocking4.4.7+
(Assignee)

Comment 19

2 years ago
(In reply to Frédéric Buclin from comment #18)
> 4.4.7 has already been released.

It has, indeed? Doesn't say so on http://www.bugzilla.org/. (Sorry for the Off Topic Conversation.)
(Assignee)

Comment 20

2 years ago
Created attachment 8552944 [details] [diff] [review]
bug1121477-3.patch

Proposed Patch, version 4. Changes, compared to version 3, are as suggested in comment 15.
Attachment #8552359 - Attachment is obsolete: true
Attachment #8552944 - Flags: review?(dkl)
Attachment #8552944 - Flags: feedback?(LpSolit)
Comment on attachment 8552944 [details] [diff] [review]
bug1121477-3.patch

Review of attachment 8552944 [details] [diff] [review]:
-----------------------------------------------------------------

If only there were an <IfElseModule> and <IfElseVersion> to make this simpler looking. r=dkl
Attachment #8552944 - Flags: review?(dkl) → review+

Updated

2 years ago
Flags: approval?
Flags: approval5.0?
(Assignee)

Updated

2 years ago
Flags: blocking4.4.9?
Flags: blocking4.4.9?
Flags: blocking4.4.9+
Flags: approval?
Flags: approval5.0?
Flags: approval5.0+
Flags: approval4.4+
Flags: approval+
Target Milestone: --- → Bugzilla 4.4
Thanks for the contribution!

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   f2e695e..981729e  4.4 -> 4.4

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   689f76e..fe2e8f6  5.0 -> 5.0

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   98fe072..64250f2  master -> master
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED

Updated

2 years ago
Attachment #8552944 - Flags: feedback?(LpSolit)

Updated

2 years ago
Blocks: 1131404

Comment 23

2 years ago
Note that your patch doesn't nuke old .htaccess files and so it has no effect on existing installations. This means that upgraded installations won't benefit from this fix.
(In reply to Frédéric Buclin from comment #23)
> Note that your patch doesn't nuke old .htaccess files and so it has no
> effect on existing installations. This means that upgraded installations
> won't benefit from this fix.

This also assumes their current .htaccess files are working with the version of Apache they currently have installed so not convinced this is an issue.
(Assignee)

Comment 25

2 years ago
(In reply to Frédéric Buclin from comment #23)

> Note that your patch doesn't nuke old .htaccess files and so it has no
> effect on existing installations. This means that upgraded installations
> won't benefit from this fix.

As David has pointed out: I worked with fresh installations in mind. Besides: Your note is a bit late, isn't it? The patch has already landed.

Updated

2 years ago
Blocks: 1133690

Updated

2 years ago
Blocks: 1138463
You need to log in before you can comment on or make changes to this bug.