Ideas….

First I’d like to say that I know nothing about LDAP. I think its a magical thing that has all our usernames and passwords and just connects to software so I don’t have to maintain user information. This makes LDAP wonderful.

That being said its actually important that you know a little something about LDAP when setting up LDAP and MediaWiki. While this page is helpful:
http://www.mediawiki.org/wiki/Extension:LDAP_Authentication#Explanation_of_options

You really need to know what’s going on with your LDAP. I’d post what I discovered here, but then you’d know how to get into my LDAP server and that would be bad. Needless to say, the best thing to do is copy the options on the page above and then talk to the owner of the LDAP server. They can point you in the right direction.

I’d also like to end this post with a shout out to Brian Gibson for helping me out and teaching me a little something about LDAP.

I’m currently in the process of setting up a MediaWiki farm.  As I stated in my previous post on creating a MediaWiki farm, I have a number of already existing MediaWikis that I need to move into my MediaWiki farm. This post outlines the steps I followed in order to move those existing MediaWikis, into my new farm.

First a Bit of Research

A number of people have posted that its just simply moving the LocalSettings.php file and image directory into the new directory, changing some words in the LocalSettings.php file and voila…it all works.  But this wasn’t the case for me.  I’m not sure if its because of the symlinks or what, but I was running into problems when I did this.

So I did a comparison between a moved wiki and a wiki created within the farm.  Interestingly enough the ones created in the farm were indicating that their $wgScriptPath was /wikis/[wiki-name].  Now when I set up my MediaWiki, I didn’t put it at the web root, instead I put it in a containing directory called wikis (clever huh).  One reason I did this was because I had other things on the server beside MediaWiki (WordPressMU for one) and I didn’t want there to be any conflicts.

Another reason I did this was so that I could set up a DNS to point to the wikis directory.  So if you go to http://wikis.wheatoncollege.edu/domingo you’ll see a wiki that’s part of the farm but its not sitting at the root of a server called wikis.wheatoncollege.edu, its sitting at fred.wheatoncollege.edu/wikis.  So…

• wikis.wheatoncollege.edu = fred.wheatoncollege.edu/wikis
• wikis.wheatoncollege.edu/domingo = fred.wheatoncollege.edu/wikis/domingo

I digress…

So I couldn’t figure out why this change was happening (I’m sure it has something to do with symbolic links) and I honestly didn’t have time to try to figure it out, and besides the web interface install script nicely creates a LocalSettings.php file for you anyway, and no one did a lot (if any) customization for the wikis at my institution.  So why not just use the web based script?

Backing Up a MediaWiki Database

So at this point all I’m doing is really moving over the database.  I could (if I wanted to) not even move the database, I could just connect the current MediaWikis’ databases to the new interface.  You can do this by entering in all the information that you used before into the web based install script.  But I don’t like the names my databases were given :) (ok that’s not the real reason…the real reason is so that i can keep the old ones running for a day without it affecting the new one)

So I did a MySQL backup:

mysqldump -u [mysqlrootuser] -p[mysqlrootpassword] --add-drop-table -B > [mysqldumpfile].sql

Note that I’m using the --add-drop-table mysql option.  What does this do? Well when I restore the database, it will look in the existing database and see if the tables already exist.  If they do, it’ll drop them and then re-add them.  If they don’t, it’ll just add them.  This means that essentially its wiping EVERYTHING in your database and replacing it with everything in your backup.  So if there is a table not in your backup that you want to keep…re-run your backup.  Or restore the tables one at a time (this is an option with MySQL).

Now I stated that I wanted to change my database’s names.  If I simply restored the database using:

mysql -u [mysqlrootuser] -p[mysqlrootpassword] < [mysqldumpfile].sql

It would restore with the same name as before.  Now I thought if I ran this command:

mysql -u [mysqlrootuser] -p[mysqlrootpassword] [newdbname] < [mysqldumpfile].sql

It would restore with a different database name, I was wrong.  I’m sure there is a way to do it from the commandline, but I’m in a hurry.  So I opened up the .sql file with TextWrangler (a Mac text editor) and found the database name (it occurs four times in the top part of the file) and changed it (much thanks to Carol Ou for confirming I could do this).  If you do choose to go this route, make sure you have a backup of the .sql file before you edit it.

A couple of quick notes about doing a backup this way:

1. before you restore the database, you’ll need to create the new database (with your new database name).  you can do that with a quick create database [newname]; query.
2. once you restore the database, there will be no MySQL users associated with the database, but there will be MediaWiki users associated with the database.  A MediaWiki user does not equal a MySQL user.  One is so that you can go into the GUI and edit the wiki and the other is so that MediaWiki can write information to the database.  When you run the MediaWiki web install script, it will allow you to create MySQL users for the database.
3. after you restore the database do a quick show tables; query in MySQL to make sure the data was really restored.  doublechecking is always important.

Backing up the Images

