Bug 463784
| Summary: | Should a mediawiki update autoupgrade the databases as well? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dave Allan <redhat> |
| Component: | mediawiki | Assignee: | Axel Thimm <axel.thimm> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 12 | CC: | dennisml, rzhou, Simetrical+redhat |
| Target Milestone: | --- | Keywords: | Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-12-05 07:08:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dave Allan
2008-09-24 18:12:42 UTC
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. 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? 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 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 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). 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. 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. 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. (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. 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 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 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. |