Colin Charles Agenda

Do you use mod_auth_mysql, the Apache module that allows authentication of users to happen through a MySQL database?

If so, the nice folk at Automattic (makers of fine blogging software like Wordpress) have released a patched version that works with phpass.

With this, you can now have single sign on (SSO), with authentication against a WordPress blog (or bbPress forum). Note that WordPress (in 2.5 and later), doesn’t use MD5 hashes to store passwords any longer; instead they are salted and hashed with the phpass library. The Automattic folk use this to provide SSO for Trac and Subversion.

Read Barry’s announcement, and grab the patched mod_auth_mysql.

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