First I always recommend keeping up the old installation while you’re migrating and not taking it down for at least a week or two (perhaps even longer if you’re paranoid).  That way if you need to, you can always go back.

Here are the steps that I followed:

1. I installed a blank MDID2 to make sure that I had everything I needed on the server to make MDID2 work.  When installing MySQL I made sure that it was the same version as the old server to ensure that MySQL weirdness didn’t interfere with the installation.  For instructions on installing MDID2, I used the MDID wiki’s instructions.  I actually ran the system and had our Visual Resources Curator test things out to see if it worked like he expected a fresh MDID would work (because lets face it, I don’t know nearly as much about the system as he does).
2. Once our Visual Resources Curator gave me the thumbs up I mounted, as a network drive, the directory on the old server that had the MDID2 files and images.  I then copied ALL of the files over to the new directory on the new server.  I then went home for the night…because that’s going to take a while.
3. The next morning go into the config.xml file (found at the root level of mdid2) and change the information in the file so that it’s settings match your new servers configuration.  Most likely all you’ll need to do is change the location of the image files or the username and password of the database, but you should check over the rest of the file just to be safe.
4. Create a mysqldump of the old database using: mysqldump -u mdid2 -p -q mdid2 > mdid2export.sql I then moved the dump over to the new server.  Keep in mind that your MySQL command may be different if:
   • you don’t use passwords
   • have a different MySQL user set to run mdid2
   • your mdid2 user doesn’t have privileges to do this type of command.
5. Once I got the dump onto the new server I opened the dump file in notepad and did a find replace.  In my case on the old server mdid was on the d drive and on the new server it was going to be on the c drive.  So I had notepad go through the file and find all instances of d:\\mdid2\\ and replace it with c:\\mdid2\\.  Again this may be different for you, depending on how your installation is set up.  Once this started I went to go get myself some tea, because this was going to take a bit (although not as long as moving all those files over).
6. Now that the database file has been “fixed” you’re ready to import the database.
   1. Go into MySQL’s commandline and drop the existing mdid2 database: drop database mdid2;
   2. Recreate the mdid2 database: create database mdid2; The reason you just destroyed and recreated the database was because the database has structure and data attached to it based on the work you did in step 1, you want to overwrite that.
   3. import the mysql database by going to Window’s commandline and doing: mysql -u mdid2 -p mdid2 < mdid2export.sql
7. This step is key to avoiding any indexing weirdness you may see.  Trust me, I did these steps multiple times before finally figuring this out (thanks to the mdid listserv).  You’ll need to go in and delete all instances of the _ftindex directory in the image directory.  Go through each and every directory in the mdid2/image directory to get rid of this folder.  If you don’t you’ll find some weirdness in the indexing of data.  Don’t worry this directory will be rebuilt once you start up mdid2.
8. Start up IIS and wait a bit for the full text index to finish up.  If you want, you can log in to your newly migrated MDID2 and click background transactions to see if the indexing process is still running (it should be the second thing in the list).
9. Last but certainly not least, have your Visual Resources Curator check the system over and give their stamp of approval.  Without that, you might as well be dead in the water.

Like I stated above, this is the process that I followed.  Everyone’s systems are set up differently, but hopefully this can act as a guide of sorts to whatever poor schmuck needs to do something similar (ie me…so I don’t forget like I always seem to).

Share/Save

So I got my text message at 12:30am.  It confused me but then I woke up a bit.  It was a good thing I wrote the notes I did in my previous post, because trust me, I could have never come up with that stuff on my own right now.

First thing I did was run top.  CPU was at 100.1% (way to work hard server) for the mysqld process.  Second thing I did was check the slow query log.  There were actually a few slow queries, the first ones are still puzzling me.  Basically these were checking a table that had a whole lot of rows of data, the data didn’t need to be stored in those tables, i removed the data, and I stopped logging that data in the tables.  I probably won’t see those queries ever again. But this doesn’t really matter, those queries weren’t the ones hanging up the system, they were only take 11 t0 17 seconds to run.

I did see the last query that ran though, and this seems to be part of the problem, but not the query that was actually causing mysqld to hang. This query was:

INSERT INTO stats_daily (stattype, timeend, courseid, roleid, stat1, stat2)

