MediaWiki:Config

Some configuration notes about our installation.

=Apache=

Note that subversion needs Apache2 to run properly. We use the standard install from RedHat. The apache2 server (httpd) is stopped started and restarted as follows:

/etc/rc.d/init.d/httpd stop /etc/rc.d/init.d/httpd start /etc/rc.d/init.d/httpd restart

The Apache configuration file is located at /etc/httpd/conf/httpd.conf.

The only modifications done were:


 * AcceptPathInfo to beautify MediaWiki's URLs:
 * 1) AcceptPathInfo is required for the nice URLs in the wiki so that
 * 2) requests to /wiki/Page send to /w/index.php?page=Page

AcceptPathInfo on

Alias /wiki /var/www/html/w/index.php Alias /index.php /var/www/html/w/index.php
 * Two aliases to beautify Mediawiki's URLs
 * 1) Aliases for the wiki to get nice URLs

=PHP= The standard PHP install from RedHat is just fine too although we also need php-mysql for MediaWiki (see the section on MySQL below). To speed-up the websites, a PHP cache program (eaccelerator) has been installed. This is described below.

=Subversion=

subversion.conf
The subversion RPMs were downloaded from the subversion website. A copy of the relevant RPMs is still stored in /root/RPMs.

The configuration of the Apache server for subversion is kept in the file /etc/httpd/conf.d/subversion.conf:

LoadModule dav_svn_module    modules/mod_dav_svn.so
 * 1) Needed to do Subversion Apache server.

LoadModule authz_svn_module  modules/mod_authz_svn.so
 * 1) Only Needed if you decide to do "per-directory" access control.


 * 1) Direct access to the repositories in /home/subversion #
 * 1) Direct access to the repositories in /home/subversion #

 DAV svn SVNParentPath /home/subversion

AuthzSVNAccessFile /etc/svn-rules
 * 1) Access control policy


 * 1) Require a valid user

Require valid-user
 * 1)   Satisfy Any


 * 1) How to authenticate a valid user
 * 2) (they are stored in /etc/svn-users)

AuthType Basic AuthName "Subversion repositories" AuthUserFile /etc/svn-users



The repositories are in /home/subversion (and not in /var/www/html). They belong to the apache user. The access rules are in <t>/etc/svn-rules</tt> and the users in /etc/svn-users</tt>. Note that both files belong to the apache</tt> user. We require authentification for everybody (i.e. there is anonymous read access). This is something that we might change in the future.

Creating new repositories
To create a new repository, log in as apache</tt>, create a new directory in /home/subversion</tt> with the right name and then use svnadmin</tt> to make this directory a subversion repository:

su apache cd /home/subversion mkdir newproject svnadmin create newproject

Managing users
The password file is /etc/svn-users</tt> and belongs to the apache</tt> user. To create new users, log in as apache</tt> and use the htpasswd</tt> command. Basically:

htpasswd /etc/svn-users newuser     # to add a new user htpasswd -D /etc/svn-users olduser  # to delete an old user htpasswd /etc/svn-users existinguser # to change the password of an existing user

We keep a log of all subversion users in the root account of source (/root/</tt>). Use open.sh</tt>, enter the key and then look at the USER-tmp</tt> file. To close it, use close.sh</tt>.

Tweaking access rules
The access rules are in /etc/svn-rules</tt>. This file belongs to the apache</tt> user. The syntax is very simple and almost self-explanatory. Refer to the Subversion RedBook for details.

=WebSVN= WebSVN is installed in /var/www/html/websvn</tt>. It is acually a working directory of the WebSVN trunk. For some reason, newer updates do not seem to work anymore so be careful. The configuration file is <tt>/var/www/html/websvn/include/config.inc</tt>. Not much has been changed from the default:

$config->setEnscriptPath("/usr/bin/"); $config->setSedPath("/bin/"); $config->parentPath("/home/subversion"); $config->setTemplatePath("$locwebsvnreal/templates/UOB/"); $config->useAuthenticationFile("/etc/svn-rules"); $config->allowDownload; $config->setMinDownloadLevel(1); $config->useEnscript;

It looks like the WebSVN interface is not used much as it is much more convenient to use a real client. Nonetheless, the RSS and download links are interesting.

=Mediawiki=

Base
MediaWiki is installed in <tt>/var/www/html/w</tt>. It is only a set of php scripts that was copied in this directory.

MySQL
As root: up2date mysql up2date mysql-server up2date php-mysql

It looks like there is an issue with the redHat version of MySQL and some backp scripts provided by MediaWiki. Not a big deal so far as we backup "manuall" but an issue to keep in mind.

The <tt>mysqld</tt> daemon must also be started:

/etc/rc.d/init.d/mysqld start

Apache
See main section above.

LocalSettings.php
The MediaWiki configuration is kept in <tt>/var/www/html/w/LocalSettings.php</tt>. The modifications are fairly straightforward except maybe creating custom groups (see below).

Uploads
$wgUploadPath      = "/uploads"; $wgUploadDirectory = "/var/www/html/uploads"; $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf' );
 * 1) Upload files in /var/www/html/uploads
 * 1) Control the file extensions

MySQL
Deatils of the MySQL database used by the wiki: $wgDBserver        = "localhost"; $wgDBname          = "wikidb"; $wgDBuser          = "wikiuser"; $wgDBpassword      = "rnk635%1"; $wgDBprefix        = "";

Image support
$wgEnableUploads               = true; $wgUseImageResize              = true; $wgUseImageMagick = true; $wgImageMagickConvertCommand = "/usr/bin/convert";
 * 1) To enable image uploads, make sure the 'images' directory
 * 2) is writable, then uncomment this:

