Upgrading Mediawiki from 1.6.5 to 1.9.2

I have been running Mediawiki 1.6.5 on a Gentoo server for quite some time. Today I decided that I would perform the upgrade to 1.9.2 -- which has been installed for a while without being configured for use.

The first step that I took was to update my httpd.conf to point to the new wiki location:

#Alias /mediawiki "/usr/share/webapps/mediawiki/1.6.5/htdocs"
Alias /mediawiki "/usr/share/webapps/mediawiki/1.9.2/htdocs"

The next step was to test it out. If I had a large user base or any outside users, I would have enabled the second one without disabling the first and locked my database. I dont have any users other than myself, so I did not worry about this step.

I navigated to the URL of my installation and I received an error about the config directory not being writable. I realized here that I needed to copy by LocalSettings.php from the old installation to the new version.

cp /usr/share/webapps/mediawiki/1.6.5/htdocs/LocalSettings.php /usr/share/webapps/mediawiki/1.9.2/htdocs

After copying the settings file, I visited the URL again and this time I was able to see the content. Now on to the testing phase.

To test my new wiki version, I first navigated around to make sure I could see all of the content -- this worked flawlessly. The next test was to add some content.

After adding some content, I received an internal error that suggested that I add the following line to my LocalSettings.php:

$wgShowExceptionDetails = true;

I added the above line to the end of my LocalSettings.php and I was rewarded with the error message below:

Utf8Case.ser is missing, please run "make" in the serialized directory

Backtrace:

#0 /var/www/fuag.com/htdocs/mediawiki/languages/Language.php(972): Language::getCaseMaps()
#1 /var/www/fuag.com/htdocs/mediawiki/includes/SearchUpdate.php(51): Language->stripForSearch('This will be an...')
#2 /var/www/fuag.com/htdocs/mediawiki/includes/Wiki.php(295): SearchUpdate->doUpdate()
#3 /var/www/fuag.com/htdocs/mediawiki/includes/Wiki.php(277): MediaWiki->doUpdates(Array)
#4 /var/www/fuag.com/htdocs/mediawiki/index.php(49): MediaWiki->finalCleanup(Array, Object(LoadBalancer), Object(OutputPage))
#5 {main}

This was not very clear to me, as there was not serialize directory in my installation. I did some looking around and came up with the following fix, specific to Gentoo:

1. Download new mediawiki from: http://download.wikimedia.org/mediawiki/1.9/mediawiki-1.9.3.tar.gz

curl -C - -O 'http://download.wikimedia.org/mediawiki/1.9/mediawiki-1.9.3.tar.gz'

2. Un-tar in /tmp and copy the serialized directory from the downloaded version to my local copy:

tar xzf mediawiki-1.9.3.tar.gz

cp -a serialized/ /usr/share/webapps/mediawiki/1.9.2/htdocs/

3. Run make in the new directory

make

4. Change permissions on the new directory to match the rest of my stuff in htdocs:

chown -R root:web_devs serialized/

5. Restart apache and it should now work!

Don't forget to comment out the added line in LocalSettings.php so that any end-users don't see your specific error messages.

Now I can remove all of the in-between versions that I have not been using.

primary mediawiki # ll
total 32
drwxrwsr-x 6 root web_devs 4096 Mar  4 15:14 1.6.5
drwxr-xr-x 7 root web_devs 4096 May 23  2006 1.6.6
drwxr-xr-x 7 root web_devs 4096 Jun  8  2006 1.6.7
drwxr-xr-x 7 root web_devs 4096 Sep  3 09:13 1.6.8
drwxr-xr-x 7 root web_devs 4096 Nov 28 23:45 1.7.1
drwxr-xr-x 7 root web_devs 4096 Jan 13 21:15 1.8.2
drwxr-xr-x 7 root web_devs 4096 Jan 19 22:10 1.9.0
drwxr-xr-x 6 root web_devs 4096 Mar  4 16:07 1.9.2
primary mediawiki #

Fedora Core 7 -- Going free?

