Difference between pages "Multiple ABI Support" and "MediaWiki"

From Funtoo
(Difference between pages)
Jump to: navigation, search
 
 
Line 1: Line 1:
=== Summary ===
+
This page documents how to set up MediaWiki on Funtoo Linux, from a bare stage3 install with network connectivity. We will use Nginx, xcache and PHP-FPM, which will result in very good performance. We will also properly secure MediaWiki, and also cover some additional tips and tricks, focusing on spam reduction.
  
Support for multiple ABIs has been partially integrated into Portage and the Gentoo gcc wrapper (part of sys-devel/gcc-config) and has been enabled in some system profiles. Extended Multiple ABI is available as part of <tt>multilib.eclass</tt>. This page documents this functionality so it can be more easily understood, used and improved.
+
== Portage Settings ==
  
=== Core ABI Support ===
+
Add the following line to <tt>/etc/make.conf</tt>:
  
Portage and some system profiles currently contain a very small set of changes so that multiple ABIs can be targeted by Portage. In addition, Gentoo's gcc "wrapper" (part of sys-devel/gcc-config) has a key feature in it to enable this multiple ABI support -- this functionality is detailed later in this section. This implements the core minimal multiple ABI functionality.
 
  
In practice, this capability, combined with the gcc-wrapper's ABI support, can come in handy for directing Portage to build libraries for the non-default ABI, using the appropriate directories so that the resultant .tbz2 file can be manually installed on your system without overwriting the libraries for the default ABI. An example of this approach is documented later in this section. This support is also useful when it is necessary for the ebuild to direct the system to create 32-bit versions of some applications that may not be compatible with 64-bit multilib systems, and supports the ability for the ebuild to reliably compile both 32-bit and 64-bit versions of certain applications when necessary.
+
<pre>
 +
PHP_TARGETS="php5-4"
 +
</pre>
  
==== Core ABI: econf() ====
+
Add the following lines to <tt>/etc/portage/package.use/php</tt>:
  
Portage's <tt>econf()</tt> function has support for automatically specifying the proper <tt>--libdir=</tt> setting to <tt>configure</tt> based on settings that are found in the system profile. The intended purpose of automatically setting <tt>--libdir=</tt> is designed so that 64-bit libraries will be installed into /usr/lib64 on multilib systems, and 32-bit libraries will be installed into /usr/lib32 on multilib systems, rather than simply installing these libraries into /usr/lib.
+
<pre>
 +
dev-lang/php curl exif fpm gd mysql mysqli sockets suhosin threads intl xmlreader xmlwriter
 +
>=dev-php/xcache-2.0.0 php_targets_php5-4
 +
</pre>
  
While this functionality has questionable value for most normal ebuilds (since a library installed into /usr/lib will work just as well as one installed into /usr/lib64 on an amd64 multilib system,) this functionality likely comes in handy when building the app-emulation/emul-linux-x86-* binary library bundles to support 32-bit applications, as it allows the ABI to be set in the environment, and in combination with the gcc wrapper will cause 32-bit libraries to be built and installed to /usr/lib32.
+
== Emerge ==
  
==== Core ABI: Gcc Wrapper ====
+
Emerge xcache, and we'll also emerge metalog and postfix. This should pull in MySQL as well as php-5.4:
  
It is important to note that Gentoo Linux uses a ''gcc wrapper'' as a front-end for all calls to gcc, and this wrapper  is part of the sys-devel/gcc-config ebuild. One of the features of the wrapper is that it determines whether the <tt>ABI</tt> variable has been defined in the environment, and if it has, the wrapper will automatically ensure that the <tt>CFLAGS</tt> variable that the compiler sees is actually the <tt>CFLAGS_$ABI</tt> variable, which originates from the system profile. On amd64 multilib systems, this means that a call to <tt>ABI="x86" gcc</tt> will result in an extra <tt>-m32</tt> option being passed to gcc to force it to produce 32-bit code. The <tt>-m32</tt> option will generally not appear in the build log, which may cause some confusion for developers. This is a critical component of the multiple ABI support in Gentoo and Funtoo Linux.
+
<console>
 +
# ##i##emerge --jobs xcache metalog postfix
 +
</console>
  
==== Core ABI: Working Together ====
+
== Start and Configure Services ==
  