LaTeX support
$wgUseTeX                      = true; $wgMathPath        = "{$wgUploadPath}/math"; $wgMathDirectory   = "{$wgUploadDirectory}/math"; $wgTmpDirectory    = "{$wgUploadDirectory}/tmp";
 * 1) If you have the appropriate support software installed
 * 2) you can enable inline LaTeX equations:

User rights
$wgGroupPermissions['*']['createaccount'] = false;
 * 1) Anonymous users cannot create accounts

$wgGroupPermissions['*']['edit'] = false; $wgShowIPinHeader = false; # For non-logged in users
 * 1) Remove editing and talking right from anonymous users

Email setup

 * 1) SMTP server

$wgSMTP = array( "host" => 'smtp-srv.bris.ac.uk',  "IDHost" => 'smtp-srv.bris.ac.uk',  "port" => "25",  "auth" => false,  #"username" => user,  #"password" => password  );

This will probably break sometimes in the future when the University pushes everybody to use their authentified SMTP server. We will have to find another solution then.

Custom groups
Creating custom groups is done in four steps:

Create a new namespace
In <tt>LocalSettings.php</tt>, define a new namespace number and it's associated "Talk" namespace: $wgExtraNamespaces = array(100 => "GENIE",            101 => "GENIE_Talk",             );

$wgNamespacesToBeSearchedDefault = array(       NS_MAIN           => true,        GENIE             => true, );

Create a new group
Create a new group and associate a right to it in <tt>LocalSettings.php</tt>: $wgGroupPermissions['genie']['viewgenie'] = true;
 * 1) Create the genie group and associate the viewforbidden right to it.

Associate the group and the namespace
This is done by editing the php in <tt>includes/Title.php</tt>. Basically, when a page in a given namespace is requested, we check that the group has the relevant credentials:

/**        * Can $wgUser read this page? * @return boolean * @access public */       function userCanRead { global $wgUser;

if( $wgUser->isAllowed('read') ) { if( $this->getNamespace == 100 ) { if( $wgUser->isAllowed('viewgenie') ) { return true; } else { return false; }                       } else { return true; }               } else {

Create content in the new namespace
Now the hidden/protected pages need to be created in the new namespace so use the following syntax: <tt>http://source.ggy.bris.ac.uk/wiki/NAMESPACE:New_Page</tt>

Extras requirements

 * Adding images needs ImageMagick support (<tt>up2date imagemagick</tt>)
 * Latex support needs
 * ImageMagick (see above)
 * tetex-latex (<tt>up2date tetex-latex</tt>)
 * tetex-dvips (<tt>up2date tetex-dvips</tt>)
 * ocaml (rpm in <tt>/root/RPMs/</tt> folder but requires tcl and tk, both available through up2date.
 * then, you need to type make in the <tt>math/</tt> directory to create the executable.

=eaccelerator= As Mediawiki is quite CPU intensive, it is very advantageous to cache the php scripts in compiled form so that execution is faster. This is done on source via the eaccelerator program. The speed-up is very impressive.

Instalation
Download the right RPM (Redhat EL3, x86) from. One copy (<tt>php-eaccelerator-4.3.2_0.9.3-4.1.el3.rf.i386.rpm</tt>) has been saved in <tt>/root/RPMs/</tt> on <tt>source</tt>. Install the RPM, as root:

cd /root/RPMs rpm -i php-eaccelerator-4.3.2_0.9.3-4.1.el3.rf.i386.rpm

That's it! You need to restart <tt>httpd</tt> though: /etc/rc.d/init.d/httpd restart

Configuration
The configuration options are kept in <tt>/etc/php.d/eacceletator.ini</tt>.

Eaccelerator is switched on and configuration is fine by default (i.e. no editing of the file). If you modify this file, you probably need to to restart <tt>httpd</tt> too.

Statistics
To check that eaccelerator is actually used, point your browser to the check_php.php script. eaccelerator should be mentionned somewhere next to the Powered by Zend logo. The interface is definitely snappier so you'd notice if it's not there.

To see what is actually cached by eaccelerator, point your browser to the check_eaccelerator.php script. Note that eaccelerator should cache Mediawiki and WebSVN scripts.

=cvs2svn=

To convert a CVS repository into a Subversion dumpfile: cvs2svn --dumpfile=<path/to/dumpfile> <path/to/cvs-repos>

Note: <tt>cvs2svn -help</tt> and <tt>--dry-run</tt>

To load a dump file into a new repository: svnadmin load <

=Backup strategy= <tt>source.ggy.bris.ac.uk</tt> (the machine) is fully backed up by the departmental backup system. However, we felt that because of the importance of what is hosted on this machine, we should be extra cautious and back it up by another mean too.

Requirements
The following need to be backed up on <tt>source</tt>:
 * subversion repositories (daily incremental back-up and weekly full backup)
 * MediaWiki MySQL table (daily back-up)
 * MediaWiki uploads directory (daily back-up)

On <tt>source</tt>
<tt>cron</tt> jobs run on <tt>source</tt> for the <tt>apache</tt> user. They run a series of scripts (bash and perl) located in <tt>/home/apache/script/</tt> which perform the relevant backup duties and store it in <tt>/home/apache/svn-backup</tt> and <tt>/home/apache/mysql-backup</tt>

On source2 they run as root and backup to <tt>/home/root/mysql-backup</tt> etc.

On <tt>dylan</tt> <tt>eocene</tt>
JP has a series of <tt>cron</tt> jobs running on <tt>dylan</tt> which copy the backed-up content on <tt>source</tt> straight to <tt>/gsa25/rgg00s/ggjpr/source-backups</tt>

Now an rsync with <tt>eocene</tt> by Gethin to <tt>/home/ggdagw/source-backup</tt>.