The last piece that you’ll want to remember to do is create a backup of the images.  This is simple enough to do, just tar and zip it all up:

tar -cvzpf [backupname].tgz [wikidirectory]/images

At this point you’ll have all of the images in a tarball ready to move into your new wiki’s image directory.

Now On To Moving a MediaWiki into Your Farm

Now that I have a backup of the database and a tarball of the images, I’m ready to move the MediaWiki over.  One thing to note, all my MediaWikis are the same version (yay).  If you have different MediaWiki versions, you’ll probably want to update them before doing the following steps.

1. Create the directory the MediaWiki will live in under that wikis directory you set up (see above).
2. Restore the MySQL database as its new name.  You can do this by:
   

   mysql -u [mysqlrootuser] -p[mysqlrootpassword] [newdbname] < [mysqldumpfile].sql

   Another thing to check is whether or not table prefixes were used when the MediaWiki was originally installed. In my case, one of the MediaWikis did have prefixes; I checked this by running a simple show tables; query in MySQL.

3. Create the symbolic links for the MediaWiki.  You can use my other post on creating a MediaWiki farm if you’re not sure how to do this.  I’ve also created a script that walks the liaisons here at Wheaton through creating the wiki.  Its works…but I could improve it and hopefully I’ll update the file when I do.
4. Move the untar the images directory that you tarred up before.  You’ll want to untar it in the MediaWiki’s directory.  Doing this will move all the images over to the new wiki.
5. Once you create the symbolic links, you’ll want to go to the web install script and run it.  This includes:
   • database name [the new one]
   • database username [you can create a new database user]
   • database password [again you can create a new one]
   • database prefix [only if you entered one for the previous incarnation of the wiki]
   • wiki admin and password [best to use the previous one...if you have it]
6. Finish up the install by moving the LocalSettings.php file into the MediaWiki’s main directory, changing permission on the file, and deleting the config directory.
7. If the LocalSettings.php file was altered for any of the MediaWikis (in my case one was).  Go in and remake those changes.

And voila! MediaWiki moved.

Introduction

I was tasked by my boss to create a MediaWiki Farm.  I thought this would give me the opportunity to learn more about MediaWiki, but believe it or not it also helped me learn more about Mac’s “Unix” flavor.

The purpose of the MediaWiki Farm is so that professors can request wikis for academic/research work from our Research and Instruction Department.  The reason we chose to create a farm was so that we could minimize the amount of work necessary to maintain 5 plus MediaWikis (I don’t want to have to update each and every one’s filesystem each time a new version comes out).

Creating the MediaWiki Farm with Symbolic Links

While poking around on my good friend Google I found a lovely page that described How to Create a MediaWiki Farm using Symbolic Links on Mac OS X.  It was nice because it gave me directions.  But as a former Unix person I assumed some of the directions could be improved upon (silly me).  So I set about creating my MediaWiki Farm.

Below are the directions that I followed and what I learned from the process:

1. Download MediaWiki and unpack it.
   I decided to put everything in a directory named wikis since I have multiple products running on this server. I then asked that the wikis folder be mapped to a new DNS (wikis.wheatoncollege.edu).
2. Create symbolic links from the unpacked MediaWiki to a template directory.
   

   ln -s mediawiki-[version] template

   At first I wasn’t sure why I was doing this that way.  Why not just link everything to the unpacked file system?  After thinking about this I realized that it would be easier to update symbolic links once, not 5, 10, 15 times.  But I have to say I’m still on the fence about this, because of the next step.

3. Create a blank wiki from your template.
   First I created the direcotory the new wiki will reside in.

   cd /Library/WebServer/Documents/wikis
mkdir [newdirectory]
cd /Library/WebServer/Documents/wikis/[newdirectory]


   Another thing to consider is creating the AdminSettings.php file. To do this I renamed the sample file and created a symbolic link for it:

   cd /Library/WebServer/Documents/wikis/template
mv AdminSettings.sample AdminSettings.php
sudo chmod 744 AdminSettings.php

   You’ll also want to edit the AdminSettings.php file and include super user access. This will help you in updating the wiki later on down the road.

   The next thing I did was create a list of all the files in the template directory. This is why I’m still on the fence about not just linking directly; will I have to create a new list every time I update MediaWiki? I’m sure there is a way to automate this, but I don’t have time to work on this now, I’ll do that later.

   Another thing is that Mac works strangely with symbolic links. If I were to do an ln -s mediawiki-[version] [newdirectory] it would link to everything in that directory. And let’s say I go into [newdirectory] and remove one of the files in the directory using rm wiki.phtml for example. The rm wiki.phtml will not only delete the file in [newdirectory], but also the one in the template directory and the one in the mediawiki-[version] directory. I discovered this when I went in and symlinked the template to [newdirectory] using ln -s template [newdirectory]. I ended up having to start over.

   So I created a symlink for each of the files and the subdirectories:

   ln -s /Library/WebServer/Documents/wikis/template/api.php
