To get you started: Get a Linux VPS.
For OS I chose latest Debian Stable which was version 9 at the time of writing.
Tavu.io created the VPS on their OpenStack based cloud in a matter of few tens of seconds.
Then the system gave a temporary password and on login via ssh the system required a new password was set.
Login with the new password and run
sudo apt update && sudo apt upgrade
This will get the pre-installed software to their latest version numbers and may take a while.
Then I added a user name I usually use on Linux systems by entering:
sudo useradd -m -s /bin/bash <username>
Now set a password for username with
sudo passwd <username>
and add the user to /etc/sudoers (make a copy of the line that says “root” and change ‘root’ to your user name of choice) and log out and log in as the newly created user.
Now is a good time to get an firewall going so do so.
Now grab a list of installed packages with
dpkg --get-selections > packages-YYYY-MM-DD.list
This could be useful for later use.
Now install some software
sudo apt install tmux nmap apache2 lynx
- tmux is a shell session multiplexer
- nmap is a port scanner
- apache2 is a web server
- lynx is a terminal-based web browser
And some more software
sudo apt install htop atop itop iotop glances chkrootkit
- htop, atop, itop and glances are system monitoring (for humans)
- iotop is a IO (Input/Output) monitoring system for humans (requires sudo)
- chkrootkit is a software for checking if your system has a known rootkit installed (bad for you)
Migrating the Mediawiki
First install the dependencies as described below and only then we switch to following the moving a wiki guide. which consists of actually three operations:
- Making a backup of the Mediawiki on the old server
- Moving the backup to the new machine
- Restoring Mediawiki from the backup.
Installing Mediawiki’s dependencies
Now we move on to installing the dependencies of Mediawiki. For this we will follow the Mediawiki installation guide for Debian and Ubuntu (generic guide here) up-to-the-point of actually installing one.
sudo apt-get install apache2 mariadb-server php php-mysql libapache2-mod-php php-xml php-mbstring
We installed MariaDB instead of MySQL. They are binary compatible so you can choose one or the other and also interchange them afterwards. Add the database and database user of your wiki and grant all rights on the database to the database user.
Those are the mandatory components and next up are the beneficial components out of which we chose the following
sudo apt-get install php-apcu php-intl imagemagick php-cli
Move required files and the database to new machine
If possible make sure that your Mediawiki is the latest version on the old server.
Next I packed and moved
- The database
- The Mediawiki directory /var/www/mediawiki
- The Mediawiki logs from /var/log/sites/mediawiki
- site configuration from /etc/apache/sites-available
and expanded them into the right place on the new server.
A sane approach to the Mediawiki files ownership is as follows
First recursively make you the owner of all of the Mediawiki directory and its subdirectories and files with
sudo chown -R <username> /var/www/mediawiki
and then explicitly making the images/-directory, where Mediawiki stores its writables, to be posession of user www-data (www-data is the user that Apache and Mediawiki run as) by
sudo chown -R www-data /var/www/mediawiki/images
The TTL (Time To Live) of the domain at the DNS also naturally affects the length of the outage so modifying it to very short time such as 15 minutes way in advance of commencing the migration.
I temporarily modified the domain name of the Mediawiki (in /etc/apache2/sites-available and also LocalSettings.php) to a temporary subdomain to test that the Mediawiki is working on the new server before doing the DNS change of the production Mediawiki. After you have viewed that the wiki is working on the new server change the domains back to the “real” one.
Following these two practices are simple practical things to do that help to make the imminent outage of your service as short as possible.
Link the .conf files with symbolic links from /etc/apache2/sites-available to /etc/apache2/sites-enabled.
ln -s ../sites-available/example.com example.com
Enable mod_rewrite which is needed for the pretty URLs to work.
sudo a2enmod rewrite
Test your Apache2 configuration with
sudo apachectl configtest
and fix your config untill the configuration says ‘Syntax OK’
The last step is that we need to make the Apache2 reload its configuration which is accomplished with
sudo service apache2 reload
Now navigate to the temporary subdomain’s /wiki/-directory and you should see your wiki there.
Warning: The Mediawiki extensions may have dependencies that are not satisfied so also check that each extension works.
If using reCAPTCHA
Google’s reCAPTCHA stopped working (CAPTCHA shows up but when it is time to approve the human as a human I got an error message that reCAPTCHA “cannot contact server”.
This seemed to be solved by logging in to the CAPTCHA management page at Google and deleting the old keys and generating new keys and naturally changing the keys to the new ones at Mediawiki’s LocalSettings.php
Important: Enable outgoing email for Mediawiki
Now we need to put in place a way for the Mediawiki to send emails (very important).
My registrar Gandi.net provides a mailing system which enables the one to use $wgSMTP (set this in LocalSettings) to send outgoing mailing. They also have 5 mailboxes and 1000 forwards included for each domain for all registrants so I can confidently use …@consumerium.org addresses since Gandi.net is rock-solid operation with a very wide palette of TLD’s though maybe 20% higher prices than the price leader which is often buggy, slow and unreliable if they just compete with the “cheapest on planet”.
Other method to get email to go outwards is to install a MTA (Mail Transfer Agent) such as Sendmail, Postfix or Nullmailer and configure it to send the messages.
Whichever method you chose to enable email do check that it works!
Happy wikiditing! – Juho