SELECT ‘enrolments’, timeend, courseid, roleid, COUNT(DISTINCT userid), 0
FROM (
SELECT 1251691200 AS timeend, pl.courseid, pl.roleid, pl.userid
FROM (
SELECT DISTINCT ra.roleid, ra.userid, c.id as courseid
FROM role_assignments ra JOIN context ctx
ON ctx.id = ra.contextid
CROSS JOIN course c
JOIN role_capabilities rc
ON rc.roleid = ra.roleid LEFT OUTER JOIN course_categories cc1
ON cc1.id = c.category
WHERE ((rc.capability = ‘moodle/course:view’ )
AND rc.permission = 1 AND rc.contextid = 1
AND (ctx.contextlevel = 10
OR (c.id = ctx.instanceid AND ctx.contextlevel = 50) OR (cc1.id = ctx.instanceid AND ctx.contextlevel = 40)))
) pl
) inline_view
GROUP BY timeend, courseid, roleid;

This query took a total of 41 seconds to execute.  I’m assuming that the next query after this was the one that brought the house down.  I saw the beginning of this when I went into mysql and did a show processlist:

+——-+————+———–+——–+———+——+————–+——————————————————————————————————+
| Id    | User       | Host      | db     | Command | Time | State        | Info                                                                                                 |
+——-+————+———–+——–+———+——+————–+——————————————————————————————————+
| 45654 | moodleuser | localhost | moodle | Query   | 1776 | Sending data | UPDATE stats_daily
SET stat2 = (SELECT COUNT(DISTINCT ra.userid)
|

The full query finally showed up in my query log once I killed the process.  Here it is in case you’re curious:

090902  0:01:29      45654 Query       UPDATE stats_daily
SET stat2 = (SELECT COUNT(DISTINCT ra.userid)
FROM role_assignments ra JOIN context ctx
ON ctx.id = ra.contextid
CROSS JOIN course c
JOIN role_capabilities rc
ON rc.roleid = ra.roleid LEFT OUTER JOIN course_categories cc1
ON cc1.id = c.category
WHERE ra.roleid = stats_daily.roleid AND
c.id = stats_daily.courseid AND
((rc.capability = ‘moodle/course:view’ )
AND rc.permission = 1 AND rc.contextid = 1
AND (ctx.contextlevel = 10
OR (c.id = ctx.instanceid AND ctx.contextlevel = 50) OR (cc1.id = ctx.instanceid AND ctx.contextlevel = 40))) AND
EXISTS (SELECT ‘x’
FROM log l
WHERE l.course = stats_daily.courseid AND
l.userid = ra.userid AND l.time >= 1251604800  AND l.time  < 1251691200))
WHERE stats_daily.stattype = ‘enrolments’ AND
stats_daily.timeend = 1251691200 AND
stats_daily.courseid IN
(SELECT DISTINCT l.course
FROM log l
WHERE l.time >= 1251604800  AND l.time  < 1251691200)

I also saw a whole bunch of other queries locked, waiting for this query to run.  I thought that perhaps switching the tables over to InnoDB rather than MyISAM might help alleviate the problem, but the truth is this appears to be a “the query is just ridiculous” problem rather than a “InnoDB is better at performance” problem.

So at anyrate I looked around and it seems this is a problem with the stats that Moodle keeps about itself.  Apparently in version 1.6 people had this problem a lot (because stats was new).  Basically I enabled stats because someone thought it was a good idea and I didn’t bother to consider how resource intensive this process could be (note to self: be a better sys admin and read documentation when someone thinks something might be useful).  I changed some settings in the stats configuration page and hope that this reduces the load and processing time of the stats query.  We’ll see if this fixes my problem.

Also, the amount of time I spent on this right now totally makes up for leaving work an hour and a half early to go meet my brother in law the electrician so he could replace outlets and light fixtures (my $12 sconces from lowes look quite lovely).

Share/Save

Recently Nagios started informing me that HTTPS was going down infrequently (but started to become more frequent).

***** Nagios  *****
Notification Type: PROBLEM
Service: HTTPS
Host: Moodle Server
Address: 123.456.78.912
State: CRITICAL
Date/Time: Fri Aug 28 01:06:50 EDT 2009
Additional Info:
CRITICAL – Socket timeout after 10 seconds

What was strange was that HTTP wasn’t going down.  I felt like Nagios was lying to me so I figured I would have to wake up late at night (early in the morning?) and catch it lying to me.  To do this I decided I’d try to figure out if my cellphone had an email to associate to text messaging.  Mine wasn’t working so I had to talk to Sprint about it.

In the mean time though, it was still going down.  Luckily last night at 4am I randomly woke up. I ran downstairs (imagine kid at Christmas…but like a reverse Christmas) and fired up the laptop.  Sure enough when I went to the Moodle homepage I saw this:

Error: Database connection failed.

It is possible that the database is overloaded or otherwise not running properly.

The site administrator should also check that the database details have been correctly specified in config.php

Now in hindsight, there were so many things I could have done at this point.  But it was 4am and my house was freezing so I made some mistakes.  The first thing I did was restart Apache.  It appeared to be running and the restart didn’t throw any errors, but it didn’t fix the problem either.  Next I “turned off SSL”.  I was able to get to the error page without the HTTPS so I determined at this point that Nagios clearly was lying to me, something else was wrong (p.s. i am thankful to Nagios for telling me that something was wrong).  So then I decided that maybe it was a database problem.  I went into MySQL and was able to access the Moodle database and do a “show tables;”.  So I thought at that point I should restart MySQL, in hindsight there are so many other things I should have done first, but I will document those below.  A restart of MySQL fixed the issue.

So what will I do next time (and yes…there will be a next time):

1) run top on the server: See if MySQL is hogging the CPU.  This could lead you to a number of options.

