This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 463784 - Should a mediawiki update autoupgrade the databases as well?
Should a mediawiki update autoupgrade the databases as well?
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mediawiki (Show other bugs)
12
All Linux
high Severity high
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-24 14:12 EDT by Dave Allan
Modified: 2010-12-05 02:08 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:08:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Allan 2008-09-24 14:12:42 EDT
Description of problem:
My Fedora 9 box picked up the mediawiki 1.13 update recently, and when I went to update a page I got a database error.  A couple minutes of research showed that the MySQL DB schema had not been updated.  Running update.php solved the problem, but I would think that the RPM update would run the update script automatically so that the update doesn't break a running wiki.  (I should admit, I'm a kernel developer, not really a wiki admin, so there may be good reasons why running update automatically would be a bad idea, but it was surprising to me to have my wiki break.)

Version-Release number of selected component (if applicable):
mediawiki-1.13.0-40.fc9.i386

How reproducible:
No attempt made.

Steps to Reproduce:
1. Create a wiki with mediawiki < 1.13
2. Update the rpm to 1.13
3. Try to create a new page, it should fail with a DB error.
  
Actual results:
New page create failed with the error "Table 'wikidb.protected_titles' doesn't exist"

Expected results:
No error.

Additional info:
Comment 1 Axel Thimm 2008-09-25 16:13:17 EDT
The rpm package cannot know how many mediawiki installations you have, how you called the databases, whether the databases are local or remote etc.

This is a weak spot of most applications running on php/mysql, as the code update and the database update cannot always be done by the same instance.
Comment 2 Dave Allan 2008-09-29 13:11:43 EDT
That makes sense, and am I correct to assume it could be dangerous to run the update.php script if the DB config wasn't what was expected?
Comment 3 R P Herrold 2008-09-29 13:48:27 EDT
If 'update.php' does not do 'sanity checks', there would deep problems which need to be filed and fixed upstream; that said, /usr/share/mediawiki/maintenance/archives seems to be just the opposite [i.e., a careful compilation], used by: 
/usr/share/mediawiki/maintenance/updaters.inc  in an appropriate fashion.

The credentials issue seems to be solveable in a scriptable fashion, by walking the output from a 'find' on LocalSettings.php, etc and following the process of:
   /usr/share/mediawiki/UPGRADE
Comment 4 Bug Zapper 2009-06-09 22:47:54 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Ricky Zhou 2009-06-21 19:55:57 EDT
Hi, as Axel mentioned, it wouldn't be proper behavior for the RPM to attempt to perform the update process automatically, so I'm marking this as NOTABUG for now (feel free to reopen if I'm mistaken).
Comment 6 Axel Thimm 2009-07-26 16:47:17 EDT
I'm reopening this as it looks like Debian and Debian-derived distro take their risk in auto-upgrading and a mediawiki developer also encourages us to do so.

Or at least we need to reconsider whether auto-upgrading the code w/o auto-upgrading the database makes any sense. It's probably either both or none.

(In reply to comment #1)
> The rpm package cannot know how many mediawiki installations you have, how you
> called the databases, whether the databases are local or remote etc.
> 
> This is a weak spot of most applications running on php/mysql, as the code
> update and the database update cannot always be done by the same instance.  

If the upgrades are to be done automatically then either the packaged version needs to keep track of where the various mediawiki instances have been spawn off, or there needs to be a check in the entries to the code to auto-upgrade on first use.

The question is what happens if the rpm upgrade happens when the database is not running? Would it leave again a half-upgraded setup while the package would claim to perform everything for the user? Would the upgrade-on-first-use fix this, but perhaps introduce new issues (like DoS if not properly locked)? The auto-update-on-first-use method would have to be a common project with upstream to have a chance.
Comment 7 Aryeh Gregor 2009-07-26 18:56:55 EDT
Auto update on first use sounds interesting.  From my POV it would be especially helpful for users without command-line access, who currently have to go through a somewhat contorted procedure to upgrade their DB (and who constitute a large percentage of our users).

However, normally upgrading requires some ALTER TABLEs.  On moderately large databases, this could take a significant amount of time (minutes, or for very large databases hours).  Some mechanism would have to be worked out to ensure that we don't have multiple concurrent updates trying to run, at least.

I'm not certain what the best way is to check whether the database is already up-to-date, either -- the check would have to be very cheap if it was done on every page view.  Possibly we should just do the check and attempted upgrade if a database error is thrown.

Very large sites (like Wikipedia or Wikia) are unlikely to ever want this kind of automated upgrade, since it would take out write locks on major tables and bring everything to a screeching halt.  It also might not work correctly with replication, etc.  I think it would have to be opt-in -- but that would really kind of kill its utility.

It might be better to have some kind of web interface for updating, and have database error messages direct the user to that interface.  We would need to work out some secure way of telling who should have the rights to try an upgrade, though, since the database possibly wouldn't be available.

This sounds like an interesting project, but unfortunately I don't have any time to commit to it.  I think naively attempting to run maintenance/update.php would be an improvement over the current situation for Fedora, at least.  Barring bugs it should fail harmlessly, at worst.  And if there are bugs they'll probably strike anyway when the user upgrades manually.
Comment 8 Dennis Jacobfeuerborn 2009-07-27 08:51:02 EDT
Would maybe a tunable in e.g. /etc/sysconfig/mediawiki help? Something like "AUTO_UPDATE_DB=0/1" that could be read on a package update.

By default it would be "1" and the DB would be updated automatically. Large/Complex installations could set this to 0 to indicate that they want to handle the database updates themselves.
Comment 9 Axel Thimm 2009-07-27 15:15:08 EDT
(In reply to comment #8)
> Would maybe a tunable in e.g. /etc/sysconfig/mediawiki help? Something like
> "AUTO_UPDATE_DB=0/1" that could be read on a package update.
> 
> By default it would be "1" and the DB would be updated automatically.
> Large/Complex installations could set this to 0 to indicate that they want to
> handle the database updates themselves.  

This would mean to follow a completely different setup. Currently the codebase is being updated, whether the db is or not. If we introduce semantics of AUTO_UPDATE_DB=0, then we need to make sure the code is not updated as well, e.g. the code bits of the previous mediawiki install(s) would need to have been copied away, and to avoid the disk getting full of mediawiki code bases of different versions one would need to do some reference counting.

That being said, probably the best we can currently do on a downstream basis.
Comment 10 Bug Zapper 2009-11-16 04:27:22 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Bug Zapper 2010-11-04 07:47:20 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2010-12-05 02:08:05 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.