Installation Documentation
From GRWiktionaryHelp
This page contains instructions specific to the goal of installing and configuring MediaWiki software for the purpose of hosting a Wiki dictionary.
These instructions were written prior to the release of Ultimate Wikitionary, and are regarding MediaWiki version 1.4 and with some exceptions version 1.5. We have tried to order the instructions according to the order the user would proceed in installing a Wiki dictionary for the first time.
Caching: Maximizing Your Wiki Speed
We have used Turck MMCache to speed up our Wiki response times. TurckMMCache is the most well-supported caching program available at the time of the writing of this page.
Instructions for installing Turck MMCache can be found at the Turck MMCache website. Other available caching programs which are not as well supported, but might be in future. You can find instructions for installing other caching software at Help:PHP caching and optimization.
Installation
You will need to install MediaWiki. Installation instructions can be found at Help:Installation.
- After the web install, you can return the config settings to what they were by doing the following:
- cd /path/to/wiki/
- chmod a-w config/
Multiple Installations for Multiple Languages on the Same Server
In our installation of a Wiki dictionary we have used a multiple installation of MediaWiki. We chose the multiple installation since our dictionary will have multiple translations and we also have an installation where we imported our help pages to. Seperating the translations into different installations should make it easier to dump and maintain content specific to each language and to the help pages (to setup help pages, you will have to create a new installation as well with the database prefix 'help_' and then follow the process for importing our help pages database into that installation; see Importing/Exporting help pages below). This installation also follows the model of Wiktionary and allows us to set a language during setup which displays the MediaWiki user interface for that installation in the selected language. You might prefer an alternative setup but these instructions will cover multiple MediaWiki installation.
We followed the convention used by Wiktionary to name the different interwiki links of the different installations using the two letter ISO country codes. We also used this naming convention for the install directories of the wikis.
Instructions for installing multiple MediaWikis to support multiple languages can be found at Help:Installing more than one wiki on one server.
InterWiki Linking: Linking Between Your Different Wiki Language Installations
If you are installing multiple instances of MediaWiki for a multiple language setup, you will also need to setup Interwiki linking. This will let users make simple links between the different installations using wikitext and the language ISO code. For each installation we had to setup interwiki links to each of the other installations. Our help pages also require they're
Instructions for setting up interwiki linking can be found at Help:Interwiki links.
Configuring To Allow Users To Stay Logged In Across Different MediaWiki Installations
Importing and Exporting Help Pages
Once you have setup your installations, including an installation for the help pages, you can import the help pages from a database export. You will have setup an installation to hold the help pages in the section above: Multiple Installations for Multiple Languages on the Same Server. After your installation has been active for a while and changes have been made to your help pages, you might want to export them in the instance that you are modifying or moving your installation.
Instruction for importing and exporting help pages can be found at Help:Importing and Exporting Help Pages.
Security precautions
Securing your Wiki from intruders is a necessity. To secure your Wiki follow the recommendations listed at Help:Security.
Setup Email Notification
When users setup watches on certain wiki pages, we would like automated emails sent to them every time changes were made to that page. For this we need the feature known as email notification.
Newer versions of MediaWiki have email notification integrated into the installation. You won't need to install anything extra, only to configure it. Versions of MediaWiki previous to 1.5 don't have it and to install it you will be required download the package, then install it and configure it.
You can find instructions for installing and configuring email notification at m:Help:Email notification and update marker.
Installing Document Export Support
We have implemented a special page that will allow users to export pages from the wiki into HTML, PDF, and XML.
The instructions for installing the document export functionality are at Help:Installing Document Export Support.
The location of the files referenced in those instructions can be found at Help:Wiki Dictionary Installation Files.
Instructions on using the Document Export can be found at Help:Document export.
Installing The Automatic Keyword Linking Function
We have implemented a special page that will automatically look for keywords in each of your wiki pages and create links to the relevant wiki pages. However it is only designed to work when your wiki pages do not yet have any links to other wiki pages. The function should only be used once immediately after you have populated the wiki with your content which was done immediately after a fresh install of the wiki without any further configuration. That content should not contain any wiki links when you execute the function. You will have to make sure that users are not accessing the wiki while you execute this function.
There are some variables you can change to modify functioning of the scan. The scan is set to start at the first created page on a newly installed wiki. You might want to change it. You can change the variable $wgStartTitle to do so. You can login to the wiki database on MySQL and find which id numbers go with which wiki pages so you can decide what you would like to set it to.
If there are many pages in your wiki the scan can slow and halt since it requires a lot of processing power. You can slow processing by decreasing the value of $wgTitlesPerRun which determines the number of wiki pages processed per run of the scan.
You can use the instructions for installing special pages to install the Automatic Keyword Linking Function. They are at Help:Installing extensions and special pages. The location of the files referenced in those instructions can be found at Help:Wiki Dictionary Installation Files
Further help on using the keyword linking function can be found at Help:Keyword linking scan.
How To Change Contents of Navigation Toolbar
We changed our navigation toolbar that appears on the top left margin of the Wiki. We added a link to our help pages. Instructions for adding a link to your navigation toolbar can be found at Help:How To Change Contents of Navigation Toolbar.
In our case, we have the following array defined in our LocalSettings.php file:
$wgNavigationLinks = array (
array( 'text'=>'mainpage', 'href'=>'mainpage' ),
array( 'text'=>'portal', 'href'=>'portal-url' ),
array( 'text'=>'currentevents', 'href'=>'currentevents-url' ),
array( 'text'=>'recentchanges', 'href'=>'recentchanges-url' ),
array( 'text'=>'randompage', 'href'=>'randompage-url' ),
array( 'text'=>'help', 'href'=>'helppage' ),
array( 'text'=>'sitesupport', 'href'=>'sitesupport-url' ),
array( 'text'=>'documentexport', 'href'=>'documentexport-url' ),
);
The last defining the link to the document export special page. Then we could define the name of the link by logging in as the admin of our wiki and loading the page:
http://xx.xx.xx.xx/en/index.php/MediaWiki:Documentexport
and editing it to display the name we choose. We set the url of the link by loading the page:
http://xx.xx.xx.xx/en/index.php/MediaWiki:Documentexport-url
And entering the url of our link. In our case that url was:
http://xx.xx.xx.xx/en/index.php/Special:DocumentExport
Setting Up Create Page Option For When A Search Fails
When a user searches a term and nothing is returned, by default there is not option to create a page with the inputted term. We can configure so that the option is presented upon an empty search return.
Instructions for doing this can be found at Help:Setting up create page option for when a search fails.
Setting The Copyright For Your Wiki
You might want to append your copyright to your Wiki pages.
Instruction to insert your copyright can be found at Help:Setting the copyright for your wiki.
Changing the Wiki Logo
We changed the default MediaWiki logo that appears at the top left margin, to our own logo.
Instructions for changining the logo can be found at Help:Changing the Wiki Logo
Configure To Allow Image Uploads
To allow users to upload images to your wiki you will have to modify the file LocalSettings.php located in the main MediaWiki install directory. It contains the local configuration of a MediaWiki. Changing a setting usually means changing the value of a PHP variable. You might want to make yourself familiar with the PHP syntax first before going ahead. If you are too lazy, keep in mind that PHP variables are accessed by prepending a "$" character before the variable name; many variables are simply set to either true or false. It is located in the main MediaWiki install directory.
Before users are allowed to upload files to the MediaWiki system, you have to enable that feature. Make sure the Upload Directory is properly configured and writeable by the Apache web server process. It's ownership should be by the webserver and we had to use the chmod command to make it writeable by group and other with the commands:
chmod g+w images chmod o+w images
Then set the wgDisableUploads to false to allow uploading in the web user interface (it is likely the case that the line is already there but just commented out with a prepended '#', so you can uncomment it by removing the '#'). The 'Upload file' link will appear to users in the toolbox menu in the left margin of your wiki when they are logged in as valid users.
If you want to be able to resize images on the fly to support thumbnails, MediaWiki needs a working ImageMagick installation. Set the variable $wgUseImageMagick to true once you have installed and tested ImageMagick on your system. Make sure the wgImageMagickConvertCommand variable points to the proper location of the convert command of your installation and that the command is executable by the web server process.
Also, you may want to modify the list of accepted extensions:
$wgFileExtensions = array( 'png', 'jpg', 'jpeg', 'ogg','doc','xls','ppt','mp3','sxc','pdf' );
Backup Your Wiki
Instructions for manually backing up and restoring your wiki contents can be found at Help:Backup database.
We implemented an automated Wiki backup script. A description of the script and instructions for installing it can be found at Help:Automated wiki backup.
The location of the script is listed in Help:Wiki Dictionary Installation Files.
Upgrading MediaWiki
For security reasons it is important to keep your MediaWiki up to date with the latest release.
You should backup your wiki before you make any serious upgrades (i.e. dump the contents of your current database for safety). You can find instructions on backing up your wiki at Help:Backup database.
You can find upgrade instructions at Help:Upgrading MediaWiki. However, read the following tips before you start:
Generally when upgrading you should consider the following instructions:
- Check what version of MediaWiki you are running.
- This will be located at the top of includes/DefaultSettings.php of your MediaWiki install directory.
- Download latest version of MediaWiki at http://wikipedia.sourceforge.net/
- First read the UPGRADE readme in the package you downloaded to see what sort of upgrade to use: script or web-based.
- In the case of the web-based upgrade: You will have to unpack the downloaded upgraded MediaWiki directly into the current Wiki directory for upgrade.
- One way to do this is to rename the wiki directory to the directory that MediaWiki will automatically unpack to (usually the text of the package name up to but not including .tar.gz), and then unpack the file in directory just above that of the installed wiki.
- Then start the web-based upgrade (you will need information you used in the original installation: database access info (wiki user, pw), the wiki name, wiki admin name and password).
- If you have backed up your configuration files, you should be able to find some of these in the LocalSettings.php file.
- The script should allow you to upgrade directly from the command line and should be the case for newer versions of MediaWiki.
- Open the package and read the file labeled UPGRADE. It will contain specific instructions on how to upgrade.
- You should check if there are upgrades to the HTML2PDF conversion tool if you have installed it.
Keeping Up To Date
- The most important security precaution is patching security holes as software updates become available. The following mailing lists should be subscribed to by the Wiki maintainer:
- Subscribe to MediaWiki announce mailing list. Information on how to subscribe can be found on the communication page of the Mediawiki homepage.
- The PHP announcement mailing list
Check the MediaWiki homepage for other mailing lists.
Installation
See also : Newcomers guide to installing on Windows
- Installation instructions are hard to find,
- I know they are here somewhere.
- —Anonymous mediawiki's handbook reader
Before you install
Prerequisite tools
To install MediaWiki you need four components:
- MySQL - an SQL database to store the Wiki text, user list etc.
- Apache - a web server to serve the HTML web pages
- PHP - the programming language that MediaWiki is written in. Fedora/Redhat users will also need the PHP-Mysql package. SUSE users also require the equivalent mysql package, php4-mysql and the PHP session management package, php4-session.
- MediaWiki itself, which is a suite of programs written in PHP.
Note: there is experimental support for more databases: Postgres since 1.5, but no installer yet; Oracle support is tagged somewhere in cvs and under development. For webservers, users reported successful installation under Microsoft IIS and Lighttpd (see also: Installing MediaWiki with Lighttpd).
Minimum system requirements
Slow performance has been reported on systems where the whole site is on a single Pentium 133 with 48MB of RAM. 256MB is the recommended minimum amount of RAM for a single computer site but you're certain to need more for a busy public site. The Wikimedia Apache servers typically have 512MB to 1GB and the database servers 4GB.
Having spellchecker enabled
To have spelling installed, one must install ispell (or aspell, I now have both). This was not so evident on a server where it never works with graphical interface.
Then, to verify, open an edit window and begin editing
1. Download and uncompress (untar) the Wikipedia Files
Download the tarball setup file from: http://www.sf.net/projects/wikipedia
2. Upload them to your servers
Untar the file on your local machine and upload it into the web accessible folder (this is usually the htdocs directory on Apache webservers). You can place it in the root and if you have access to the httpd.conf, setup a symlink.
If you are using a hosting company, it is usually worth creating a directory under the /www/ folder in the filesystem, such as /wiki and upload all the files from your local drive into this folder.
- Note: The pack includes a lot of files, spread over dozens of directories. Be careful when uploading. If the transfer is interrupted, you might have missing or incomplete files. You may have to retry your upload several times, especially if you have a slow connection.
3. Create a MySQL database
If you don't have root access on your server, you will need to create a MySQL database and a user for the database at your local host. After logging in as root, here is how we created the database user for our wiki installation:
mysql> GRANT ALL PRIVILEGES ON *.* TO 'wikiuser'@'localhost'
-> IDENTIFIED BY 'wikiuser' WITH GRANT OPTION;
and then we created a database for the wiki:
mysql> CREATE DATABASE wikidb;
If you have root access, the setup file will ask you for the root password and automatically setup the database for you. See MySQL config for more details.
Make sure that you have set a password for your root mysql account. By default, no password is required. To change it start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password' /usr/bin/mysqladmin -u root -h 'hostname' password 'new-password'
4. Change folders permissions
cd into the directory where the mediawiki files are. You will find index.php and the config directory. You need to make the config directory writable by the web server.
A good, secure way to do this is to see what group your web server process belongs to. On Debian, for example, this is www-data. Usually the web server process is "apache" and in order to see which groups the user "apache" belongs to you can run
groups apache (or groups <your_web_server_username>)
So you need to change the group of all files to www-data, and give group write access to the config directory:
cd /var/www/mediawiki-xyz
chown -R root:www-data *
chmod -R o-rwx *
chmod -R g+rw config
A simpler but very unsecure approach is to run the command chmod o+w config. For those of you who do not know what this means, you need to set the permissions (chmod) of the config directory to 777 so that it is world writable.
See your FTP client's instructions to figure out how to set permissions (E.g.: with the "Core FTP" client you simply right click on the config directory and select properties. A dialogue box will appear and easily allow you to change permissions to 777).
This can often be done by heading into your web host's control panel, and then into the file manager. If you are not allowed to set the permissions to 777, try setting it to 755 or 775 instead.
A better approach, if your web hosting server supports access control lists, is to run the command setfacl -d -m apache:rwx (be sure to replace "apache" with the name of the user your web server runs as). This grants access to just the webserver, not every user. You can later remove this access with setfacl -d -x apache config.
5. Visit your site
Visit the directory that wiki resides in. For example: if your domain is example.com and you are installing wiki in a folder called wikimedia, you will need to access http://example.com/wikimedia/ as this will lead you to the install page.
6. Answer questions
- fill in your desired wikidb name etc
- wiki site name
- license metadata
- database username
- database name
- database root password (you may not have this, this is the nice way to go, if you don't have this, you have to use another set of tools to create your db and username, or just tag tables on with another webapp!)
and submit.
If you are using a hosting service, please note that the database name and database username have a prefix (normally the userid given by your hosting provider). For example, if you have created a database named db01 with username u01 and your userid is ocom (given by your hosting provider), you should enter the database name and database username as ocom_db01 and ocom_u01 respectively.
7. Move LocalSettings.php
After setup, a file called LocalSettings.php is created in the config folder. You will need to MOVE(not to copy!) this file to the main wiki parent folder.
MediaWiki seeks LocalSettings.php in MediaWiki root directory. If LocalSettings.php exists, MediaWiki follows its configuration to run, otherwise ask user to do a installation for configuration again.
8. Set back permissions - IMPORTANT
chmod o-rwx config
You will need to set the permissions (chmod) of the config directory to 0600 so that only the owner can read and write to this file. It is important that this is done because not doing it will lead to security risks.
Question - The LocalSettings.php file is created by the web server with a+w permissions. Is it a security risk to leave it writeable by all users, or even the web server?
Guess? - Mine was just created 644, maybe this was changed/fixed or specific to your os / apache setup?
I believe it is not a security risk. If the permission is not 644, for instance 600 or so, then the web server would not be able to read the wiki's configuration. (the webserver runs with the permission "other")
- If you move it instead of copying it, then it will be writable by the web server. It may indeed be safer, especially on a multiuser server without safe mode restrictions, to make it owned and writable only by yourself. It must however be readable by the web server or the system doesn't work. --brion 03:52, 27 Feb 2005 (UTC)
Question: I just installed the newest stable Mediawiki. After moving LocalSettings.php to the root directory its permissions is 666. This permissions is probably risky but in the article it is not mentioned what permissions LocalSettings.php should have. Does anyone know?
- ...and does anyone know how to change these permissions?
Question: Do you mind: You will need to set the permissions (chmod) the config directory to 600 (instead of 0600) ? --AmbroiseIngold 09:43, 8 Apr 2005 (UTC)
Historically, the chmod command used octal notation, so the leading 0 was significant. More recent versions of chmod will do the right thing without the leading 0. Actually, what he probably should have written instead was 0700. If you use 0600, the directory is not executable to the owner. 0700 is read+write+execute for owner. For directories this means that the owner is able to change current dir to it.
- Also, nowadays, if you use a non-zero digit for the first of four, that controls the SUID/SGID/sticky settings. I don't know just how it worked back in the all-octal days, if they needed a fifth digit in there when they were setting S*ID bits or what. But the extra isn't purely a useless holdover these days. -- John Owens 20:54, 2005 August 1 (UTC)
It's still producing 0666/rw-rw-rw for me in 1.5beta4, so given others' statements that they got 644, I'd imagine it probably depends purely on your umask setting for the user your webserver runs as. And I do feel that there should be a note to check its permissions right alongside the note to move LocalSettings.php into the wiki root. --John Owens 20:54, 2005 August 1 (UTC)
- My LocalSettings.php is also 666 (ooh, how devilish!); does anyone know how I can change this? Say's I'm not allowed like...
9. Customize style sheet
You can customize the logo in the top left hand side by replacing either stylesheets/images/wiki.png or stylesheets/monobook/images/wiki.png
Lately this is: skins/common/images/wiki.png.
The size is 135 px (width) by 155 px (height) (135x135 px with version 1.4).
However a better way to change it would be to use LocalSettings.php. Look for the variable "$wgLogo".
If your logo is bigger than 135 x 135 ( version 1.4 ) you have to resize it, because the logo hurts the web lay-out.
See also
Reading:
Go |
Search |
URL |
Namespace |
Page name |
Section |
Link |
Backlinks |
Piped link |
Interwiki link |
Redirect |
Variable |
Category |
Special page
Tracking changes:
Recent |
(enhanced) |
Related |
Watching pages |
Page history |
Diff |
User contributions |
Edit summary |
Minor edit |
Logging in and preferences:
Logging in |
Preferences |
User style
Editing: Overview |
Wikitext |
New page | List |
Images/files |
Image page |
Special characters |
Formula |
Table |
EasyTimeline |
Template |
Renaming / Moving a page |
Editing shortcuts |
Talk page |
Testing |
Export |
Installing more than one wiki on one server
- Create its directory. The simplest way is just to unpack the MediaWiki archive and then rename its directory (e.g.,
mv mediawiki-VERSION mynewwiki). We renamed the directory to the two letter abbreviation of the language that the particular installation would be used for. - Give it a database. You can use the same database for multiple wikis just by giving each one a unique prefix. The prefix is specified when you fill out the form in the config directory. This is the method we used to setup the databases for the different language installations. We used the two letter ISO abbreviation for the language along with an underscore as the prefix. For example, the prefix for the english installation was: 'en_'.
- Load the installation directory in your web browser, if necessary. It depends on your setup. If all your wikis have the same parent directory and use the same hostname, you may not need to do anything here. To start the web installation script load the url: http://127.0.0.1/[wiki]/ in the browser, substituting [wiki] for the name of the new wiki's instal directory. In our case this would be the ISO country code:
- specify the language of the new installation in the appropriate drop-down menu
- specify a (different) table name prefix on the configuration page. We used the ISO country code convention again. So for example a french wiki would use the prefix fr_
- the remaining entries should be the same as the original installation
Additionally, you may want to make some settings common for all the installations, and have a central place where changes to these can be made. Since the configuration file (LocalSettings.php) is executed as PHP code, this can be done with PHP's inclusion mechanism - for instance, by adding the line include_once("../CommonSettings.php") in each LocalSettings.php, and placing settings which apply to all wikis in ../CommonSettings.php.
If you have a large number of wikis on one host, you may not want to keep a separate copy of the source code for every one. Instead, extract the source somewhere, and for each wiki installation, symlink "index.php", "math", "images" and "style" in the htroot to the equivalent directory in the MediaWiki source. You can then either use a separate LocalSettings.php for each wiki, or (easier) determine the settings based on the URL. See also Wiki farm.
If you want your login to be persistent across Wiki's running on the same server, simply add the following line to your LocalSettings.php after $wgSiteName = ... :
ini_set("session.name", "{$wgSitename}Session" );
AvOK9O <a href="http://lvyszuekukxy.com/">lvyszuekukxy</a>, [url=http://ymxdqedsxsbz.com/]ymxdqedsxsbz[/url], [link=http://mszkzrkrlgcz.com/]mszkzrkrlgcz[/link], http://yndlnetktvsf.com/http://hdchc.com
Interwiki links
http://pane9911.sitebooth.com/ divx player avi http://foru0321.freehostia.com/ moulin rouge songs http://ferk8090.fusedtree.com/ one tree hill season 5 pics http://sega8407.700megs.com/ wisconsin nursing schools http://redi5409.phreesite.com/ certified replica jacob company watches http://lett5090.blackapplehost.com/ avatar book 3 chapter 1 http://usme8470.110mb.com/ us army insignias http://pane9911.sitebooth.com/divx-mobile-player-089.html palm divx player http://foru0321.freehostia.com/moulin-rouge-history.html moulin rouge john http://ferk8090.fusedtree.com/season-2-of-one-tree-hill.html one tree hill season 5 finale spoiler http://sega8407.700megs.com/high-school-racine-wisconsin.html greendale high school wisconsin http://redi5409.phreesite.com/movado-replica-watches.html replica concord watches http://lett5090.blackapplehost.com/watch-avatar-book-3-chapter-16.html avatar book 2 chapter 8 http://usme8470.110mb.com/us-army-snipers.html us army unit insignia http://pane9911.sitebooth.com/divx-player-with-usb.html divx player 5.0 http://foru0321.freehostia.com/moulin-rouge-cabaret.html moulin rouge musical http://ferk8090.fusedtree.com/one-tree-hill-episode-synopsis.html one tree hill season 2 episode guide http://sega8407.700megs.com/oregon-wisconsin-school-district.html wisconsin middle schools http://redi5409.phreesite.com/replica-fake-watches.html replica oakley watches http://lett5090.blackapplehost.com/avatar-book-3-chapter-14-boiling-rock.html avatar book 3 chapter x http://usme8470.110mb.com/battalions-of-the-us-army.html 99th us army http://pane9911.sitebooth.com/divx-web-player-problem.html divx player reviews http://foru0321.freehostia.com/moulin-rouge-analysis.html moulin rouge images http://ferk8090.fusedtree.com/best-one-tree-hill-episode.html one tree hill episode order http://sega8407.700megs.com/kimberly-school-district-wisconsin.html burlington high school burlington wisconsin http://redi5409.phreesite.com/replica-tag-huer-watches.html replica tag huer watches http://lett5090.blackapplehost.com/avatar-316-book-3-chapter-16.html avatar book 3 chapter 16 when http://usme8470.110mb.com/australien-army.html ausa army http://pane9911.sitebooth.com/divx-web-player-for-firefox.html dvd divx media player http://foru0321.freehostia.com/moulin-rouge-development.html lyrics for moulin rouge http://ferk8090.fusedtree.com/one-tree-hill-quotes-2005.html one tree hill closing quotes http://sega8407.700megs.com/central-high-school-la-crosse-wisconsin.html pulaski school district wisconsin http://lett5090.blackapplehost.com/avatar-book-3-chapter-14-airing.html avatar book 3 chapter 16 airs http://pane9911.sitebooth.com/divx-in-windows-media-player.html windows media player 9 divx http://ferk8090.fusedtree.com/one-tree-hill-quotes-ellie.html one tree hill 513 quotes
Customization
(remember that your actual wikidb and wikiuser name were specified by you, and are stored in LocalSettings.php )
Start up mysql
Use the mysql command to start your mysql session:
mysql -u wikiuser -p
Using whatever your wiki user mysql username is, in place of wikiuser and entering the corresponding password when prompted. Next, access the database of your wiki:
use wikidb;
Where wikidb is the name of the database used by your wiki.
example:
aaron@escargot ~ $ mysql -u wikiuser -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 816 to server version: 4.0.20 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> USE wikidb Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql>
View interwiki table
type interwiki<tab><tab> to see a list of interwiki related tables
mysql> interwiki interwiki interwiki.iw_prefix interwiki.iw_local interwiki.iw_url mysql> interwiki
To show you what you have...
SELECT * FROM interwiki;
See http://dev.mysql.com/doc/mysql/en/Retrieving_data.html for more information.
Edit interwiki table
Add language links
As an example of adding interwiki links to other lanuage installations of MediaWiki we will add an interwiki link to the french language installation from the english installation.
REPLACE INTO en_interwiki (iw_prefix,iw_url,iw_local) VALUES
('fr','http://your.domain.name/fr/index.php/$1',1);
Where your.domain.name is the domain name or ip address of the Wiki. So now we can access any page that exists in the french language installation by indicating both the namespace and page name in a wiki link.
e.g. where the namespace is 'fr' and the page name is 'Main Page' would link to the page named 'Main Page' in the french language installation.
mysql -u <username> -p <nameofyourdatabase> < <filename.sql>
mysql -u wikiuser -p wikidb < bugzilla-interwiki.sql
THIS DOES NOT REPORT SUCCESS when it works... there is a bug in the mysql database program... no feedback is a bug, but it probably worked. You must open that interwiki.sql with a text editor to double check.
Use wikipedia's interwiki list
the file: maintanance/wikipedia-interwiki.sql contains data like this:
REPLACE INTO interwiki (iw_prefix,iw_url,iw_local) VALUES
('w','http://www.wikipedia.org/wiki/$1',1),
('m','http://meta.wikipedia.org/wiki/$1',1),
('meta','http://meta.wikipedia.org/wiki/$1',1),
('zu','http://zu.wikipedia.org/wiki/$1',1);
I assume the replace into works...
so,
mysql> \. /var/www/localhost/mediawiki-1.3.0/maintenance/wikipedia-interwiki.sql Query OK, 155 rows affected (0.24 sec) Records: 155 Duplicates: 0 Warnings: 0 mysql>
should have enabled the interwiki links that I wanted...
Opening interwiki-links in a new window
- Edit the Interwiki-table, the interwiki-link
- Add
{{" TARGET="_blank}}at the end of the interwiki-link.
http://de.wikipedia.org/wiki/$1" TARGET="_blank
see also: m:Opening external links in a new window
Changing Your Interwiki Links
- If we wanted to change the interwiki URL of our French language wiktionary we could use a mysql command similar to:
update en_interwiki set iw_url='http://120.0.0.1/fr/index.php/$1' where iw_prefix='fr';
More mysql help
Using phpMyAdmin instead
If your server uses the software phpMyAdmin, you can simply select the database that uses the wiki (remember that your actual wikidb and wikiuser name were specified by you, and are stored in LocalSettings.php ), then select the table "interwiki" from the sidebar. To use the graphical interface, just select "browse" at the top and then you can opt to "insert new row" (at the bottom of the table) following the pattern established for the other items ("$1" is what will be replaced with whatever follows the interwiki prefix in your code; it will usually be at the end of the URL for the site for which you want to make a shortcut). Then click go or opt to insert another record until you are done.
Maintenance script
See m:maintenance scripts for how to use it.
maintenance/wikipedia-interwiki.sql
When upgrading from a 1.2 to 1.3, your interwiki table will be created. however, it will not be updated on further upgrades.
PHP caching and optimization
Wikimedia currently uses Turck MMCache for PHP caching. PHP-Accelerator gave some problems when it didn't get updates quite right, such as adding a new method to a class. Alternative PHP Cache was also tried and gave a variety of problems but that was some time ago. (6 June 2004 post on which this is based)
APC
http://apc.communityconnect.com/
Caches compiled PHP scripts to avoid the overhead of parsing and compiling the code every time pages are loaded. Wikipedia has used it off and on; but more off than on because we've had some problems in the past with mysterious corruption of the cache files, etc.
I've just upgraded to a recent CVS version, we'll see how it goes... (It was still bumping up our load and not helping very much. It still messes up the rdf generation.)
PHPA or Zend Optimizer
Use Zend Optimizer? PHPA? (have we tried using the Zend Optimizer or PHPA?)
- These two projects are not free software (though they are free of charge), which makes me rather leery. Although since they are theoretically just drop-in accelerators and are not required, we would not be made dependant on closed-source software by using them for a boost. --Brion VIBBER
- While I too wish it was OSS, I don't see what the loss is in at least giving them a shot. If they change their license in the future, then we are (at the very least) no worse off than we are now. Anything to help the performance is horribly needed. Wikipedia is nearly unusable during the daytime hours, and any kind of solution is dearly needed. --Marumari
- I'll give them a shot, see if they're less problematic than APC. --Brion VIBBER
- I've installed PHPA, we'll see how it goes. --Brion VIBBER 21:34 20 Mar 2003 (UTC)
Comparing the 15 minutes before installation with the 15 minutes after, using the English Wikipedia logfile:
20030320211530 |20030320213030| 20030320214530 Before cutoff: 2689 pages served, runtime 14463.218 seconds That's 2.98777777777778pages/sec served At avg time per page of 5.37866046857568 After cutoff: 4169 pages served, runtime 8020.671 seconds That's 4.63222222222222pages/sec served At avg time per page of 1.92388366514752
Load average has also fallen somewhat, from 15-20 to 7-10 range. I'm reasonably happy with it so far, hopefully it won't have any other problems. (Note: I've since corrected the pages per second rates above, they was initially calculated with an incorrect ratio.) --Brion VIBBER 21:51 20 Mar 2003 (UTC)
Well, that works out to a 55% percent increase in throughput and a 64% decrease in load time. If it doesn't break anything, it seems like a big win to me. --Marumari 22:08 20 Mar 2003 (UTC)
- That's only a few minutes -- during which traffic type can change -- so it's not a reliable data set, but it's a good sign. :) --Brion VIBBER 22:11 20 Mar 2003 (UTC)
Okay, 90 minutes on either side:
20030320200030 |20030320213030| 20030320230030 Before cutoff: 19682 pages served, runtime 53717.1640000001 seconds That's 3.64481481481481pages/sec served At avg time per page of 2.72925332791383 After cutoff: 24891 pages served, runtime 59320.2220000005 seconds That's 4.60944444444444pages/sec served At avg time per page of 2.38319963038851
And compare with the same time period yesterday, since there's a dropoff in traffic over this period and we need to correct:
20030319200030 |20030319213030| 20030319230030 Before cutoff: 20774 pages served, runtime 69988.5320000001 seconds That's 3.84703703703704pages/sec served At avg time per page of 3.36904457494946 After cutoff: 21771 pages served, runtime 66441.7349999997 seconds That's 4.03166666666667pages/sec served At avg time per page of 3.05184580405125
Yes, that looks like a bigger relative improvement than just the traffic dropoff, which is definitely nice. (Also note that the runtime figures in the wiki log don't directly show script load time, which is one of the principal things that PHPA helps with.) --Brion VIBBER 23:16 20 Mar 2003 (UTC)+
eAccelerator (formerly Turck MMCache)
Development on [http://turck-mmcache.sourceforge.net/ Turck MMCache] seems to have stopped. Software Development continue on the project named eAccelerator.
Claims to be a bit faster than PHPA, a bit slower than Zend Accelerator, and is GPL. May want to consider trying this.
Now, the Fastest GPL Accelerator in GPL. (see above benchmarks)
- Can't say I've ever heard of it. It certainly might be worth trying. Perhaps we could also contact Zend and see if they would offer us a free license of their optimizing software? --Marumari 19:41 11 Apr 2003 (UTC)
How nice is it! It faster then PHPA now :)
- The 2.4.* release claims to be faster than Zend Performance Suite 3.5.0. See the link above for the benchmark. They benchmarked the start page of phpMyAdmin 2.5.1 with the Apache Benchmark program. I tried it out on wigen.net and it improved the performance a lot! Though I have not done any real benchmarking. -- Alexander Wigen, wigen.net 27 Sep 2004
I've had a shot with it on a site and it seems to work quite well, i.e. better than MMCache (but no, I lost the logs to prove this, and the site is now defunct so I can't show evidence). It wasn't as good as Zend though. --Haggis 10:08, 28 Mar 2005 (UTC)
Some Instructions on installation of eaccelerator may help here....
I have written an article about installing and benchmarking eaccelerator using ab and phpMyAdmin here: [1]. It is geared toward OS X but should hold true for any unix-style system. - William
Reading:
Go |
Search |
URL |
Namespace |
Page name |
Section |
Link |
Backlinks |
Piped link |
Interwiki link |
Redirect |
Variable |
Category |
Special page
Tracking changes:
Recent |
(enhanced) |
Related |
Watching pages |
Page history |
Diff |
User contributions |
Edit summary |
Minor edit |
Logging in and preferences:
Logging in |
Preferences |
User style
Editing: Overview |
Wikitext |
New page | List |
Images/files |
Image page |
Special characters |
Formula |
Table |
EasyTimeline |
Template |
Renaming / Moving a page |
Editing shortcuts |
Talk page |
Testing |
Export |
Importing and Exporting Help Pages
Importing help pages
You will need to have installed another MediaWiki with the database prefix 'help_' (see Multiple Installations for Multiple Languages on the Same Server).
- Then login to mysql and access the MediaWiki database.
- Next, we delete all the tables with the 'help_' prefix. We do this using the following command:
- drop table help_archive, help_blobs, help_brokenlinks, help_categorylinks, help_cur, help_hitcounter, help_image, help_imagelinks, help_interwiki, help_ipblocks, help_links, help_linkscc, help_logging, help_math, help_objectcache, help_old, help_oldimage, help_querycache, help_recentchanges, help_searchindex, help_site_stats, help_user, help_user_newtalk, help_user_rights, help_validate, help_watchlist;
- Depending on your version you may have to remove more tables than we've listed in our command. Take a look at what tables exist in your database to make sure which have to be removed (all those with the 'help_' prefix).
- Exit the mysql interaction, and go back to the command prompt.
- Now we will import the tables of the help pages, which are stored in the help.sql (or whatever the name of the file is that stores the help pages) file using the following command:
mysql -p wikidb -u wikiuser -h localhost < help.sql
- Where wikidb and wikiuser are the names of your Wiki's database and user respectively.
- You can then change the Help links of the navigation toolbars in your other MediaWiki installations.
- In the case of the help pages link however, the urls of the link name and url are respectively:
http://your.domain.name/iso-code/index.php/MediaWiki:Help http://your.domain.name/iso-code/index.php/MediaWiki:Helppage
- With your domain name or ip in place of your.domain.name and the two letter language code of each installation in place of iso-code.
Exporting help pages
If you have made changes to your help pages, you may want to export them to use in another installation. To do so you can dump all of the tables from the help installation by logging in as root and then naming all of the help tables in a mysqldump like we did in the following example (where the database name is wikidb and the user name is wikiuser):
- mysqldump -u wikiuser -p wikidb help_archive help_blobs help_brokenlinks help_categorylinks help_cur help_hitcounter help_image help_imagelinks help_interwiki help_ipblocks help_links help_linkscc help_logging help_math help_objectcache help_old help_oldimage help_querycache help_recentchanges help_searchindex help_site_stats help_user help_user_newtalk help_user_rights help_validate help_watchlist > help.sql
The help tables will be dumped to a file named help.sql which will be found in the same directory in which you ran the script.
Security
This guide is incomplete, but should serve as an introduction to some of the areas where an administrator might want to tighten up server security. Some of the advice here is geared towards people who are familiar with web server configuration and are running large servers. If you get lost in some of that, don't worry! The general notes apply to all.
Stay up to date
The most important security step you can take is to keep your software up to date. Both MediaWiki and the software it depends on will occasionally produce new versions correcting newly-discovered security vulnerabilities which may affect you.
I would strongly recommend that anyone running MediaWiki subscribe to the mediawiki-announce mailing list. This is a low-traffic list that sends out only new version announcements.
At this time (June 2005) we're still making security update releases for the 1.3.x and 1.4.x branches, and 1.5.x is nearing its public release.
If you're running the latest 1.3 or 1.4 you should be reasonably secure, insofar as they don't contain any vulnerabilities that we know about and the default configuration should not be unnecessarily unsafe. If you're running an older version, or any 1.2.x or older version, there may be problems that could affect you and you should strongly consider upgrading.
Don't forget to also keep up with updates to Apache, PHP, MySQL, and any other software running on your servers -- both the operating system and other web applications. Several peoples' MediaWiki 1.3.x installations were affected in Fall 2004 by a worm attacking a flaw in PHPbb; once it had gotten in through other customers' unpatched PHPbb sites it added a "you are hacked" message to other writable .php files on the system, including the compiled templates that MediaWiki 1.3 used.
General PHP recommendations
These bits of advice go for pretty much any PHP environment, and are not necessarily specific to MediaWiki.
PHP configuration recommendations, for php.ini or set otherwise:
- Disable
register_globals.- Many PHP security attacks are based on injection of global variable values, so making sure it's off can make many potential vulnerabilities toothless.
- If you require
register_globalsfor another web application, consider enabling it selectively, only for the virtual host or subdirectory that requires it. - MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerabilities.
- Unless you require it specifically, disable
allow_url_fopen.- Remote PHP code execution vulnerabilities may depend on being able to inject an URL into an
include()orrequire(). If you don't require the use of remote file loading, turning this off can prevent attacks of this kind on vulnerable code. - MediaWiki may require this setting to be on for the Lucene search extension, the OAI harvester extension, and certain uses of Special:Import in 1.5. It should not however be required in a typical installation.
- MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerability.
- Remote PHP code execution vulnerabilities may depend on being able to inject an URL into an
- Set
session.use_trans_sidoff.- If this is on, session IDs may be added to URLs sometimes if cookies aren't doing their thing. That can leak login session data to third-party sites through referer data or cut-and-paste of links.
- You should always turn this off if it's on.
Your php.ini may be located in:
- /etc/php.ini (Red Hat Linux, SuSE / Novell Linux)
- /etc/php4/apache/php.ini (Debian woody and sarge)
- /usr/local/php/lib/php.ini (Mac OS X using Marc Liyanage's PHP package)
- /var/www/conf/php.ini (OpenBSD)
- /usr/local/etc/php.ini (FreeBSD)
- Gentoo Linux:
- /etc/php/apache2-php4/php.ini
- /etc/php/cli-php4/php.ini
- /etc/apache2/php.ini
- c:\windows\php.ini (Windows)
For instance if you see this line in php.ini:
register_globals = On
Change it to:
register_globals = Off
Alternatively, you could add this apache directive to turn off register_globals on a per-directory basis:
php_flag register_globals off
Then restart Apache to reload the changes (apachectl reload).
On a multiuser system with PHP installed as an Apache module, all users' scripts will run under the same reduced-privilege user account. This may give other users access to read your configuration files (including database passwords), read and modify your login session data, or write files into your upload directory (if enabled).
For multiuser security, consider using a CGI/FastCGI configuration in which each user's scripts run under their own account, or enabling Safe Mode to limit script access to other users' files. Note that safe mode may interfere with some features of MediaWiki such as uploading and extensions which shell out to other programs.
General MySQL recommendations
In general, you should keep access to your MySQL database to a minimum. If it will only be used from the single machine it's running on, consider disabling networking support so the server can only communicate with local clients over Unix domain sockets.
If it will be used over a network with a limited number of client machines, consider setting the IP firewall rules to accept access to TCP port 3306 (MySQL's port) only from those machines or only from your local subnet, and reject all accesses from the larger internet. This can help prevent accidentally opening access to your server due to some unknown flaw in MySQL, a mistakenly set overbroad GRANT, or a leaked password.
If you create a new MySQL user for MediaWiki through MediaWiki's installer, somewhat liberal access is granted to it to ensure that it will work from a second server as well as a local one. You might consider manually narrowing this or establishing the user account yourself with custom permissions from just the places you need.
Note that the user table in MediaWiki's database contains hashed user passwords and may contain user e-mail addresses, and should generally be considered private data.
See:
- mysql command-line options
--skip-networking - GRANT and REVOKE syntax
Manual installation
If you use the web-based installer, you may be vulnerable to attack by somebody else running the installer on your server between the time you make the config directory writable and the time the LocalSettings.php file is written out.
Usually this should not be a very large risk, but if it's unacceptable to you (or if you need to do a batch install of many wikis), consider doing an installation manually:
- Create a database
- Grant user permissions
- Source
maintenance/tables.sqlto create the tables. - Create a
LocalSettings.phpbased on a sample or the generation code inconfig/index.php, andAdminSettings.phpbased onAdminSettings.sample -
cd maintenance && php update.php
If PHP is running as an Apache module, the LocalSettings.php generated by the web installer will usually be owned by the Apache user account. To ensure that it can't be changed again by another user (see notes above about multiuser systems) or by malicious code injected to a vulnerable web application, you should reassign it to another account. (If you have only limited access, consider copying instead of moving the file; the new copy will be under your other account.)
Alternate file layout
MediaWiki is designed to run in-place after being extracted from the distribution archive, for ease of installation.
You can however manually consolidate or relocate various files, to avoid duplicates in a mass installation or to keep sensitive files out of the web root for safety.
(Moving the main includes and skin files may require carefully picking and choosing and altering the include_path set in your LocalSettings.php. Experiment with this as desired.)
Consider moving the database password or other potentially sensitive data from LocalSettings.php to another file located outside of the web document root, and include()ing that file from LocalSettings.php. This can help to ensure that your database password will not be compromised if a web server configuration error disables PHP execution and reveals the file's source text.
Similarly, editing LocalSettings.php with some text editors will leave a backup file in the same directory with an altered file extension, causing the copy to be served as plain text if someone requests eg LocalSettings.php~. If you use such an editor, be sure to disable backup generation or move sensitive data outside the web root.
User security
Someone able to edit the user-interface messages in the MediaWiki: namespace can introduce arbitrary HTML and JavaScript code into page output. This means wiki user accounts with the 'sysop' permission, as well as anyone with direct write access to the cur table in the database.
Malicious attacks here could be used to snarf users' passwords as they login, or to attempt to exploit browser vulnerabilities (install spyware, etc). So, you should make sure that only trusted people have these permissions.
Also, don't forget to delete the config directory of each MediaWiki installation after installation is complete. Otherwise users could access the config scripts and damage the installation.
Upload security
File uploads are an optional feature of MediaWiki and are disabled by default. If you enable them, you also need to provide a directory in the web root which is writable by the web server user.
This has several implications for security:
- The directory may have to be world-writable, or else owned by the web server's limited user account. On a multiuser system it may be possible for other local users to slip malicious files into your upload directory (see multiuser notes above)
- While PHP's configuration sets a filesize limit on individual uploads, MediaWiki doesn't set any limit on total uploads. A malicious (or overzealous) visitor could fill up a disk partition by shoving lots and lots of uploads at you.
- Generated thumbnails and uploaded files held for overwrite confirmation may be kept in images/thumb and images/tmp without visible notice in the MediaWiki web interface. Keep an eye on their sizes as well.
The default configuration makes an attempt to limit the types of files which can be uploaded for safety:
- By default, file extensions .png, .gif, and .jpg are whitelisted.
- Various executable and script extensions are explicitly blacklisted even if you disable the whitelist.
- Multiple file extensions are checked against the blacklist.
- Several known image file extensions have their types verified using PHP's getimagesize function.
- Uploaded files are checked to see if they could trip filetype detection bugs in Internet Explorer and Safari which might cause them to display as HTML.
In case these checks turn out to be insufficient, you can gain further protection by explicitly disabling server-side execution of PHP scripts (and any other scripting types you may have) in the uploads directory (by default, images).
For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:
<Directory "/Library/MediaWiki/web/images"> # Ignore .htaccess files AllowOverride None # Serve HTML as plaintext, don't execute SHTML AddType text/plain .html .htm .shtml # Don't run arbitrary PHP code. php_admin_flag engine off # If you've other scripting languages, disable them too. </Directory>
Your exact configuration may vary.
Note that use of PHP's safe mode or open_basedir options may complicate handling of uploads.
External programs
-
/usr/bin/diff3may be executed for edit conflict merging. - If ImageMagick support for thumbnails or SVG images is enabled,
convertmay be run on uploaded files. - If enabled, the texvc math extension will call
texvcexecutable, which callslatex,dvips, andconvert(which callsgs).
Fixes for past vulnerabilities
If you are running an older-than-current version of either the 1.4 or 1.3 branches, or a 1.2 or older release, you should upgrade immediately:
- 1.4.5: fixes template HTML JavaScript injection
- 1.4.2: fixes JavaScript injection if $wgUseTidy on
- 1.3.13: fixes template HTML JavaScript injection
- 1.3.12: fixes JavaScript injection if $wgUseTidy on
- 1.3.11: fixes several XSS injections, introduces protection against offsite form submission forgery, fixes directory traversal in image deletion
- 1.3.10: fixes XSS injection, partial protection against offsite form submission forgery; user JavaScript now disabled by default
- 1.3.9: fix to upload file extension blacklisting if whitelist is too wide is disabled; possible PHP code injection on vulnernable configurations
- 1.3.7: fixes a bug in handling of protected pages
- 1.3.4: added upload checks for HTML/JavaScript injection
The 1.2 branch has been discontinued. It's known to contain the template HTML JavaScript