2) check the mysql-slow-queries.log: I set up the mysql option log-slow-queries.  this in conjunction with the long-query-time option will log any query that takes over a certain amount of time (default is 10s).

3) show mysql processlist: If you haven’t set up the log slow queries option this might also be helpful in determining what mysql is doing.  Here is a brief explaination of show processlist and its companion of kill <processid>.  I also found this handy script that you could set up as part of a cron to kill any runaway processes.

4) query is poorly written: I’ve found a number of reports that MySQL queries are poorly written in Moodle and that these can cause the CPU usage to top out at %100 which causes Moodle to be unusable.  Below are a few Moodle Tracker reports of this:

• http://tracker.moodle.org/browse/MDL-14911
• http://tracker.moodle.org/browse/MDL-19584
• http://tracker.moodle.org/browse/MDL-17051
• http://tracker.moodle.org/browse/MDL-10848

To see if this is the case with your Moodle use the slow query logging (or just the plain old query logging) with a backup of your database to see if you can replicate the problem somewhere else.  If you can the problem is probably the query and maybe you can figure out a way to rewrite the query (or get it rewritten) to see if that fixes the problem.

5) check your persistent db connection: Check to see if you have persistent database connections set up in the Moodle config.php file and in the php.ini file.  If you do, turn it off and see if this solves the problem.  it may be that your connections aren’t closing and they are killing your database regularly.

6) check your max connections: Are the maximum number of Apache connections greater than your maximum number of MySQL connections?  If so that might be a problem.  Basically users could get to the website but then when they go to request something in the database they can’t because the # of connections are taken up.  I have a feeling though that this may be a completely different error than what I was experiencing (people…including myself…really need to take screenshots or document errors better).

7) check your MySQL performance: Perhaps you haven’t configured Moodle right.  Take a look at these performance tuning tips to see if you can get it working better.

8) check your database tables: Stop mysqld and run a check on your Moodle tables.  See if some of the tables are corrupted, if they are fix them.

So if you’re wondering what I’m doing at 4am tomorrow, there’s the list.  Wish me luck.

Share/Save

We have a bunch of placement tests and advising courses and that sort of thing we want our first year students to be enrolled in.  Moodle happens to have a flat file enrollment feature.  Below are the instructions from that enrollment feature:

This method will repeatedly check for and process a specially-formatted text file in the location that you specify. The file is a comma separated file assumed to have four or six fields per line:

*  operation, role, idnumber(user), idnumber(course) [, starttime, endtime]
where:
*  operation        = add | del
*  role             = student | teacher | teacheredit
*  idnumber(user)   = idnumber in the user table NB not id
*  idnumber(course) = idnumber in the course table NB not id
*  starttime        = start time (in seconds since epoch) - optional
*  endtime          = end time (in seconds since epoch) - optional

It could look something like this:

   add, student, 5, CF101
   add, teacher, 6, CF101
   add, teacheredit, 7, CF101
   del, student, 8, CF101
   del, student, 17, CF101
   add, student, 21, CF101, 1091115000, 1091215000

