Upgrading MediaWiki

This method is discouraged. Use the latest tarball instead unless good reason to run the live code tree

Objective: Get the freshest MediaWiki installed on http://develop.consumerium.org/wiki/ using git where ever possible.

Instructions followed: The official upgrading MediaWiki guide

Thanks go to: Naturally the MediaWiki devels and documenters. Special thanks to SPF|Cloud @ freenode irc for kind help in figuring out the problems encountered

MediaWiki - Because ideas want to be free.
MediaWiki logo is public domain by User:Anthere

I upgraded from 1.25.6 to 1.28 alpha which is the in-development version. My experience with MediaWiki is that the people responsible for the tech know what they are doing. Prestige software attracts prestige devels so I decided to go with the development version.

First off: Backup the files and the database. Something could go wrong even if usually MediaWiki upgrade procedures are rock-solid.

Then get the latest MediaWiki from git with

git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git

Next get all the skins by removing the skins directory and then issuing in the MediaWiki core directory

git clone --recursive https://github.com/wikimedia/mediawiki-skins skins

Change into the extensions directory and update the extensions with

git pull

Put the images/ and the extensions/ directory into a .tar.gz and move it over to the ../core/ directory and uncompress there

Get the vendor libraries used by WMF clusters

git clone https://gerrit.wikimedia.org/r/p/mediawiki/vendor.git

Now you are ready to do the upgrade. I shut the Apache2 down for the duration of that just to feel more secure that the update.php will work but I don’t think this is required for safety. Change to the maintenance/-directory in core/ and

php5 update.php

move the old w/-directory out of the way and move core/ into w/ and access the Special:Version of your wiki in browser and you should see that it is up and running with the latest software version.

And keep up-to-date

  • ‘git pull’
  • ‘git pull –recurse-submodules’ in skins/ and extension/
  • Got some complains about composer being out-of-date. Fix with ‘sudo composer self-update’ and ‘composer update’
  • ‘php maintenance/update.php’

Protecting GNU MediaGoblin

GNU MediaGoblin
GNU MediaGoblin is sympa but under attack.

Objective: GNU MediaGoblin instances that have open registrations are suffering from botnets registering accounts en masse for spamming purposes and thus forcing instance maintainers to close registrations. Especially annoying thing the botnets are doing is that they do not even check if the email address lists they traded something in exchange for are valid causing massive amounts of mail returned by Mail Delivery Subsystem on the basis that the email box does not exist. Teslas_moustache on freenode irc proposed that we should look into how Fail2ban could be utilized to stop known vandals.

Fail2ban logo
Fail2ban dynamically alters firewall settings to counter vandal activity by denying access to known vandal IPs. Logo used under the clauses CC-BY-SA 3.0 courtesy of WMC user Palosirkka.

Fail2ban wiki on Fail2ban

“Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs — too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, courier, ssh, etc).”

How to use Fail2ban

When properly configured Fail2ban dynamically modifies the iptables rules when it sees improper behavior.

  • Any IP addresses that can be associated with generating flood of returned mail because they try to register an account with an email address that doesn’t exist should be banned. Stupid, annoying and basic FUD technique employed to discourage MediaGoblin people.

Sharing information on vandal IP and email addresses

Also the issue has been raised that instead of lying down as the firing from the FUD campaign botnets ensues we should try to take their ground. For this it would be beneficial to form a data sharing arrangement between GMG hosters so that we can more effectively combat the FUD campaign.