Fedora Core is one of the most popular free distributions of Linux and is the community version of Redhat Enterprise Linux.

With the pending release of Fedora Core 7, the Fedora project is attempting to merge the two primary repositories; Fedora Core and Fedora Extras. With the merging of these two repositories, the Fedora project is also considering requiring all packages in the repository to be "Free Software". (re: link.)

This change would benefit everybody involved with the Fedora Project. Users of Fedora would know that license restrictions were similar throughout the software available and developers would have an easier time integrating existing software with other packages provided.

Fedora has had a lot of negativity lately around packages not working well together and updates breaking fully functional systems. This change for Fedora Core 7 might improve much of the mess that has been made.

rootkit defense -- not so fast

A recent demonstration at Black Hat DC by Joanna Rutkowska shows how hardware based rootkit defense may not be sufficient when facing an elite hacker. Rutkowska showed how the image of volatile memory as seen by the CPU can be different from the image in memory.

This is significant as it shows that monitoring at the hardware level is not fool-proof and defenders must use a combination of hardware and software monitoring.

Read the article.

Actual implementation of this attack does not seem very likely due to the complexity.

Fun with OpenLDAP, nscd, Cyrus-Imap, and Bind

After updating a server this weekend, I restarted to verify that all services would come back up and that's where the fun started...

The first issue I noticed was that Apache would not start. Nothing, I would issue a restart command:

primary ~ # /etc/init.d/apache2 restart

and I get no output, just a new prompt. The only problem here is that nothing is listening on port 80 or 443 and there are no processes running owned by apache.

primary ~ # netstat -anp --inet | egrep '80|443'

primary ~ # ps -eaf | grep apache

Nothing...

From here, I notice that bind isn't running and my email is getting queued up in postfix and not being delivered to my Cyrus-IMAP server. I see a lot of messages like this:

master[17957]: process 25160 exited, signaled to death by 13

...and...

Mar  2 14:53:43 primary master[15457]: process 15228 exited, signaled to death by 13
Mar  2 14:53:43 primary master[15457]: service imaps pid 15228 in READY state: terminated abnormally
Mar  2 14:53:43 primary master[15457]: process 15229 exited, signaled to death by 13
Mar  2 14:53:43 primary master[15457]: service imaps pid 15229 in READY state: terminated abnormally
Mar  2 14:53:43 primary master[15457]: process 15230 exited, signaled to death by 13

...and...

Mar 2 14:53:43 primary master[15457]: service lmtpunix pid 15318 in READY state: terminated abnormally
Mar 2 14:53:43 primary master[15457]: process 15319 exited, signaled to death by 13
Mar 2 14:53:43 primary master[15457]: service imaps pid 15319 in READY state: terminated abnormally
Mar 2 14:53:43 primary master[15457]: process 15320 exited, signaled to death by 13

At this point, I'm at a loss as to what is wrong and I start checking config files -- although this doesn't make a lot of sense since I didn't change any config files...(I do it anyway).

After a few hours of troubleshooting, I've re-installed Apache, Cyrus, Bind and tried different versions of each. I ended up getting Bind to work after compiling it without thread support, although this is not a good thing, as it means something else is wrong. I'm getting pretty frustrated without a working IMAP server and beginning to reconsider my decision to go with Cyrus in the first place.

Well...to make a long story short, it turns out that a few days prior to the updates, I had disabled nscd on this host to see how my OpenLDAP server would stand up to the increased load resulting from no caching. This did not seem to cause any problems and I had made this change persistent. Anyway, after searching around on the web for a while I discovered that another person had a similar issue with Cyrus where it would not start and it was due to an LDAP server being unavailable.

It turns out that if nscd is not available when Cyrus starts, and a multi-threaded bind, and Apache with my configuration, and the system is using LDAP for authentication, then these applications will not startup and run normally.

Big LESSON LEARNED for me -- always document changes, even at home on home servers, and make sure you restart the system after making big changes to verify that they don't affect other daemons. I learn this lesson about once a month on a new server, maybe this time it will persist.