So great, I need to pull a randomly generated number rather than a username in order to enroll students.  So now I need to figure out a way to take a list of usernames in banner and get their corresponding idnumbers in Moodle.

Now if this were a one time thing I would take the lazy man’s way out and I would create a table in the database and do a simple

select table.username, user.idnumber
from table, user
where table.username = user.username;

But I’m going to have to do this every year until we either get rid of Moodle or I leave Wheaton.  Since plans are not in the work for either, I’ll actually do something more substantive.

First I made the decision to use the MySQL select in clause.  For those of you who don’t know, you can do:

select username, idnumber
from user
where username in ('value1', 'value2', 'valueN');

Its pretty useful really.  I can’t really find a MySQL page that talks about the in() clause but I did find a good post in the MySQL lists.  The next thing I had to figure out was how to push a file into a php array.  Again I found a great post on using the file() command to do this.  The only drawback is that when i go to print it’ll just show:

value1 value2 valueN

When that’s not what I want.  I need quotes and commas and crap around it.  So I found another great post that talks about using the implode function to put a php array into an in() clause.  The implode function will allow me to put quotes and what not around each one of the values in the array so it will look like this:

'value1', 'value2', 'valueN'

So now that I have the component parts, all I need to do is create a php page that will let me upload a file, run the query, and retrieve the outfile.  Of course the idea of writing this code makes me tired and since its 5pm I shall just publish this post and write the code tomorrow (hopefully).

UPDATE

I was wrong.  The value is not a randomly generated number, well it is, but its randomly generated by Banner.  In the Banner XML the value is the <sourcedid> for a <person>.

Luckily this randomly generated value is something that we can pull out of Banner using our reporting system.  The value (in our Banner) is gobsrid_sourced_id.  Not sure if it will be the same in your Banner, but hopefully this will put someone on the right track.

My next step is to document how to do all of this in our Moodle Documentation Wiki.  I might do a Jing Video.

Share/Save

Sometimes though, you’re a stupid Sys Admin (read me) and you set up a wiki real quick and think “I won’t forget the password!”. You then decide not to include your email address when creating the wiki account profile. So if you’re that Sys Admin (read me) here are the instructions for retrieving that password:

1. log on to mysql
2. type the following query:
   

   UPDATE user SET user_password = MD5(CONCAT(user_id, ‘-’, MD5(’newpassword‘))) WHERE user_id = uid

3. go back to the MediaWiki page and log in.

And next time don’t think you can remember a password, you can barely remember your name.

Share/Save

1. GD Library — By default the GD library’s aren’t part of the PHP package in Server 10.5.  I was poking around in this Step by Step Installation guide trying to upgrade my PHP library on my server.  Turns out I didn’t need to for various reasons (also the package recommended screwed with my Apache).  So instead i went into my php.ini file and uncommented the line:
   

   extension=php_gd2.dll

   This turned on the GD Library and Moodle looks much better now.

2. MySQL — I was getting a weird error in Moodle under Admin > Server > Environment.
   

   It is required that you store all your data in Unicode format (UTF-8). New installations must be performed into databases that have their default character set as Unicode. If you are upgrading, you should perform the UTF-8 migration process (see the Admin page).

   I thought that was a bit weird cause I installed the database from scratch. But sometimes you just need to do what it tells you to. So I ran the following query:

   alter database moodle collate = utf8_unicode_ci;

   And voila the error went away.

So now my Moodle is a bit happier.  I am of course (like always) recording this so that when I get my new server and I run into these problems again, I can remember what the heck I did.

Share/Save

1. First I tarred up all the files for the directory:
   

   tar cvzf wordpress.tgz wordpress/

    

2. Then I backed up the mysql database:
   

   mysqldump -u root -p wordpress > wordpress.sql

    

3. When you back up a MySQL database it comes out as a simple text file.  You can open it up with a text editor (I have a mac and use TextWrangler).  I then use a simple find and replace in my text editor to find all the old URLs and replace them.  If you’re supper fancy you can use vi (which sometimes I do when I’m really really lazy and don’t want to go into a gui…yes I know that makes me a loser):
   

   :%s/old.url.com/new.url.com/g

    

