[Server-admins] Mediawiki updates need update.php to be run

[Jonathan Marsden]

DM Smith wrote:

> When mediawiki is updated the wiki will break but each time has been
> different. The fix is the same: run update.php. (it might be upgrade.php.)

Logically, then, this update.php script (assuming it is part of the
mediawiki package itself) should be being run from a postinstall script
so that it happens automatically when the package is updated.

Is it worth asking whoever packages MediaWiki about this?  Do other
Fedora MediaWiki users experience similar upgrading issues?  Perhaps the
long term solution is to provide the packagers with a patch to their
packaging scripts to do this updating automatically if mediawiki is
running at the time of the RPM update :)

If that works, this is probably the ultimate fix for this issue, because
it fixes it for all (Fedora) mediawiki users, not just CrossWire.

OTOH, the mediawiki docs seem to be ultra conservative and suggest you
back up the wiki competely before doing any such updates... if there
really is a risk to the wiki, of course you wouldn't want the update.php
run automatically!

> o add media wiki to the manual update list. Give me the ability to
> update via sudo.

Works, but adds ongoing human work at every update. Not scalable :)

> o maybe run the update nightly. I don't know if it is safe to do that.

A quick look at /usr/share/mediawiki/maintenance/updaters.inc suggests
that it is probably OK to re-run this script.  update.php calls
do_all_updates which calls generic routines such as add_table, add_field
and so forth, and these each check whether the item concerned already
exists, and they do nothing (except emit a warning) if it does.

I have not checked every single possible updaters.inc function to make
sure (it is 1820 lines of PHP!), but all the ones I looked at seem to
have such checks in them.

It might be better to run the update.php script only after yum update
has been run, rather than nightly?  So perhaps just add a line to run
update.php at the end of the script that runs yum update?  BTW, I didn't
find such a script in a quick look in /etc/cron.*/* ... where is it?

> o write a script to detect the update and to run the php if changed.

Seems unnecessary, if my sense of what updaters.inc does is correct.

> o wait for a break as we do now and wait for me to run the php.

I'm guessing this option is probably not acceptable long term, or Troy
would not have listed this as an issue needing fixing :)

If an admin is doing the yum update by hand, then more or less by
definition there is no real issue, that same admin can also run the
update.php script.  But in that case, surely whoever typed in

  yum update

would also have typed in

  php /usr/share/mediawiki/maintenance/update.php --whatever-options...

(or whatever the real incantation is) immediately afterwards, and there
would have been near zero wiki downtime?

Anyone with a shell can run that php script, no extra priviledges
needed, so (if yum update is currently a manual operation) whoever ran
the yum update by definition had enough privs to run the update.php
script too.

One final thought: having a file with the MySQL superuser username/pw in
it be world readable is unfortunate from a security perspective
(although it was somewhat convenient for me as I looked around, it would
also be highly convenient for an attacker!).

Jonathan