1270116 - checksetup.pl should update .htaccess files in subdirectories

Status: NEW

(Bugzilla :: Installation & Upgrading, enhancement)

Description

[Markus Ellinger]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/49.0.2623.108 Chrome/49.0.2623.108 Safari/537.36

Steps to reproduce:

I moved my Bugzilla installation to another server (tar czvf -> tar zxvf and dumping/restoring the MySQL database), then ran ./checksetup.pl.


Actual results:

After movement to the new server, browsers would report a "403 forbidden" error for all URLs in the data/assets directory (e.g. when trying to download http://www.example.com/bugzilla/data/assets/5147619eb5c09847e7f63245e52bde9c.css?1461869818).

I tracked this down to the following situation:

The .htaccess file in data/assets was updated and used a "Require all granted" directive.
However, the .htaccess file in data/ was apparently not updated and still used a "Deny from all" directive.

To fix this, I deleted both data/.htaccess and data/assets/.htaccess, then re-run ./checksetup.pl. This recreated both .htaccess file and now everything works.

Detailed discussion can be found also on the mailing list:
https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/pC0CP4AB4JQ


Expected results:

Bugzilla should have updated both .htaccess files (in data/ and data/assets/) to match the configuration of the new server I migrated to.

Comment 1

[Frédéric Buclin]

The fact that checksetup.pl doesn't nuke old .htaccess files and replace them by new ones is intentional, see bug 1121477 comment 23. The release notes also ask admins to nuke old ones manually before running checksetup.pl again:

https://www.bugzilla.org/releases/5.0.2/release-notes.html

I don't think checksetup.pl should blindly nuke old files and replace them by new ones, in case some of them have custom code. I would suggest a --update-htaccess argument to pass to checksetup.pl to regenerate them. This is safer.

Comment 2

[Markus Ellinger]

I am not sure the --update-htaccess argument will help reduce trouble for anyone who has this problem. After all, the effort is in (a) searching why the 403 forbidden error is there (takes some time to research, especially with nested .htaccess files) and (b) finding out that this argument is there AND that it will fix the problem. Instead, Bugzilla should just have just updated the .htaccess file because it is a generated (worthless) file anyway, so it would just work.

Therefore I would propose a solution where Bugzilla would save the last state of the generated file (timestamp, md5sum or even a backup copy) and update all files which were not changed manually by the user. This way, you can even output a message like "Warning: File XYZ was manually changed, it is not updated."

Comment 3

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

(In reply to Markus Ellinger from comment #2)
> I am not sure the --update-htaccess argument will help reduce trouble for
> anyone who has this problem. After all, the effort is in (a) searching why
> the 403 forbidden error is there (takes some time to research, especially
> with nested .htaccess files) and (b) finding out that this argument is there
> AND that it will fix the problem. Instead, Bugzilla should just have just
> updated the .htaccess file because it is a generated (worthless) file
> anyway, so it would just work.
> 
> Therefore I would propose a solution where Bugzilla would save the last
> state of the generated file (timestamp, md5sum or even a backup copy) and
> update all files which were not changed manually by the user. This way, you
> can even output a message like "Warning: File XYZ was manually changed, it
> is not updated."

+1 to checksuming or comparing file content.

Comment 4

[Thorsten Schöning]

Saving the last state of a generated file seems like unnecessary work for me, because Bugzilla can compare the current state of a present file with what it uses as default template any given time. If both contents differ, output a warning or such, so people running checksetup.pl can read it and look at the file. Of course it would be good in such a case if the templates for .htaccess wheren't included in Filesystem directly, but stored externally as a regular file, so admins could easier compare things. One could even argue reusing the "template" folder, "setup" is already there.

A bit more work would be to maybe not store a template file, but some diffs which are (test-)applied and either things work or conflict...

Is it even clear that this problem only occured because the user upgraded to 5.0.2 instead of e.g. 5.0.1 or earlier? I don't think so, the problem is mixing "Deny..." with "Required..." in general and that was the case before 5.0.2 with the hint in the release notes already. And if you think of people upgrading from 4.x... They mostly won't read all the release notes anyway. I'm not sure I did... ;-)