1121477 - Support for Apache HTTPD 2.4

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect)

Description

[Jochen Wiedmann]

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

Comment 1

[Dylan Hardison [:dylan] (he/him)]

Assuming I get the tuits, I'll go over the docs and square them with reality.

Comment 2

[David Lawrence [:dkl]]

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

[Frédéric Buclin]

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

Comment 4

[Jochen Wiedmann]

Attachment: 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.

Comment 5

[Jochen Wiedmann]

(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.

Comment 6

[David Lawrence [:dkl]]

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

Comment 7

[Frédéric Buclin]

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?

Comment 8

[Jochen Wiedmann]

(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.

Comment 9

[:glob ✱]

> 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.

Comment 10

[Jochen Wiedmann]

(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".)

Comment 11

[:glob ✱]

(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.

Comment 12

[Jochen Wiedmann]

Attachment: 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.)

Comment 13

[:glob ✱]

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.

Comment 14

[Jochen Wiedmann]

Attachment: 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.

Comment 15

[Frédéric Buclin]

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.

Comment 16

[Jochen Wiedmann]

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

[Frédéric Buclin]

(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

[Frédéric Buclin]

4.4.7 has already been released.

Comment 19

[Jochen Wiedmann]

(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.)

Comment 20

[Jochen Wiedmann]

Attachment: bug1121477-3.patch

Proposed Patch, version 4. Changes, compared to version 3, are as suggested in comment 15.

Comment 21

[David Lawrence [:dkl]]

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

Comment 22

[David Lawrence [:dkl]]

Thanks for the contribution!

To ssh://[e-mail]/bugzilla/bugzilla.git
   f2e695e..981729e  4.4 -> 4.4

To ssh://[e-mail]/bugzilla/bugzilla.git
   689f76e..fe2e8f6  5.0 -> 5.0

To ssh://[e-mail]/bugzilla/bugzilla.git
   98fe072..64250f2  master -> master

Comment 23

[Frédéric Buclin]

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.

Comment 24

[David Lawrence [:dkl]]

(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.

Comment 25

[Jochen Wiedmann]

(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.