User:Ashley/Wiki upgrade plan Q2 2014 upgrade plan — ETA: Q2 2014 (likely early May/June)

old notes from 13 May 2013:

16:20:33 <ashley> also, could someone explain to me just how garage/wiki are "married" to each other? where is the "master" user data? I was thinking of writing an AuthPlugin < > to handle the wiki logins since MediaWiki does not natively and will not support lowercase user names and hacking MW core to make it "support" such a thing is ugly and very error-prone and causes a lot of issues
16:21:44 <DocScrutinizer05> I'm  not sure wiki and garage are linked in any way
16:22:23 <merlin1991> wiki accounts are sepperated from garage accounts
16:23:43 <ashley> wiki's [[Special:UserLogin]] page allows only to log in, there isn't a "create an account" link; manually trying to access [[Special:UserLogin/signup]] informs you that the requested action is restricted to administrators; when I created my garage account, I was able to log in to the wiki with that account
16:54:52 <Woody14619> My understanding is that wiki got its auth from Midgard, which gets updated from garage (or used to anyway)

What are these in the server's root directory and do we need 'em?

  • etc_wiki_20130507.tar.gz
  • etc_wiki_20130513_to_check.tar.gz
  • etc_wiki_20130515.tar.gz

Configuration files are in /etc/mediawiki.

/etc/mediawiki-extensions contains

  • extensions-available — symlinks
  • extensions-enabled — empty folder
  • extensions.php — Debian-specific junk which includes ExtensionFunctions.php (yuck) and all the extensions in /etc/mediawiki-extensions/extensions-enabled

Apache is in /etc/apache2

Actual MediaWiki sources are in /var/lib/mediawiki/ — lots of symlinks there, btw.


  • config/ — getting a "permission denied" here; TODO figure out what this is and if it's needed
  • extensions/ — mostly symlinks but a couple real dirs, too
  • images/ — all files uploaded to the wiki via Special:Upload
  • skins/ — symlink to /usr/share/mediawiki/skins
  • apc.php — lines 41-42 are giving me the heebie-jeebies

Get rid of the useless 'wikiadmin' and 'nokiaeditors' groups:

DELETE FROM user_groups WHERE ug_group IN ('wikiadmin', 'nokiaeditors');

Migrate user preferences from old skin name to new skin name (after the upgrade!):

UPDATE user_properties SET up_value = 'maemo' WHERE up_property = 'skin' AND up_value = 'monobookmaemo2009';

$wgLogo points to a nonexistent image (plus it's using $IP which it shouldn't be since $IP is a filesystem path).

[edit] The master plan


  1. Backup everything. If necessary, ask sysops to take a snapshot of the machine (probably would make sense to set the wiki to read-only mode via $wgReadOnly *before* doing that, though); it'd be a safe bet if we have enough time & resources for that. Otherwise a backup of the database & images will have to do.
  2. Download latest stable version of MediaWiki from into a sane, self-contained directory, such as /var/www/wiki
    1. Put new skin files into /var/www/wiki/skins/Maemo
      1. TODO: Where should the master version of this skin be hosted? Currently I think it's hosted on, but I wouldn't mind moving it to the official MediaWiki git repository,
    2. Download any and all necessary extensions into /var/www/wiki/extensions from
      1. Need my updated version of the GForgeAuthentication extension, which pulls user data from; this means also that the new configuration variable $wgGForgeAuthenticationConfiguration has to be defined in LocalSettigs.php.
      2. Can we publish the source of the new version of GForgeAuthentication? (Old version contains hard-coded passwords, so it's a no-go.)
    3. Copy old LocalSettings.php over to /var/www/wiki and edit them accordingly (see previous note about GForgeAuthentication etc.)
  3. Move images over from /var/lib/mediawiki/images/ into /var/www/wiki/images/
  4. Run /var/www/wiki/maintenance/update.php to perform any and all database upgrades
  5. Test that nothing's blown up...
  6.  ???
  7. PROFIT!

[edit] Open questions

  1. What kind of Apache changes are needed? BONUS: Would like to fix the "plus sign bug" which prevents accessing pages like PEAP+MSCHAPv2 WiFi authentication setup directly.
  2. Service interruption — how much downtime will there be?
  3. If something goes totally kaboom, how easy/hard will it be to restore from a backup?
  4. Lowercase wiki user names — do we really need to deal with these or can we just force them to be uppercase (because MW does not support lowercase user names without ugly core hacks)?
    1. Apparently the canonical form of my name is in lowercase, so it'll be easy for me to test it out. In the worst case I can hack up a maintenance script that changes all initial lowercase names (in MediaWiki's user table) to an initial uppercase (which is standard MW convention). GForgeAuthentication seems to be (correctly) enforcing uppercase in its getCanonicalName function