ln -s /Library/WebServer/Documents/wikis/template/AdminSettings.php
ln -s /Library/WebServer/Documents/wikis/template/api.php5
ln -s /Library/WebServer/Documents/wikis/template/COPYING
ln -s /Library/WebServer/Documents/wikis/template/docs
ln -s /Library/WebServer/Documents/wikis/template/extensions
ln -s /Library/WebServer/Documents/wikis/template/FAQ
ln -s /Library/WebServer/Documents/wikis/template/HISTORY
ln -s /Library/WebServer/Documents/wikis/template/img_auth.php
ln -s /Library/WebServer/Documents/wikis/template/img_auth.php5
ln -s /Library/WebServer/Documents/wikis/template/includes
ln -s /Library/WebServer/Documents/wikis/template/index.php
ln -s /Library/WebServer/Documents/wikis/template/index.php5
ln -s /Library/WebServer/Documents/wikis/template/INSTALL
ln -s /Library/WebServer/Documents/wikis/template/install-utils.inc
ln -s /Library/WebServer/Documents/wikis/template/languages
ln -s /Library/WebServer/Documents/wikis/template/locale
ln -s /Library/WebServer/Documents/wikis/template/maintenance
ln -s /Library/WebServer/Documents/wikis/template/Makefile
ln -s /Library/WebServer/Documents/wikis/template/math
ln -s /Library/WebServer/Documents/wikis/template/opensearch_desc.php
ln -s /Library/WebServer/Documents/wikis/template/opensearch_desc.php5
ln -s /Library/WebServer/Documents/wikis/template/profileinfo.php
ln -s /Library/WebServer/Documents/wikis/template/README
ln -s /Library/WebServer/Documents/wikis/template/redirect.php
ln -s /Library/WebServer/Documents/wikis/template/redirect.php5
ln -s /Library/WebServer/Documents/wikis/template/redirect.phtml
ln -s /Library/WebServer/Documents/wikis/template/RELEASE-NOTES
ln -s /Library/WebServer/Documents/wikis/template/serialized
ln -s /Library/WebServer/Documents/wikis/template/skins
ln -s /Library/WebServer/Documents/wikis/template/StartProfiler.php
ln -s /Library/WebServer/Documents/wikis/template/t
ln -s /Library/WebServer/Documents/wikis/template/Test.php
ln -s /Library/WebServer/Documents/wikis/template/tests
ln -s /Library/WebServer/Documents/wikis/template/thumb.php
ln -s /Library/WebServer/Documents/wikis/template/thumb.php5
ln -s /Library/WebServer/Documents/wikis/template/trackback.php
ln -s /Library/WebServer/Documents/wikis/template/UPGRADE
ln -s /Library/WebServer/Documents/wikis/template/wiki.phtml

   Essentially the reason I’m creating a list is because certain files in the first layer of the directory should not be symlinked (ie. LocalSettings.php and the images directory). So I need to create/copy those files into [newdirectory]:

   mkdir images
sudo chown www:wheel images
cp -R /Library/WebServer/Documents/wikis/template/config .
sudo chmod a+w config

   Ok now we have the file system for a new wiki set up. Next we need to create the database piece.

4. Create the Database for the MediaWiki
   So in the document on How to Create a MediaWiki Farm on Using Mac OS X, the author creates the database from a shell script. While it seems to make sense, I personally need to know more about how it works before I’ll do this. And I just don’t have the time to do that right now.

   So what I’ll do for now is go to the wiki’s start page and follow the instructions there. Simple enough.

5. Move the LocalSettings.php file and delete the config directory
   The last step is to move the LocalSettings.php file and delete the config directory. Make sure that when you move the LocalSettings.php file that you’re moving it to the full path name, otherwise if you do a mv LocalSettings.php ../ it’ll end up in the template directory (this is because of the weirdness with Macs and symlinks).

   cd config/
mv LocalSettings.php /Library/WebServer/Documents/wikis/[newdirectory]/
cd ..
rm -rf config

   After you move the the LocalSettings.php file you will need to change permissions on it so that people can’t write or execute the file unless they are the admin user.

   sudo chmod 744 LocalSettings.php

6. Now your MediaWiki is ready to go!

Next Steps for the MediaWiki Farm

My next posts will be on moving a MediaWiki to the farm and updating a farmed MediaWiki with separate databases for each instance of MediaWiki. These topics of are concerned from me since we are currently in an environment where we have multiple outdated MediaWikis being housed in completely seperate installations. I need to end that, and quickly since its a lot of work to maintain multiple MediaWikis.

Also its important to point out that the reason I chose to use separate databases for each instance of MediaWiki is because of our current environment. It is possible to use one database for all of your MediaWikis, you just append tables with a prefix when you do the install. The reason I’ve chosen not to do this is because importing a database as a database and not as tables is significantly easier than renaming all those tables.