The algorithm used by <tt>econf()</tt> works as follows: A system profile (or the user, via the environment) sets the <tt>ABI</tt> variable to a value like <tt>amd64</tt> or <tt>x86</tt>. A corresponding ABI-specific variable named <tt>LIBDIR_$ABI</tt> (e.g. <tt>LIBDIR_x86</tt>) will be used from the system profile, and will be set to either <tt>lib32</tt>, <tt>lib64</tt> or <tt>lib</tt>. This will be used to define the target <tt>--libdir</tt> setting used by <tt>econf()</tt>. This will allow the system profile to control exactly where libraries are installed when building them for a particular ABI, as long as the ebuild author uses <tt>econf()</tt> (part of core Portage) or <tt>get_libdir()</tt> (part of <tt>multilib.eclass</tt>.)
+
Time to configure MySQL with a root password, start it, secure it, and enable it to start at boot. We'll also start metalog and postfix:
  
In addition, the <tt>ABI</tt> variable set in the environment will cause the gcc-wrapper to adjust the <tt>CFLAGS</tt> variable, by using the <tt>CFLAGS_$ABI</tt> variable to tell the multilib-aware gcc to target the alternate ABI. With <tt>ABI="x86"</tt> on amd64 multilib systems, this will cause <tt>-m32</tt> to be appended to the <tt>CFLAGS</tt> variable, which will instruct gcc to produce 32-bit code.
+
<console>
 +
# ##i##emerge --config mysql
 +
# ##i##rc-update add mysql default
 +
# ##i##rc-update add metalog default
 +
# ##i##rc-update add postfix default
 +
# ##i##rc
 +
# ##i##mysql_secure_installation
 +
</console>
  
==== Core ABI: Demonstration ====
+
== Database Setup ==
  
To test the multiple ABI functionality on an amd64 multilib system, you can execute the following command:
+
Now, let's create a database named <tt>mediawiki</tt> for use by MediaWiki, and a <tt>mediawiki@localhost</tt> user to access this database, using a password of <tt>wikifever</tt>:
 +
 
 +
<console>
 +
# ##i##mysql -u root -p
 +
Enter password:
 +
Welcome to the MySQL monitor.  Commands end with ; or \g.
 +
Your MySQL connection id is 7
 +
Server version: 5.1.62-log Gentoo Linux mysql-5.1.62-r1
 +
 
 +
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
 +
 
 +
Oracle is a registered trademark of Oracle Corporation and/or its
 +
affiliates. Other names may be trademarks of their respective
 +
owners.
 +
 
 +
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 +
 
 +
mysql> ##i##create database mediawiki;
 +
Query OK, 1 row affected (0.01 sec)
 +
 
 +
mysql> ##i##grant index, create, select, insert, update, delete, alter, lock tables on mediawiki.* to 'mediawiki'@'localhost' identified by 'wikifever';
 +
Query OK, 0 rows affected (0.01 sec)
 +
 
 +
mysql> ##i##\q
 +
Bye
 +
#
 +
</console>
 +
 
 +
== Nginx Setup ==
 +
 
 +
We will use nginx as our Web server. Let's emerge it:
 +
 
 +
<console>
 +
# ##i##emerge --jobs nginx
 +
</console>
 +
 
 +
== User and Group ==
 +
 
 +
When we run our wiki, we will run it as the <tt>docs</tt> user, for security. Let's set up a <tt>docs</tt> user and group:
 +
 
 +
<console>
 +
# ##i##groupadd docs
 +
# ##i##useradd -g docs --home /home/docs docs
 +
# ##i##install -d /home/docs
 +
# ##i##chown -R docs:docs /home/docs
 +
</console>
 +
 
 +
== Set up PHP ==
 +
 
 +
As our last major configuration step, we will configure the PHP FastCGI Process Manager by creating a <tt>/etc/php/fpm-php5.4/php-fpm.conf</tt> file with the following contents (existing contents can be deleted):
  
 
<pre>
 
<pre>
# ABI="x86" emerge --buildpkgonly sys-libs/zlib
+
[global]
 +
error_log = /var/log/php-fpm.log
 +
log_level = notice
 +
 
 +
[docs]
 +
listen = /var/run/docs.php-fpm.socket
 +
listen.allowed_clients = 127.0.0.1
 +
listen.owner = docs
 +
listen.group = nginx
 +
listen.mode = 0660
 +
user = docs
 +
group = docs
 +
pm = dynamic
 +
pm.max_children = 16
 +
pm.start_servers = 2
 +
pm.min_spare_servers = 2
 +
pm.max_spare_servers = 2
 +
