Intranet/Intranet Installation

This page documents installing Mediawiki, some basic customisation and an upgrade process. This process builds upon the reference OS and supporting software detailed at ##### link here #### {| class="wikitable mw-collapsible"

Key features
!Date !OS !MW version !Notes
 * Install from Git or tarball release
 * Use symlinks to keep code and data separate
 * Database backup method
 * Simple, safe upgrades
 * Auto created users matching web server authentication scheme
 * +Documentation test log
 * 16 Nov 2017
 * Ubuntu "Xenial"
 * 1.31.0-wmf.6 (Git)
 * Everything appears to work OK up to and including DB backups
 * }
 * }
 * }
 * }
 * }
 * }
 * }
 * }
 * }
 * }
 * }
 * }

Filesystem layout
By following this procedure, the directory structure you end up with is like this:

Pre requisites

 * Install PHP modules
 * Install git
 * Imagemagick (for image thumbnails)
 * Setup database

Install MW software
To help you decide what version to run, check the official release status, check what version Wikipedia is using look at change logs for development status Two methods of getting the software are presented here - choose one of them.

Option 1 - Packaged release

 * Download a release for example:
 * Untar/gzip it

Option 2 - Use GIT

 * Find a version using git ls-remote:
 * Clone the chosen version
 * Update the submodules and Composer managed libraries

Web based Installer
cd /var/www/html/mediawiki ln -s /var/www/html/LocalSettings.php
 * This is just the initial install. We will change the URL to access MW later.
 * Browse to https://wiki.example.co.uk/mediawiki and the first run wizard will start. Keep the settings to a minimum and don't enable any modules. All of this can be changed later. At the end, download the provided  file and upload it to the web server's filesystem at /var/www/html.  Finally symlink to it from the wiki folder.
 * Disable the Minerva Neue skin in LocalSettings.php to get the wiki to load until it is no longer dependent on MobileFrontend . Edit LocalSettings.php and towards the end put a # in front of wfLoadSkin( 'MinervaNeue' );

Short URLs

 * Add a couple of Aliases to the virtual host definition. These are for the final desired short URLs:
 * Change $wgScriptPath and add $wgArticlePath in LocalSettings.php to match the short URL:
 * Browse to https://wiki.example.co.uk and check https://wiki.example.co.uk/wiki/Special:Version to make sure it all looks OK.

Logo

 * Copy a logo file into /var/www/html and rename it to logo.gif (or.png or whatever) and reference it in LocalSettings.php

Cache

 * This enables a simple filesystem based cache which will help speed up page load times. Create a cache directory for the wiki to use:
 * Add this to LocalSettings.php:

Cronjob for runJobs

 * Add the following to LocalSettings.php to disable runjobs
 * Add this to crontab (change the timings to suit - this example runs every seven minutes)
 * Create a directory for the log
 * When you are happy that runJobs is working correctly then either use something like logrotate to handle the ever growing log file or disable it by removing the redirection in crontab.

Enable wikieditor

 * Edit LocalSettings.php and add this at the bottom:
 * Try editing a page. if the editor does not appear then hold down shift and press the reload button in your browser to clear the cached page.

Auth_remoteuser
The reference build that this article is part of sets REMOTE_USER via Kerberos.
 * Create local-extensions area. This avoids our locally maintained extensions from being overwritten by upgrades
 * Get the latest code
 * Configure the extension
 * You should now be logged into an automatically created wiki account based on your AD username when you access the wiki.

Database Backups

 * This script is really designed for ad hoc use because you will be backing up the entire system anyway
 * Create backup script in /usr/local/bin/mediawiki-backup.sh
 * Make the script executable
 * Run it and verify that you have a database backup file. There should be a file named wiki- .sql - check its contents to verify that it really is a backup

Updating
It is possible to avoid the downtime associated with snapshots and waiting for the code to download but this process is designed to be as safe as possible.

Before updating

 * Perform pre-upgrade change control process
 * Check backups
 * Run database backup script
 * Shutdown the system and take a snapshot
 * Start the system
 * Stop the web server (systemctl stop apache2)

Update the code

 * Do Option 1 or 2 from the installation section of this article to get the new code
 * Create symlinks

Switch to the new code

 * Make the wiki readonly. Put this at the bottom of LocalSettings.php:
 * Start Apache
 * Remove and re-point the symlink.
 * Run update.php
 * Make the wiki read/write. Delete or comment out $wgReadOnly
 * Run the database backup script again
 * Test the new code
 * Notify users that the wiki is available again
 * Perform post-upgrade change control process