Library Web Chic

Today I got the Mediawiki-based wiki farm I’ve been testing move to our production open source webserver. Overall it was a fairly simple process but I wanted to share a few things that I learned from the experience.

First, being able to do this type of thing quickly and easily relies on being able to create an export of your data from the database that holds your wiki data. To do this in MySQL use the following syntax:

mysqldump -u username -p databasename > database.sql

This will create a file that contains all the data from the database. Take this file a use it to recreate database on another server. To do this you will first need to create the database in MySQL. Then you will import the data using the following syntax:

mysql -u root -p new_database_name < database.sql


Next you will need to setup an account that has access to this database and give it permissions. If you had your wikis running successfully on another server then check out your LocalSettings.php file. It should have the information on your database connection in it.

For example:
$wgDBserver = “localhost”;
$wgDBname = “database_name”;
$wgDBuser = “username”;
$wgDBpassword = “password”;
$wgDBtype = “mysql”;

Here is how you would give the proper permissions to that account in MySQL.

GRANT DELETE,INSERT,SELECT,UPDATE ON new_database_name.* TO ‘username’@localhost IDENTIFIED BY ‘password’;
GRANT DELETE,INSERT,SELECT,UPDATE ON new_database_name.* TO ‘username’@server.domain.edu IDENTIFIED BY ‘password’;

Now your database is properly configured for your wiki. You also need to move the files in your wiki’s directory from the test server to the production server. Secure copy is good for this. If you are running a wiki-farm you will need to follow the same directions as you did to set up on your test server.

Another issue I ran into while setting up the wikis on the production server involved Apache. The production server already has one website running on it. I wanted to run a second seperate website for the wikis. This meant configuring a virtual host in Apache. This is done by editing the vhost.conf file. If you are only running one website on your server or are setting up the server for the first time you probably don’t have one of these files but rather have a file named vhost.template which is a template designed to help you create a functional vhost.conf file. Below is an example configuration for a server running two websites.

    ServerAdmin name@university.edu
    ServerName host.university.edu

    # DocumentRoot: The directory out of which you will serve your
    # documents. By default, all requests are taken from this directory, but
    # symbolic links and aliases may be used to point to other locations.
    DocumentRoot /path/to/website_files



    ServerAdmin name@university.edu
    ServerName host2.university.edu

    # DocumentRoot: The directory out of which you will serve your
    # documents. By default, all requests are taken from this directory, but
    # symbolic links and aliases may be used to point to other locations.
    DocumentRoot /path/to/some_other_website_files

Additionally, I needed to be able to enable SSL for both of websites on the production server. This was necessary because the wikis require that our staff authenticate to our Active Directory server in order to make changes to the wikis. Because of this I need an SSL connections. Technically, you can’t configure SSL for two name-based virtual hosts. This isn’t an issue with Apache its an issue with SSL. For more information see the following article in the Apache Development Center at On LAMP.

Reading the same article, I discovered that there is a way around this. What you need to do is edit your vhost-ssl.conf file (/etc/apache2/vhost.d/vhost-ssl.conf). Below is a sample configuration:

   NameVirtualHost *:443

    
        ServerName www.domain.com
        SSLEngine on
        SSLCertificateFile /path/to/www.domain.com.cert
        SSLCertificateKeyFile /path/to/www.domain.com.key

        DocumentRoot /www/vhosts/domain.com
   

   
        ServerName www.domain.org
        SSLEngine on
        SSLCertificateFile /path/to/www.domain.com.cert
        SSLCertificateKeyFile /path/to/www.domain.com.key

        DocumentRoot /www/vhosts/domain.org
   

Please read the article I link to above carefully so that you understand what you lose by doing it this way. There are issues, but you still might want to do things this way. If you can (it doesn’t create usability issues for your users) run the other SSL site on the same IP address using a different port. This is slightly safer than the method described above because you get standard the “authentication” and encryption benefits of SSL. The shared certificate methods only gets you the encryption benefits but depending on what you are doing that might be okay. You will need to make this decision for yourself though.