4. The next thing that I did was move the sql file and the tar file over to my new server.  I then created the database in mysql:
   

   create database wordpress;

   and then imported the mysql export file into the database that I just created:

   mysql -u root -p wordpress < wordpress.sql

   Afterward, I double check that the database really is populated, but that’s because I’m a cautious person.  So I do a really quick:

   use wordpress;
show tables;

   Before moving on.
    

5. I then moved the tar file into the web directory and unzipped it:
   

   tar xvzf wordpress.tgz

   This will unzip all the files and create the wordpress directory.
    

6. Finally you’ll want to go into your wp-config.php file and look at your database settings.  There is a section that reads:
   

   // ** MySQL settings ** //
define('DB_NAME', 'wordpress');    // The name of the database
define('DB_USER', 'wordpress');     // Your MySQL username
define('DB_PASSWORD', 'wordpress'); // ...and password
define('DB_HOST', 'localhost');    // 99% chance you won't need to change this value
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('VHOST', 'no');
$base = '/wordpress/';

   Using this information you’ll want to create a MySQL user according to this information (or you can create any old user and change these values in the wp-config.php file).  The MySQL query to create the user referenced above is:

   grant all privileges on wordpress.* to 'wordpress'@'localhost' identified by 'wordpress';

   So now you have created the same wordpress user that you had on your other wordpressmu site.
    

7. At this point I like to double check that everything worked as planned.  You’ll want to go to your new URL and make sure that everything that was there before is there now.  Also tip:  don’t delete the old wordpressmu site until you’re certain the new one is working properly.

Share/Save

]]> http://rosalynmetz.com/ideas/2009/01/30/moving-wordpress-mu-to-a-new-server/feed/ 2 http://rosalynmetz.com/ideas/2008/12/23/making-moodle-courses-not-enrollable/ http://rosalynmetz.com/ideas/2008/12/23/making-moodle-courses-not-enrollable/#comments Tue, 23 Dec 2008 15:52:13 +0000 Rosalyn Metz http://rosalynmetz.com/ideas/?p=285 What?!? Rosalyn what the heck are you talking about.

I know, I know, my blog’s tag cloud is becoming Moodle heavy. Its true. But the boss man thinks that students shouldn’t be able to enroll themselves into any Moodle class at the drop of a hat. Sadly this makes sense (professors can be very protective of their class information because often times it informs their research). Sigh. So I’m off to make this happen.

So I’ve come up with a few ideas:

1. I can just run a MySQL query every month:
   

   update course set enrollable = 0;

   While yes this will work, how much of a pain will that be. I guess I could create a little script to do it for me. But honestly that’s not a solution that’s a patch.

2. I can try going into moodle/course/edit_form.php and find the line:
   

   $mform->setDefault('enrollable', 1);

   And change it to:

   $mform->setDefault('enrollable', 0);

   Wow Rosalyn you’re genius! Yeah, no, I’m not I just found that in the Moodle Enrollment Plugins forum. A guy named Michael Skwara came up with it.  So I tried it out.  Unfortunately it doesn’t effect (or is that affect) courses I create using the LMB Enrollment Plugin.  You can still enroll yourself into those.  Darn it!  Foiled again.

3. Just change the database schema (oh yeah rosalyn…like that’s just so easy).  I took a look in MySQL and the default for that column is set to 1, so if I set it to 0 perhaps that will make all new courses created with LMB default to not enrollable.  Of course I’m assuming that LMB doesn’t really update things like the enrollable field in the course table (I mean where would it get that information).  So I set about testing my theory.
   First things first, I asked in the forum I referenced above if anyone saw a problem with what I was about to do before I did it. One of the Moodlers, Iñaki Arenaza, said that there shouldn’t be any problem with this. Which is what I suspected, unless of course Moodle goes crazy and revamps their DB schema…which would cause me other headaches.So on to my next portion of the testing, does LMB update the field enrollable or does it just leave it alone. So I installed a fresh Moodle (including the LMB plugin).  From there I logged into the MySQL and changed the default value for the column enrollable by running the query:

   alter table course alter column enrollable set default 0;

   Your query might be different if you are using a prefix for your Moodle tables. I then ran an import using the LMB plug in. After that had finished I logged in using LDAP and tried to enroll myself in a course. And lo and behold I received the message:

   This course is not enrollable at the moment.

   SUCCESS!  So students who aren’t attached to the course in Banner, can’t attach themselves to the course in Moodle.  Professors however can still go in and add students (or delete students) from a course the way they did before.

