Colin Charles Agenda

We’ve migrated some services from a machine, to another. The architecture of these machines, and directory structures are completely different. So I’ve played Joe Random Sysadmin.

MediaWiki is completely configured from LocalSettings.php. It does not have any configuration data stored in the database, so editing the LocalSettings.php file is really all you need to do. One document you want to read, in case the LocalSettings.php configuration is not hard-wired in your brain is the documentation on LocalSettings.php. Items you would likely need to change:

• $IP - where on disk, MediaWiki is installed
• $wgScriptPath - a lot of things depend on this, and if you’re making a change in Apache, I seriously suggest paying attention to this one. I have installed MediaWiki into a directory such that its called w/. There’s a RewriteRule for this, so $wgScriptPath is now set to /w.
• $wgUploadDirectory - wherever this is, make sure its writeable by the web-server (let the directory be owned by www-data on a Debian system, for instance).

Everything else is pretty kosher, you don’t actually need to change much more than that. I found that using $wgCacheEpoch was really very handy, when actually testing MediaWiki. $wgCacheEpoch=”date +%Y%m%d%H%M%S”; (well, get that value from your shell, trivial to do in vim).

Now, on to Apache. Make sure the RewriteEngine is on (read more about mod_rewrite). The rewrite rule that I have in the configuration is:
    RewriteRule ^/wiki(/(.*))? /w/index.php$1

That basically ensures we get rid of the ugly index.php in MediaWiki URLs and we get sensible domain.name.com/wiki/PageTitle. When faced with problems, ensure you’re getting the RewriteLog. This is done via:
    RewriteLog /var/log/apache2/rewrite.log
    RewriteLogLevel 3

Now, to debug, get intimate with rewrite.log.

(2) init rewrite engine with requested uri /wiki/Contributing
(3) applying pattern ‘^/wiki(/(.*))?’ to uri ‘/wiki/Contributing’
(2) rewrite ‘/wiki/Contributing’ -> ‘/w/index.php?/Contributing’
(3) split uri=/w/index.php?/Contributing -> uri=/w/index.php, args=/Contributing
(2) local path result: /w/index.php
(2) prefixed with document_root to /data0/forge/work/w/index.php
(1) go-ahead with /data0/forge/work/w/index.php [OK]
(2) init rewrite engine with requested uri /data0/forge/work/w/skins/monobook/main.css
(3) applying pattern ‘^/wiki(/(.*))?’ to uri ‘/data0/forge/work/w/skins/monobook/main.css’

My real problem was there, where document_root was getting a prefix to the actual path. Which as we all know, is easily fixable in LocalSettings.php. And voila! that’s your Apache+MediaWiki issue solved. Now, everything just loads.

Another useful debugging tool, besides the access and error logs, is also the Firefox Page Information (Ctrl+I). You can also see what’s being loaded, and how.

Incidentally, I hopped on to #apache on freenode, only to see many a question being asked about mod_rewrite. I think there’s clearly a big opportunity here, business wise, for good sys-admins. Master Apache.

Technorati Tags: apache, mediawiki, mod_rewrite, rewritelog, localsettings.php

One interesting feature of OpenOffice.org 2.3 is its Export to MediaWiki functionality. Its simply, a File -> Export, give it a filename, and select MediaWiki. Automatically, you have a .txt file, that you can paste directly into MediaWiki. There, an offline editor for MediaWiki!

Sadly, this isn’t as well integrated as I’d like. You can’t actually edit an existing MediaWiki document in OpenOffice.org. And it has some limitations, so I suggest taking a read of the Odt2Wiki page (also, the Features page). Like adding images manually, is a bit of a quirk.

However, as someone that writes a lot in a Wiki, I’m pleased to say that I can now do this easily in OOo Writer, and will only have to resort to the built-in Wiki editor, when actually, editing content. Well, here’s to open standards and XSLT transformations.

In a related matter, of editing Wikis, its good to know that Firefox 2 has built-in spell-checking in text area fields, so there’s now no reason to have badly spelt Wiki documents.

Technorati Tags: openoffice.org, mediawiki, odt2wiki, xslt, firefox, spell checking

Well, its been a while since I dirtied my hands in the sysadmin forays. I was wondering why my system was not accepting mail for a domain that clearly pointed to it. Running host just pointed to the mailserver correctly, but when I ran it on the mailserver, there was an IP address mismatch. Thinking back a little, it seems that there was an IP change, just something I’d forgotten about. Oh how the great DNS, comes to bite you in the behind.

MediaWiki these days likes PHP 5 (5.1 being preferred). I’ve discovered why Red Hat Enterprise Linux 4 might suck - they only ship PHP 4.3.9, which is nowhere near as adequate for modern applications. So if I were a corporation and wanted to run the latest greatest Mediawiki on my corporate wiki, I’d be in a bind if I’m on RHEL4. Luckily, this is where the centosplus repository comes into active play - its got a modern PHP, and modern databases.

I’ve gotten out of the Planet game. After running Planet MyOSS for a countless number of years, I’ve just decided that the final migration should happen today - and it did thanks to a Redirect 301 / http://planet.foss.org.my/. Update your bookmarks, feed readers, etc.. as Planet MyOSS now resides at: http://planet.foss.org.my/. (except I checked it just now, and foss.org.my was down… it seems to be regularly down, why?)

Those having to deal with MYNIC, keep in mind that their online forms differ if you’re logging in as the Administrative or Technical contact (the latter is where you get to change DNS servers). And no, its not instant, they say its a 24-hr waiting period.

Back to RHEL/Centos. Why does the Linux Standards Base (LSB) stipulate that servers need to have CUPS installed, to be LSB compliant? I’ll probably talk more about the recent cleanups I’ve been doing at another stage.

Just a quick note to say that the MySQL Forge Wiki looks like the rest of the Forge, and there’s now SpamBlacklist installed. If spam still persists (you know you’re popular when spam’s abound, right?), we might have to install captchas. From an accessibility perspective, I don’t quite like this idea, so lets hope the spam stays under control nonetheless.

Maybe inflammatory, but I don’t quite remember spam on the Fedora Project wiki. Do Python-based wikis suffer less spam (or no spam) than the PHP-based ones? (otherwise known as MoinMoin vs. MediaWiki)