pm.max_requests = 500
 +
php_admin_value[open_basedir] = /home/docs/public_html:/tmp
 +
php_admin_value[error_log] = /home/docs/php-errors.log
 +
php_admin_value[disable_functions] = exec, system, shell_exec, passthru, popen, dl, curl_multi_exec, posix_getpwuid,
 +
disk_total_space, disk_free_space, escapeshellcmd, escapeshellarg, eval, get_current_user, getmyuid, getmygid,
 +
posix_getgrgid, parse_ini_file, proc_get-status, proc_nice, proc_terminate, suexec, pclose, virtual, set_time_limit, show_source
 
</pre>
 
</pre>
  
If you compare the libz shared library in the resultant .tbz2 package ot the one installed in /lib64, you'll note that the one in the .tbz2 is 32-bit while the one in /lib64 is 64-bit:
+
This configuration file tells PHP to use the <tt>docs</tt> user when running MediaWiki. '''Please note that the last line is very long - I have split it into 3 lines for readability on this wiki, but you should combine them into a single line in your configuration file. The line should start with <tt>php_admin_value[disable_functions]</tt> and end with <tt>show_source</tt>.
 +
 
 +
== Configure Nginx ==
 +
 
 +
Oh! Now we need to configure nginx to serve pages as the docs user. Assuming your site is named wiki.mysite.com, create a <tt>/etc/nginx/sites-available/wiki.mysite.com</tt> file with the following contents:
  
 
<pre>
 
<pre>
ninja1 lib32 # file libz.so.1.2.5
+
server {
libz.so.1.2.5: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
+
        listen 80;
ninja1 lib32 # file /lib/libz.so.1.2.5
+
        server_name wiki.mysite.com;
/lib/libz.so.1.2.5: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
+
 
 +
        access_log /var/log/nginx/wiki.mysite.com.access.log main;
 +
        error_log /var/log/nginx/wiki.mysite.com.error.log error;
 +
       
 +
        root /home/docs/public_html;
 +
        index index.html index.php;
 +
 
 +
        # uncomment this if you want to htpasswd-protect your site while you set it up initially
 +
        # auth_basic "Ninjas allowed only";
 +
        # auth_basic_user_file /etc/nginx/docs.funtoo.org.htpasswd;
 +
 
 +
location ~* ^(.*)(install.php|LocalSettings.php|\.git) { deny all; }
 +
 
 +
location ~* \.php$ {
 +
        #set $https "off";
 +
        #if ($scheme = https) { set $https "on"; }
 +
        #fastcgi_param HTTPS $https;
 +
 
 +
        try_files      $uri    @404;
 +
        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
 +
        fastcgi_param  SERVER_SOFTWARE    nginx;
 +
        fastcgi_param  QUERY_STRING      $query_string;
 +
        fastcgi_param  REQUEST_METHOD    $request_method;
 +
        fastcgi_param  CONTENT_TYPE      $content_type;
 +
        fastcgi_param  CONTENT_LENGTH    $content_length;
 +
        fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
 +
        fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
 +
        fastcgi_param  REQUEST_URI        $request_uri;
 +
        fastcgi_param  DOCUMENT_URI      $document_uri;
 +
        fastcgi_param  DOCUMENT_ROOT      $document_root;
 +
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;
 +
        fastcgi_param  REMOTE_ADDR        $remote_addr;
 +
        fastcgi_param  REMOTE_PORT        $remote_port;
 +
        fastcgi_param  SERVER_ADDR        $server_addr;
 +
        fastcgi_param  SERVER_PORT        $server_port;
 +
        fastcgi_param  SERVER_NAME        wiki.mysite.com;
 +
 
 +
        fastcgi_pass    unix:/var/run/docs.php-fpm.socket;
 +
        fastcgi_index  index.php;
 +
}
 +
 
 +
# this will secure the MediaWiki uploads against arbitrary PHP injection attacks:
 +
location /images/ {
 +
        location ~.*\.(php)?$ {
 +
                deny all;
 +
        }
 +
}
 +
 
 +
 
 +
location @404 {
 +
        return 404;
 +
        break;
 +
}
 +
 
 +
location / {
 +
        try_files $uri $uri/ @mediawiki;
 +
}
 +
 
 +
location @mediawiki {
 +
        rewrite ^/([^?]*)(?:\?(.*))? /index.php?title=$1&$2 last;
 +
}
 +
 
 +
}
 
</pre>
 
</pre>
  
It is important to note that Gentoo's gcc wrapper (part of sys-devel/gcc-config) instructs gcc to produce 32-bit code by silently passing (not visible in the build output, due to the wrapper design)a <tt>-m32</tt> option to all compiler calls.
+
== Enable Ngnix and PHP-FPM ==
  
Note that you should not install the 32-bit zlib .tbz2 package on a 64-bit multilib system, as it will replace the critical 64-bit zlib binaries on your system. Portage's   /var/db/pkg database does not allow side-by-side installations of packages that were built against different ABIs. However, this Portage functionality can be used to build 32-bit libraries when needed, which can be installed via manual extraction of the resultant .tbz2 file to the root filesystem.
+
Now, let's enable nginx to serve our site, and also be sure to enable php-fpm:
  
=== Extended ABI Support ===
+
<console>
 +
# ##i##cd /etc/nginx/sites-enabled
 +
# ##i##ln -s ../sites-available/wiki.mysite.com wiki.mysite.com
 +
# ##i##rc-update add nginx default
 +
# ##i##rc-update add php-fpm default
 +
# ##i##rc
 +
* Starting PHP FastCGI Process Manager ...                                                            [ ok ]
 +
* Starting nginx ...                                                                                  [ ok ]
 +
#
 +
</console>
  
Beyond the core functionality, the <tt>multilib.eclass</tt> (which is inherited as part of the ubiquitous <tt>eutils.eclass</tt>) contains a more significant set of code to support multiple ABIs, which appears to be designed to be eventually merged into the Portage core. This means that latent multiple ABI support is available in Portage and can be used without inheriting <tt>multilib.eclass</tt> for "regular" ebuilds, but ebuilds that need more control over the ABI configuration can inherit <tt>multilib.eclass</tt> for access to a significant number of helper functions. If you want to use <tt>multilib.eclass</tt>, first familiarize yourself with the changes in Portage that exist that support <tt>multilib.eclass</tt> functionality, which are documented in this section. Then you will have a much easier time understanding <tt>multilib.eclass</tt>.
+
== Download MediaWiki ==
  
==== ABI Profile Variables ====
+
We're getting close. Now, head to http://www.mediawiki.org/wiki/Download and copy the link address for the latest version of MediaWiki, currently 1.19.1 at the time this was written. Let's download the archive to <tt>/var/tmp</tt>:
  
The following variables are supported on a limited number of architectures - namely, those that have different ABIs available. These include Sparc, PowerPC and PC-compatible x86/amd64 architectures.
+
<console>
+
# ##i##cd /var/tmp
; ABI
+
# ##i##wget http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.1.tar.gz
: Defines the name of the current ABI for which packages should be built. This variable is recognized by the gcc wrapper - see "Core gcc wrapper ABI support", below.
+
</console>
  
; DEFAULT_ABI
+
== Extract MediaWiki ==
: Defines the name of the default ABI for which packages should be built.
+
  
; MULTILIB_ABIS
+
We now have all the Web, database and email infrastructure enabled that we need. Heading to the IP address of your server should result in a 404 - Not Found error in your Web browser. Time to extract and configure MediaWiki itself:
: This consists of a space-separated string of one or more ABIs that are supported on the current system. Amd64 multilib systems will have this set to <tt>amd64 x86</tt>
+
  
==== ABI-Specific Profile Variables ====
+
<console>
 +
# ##i##su docs
 +
$ ##i##cd /var/tmp
 +
$ ##i##tar xvf ./mediawiki-1.19.1.tar.gz
 +
$ ##i##mv mediawiki-1.19.1 ~/public_html
 +
</console>
  
These variables have a suffix (represented below by <tt>*</tt>) that is set based on the ABI that the particular setting is for. For example, <tt>LIBDIR_amd64</tt> would set the library directory name for the amd64 ABI. The rationale for this naming convention is that it allows settings for multiple architectures to be defined together in a single file, and multiple ABI settings to exist on a system that may support multiple ABIs.
+
== MediaWiki from GIT ==
  
; LIBDIR_*
+
Alternatively, we can download the code from the git repository:
  
; CHOST_*
+
<console>
 +
# ##i##su docs
 +
$ ##i##cd ~
 +
$ ##i##git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git public_html
 +
</console>
  
; CDEFINE_*
+
Specific stable versions of MediaWiki are tracked using 'tags'. These are analogous to the tarball releases. We can see the versions available with:
 +
<console>
 +
$ ##i##cd public_html
 +
$ ##i##git tag -l | sort -V
 +
</console>
  
; CFLAGS_*
+
To use a specific tag (1.19.1):
: Note: this variable is used by the gcc wrapper when ABI is defined in the environment.
+
<console>
 +
$ ##i##git checkout 1.19.1
 +
</console>
  
; LDFLAGS_*
+
== Initial Web Config ==
  
; ASFLAGS_*
+
You will now be able to load the URL of your server in your Web browser and configure MediaWiki through the Web user interface. Complete the '''full''' installation process and be sure to specify that you are using XCache for caching. Once you go through this process, the Web installation process will provide you with a <tt>LocalSettings.php</tt> file, which you should place in <tt>/home/docs/public_html</tt>. The <tt>LocalSettings.php</tt> file can also be manually edited and used to enable MediaWiki features and extensions.
  
==== multilib.eclass ====
+
== Tips and Tricks ==
  
Note that a number of these functions can probably be replaced with enhanced profile settings, as all they do is spit out canned values based on the setting of one variable or another. They are also prime candidates for inclusion into the Portage core, possibly with some reworking or deprecation so that as many of these as possible are replaced with "dead" variables rather than "live" code.
+
=== ArticlePath ===
  
; has_multilib_profile()
+
By default, MediaWiki pages will have a URL of <tt>wiki.myserver.com/index.php?title=PageName</tt>. With a few minor tweaks, you can tell MediaWiki to use <tt>wiki.myserver.com/PageName</tt> instead. Here's how. Open up <tt>LocalSettings.php</tt> and search for the <tt>$wgScriptPath</tt> line. This part of the config will look like this:
: This is a boolean function that returns 0 (true) if multiple ABIs are defined in the MULTILIB_ABIS variable; otherwise 1 (false).
+
  
; get_libdir()
+
<pre>
: Returns the "lib" directory name to use, based on the current setting of ABI. For example, on amd64 multilib systems, this will typically return <tt>lib64</tt>, and is typically used in <tt>src_configure()</tt> like this: <tt>./configure --libdir=/usr/$(get_libdir)</tt>.
+
$wgScriptPath      = "";
 +
$wgScriptExtension  = ".php";
 +
</pre>
  
; get_modname()
+
Change this part of the file to look like this:
: Used by some ebuilds that generate dynamically-loadable modules, called "bundles" on MacOS X. ELF (used by Linux) makes no differentiation between the handling of shared libraries and loadable modules (or their file extension, which is ".so",) but Mach (MacOS X) does. MacOS X bundles cannot be linked against, but can be dynamically loaded using the dyld API. Apple also recommends that they have an extension of ".bundle" rather than ".so". This function will return ".bundle" for Darwin (Mach) systems, and ".so" for everything else. For more information, see [http://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm MacOS X Guide For Unix Geeks].
+
  
; get_libname()
+
<pre>
: Used by a handful of ebuilds to determine the proper suffix for shared libraries on the current system. This function has various hard-coded values depending on the value of CHOST. For example, Darwin systems will get an echoed value of "<tt>.dylib</tt>" while Linux systems will get a value of "<tt>.so</tt>". Accepts an optional version argument that will be properly appended to the output.
+
$wgScriptPath      = "";
 +
$wgArticlePath      = "/$1";
 +
$wgUsePathInfo      = true;
 +
$wgScriptExtension  = ".php";
 +
</pre>
  
; multilib_env()
+
The old-style URLs will still work, but the shorter more intuitive URLs will now be used for all wiki links.
: Used by toolchain.eclass, gnatbuild.eclass and the glibc ebuild - sets up environment variables for using a cross-compiler. Accepts a single argument - the target architecture in GNU format.
+
  
; multilib_toolchain_setup()
+
=== $wgSpamRegex ===
: In practice, this function is used exclusively to target a non-default x86 ABI on amd64 multilib systems. It accepts one argument, the name of an ABI, or <tt>default</tt> as a shorthand for the default system ABI. It will configure environment variables so the x86 (or other) compiler is targeted, and also backs up all modified variables so they can be restored later. It is typically used to allow non-64-bit-compatible code to still be installed on amd64 multilib systems, by adding the following to the top of <tt>src_configure()</tt>:
+
 
 +
You may find that your wiki is the target of spammers. The easiest way to combat spam is to set <tt>$wgSpamRegex</tt> in <tt>LocalSettings.php</tt>, like so:
  
 
<pre>
 
<pre>
src_configure() {
+
$wgSpamRegex = "/badword1|badword2|badword3/i"
  use amd64 && multilib_toolchain_setup x86
+
  # we're now building a 32-bit app on a 64-bit system, whee!
+
  econf
+
}
+
 
</pre>
 
</pre>
  
=== ABI Support Limitations ===
+
This will perform a case-insensitive match against the bad words and block anyone from saving edits that contain these words.
  
Only a handful of applications leverage the more sophisticated functionality available in <tt>multilib.eclass</tt>, and Gentoo Linux currently uses binary bundles of 32-bit libraries to provide support for 32-bit applications on 64-bit multilib systems, rather than using Portage functionality to build these components from source. One possible explanation for this approach is that Portage currently does not allow applications to be slotted on ABI -- that is, a 32-bit and 64-bit version of sys-libs/zlib cannot co-exist in the Portage /var/db/pkg database, even if they do not overwrite one another on the filesystem when installed. There may be other possible reasons why building 32-bit packages from source remains unfeasible in Gentoo Linux, and will be documented here as they are discovered.
+
=== DNS Blacklist ===
  
[[Category:Internals]]
+
MediaWiki also has the ability to consult a DNS blacklist to prevent known forum and wiki spam sites from performing any edits on your wiki. To enable this capability, add the following to <tt>LocalSettings.php</tt>:
[[Category:Portage]]
+
 
 +
<pre>
 +
$wgEnableDnsBlacklist = true;
 +
$wgDnsBlacklistUrls = array( 'xbl.spamhaus.org', 'opm.tornevall.org' );
 +
</pre>
 +
 
 +
You may notice a significant decrease in spam posts.
 +
 
 +
=== $wgServer ===
 +
 
 +
Here is an important tip -- the <tt>$wgServer</tt> variable in <tt>LocalSettings.php</tt> defines the URL of your MediaWiki installation. MediaWiki will encode this within its HTML replies, which means that the Web browser from which you are accessing MediaWiki must be able to reach your server using this address, or pages will not display. This is not a security feature in any way, but a configuration issue. For example, if <tt>$wgServer</tt> is set to <tt>10.0.1.128</tt>, then the only systems that will be able to access your MediaWiki installation are those for which <tt>10.0.1.128</tt> resolves to your MediaWiki installation.  The same is true of non-IP <tt>$wgServer</tt> entries like <tt>wiki.mysite.com</tt>. If you are setting up a test wiki, you may need a temporary entry in a desktop's <tt>/etc/hosts</tt> file so that it can interact with the wiki properly before DNS is set up.
 +
 
 +
=== $wgLogo ===
 +
 
 +
If you want to change the wiki logo, edit <tt>LocalSettings.php</tt> and replace $wgLogo with the location of the image you want to use:
 +
 
 +
<pre>
 +
$wgLogo = "image.png"
 +
</pre>
 +
{{fancynote| The above references the file <tt>image.png</tt> in the directory <tt>/home/docs/public_html</tt>}}
 +
[[Category:Featured]]
 +
[[Category:HOWTO]]
 
[[Category:Official Documentation]]
 
[[Category:Official Documentation]]

Latest revision as of 23:30, 15 March 2014

This page documents how to set up MediaWiki on Funtoo Linux, from a bare stage3 install with network connectivity. We will use Nginx, xcache and PHP-FPM, which will result in very good performance. We will also properly secure MediaWiki, and also cover some additional tips and tricks, focusing on spam reduction.

Contents

[edit] Portage Settings

Add the following line to /etc/make.conf:


PHP_TARGETS="php5-4"

Add the following lines to /etc/portage/package.use/php:

dev-lang/php curl exif fpm gd mysql mysqli sockets suhosin threads intl xmlreader xmlwriter
>=dev-php/xcache-2.0.0 php_targets_php5-4

[edit] Emerge

Emerge xcache, and we'll also emerge metalog and postfix. This should pull in MySQL as well as php-5.4:

# emerge --jobs xcache metalog postfix

[edit] Start and Configure Services

Time to configure MySQL with a root password, start it, secure it, and enable it to start at boot. We'll also start metalog and postfix:

# emerge --config mysql
# rc-update add mysql default
# rc-update add metalog default
# rc-update add postfix default
# rc
# mysql_secure_installation

[edit] Database Setup

Now, let's create a database named mediawiki for use by MediaWiki, and a mediawiki@localhost user to access this database, using a password of wikifever:

# mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 5.1.62-log Gentoo Linux mysql-5.1.62-r1

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create database mediawiki;
Query OK, 1 row affected (0.01 sec)

mysql> grant index, create, select, insert, update, delete, alter, lock tables on mediawiki.* to 'mediawiki'@'localhost' identified by 'wikifever';
Query OK, 0 rows affected (0.01 sec)

mysql> \q
Bye
# 

[edit] Nginx Setup

We will use nginx as our Web server. Let's emerge it:

# emerge --jobs nginx

[edit] User and Group

When we run our wiki, we will run it as the docs user, for security. Let's set up a docs user and group:

# groupadd docs
# useradd -g docs --home /home/docs docs
# install -d /home/docs
# chown -R docs:docs /home/docs

[edit] Set up PHP

As our last major configuration step, we will configure the PHP FastCGI Process Manager by creating a /etc/php/fpm-php5.4/php-fpm.conf file with the following contents (existing contents can be deleted):

[global]
error_log = /var/log/php-fpm.log
log_level = notice

[docs]
listen = /var/run/docs.php-fpm.socket
listen.allowed_clients = 127.0.0.1
listen.owner = docs
listen.group = nginx
listen.mode = 0660
user = docs
group = docs
pm = dynamic
pm.max_children = 16
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 2
pm.max_requests = 500
php_admin_value[open_basedir] = /home/docs/public_html:/tmp
php_admin_value[error_log] = /home/docs/php-errors.log
php_admin_value[disable_functions] = exec, system, shell_exec, passthru, popen, dl, curl_multi_exec, posix_getpwuid, 
 disk_total_space, disk_free_space, escapeshellcmd, escapeshellarg, eval, get_current_user, getmyuid, getmygid, 
 posix_getgrgid, parse_ini_file, proc_get-status, proc_nice, proc_terminate, suexec, pclose, virtual, set_time_limit, show_source

This configuration file tells PHP to use the docs user when running MediaWiki. Please note that the last line is very long - I have split it into 3 lines for readability on this wiki, but you should combine them into a single line in your configuration file. The line should start with php_admin_value[disable_functions] and end with show_source.

[edit] Configure Nginx

Oh! Now we need to configure nginx to serve pages as the docs user. Assuming your site is named wiki.mysite.com, create a /etc/nginx/sites-available/wiki.mysite.com file with the following contents:

server {
        listen 80;
        server_name wiki.mysite.com;

        access_log /var/log/nginx/wiki.mysite.com.access.log main;
        error_log /var/log/nginx/wiki.mysite.com.error.log error;
        
        root /home/docs/public_html;
        index index.html index.php;

        # uncomment this if you want to htpasswd-protect your site while you set it up initially
        # auth_basic "Ninjas allowed only";
        # auth_basic_user_file /etc/nginx/docs.funtoo.org.htpasswd;

location ~* ^(.*)(install.php|LocalSettings.php|\.git) { deny all; }

location ~* \.php$ {
        #set $https "off"; 
        #if ($scheme = https) { set $https "on"; }
        #fastcgi_param HTTPS $https;

        try_files       $uri    @404;
        fastcgi_param   GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param   SERVER_SOFTWARE    nginx;
        fastcgi_param   QUERY_STRING       $query_string;
        fastcgi_param   REQUEST_METHOD     $request_method;
        fastcgi_param   CONTENT_TYPE       $content_type;
        fastcgi_param   CONTENT_LENGTH     $content_length;
        fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
        fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
        fastcgi_param   REQUEST_URI        $request_uri;
        fastcgi_param   DOCUMENT_URI       $document_uri;
        fastcgi_param   DOCUMENT_ROOT      $document_root;
        fastcgi_param   SERVER_PROTOCOL    $server_protocol;
        fastcgi_param   REMOTE_ADDR        $remote_addr;
        fastcgi_param   REMOTE_PORT        $remote_port;
        fastcgi_param   SERVER_ADDR        $server_addr;
        fastcgi_param   SERVER_PORT        $server_port;
        fastcgi_param   SERVER_NAME        wiki.mysite.com;

        fastcgi_pass    unix:/var/run/docs.php-fpm.socket;
        fastcgi_index   index.php;
}

# this will secure the MediaWiki uploads against arbitrary PHP injection attacks:
location /images/ {
        location ~.*\.(php)?$ {
                deny all;
        }
}


location @404 {
        return 404;
        break;
}

location / {
        try_files $uri $uri/ @mediawiki;
}

location @mediawiki {
        rewrite ^/([^?]*)(?:\?(.*))? /index.php?title=$1&$2 last;
}

}

[edit] Enable Ngnix and PHP-FPM

Now, let's enable nginx to serve our site, and also be sure to enable php-fpm:

# cd /etc/nginx/sites-enabled
# ln -s ../sites-available/wiki.mysite.com wiki.mysite.com
# rc-update add nginx default
# rc-update add php-fpm default
# rc
 * Starting PHP FastCGI Process Manager ...                                                            [ ok ]
 * Starting nginx ...                                                                                  [ ok ]
#

[edit] Download MediaWiki

We're getting close. Now, head to http://www.mediawiki.org/wiki/Download and copy the link address for the latest version of MediaWiki, currently 1.19.1 at the time this was written. Let's download the archive to /var/tmp:

# cd /var/tmp
# wget http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.1.tar.gz

[edit] Extract MediaWiki

We now have all the Web, database and email infrastructure enabled that we need. Heading to the IP address of your server should result in a 404 - Not Found error in your Web browser. Time to extract and configure MediaWiki itself:

# su docs
$ cd /var/tmp
$ tar xvf ./mediawiki-1.19.1.tar.gz
$ mv mediawiki-1.19.1 ~/public_html

[edit] MediaWiki from GIT

Alternatively, we can download the code from the git repository:

# su docs
$ cd ~
$ git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git public_html

Specific stable versions of MediaWiki are tracked using 'tags'. These are analogous to the tarball releases. We can see the versions available with:

$ cd public_html
$ git tag -l | sort -V

To use a specific tag (1.19.1):

$ git checkout 1.19.1

[edit] Initial Web Config

You will now be able to load the URL of your server in your Web browser and configure MediaWiki through the Web user interface. Complete the full installation process and be sure to specify that you are using XCache for caching. Once you go through this process, the Web installation process will provide you with a LocalSettings.php file, which you should place in /home/docs/public_html. The LocalSettings.php file can also be manually edited and used to enable MediaWiki features and extensions.

[edit] Tips and Tricks

[edit] ArticlePath

By default, MediaWiki pages will have a URL of wiki.myserver.com/index.php?title=PageName. With a few minor tweaks, you can tell MediaWiki to use wiki.myserver.com/PageName instead. Here's how. Open up LocalSettings.php and search for the $wgScriptPath line. This part of the config will look like this:

$wgScriptPath       = "";
$wgScriptExtension  = ".php";

Change this part of the file to look like this:

$wgScriptPath       = "";
$wgArticlePath      = "/$1";
$wgUsePathInfo      = true;
$wgScriptExtension  = ".php";

The old-style URLs will still work, but the shorter more intuitive URLs will now be used for all wiki links.

[edit] $wgSpamRegex

You may find that your wiki is the target of spammers. The easiest way to combat spam is to set $wgSpamRegex in LocalSettings.php, like so:

$wgSpamRegex = "/badword1|badword2|badword3/i"

This will perform a case-insensitive match against the bad words and block anyone from saving edits that contain these words.

[edit] DNS Blacklist

MediaWiki also has the ability to consult a DNS blacklist to prevent known forum and wiki spam sites from performing any edits on your wiki. To enable this capability, add the following to LocalSettings.php:

$wgEnableDnsBlacklist = true;
$wgDnsBlacklistUrls = array( 'xbl.spamhaus.org', 'opm.tornevall.org' );

You may notice a significant decrease in spam posts.

[edit] $wgServer

Here is an important tip -- the $wgServer variable in LocalSettings.php defines the URL of your MediaWiki installation. MediaWiki will encode this within its HTML replies, which means that the Web browser from which you are accessing MediaWiki must be able to reach your server using this address, or pages will not display. This is not a security feature in any way, but a configuration issue. For example, if $wgServer is set to 10.0.1.128, then the only systems that will be able to access your MediaWiki installation are those for which 10.0.1.128 resolves to your MediaWiki installation. The same is true of non-IP $wgServer entries like wiki.mysite.com. If you are setting up a test wiki, you may need a temporary entry in a desktop's /etc/hosts file so that it can interact with the wiki properly before DNS is set up.

[edit]

If you want to change the wiki logo, edit LocalSettings.php and replace $wgLogo with the location of the image you want to use:

$wgLogo = "image.png"
Note: The above references the file image.png in the directory /home/docs/public_html