So that’s my foyer into the world of altering the Moodle database schema in order to make the boss man happy. My next step is to upgrade Moodle so I can take advantage of the fun new features.

UPDATE

I noticed a few people have visited this post recently.  While this fixed worked for me I recommend that you TEST IT OUT FIRST.

Share/Save

]]> http://rosalynmetz.com/ideas/2008/12/23/making-moodle-courses-not-enrollable/feed/ 4 http://rosalynmetz.com/ideas/2008/12/16/upgrading-moodle/ http://rosalynmetz.com/ideas/2008/12/16/upgrading-moodle/#comments Tue, 16 Dec 2008 21:57:55 +0000 Rosalyn Metz http://rosalynmetz.com/ideas/?p=278 I just decided to upgrade Moodle since one of my action items was “Remove the Percentage Column for Outcomes in the gradebook.”  Luckily I sat on this task long enough and lo and behold, the Moodle community did this for me (note to self, try to be more proactive and put things in Moodle Tracker).

So at any rate, I decided to upgrade Moodle.  Here are the steps I have outlined for doing an upgrade such as this:

1. Read the directions on the Moodle Documentation site. These are most useful.  http://docs.moodle.org/en/Upgrading.  Keep in mind that there may be directions specific for your installation or the version that you’re upgrading too.  Which brings me to an excellent point, don’t just follow directions you find on the internet blindly, INVESTIGATE!
2. Create a back up of the MySQL database. Also outlined in the upgrading documentation, but putting it in for good measure.  I just ran the following command:
   

   mysqldump -u username -p -C -Q -e -a moodle > moodle-backup.sql

   Again this command is outlined in the upgrading Moodle documentation, but since these are my notes…I’m putting it here

3. Create a list of the plugins you have installed. If you’re a good systems administrator, you should have all of this somewhere or other…right?  Well some of us don’t.  But you’re going to need this list to make sure that everything you’ve installed gets moved over after you unpacked the new Moodle you’re about to download and install.  Here at Wheaton, I’ve put it on an in house wiki.
4. Move the moodle directory. The directions recommend moving and zipping up the directory.  I personally just move it and then if anything goes wrong I can move it back.  Once everything is said and done I’ll zip it up (and include the mysqldump in that zip file) and store it in the event that something goes wrong farther down the line.  To move the moodle directory:
   

   cd /your/web/directory/
mv moodle moodle-bak

5. Download the Moodle zip file and unpack it in your web directory. The next thing you’ll want to do is download the latest version of Moodle.  Once you’ve done that move it to your web directory and unpack it.  This should create a Moodle directory.
6. Move your config.php file from the moodle-bak directory into the moodle directory. This will essentially transfer your database, server, etc. information over to the new Moodle directory.  You’ll want to go to your Moodle homepage to check out that things went smoothly with this.  You’ll see a button asking you to update, but don’t update your Moodle at this point (you’re still not done).
7. Copy all of your plugins and themes from the moodle-bak directory to the moodle directory. Make sure that when you do this that the correct permissions get moved over.  One way to do this is by using the -p flag.  This will ensure that the directory is copied over as well as the permissions:
   

   cp -pR /path/to/your/plugins /path/to/new/location

8. Visit the admin page for your Moodle and run the update. Your admin page is located at: http://server/moodle/admin.  When you get there you’ll click on a button and the script will update the database; it basically runs itself.  If there is any intervention you need to do, Moodle will let you know.
9. Zip up the old Moodle database and file system. I like to keep these things lying around just in case.  You never know when you’ll want an old version of moodle to play with.

Now that you’ve upgraded you should be a happy camper and get all of the cool new fun features that Moodle has to offer.

Share/Save

]]> http://rosalynmetz.com/ideas/2008/12/16/upgrading-moodle/feed/ 6 http://rosalynmetz.com/ideas/2008/11/18/moving-a-mediawiki/ http://rosalynmetz.com/ideas/2008/11/18/moving-a-mediawiki/#comments Tue, 18 Nov 2008 16:23:34 +0000 Rosalyn Metz http://rosalynmetz.com/ideas/?p=198 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.

Share/Save

]]> http://rosalynmetz.com/ideas/2008/11/18/moving-a-mediawiki/feed/ 0