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

[DM Smith]

Sent from my iPhone

On Jul 26, 2009, at 1:04 AM, Jonathan Marsden <jmarsden at fastmail.fm>  
wrote:

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

Logical, but as you noted below there is a reason:

The docs warn to backup the database first. Mediawiki can use many  
different DBS.

There is no automatic backup (at least when I last checked).

I probably should do regular backups via cron.

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

The wiki is running just fine. I'd rather it not update unless there  
is a critical security fix. The improvements are too small to justify  
the breaking.

>
>> 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 *think* it is safe as it allows for update from any recent prior  
version.

I have had to run it twice in the past.

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

I think there is a yum update daemon, one of the rc.d scripts.

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

Agreed. :)
>
> 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?
I hope it is a manual run of yum. But the update.php should follow a  
backup of the db. I really need to automate this.
>
> 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.
>

I thought it required being in the wiki group.

> 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!)

It shouldn't be world readable.

One of the problems with the Fedore installation is that it makes  
everything owned by root with very restrictive perms.   We have a cron  
job that fixes the perms for non-root management of the wiki.

>
> Jonathan
>
>
Thanks for your insight.

In Him, DM